Backtesting a stock strategy involves testing a trading or investment strategy using historical data to see how it would have performed in the past. It’s a crucial step in the development and validation of any trading strategy before applying it to real market conditions. Here’s why backtesting is important:

• Performance Evaluation: Backtesting allows traders and investors to evaluate the performance of their trading strategies objectively. By analyzing historical data, they can assess how profitable or effective the strategy would have been over a specific period.

• Risk Management: Backtesting helps in identifying potential risks associated with a particular strategy. By analyzing past performance, traders can determine the maximum drawdowns and volatility levels they might encounter during real trading. This information is crucial for managing risk and setting realistic expectations.

• Strategy Optimization: Backtesting provides insights into how different parameters and variables affect the performance of a trading strategy. Traders can optimize their strategies by tweaking these variables to maximize returns or minimize risks.

• Confirmation of Assumptions: Many trading strategies are based on certain assumptions about market behavior. Backtesting allows traders to validate these assumptions by testing them against historical data. If the strategy performs well in backtesting, it lends credibility to the underlying assumptions.

• Decision Making: Backtesting helps traders make informed decisions about whether to adopt, modify, or discard a particular trading strategy. It provides valuable insights into the strengths and weaknesses of the strategy, allowing traders to make adjustments accordingly.

• Psychological Preparation: Trading can be emotionally challenging, especially during periods of drawdowns or losses. Backtesting can help traders psychologically prepare for such situations by giving them a realistic understanding of the ups and downs they might experience with their chosen strategy.

• Learning Experience: Backtesting is also a valuable learning experience for traders, especially for those new to the markets. It helps them understand market dynamics, develop a deeper insight into trading strategies, and refine their analytical skills.

Overall, backtesting is a crucial component of the trading process. It provides traders with the necessary tools to assess the viability of their strategies, manage risks effectively, and make informed decisions in the dynamic world of financial markets.

How to Backtest Stock Strategy?

Are you eager to test the effectiveness of your stock trading strategy? Backtesting is a crucial tool that allows traders to evaluate their strategies using historical data. Finquota.com offers a user-friendly platform for backtesting strategies, enabling traders to make informed decisions based on empirical evidence. In this guide, I’ll walk you through the process of backtesting your stock strategy step by step using Finquota.com.

Step 1: Access Backtesting Tool

Navigate to the ‘Backtest‘ section on the platform. Here, you’ll find the tools necessary to analyze the performance of your trading strategy.

Step 2: Set Backtesting Parameters

Before running your backtest, you need to define several parameters:

Backtesting Duration: Choose the duration for your backtest. You can select the time period you want to analyze.

Ticker: Enter the ticker symbol (ex WDAY, TSLA, SOFI, AMZN, GOOGL, NVDA etc..) of the stock you want to test your strategy on.

Trading Interval: Select the interval at which you want to conduct your trades (e.g., 5 min, 10 min, 30 min etc..).

Buy/Sell Signals: Specify the conditions that trigger buying and selling actions in your strategy.

Select Indicator: Choose the technical indicator(s) you want to incorporate into your strategy (e.g., Moving Average, Relative Strength Index).

Step 3: Run Test

Once you’ve configured all the parameters, click on the “Run Test” button to initiate the backtesting process. Finquota.com will analyze historical data based on your specified parameters and provide you with the results.

Step 4: Analyze Results

After the backtest is complete, carefully review the results. Pay close attention to key metrics such as:

Profit and Loss (P&L): Evaluate the overall profitability of your strategy.
Win Rate: Determine the percentage of winning trades versus losing trades.
Maximum Drawdown: Assess the maximum loss experienced during the testing period.

Step 5: Refine and Iterate

Based on the results of your backtest, refine your strategy as needed. Consider adjusting parameters, incorporating additional indicators, or implementing risk management techniques. Iteratively backtest these modifications to validate their effectiveness.

Conclusion

Backtesting your stock trading strategy on Finquota.com empowers you to make data-driven decisions, ultimately enhancing your chances of success in the financial markets. By following this guide and leveraging the platform’s tools, you can gain valuable insights into the performance of your strategy and optimize it for improved results. Start backtesting today and take your trading to the next level!

The post How to Backtest a Stock Trading Strategy in 2024? appeared first on ProdSens.live.

In the rapidly evolving world of cryptocurrency, businesses are constantly seeking innovative solutions to cater to their growing customer base. One such solution is the White Label Crypto Payment Gateway platform, which offers a host of advanced features and benefits.

Embrace the future of payments and reap the benefits of a White Label Crypto Payment Gateway platform today!

Now, we will explore the exciting aspects of this technology and how it can revolutionize your business in the era of digital currencies.

1. Streamlined Integration and Customization

A White Label Crypto Payment Gateway platform allows businesses to seamlessly integrate cryptocurrency payment options into their existing websites or applications. The platform can be customized to match the brand’s aesthetics, ensuring a consistent customer experience. With a user-friendly interface and intuitive design, businesses can effortlessly harness the power of cryptocurrencies for enhanced customer satisfaction.

2. Expanded Payment Options

By implementing a White Label Crypto Payment Gateway, businesses can offer their customers an array of payment options beyond traditional methods. Cryptocurrencies like Bitcoin, Ethereum, and Ripple are gaining popularity, and embracing them as payment alternatives can attract a broader range of tech-savvy customers. This diverse range of payment options can also help to secure transactions and boost overall trust in the business.

3. Increased Security and Privacy

One of the defining features of cryptocurrency transactions is the higher level of security and privacy they provide. With a White Label Crypto Payment Gateway, customers can confidently make purchases or conduct transactions, knowing that their sensitive financial information is safeguarded through advanced encryption techniques. This level of security not only enhances customer trust but also protects businesses from potential data breaches.

4. Global Reach and Lower Transaction Fees

Traditional cross-border transactions often come with hefty fees and lengthy processing times. White Label Crypto Payment Gateways leverage the decentralized nature of cryptocurrencies to offer businesses a global reach while significantly reducing transaction fees. This approach enables businesses to tap into international markets without being tied down by the limitations of traditional banking systems. The result? An improved bottom line and enhanced efficiency.

5. Real-Time Analytics and Reporting

To make informed decisions and optimize business operations, understanding transaction patterns and customer behaviors is crucial. White Label Crypto Payment Gateway platforms provide real-time analytics and reporting, empowering businesses with valuable insights into customer preferences, peak transaction times, and more. By leveraging these analytics, businesses can refine their marketing strategies, improve customer targeting, and stay one step ahead of the competition.

Conclusion

In today’s digitally-driven world, businesses need to adapt to emerging technologies to stay relevant and competitive. Implementing a White Label offers a range of features that can revolutionize the way businesses accept and process payments. With streamlined integration, expanded payment options, and enhanced security, this technology opens up new horizons for businesses aiming to harness the potential of cryptocurrencies.

The post White Label Crypto Payment Gateway Platform – Revolutionize Your Business appeared first on ProdSens.live.

Is your fintech blog boring and not engaging your readers?

If your blog posts look a lot like these:

• “Great news! [Company name] closes Series B funding”
• “[Company name ] featured on [publication name]”
• “[New product feature] is here!”

It may be time to shake things up.

Fintechs, like many tech companies, use blogs as a PR channel, publishing content focused on them and their products without speaking to topics that potential customers are looking for.

A fintech’s blog could be so much more than a PR or news channel. For example, it could act as a content hub to help educate rather than market or sell, drawing readers back to consume more and share with their own community.

But how do you determine what your audience wants to read or learn about? To start, check out trending relevant topics on social media. Or study the agenda at industry events and even ask current customers. There’s no drawback to learning more about readers. It will only help you engage better with them so they’ll take notice of every post, blog series, and short video you publish.

Whether you’re a stand-alone fintech like Better.com or a financial institution partner like Plaid, almost every fintech could benefit from this switch in thinking. A successful fintech blog can be a resource library that increases brand awareness, educates readers on your products and the challenges faced by the industry, and more.

We’ve noticed a few that stand out in how they successfully engage their readers and offer good examples to follow.

The brand that calls out competitors: Wise

Wise Payments Canada is an international bank that has implemented a marketing tactic other fintechs may be hesitant to try: publishing articles that explain how to open and close accounts with their competitors, like How to Close your Bank of America Account: Options and Tips.

But why does Wise publish these kinds of posts? Because they know their prospects are already searching for information on how to close an account with a competitor. So, they target these prospects by creating posts on their own blog. And a good keyword strategy ensures their post appears before the competitors in search engine results.

Plus, Wise is controlling the conversation by writing a post that directly answers the reader’s intent. They can mention their own products without being overly sales-y. By publishing it on the Wise website, it’s just a quick couple of clicks to get them to sign up for a new Wise account.

The brand that provides the info customers want: Betterment

As a fintech, Betterment knows people are looking for financial information and tools. So, instead of creating content that covers topics related to their products, they’ve created a massive resource hub.

Betterment has content for both personal finance beginners and advanced investors to help better manage their money. Topics range from how to use their products to helping readers plan retirement and investing in real estate to understanding the latest developments in the financial world.

Betterment does a stellar job in aligning customer intent with their content strategy, making it easy for people to find what they’re looking for.

The brand that makes finding information easy: Lightspeed POS

Lightspeed POS offers products and services that target three specific audiences: retailers, restaurants, and golf courses. These businesses have unique needs for point-of-sale solutions, so Lightspeed publishes content just for them. But how is that different from other POS vendors or fintechs?

Well, Lightspeed makes good use of the “featured post” and “most read articles” capabilities of their blog platform. Many fintechs relegate this info to the sidebar, but Lightspeed knows their target audiences want to learn about how others in their industry are approaching certain challenges. They also don’t have as much time as other corporate audiences do to scroll through the Lightspeed blog. So having the “most read articles” at the top of the page cuts down the time they spend searching.

Each post offers tips, advice, and relevant how-tos their audience can consume and implement quickly. Plus, each post has a reading time at the top, so readers can decide for themselves whether they want to continue or not.

The brand that creates unique customer solutions: Blueleaf

Blueleaf publishes a variety of helpful content (think explainers, behind-the-scenes posts, and podcasts) centered around specific problems or challenges wealth management advisors face. Each post discusses in-depth insights about a problem and offers several solutions, including how Blueleaf can help, like in this post.

The Blueleaf team always adds a clear CTA so readers know what’s next in the reading journey, like:

• “An Experience Your Clients Will Love. Clients will love the service you deliver with Blueleaf’s superior client experience. [Button] Get a FREE Demo”
• “Look for more on this topic in the upcoming weeks, including the release of our next eBook, titled ‘Remote First,’ which will show you how to grow and manage a virtual advisory practice. Subscribe to our blog so you don’t miss any updates.”

The brand that over delivers on helpful information: SoFi

The SoFi blog is actually part of their “SoFi Learn” content library and is found at the bottom of the page. They’ve created so much content that the actual blog is one of the final places readers might go. At first glance, the SoFi blog looks like the typical “bad” blog in that it publishes a lot of press releases and product updates.

Where they differentiate it is by also publishing relevant industry news like this post, investment strategies from SoFi experts like this one, and company updates that are benefit-driven, like this one.

Each post feels like a mini deep-dive as they dig deep into the why of their own products and services as well as what’s happening in the industry. They take the very technical and financial details and put them into language their readers can quickly understand.

Are these the only great examples?

And these are just some of the great fintech blogs out there. Many companies are leaning into content marketing and publishing helpful resources on their blogs. These companies know they’ve got to publish information that’s relevant and sought after by their readers. They’re looking at interesting ways to capture readers’ attention, like Wise, that publishes posts targeting their competitors. They’re being relentlessly helpful, like Lightspeed, so people know exactly where to go for help.

Use one of these fintechs as a model to improve your company blog, and you’ll create an engaging and useful resource for your audience.

The post The Problem with the Fintech Blog (and How to Fix It) appeared first on Contently.

The post The Problem with the Fintech Blog (and How to Fix It) appeared first on ProdSens.live.

Intro

At FINN, we strongly believe in the principle of do it, do it, automate it. If you find yourself doing something manually twice, you should find a way to automate the process. This holds just as true when it comes to the precious details of invoices and financial document processing. Within the FINN Finance team, we’ve recently started using a platform called Rossum that helps us improve the automatic optical character recognition (OCR) of documents. But to understand why Rossum is so helpful, let’s first dive into the problems you’ll frequently run into with traditional OCR tools.

Problems with traditional OCR

Consider the sheer variety of invoices we receive on a daily basis:

In these invoice PDF snippets, the fields indicating the total amount due are very different from one another. Sometimes the currency is specified in euros, in other cases it’s in dollars. Some invoices speak of ‘Total amount’, or ‘Balance due’, while still others use ‘Brutto’. The formatting is all over the place, which wreaks havoc on regex-based OCR.

For humans, such variation is relatively easy to read. When a human looks at this, they should not have much trouble distinguishing what is what. A human would usually skim the documents and see that invoice number is in one place, the date in another, and so on. In skimming a document like that, we know to expect localized data (i.e. the total should be somewhere under the itemized table).

Humans can also make quick decisions. For example, when you know dates only come in a certain format, then you can easily pick up cases where there’s something wrong with an invoice, such as where the due date of the invoice appears to be before its issue date.

But such an approach is less straightforward for a machine. And this is exactly where traditional OCR systems can face challenges. When there is lots of variation in the input formatting, traditional OCR might give you accurate data, sure. But it’s not obvious that in all cases it will find exactly what you’re looking for. When you’ve got tens of thousands of invoices to process, that’s not the sort of issue you want to run into. So how did we at FINN solve this problem?

Superpowered OCR with machine learning

Enter: Rossum. Rossum is a platform for, as they call it, ‘intelligent document processing’, that automates the processing of variable documents. And ‘variable documents’ here means that you are dealing with documents that have very similar data (such as data for the total amount due), but in totally different formats (different labels, currencies, date formatting, and so on). Rossum uses machine learning to improve and speed up the processing of such documents. And it does so by trying to approach these invoice documents a bit more the way a human might. So how does that work?

At FINN, our use case is processing incoming invoices. To do this, we first set up a schema for all the data points that we want to collect from the invoice, and train the relevant model. After that initial training, by and large it can run entirely automated (though we might improve the training once in a while). Next, we set up our email automation so that we process invoices as soon as we get them. We can define a confidence score (with options ranging from 0 to 1), which indicates the degree of confidence of the AI engine that it has correctly identified the location and text of a field. For instance, if you set the required confidence score at 0.8 (80%), then when the system is able to meet that threshold, the whole OCR processing runs automatically and no human will have to look at it. Only when the system is not able to meet the selected accuracy levels, it will send you a notification, so that a human can still review it.

Two parts make the process especially fun. First, because Rossum uses machine learning, the system progressively gets better. If you have a field that initially needed regular reviews, then once you get enough manual reviews, the system will learn to detect that field. As a result, the next time we see a similar kind of case, it may very well hit the required accuracy levels and automate the entire process. That’s one huge advantage of using Rossum.

The other fun part is data validation. It is super easy to set things up to validate a range of data. For example, to check that the supplier exists, that the supplier’s International Bank Account Number (IBAN) is in such-and-such format, or even to catch plain errors. We once had a supplier send us an invoice dated the 31st of June, which is an impossible date. Due to proper data validation, it’s very easy to catch that.

Traditional OCR does not work like this at all. But such an approach is very intuitive to humans, and Rossum is trying to approximate that.

Customization and training your own engine

Different organizations will have different needs in terms of document processing. At FINN we work with car subscriptions, so it’s often crucial for us to find things such as the car’s license plate, or the Vehicle Identification Number (VIN) on the invoices. Rossum has a very good generic engine that we can use straightaway. This already helps us find many of the relevant issues. But in addition, you can also purchase an engine that you can train for customized options that are specifically relevant to your organization. So at FINN we decided to add things such as the VIN as specific options to the training process, to tailor it to our specific needs.

The Rossum website also offers a bunch of different settings for customization. It also allows us to distinguish between different types of documents to process, such as invoices, or speeding tickets. Or you also have settings to specify what kind of language you’re mostly working with.

Language processing is interesting. Many conventions in financial documents differ between languages, or from region to region—think of decimal separators, or date formats. You would think that that should result in quite some difficulties with OCR-ing the invoices? Well, not really. So far at FINN, we haven’t had to train separate models for, say, German versus US English invoices. Rossum supports a ton of customization options: it already covers most languages that use a variation of the Latin script, and support for Japanese and Chinese language documents is currently in beta. At FINN, we are regularly processing invoices with a range of different formats.

In terms of really taking things further, Rossum even allows you to add extensions with your own logic. For example, we may want to match the supplier name found on an invoice to the list of suppliers already known to FINN. But in case of a new supplier, you’re obviously not going to find a match. To solve this, we built an app with our drag-and-drop internal tools building system Retool, that we hooked into the Rossum web interface. So with a single click you can go straight from Rossum to our dedicated Retool app and insert the new supplier.

Going yet further, we already have a list of cost centers that we use on our finance management tool. Once the system recognizes the supplier name, we can also match this automatically to the cost center. Once matched, we can export and save all the information in our own database and upload it directly to our SaaS Finance Tool. Ideally, then, once it’s all trained, the entire process is mostly automated — it’s all super smooth for the user.

Alternatives

We did evaluate a few other OCR tools like Nanonets and Super.AI. Rossum caters well to both non-devs and devs. The UI is very easy to use, and they have great API Docs. The options for custom extensions using Lambdas or Webhooks open up Rossum to great extent, which makes up for some missing features. We have built our own extensions for data validation, detecting multiple invoices in a single pdf, removal of irrelevant pages, etc.

So that’s how we at FINN are using Rossum to automate and speed up our financial document processing.

Have you had any challenges with financial document processing? Let me know in the comments how you solved them!

Written by Chris Meyns (Technical Writer) and Gazala Muhamed (Software Engineer)

Resources

https://elis.rossum.ai/api/docs/#introduction

The post Using Rossum.ai to superpower OCR with machine learning appeared first on ProdSens.live.

Your current credit card can be used in four different ways:

1. Typing in the card number. We’ve been using credit cards this way since 1950.
2. Sliding the card’s magnetic strip (the black stripe) through a card reader. This method was invented by IBM in the 1960s and has been in use ever since, but it’s on its way out. In a few short years many credit cards will no longer have a magnetic strip. With luck, we’ll phase them out completely sometime in the 2030s.
3. Inserting the card into a chip reader. Chip cards were first invented in the 1960s, believe it or not. France and Germany developed standards for them in the 1980s, but it took until the 2000s for a worldwide standard (EMV) to catch on, and the U.S. didn’t start issuing chip cards until the mid-2010s. By now, every major credit card has a microchip in it.
4. Waving the card over a contactless chip reader. This is essentially the same as inserting the card and uses the same embedded microchip.

Today I’ll be going in-depth on these last two, explaining what the “chip” on your card is and how it works. The technology involved is closely related to the tech that keeps web browsing and app downloads secure.

The microchip

You’ve no doubt noticed the shiny metal chip on the front of your credit card. Except that’s not a chip; it’s an electrical contact. When you insert your card, electricity is supplied through the contact’s top left pin to power the actual microchip, which is embedded inside the card, and other pins are used to communicate between the microchip and the payment terminal. If your card is “tap to pay” enabled, it also has an antenna around the inside edge that receives wireless power and communicates with the card reader via radio waves.

To be clear, the microchip on your credit card is a computer! No, really. It’s a very small computer that runs one or more applications. So that’s cool. You’re probably carrying two or three computers in your wallet right now.

Why does your credit card need an onboard computer? Isn’t that going overboard?

Think about how easy it is to steal someone’s credit card information right now. A quick photo will do it. The card’s “passwords”—a name, 16-digit number, expiration date, and security code—are all clearly displayed. Many of us have had the unpleasant experience of discovering someone else is using our credit card number and we don’t even know how they got it. In fact, there’s a thriving industry around credit card fraud: companies that buy and sell stolen numbers, other companies that test them to see if they still work, and tens of billions of dollars circulating between them and an army of online and offline thieves.

Even if the card were blank except for the magnetic strip, it would still be a relatively easy target. A credit card’s number never changes. And reading magnetic strips is decades-old technology, so simple it can be done by a device even smaller than a credit card (including onboard memory). Devices like these (called “skimmers”) are commonly inserted in gas station card readers and left to collect data for a couple days before being retrieved. So neither credit card numbers nor magnetic strips are up to the task of protecting your financial identity.

This is a problem well worth solving. But credit cards need to identify themselves somehow. The card reader at the grocery store has to tell your bank how much you’re spending, and the bank needs to deduct money from your account. If a hacker is listening in on that electronic conversation, how can we stop them from learning enough to use your card for fraud?

That’s very similar to another topic I’ve written about: how HTTPS stops hackers from reading the information you send over the Internet. When you visit a website, your browser and the website establish a secret decoding key together, in the open, and nobody else can figure out what it is even if they’re listening the whole time. That’s the magic of prime numbers.

So is your credit card doing an HTTPS key exchange with the bank? Well, not quite.

Encryption and symmetry

If you’ve ever written to a friend in a made-up language or used a numeric code (A=1, B=2, C=3…) you understand the concept of encryption. Encryption is taking a message and disguising it with some kind of algorithm; decryption is reversing the algorithm to decode it and see the original message. Nowadays we encrypt nearly everything online. We might as well; it’s fast and free, and it’s always better to err on the side of privacy.

Sometimes we need to encrypt something so hard it can never be decrypted. We do this for passwords (or try to). There’s absolutely no reason for anyone but you to know your password. The websites you log into store an irreversibly encrypted hash of your password, then use that hash for comparison every time you log in. They don’t know your password, but they can check to see if you’re typing the right one.

This isn’t one of those times. Your credit card needs to supply a piece of information that the bank (but nobody else) can quickly decrypt.

One way to do this is by using symmetric key encryption (also called private key encryption). This requires the credit card and the bank to have a shared, predetermined key: a string of bytes that can be used to encrypt or decrypt any message. That’s no problem, since the card came from the bank in the first place; they can program the key into the card before they mail it to you.

Let’s implement a two-round symmetric key encryption algorithm in JavaScript. It will be far too simple and insecure to use in real life, but it’ll illustrate how an algorithm like AES works. We’ll be using the bitwise XOR operator ^, which you probably don’t see very often, but all you need to know is if a ^ b === c, then c ^ a === b and c ^ b === a.

//
// ENCRYPTION
//

// This is the entry point. It converts your shared key to a number
//  and your message to an array of numbers, then encrypts it in two
//  steps. It converts the resulting array of numbers back to a string
//  and returns it.
function encrypt(sharedKey, message) {
  const numericKey = stringKeyToNumeric(sharedKey)
  const messageBytes = stringToIntArray(message)
  const r1 = encryptRound1(numericKey, messageBytes)
  const r2 = encryptRound2(numericKey, r1)
  const encrypted = intArrayToString(r2)
  return encrypted
}

function encryptRound1(numericKey, byteArray) {
  // Create a "round key" so we aren't using the same key for every step
  const roundKey = numericKey ^ 4321

  // For each character in the message, XOR it with the round key
  return byteArray.map(byte => byte ^ roundKey)
}

function encryptRound2(numericKey, byteArray) {
  const roundKey = numericKey % 1234
  const newBytes = byteArray.slice()

  // "Rotate" the array (move the last element to the beginning) roundKey times
  for (let step = 0; step < roundKey; step++) {
    newBytes.unshift(newBytes.pop())
  }
  return newBytes
}

//
// DECRYPTION
//

// The other entry point. It does the same thing as `encrypt` but backwards.
function decrypt(sharedKey, encrypted) {
  const numericKey = stringKeyToNumeric(sharedKey)
  const messageBytes = stringToIntArray(encrypted)
  const r1 = decryptRound1(numericKey, messageBytes)
  const r2 = decryptRound2(numericKey, r1)
  const message = intArrayToString(r2)
  return message
}

function decryptRound1(numericKey, byteArray) {
  const roundKey = numericKey % 1234
  const newBytes = byteArray.slice()

  // "Unrotate" the array roundKey times
  for (let step = 0; step < roundKey; step++) {
    newBytes.push(newBytes.shift())
  }
  return newBytes
}

function decryptRound2(numericKey, byteArray) {
  const roundKey = numericKey ^ 4321

  // XOR each character with the same round key, which gives us the original
  return byteArray.map(byte => byte ^ roundKey)
}

//
// UTILITY
//

function stringToIntArray(message) {
  return message.split('').map(char => char.charCodeAt(0))
}

function intArrayToString(intArray) {
  return intArray.map(int => String.fromCharCode(int)).join('')
}

function stringKeyToNumeric(key) {
  const fourDigitCodes = key.split('').map(char => char.charCodeAt(0).toString().padStart(4, '0'))
  const numericKey = Number(fourDigitCodes.join(''))
  return numericKey
}

//
// TEST PROGRAM
//

const message = "Hello there."
const sharedKey = "ABCDEF"

console.log('Message:', message) // => Message: Hello there.

const encrypted = encrypt(sharedKey, message)
console.log('Encrypted:', encrypted) // => Encrypted: ႎჁ႕ႉႄ႓ႄ჏Ⴉႄႍႍ

const decrypted = decrypt(sharedKey, encrypted)
console.log('Decrypted:', decrypted) // => Decrypted: Hello there.

Go ahead, paste this into a REPL and play with it if you’d like.

Some of you might be saying “this is what you call simple?!” And others might be saying “this is way too simple, where are the lookup tables and block ciphers?” Look, I can’t please everyone but I can upset everyone, so that’s what I went with.

Let’s put this code in context. If my credit card’s microchip has the shared key "ABCDEF" programmed into it and my bank knows to use that key for messages that come from me, here’s a simplified example of how a purchase authorization might go:

Payment terminal: I’m verifying a purchase of four chinchillas at Pet Central for 89.99 USD at 11:15 PM, Oct 10 2022. Please respond.

Microchip: Okay. I’ve received the transaction but I’ll need a PIN number to authorize it.

Payment terminal: Sure thing. Customer, please enter your PIN.

Me: *Types 9999.*

Payment terminal: Is that the right PIN, microchip?

Microchip: Yep, that’s the one. I trust this transaction. encrypt("ABCDEF", "Pet Central: 89.99 USD at 11:15 PM, Oct 10 2022")…done. The transaction has been encrypted with my private key. Please send it to FIRST BANK and tell them it’s from ISAAC LYMAN, whose account number is 12345678.

Payment terminal: Great. Contacting the bank…

FIRST BANK: Hello, FIRST BANK speaking.

Payment terminal: I’m a payment terminal at Pet Central. I want to process a transaction for account 12345678 under the name ISAAC LYMAN.

FIRST BANK: Transaction received. decrypt("ABCDEF", transaction)…and done. I can verify this transaction is from ISAAC LYMAN’s credit card because otherwise it wouldn’t decrypt. Everything lines up, so I’ll deduct 89.99 USD from his account and send it over.

Payment terminal: Transaction successful.

Note that my credit card number doesn’t have to be sent over the wire. Neither does my private key. In fact, nothing worth stealing is leaving the terminal. A hacker could grab the encrypted transaction message, but there’s no way to use it unless they have a time machine and want to buy four chinchillas from Pet Central at the exact same time I originally bought them.

Symmetric key encryption is used by some banks, but it has a couple of minor flaws. One of them is that theoretically, the bank could make up a fake transaction and charge you for it. They’ve got your private key, so the only thing stopping them is hundreds of international regulations. The other flaw is that your private key is stored on an Internet-connected server at the bank, so it could be stolen if there’s a security breach.

To be clear: symmetric key encryption is so much better than credit card numbers and magnetic strips. But there’s an even better way.

Asymmetric keys

Symmetric keys make a lot of sense. Of course if you and another person have a shared secret key, you can encrypt and decrypt each other’s messages.

Asymmetric keys step into the realm of magic. Or, at least, counterintuitive math.

In asymmetric encryption, there are two different keys: a private key and a public key. These keys are mathematically related, but knowing one won’t help you figure out the other. They serve opposite functions: you can encrypt a message with the private key that can only be decrypted by the public key, and you can encrypt a message with the public key that can only be decrypted by the private key.

Asymmetric encryption is often used by journalists for sensitive investigations. They can generate a key pair, store the private key on a device they trust, and post the public key for the whole world to see. Anyone who wants to send them a secret message can use the public key to encrypt it, ensuring only the journalist will be able to decrypt it. And in the opposite direction, the journalist can encrypt a message using their private key (or encrypt a hash of it, which we call “signing” it), which provides proof of authorship. If the message (or hash) can be decrypted using their public key, that proves it came from them.

Back to credit cards. The bank can program a public/private key pair onto your credit card and then completely forget the private key. They don’t need to store it anywhere. They only need to hold onto the public key. They’ll use it for two purposes: to decrypt messages sent from your card and to prove those messages came from you, not them.

This eliminates the first risk of symmetric keys: fraud committed by the bank itself. As long as they can prove they didn’t keep your private key after they programmed your card, they can’t be accused of generating fake transactions. It also eliminates the second risk. Your private key isn’t stored on any Internet-connected server; it only lives in one place in the entire world, and that’s inside your credit card. Sure, your public key could be stolen. But the only thing the thieves could do with it is read your transactions. They wouldn’t be able to create new ones.

Let’s implement some asymmetric encryption in JavaScript. This will illustrate how an algorithm like RSA works.

//
// ENCRYPTION
//

function encrypt(privateKey, message) {
  const messageBytes = stringToIntArray(message)
  const [modulus, exponent] = privateKey
  const encrypted = messageBytes.map(byte => (BigInt(byte) ** exponent) % modulus)
  return intArrayToString(encrypted)
}

//
// DECRYPTION
//

function decrypt(publicKey, encrypted) {
  const encryptedBytes = stringToIntArray(encrypted)
  const [modulus, exponent] = publicKey
  const decrypted = encryptedBytes.map(byte => (BigInt(byte) ** exponent) % modulus)
  return intArrayToString(decrypted)
}

//
// UTILITY
//

function stringToIntArray(message) {
  return message.split('').map(char => char.charCodeAt(0))
}

function intArrayToString(intArray) {
  return intArray.map(int => String.fromCharCode(Number(int))).join('')
}

//
// TEST PROGRAM
//

/* 
  Each key has two parts: a shared "modulus" and a non-shared "exponent."
  Key generation is complex. These three numbers all have to be mathematically related.
  In real life the modulus would be a very large number in the ballpark of
  5353683424958100487553692737855921351167231508809347122534824314767512079033611122618
  8508861310385963124739442570162267402922655660049366578306762217485423974277904708682
  5660398049299993503929195152693455928734884540497474885533510411221183157745113097158
  7147857841470416503261588799943431828622126181414376019549024568602030872555448200000
  2641304272163777569374865564566594216223640291860534772832785404395599963806669068407
  0321707428203752195331410456415056194233539898345799623002726720980709094812380346346
  3583607751796240362096547051130726215056560026642532836575212569426651466587428695230
  1071376112504419090641365.
  The exponents would be somewhat smaller. Both exponents must be prime numbers.

  We use the `n` suffix to get BigInts, since playing with exponents can exceed
  JavaScript's standard number limit pretty quickly.
*/
const privateKey = [25777n, 3n]
const publicKey = [25777n, 16971n]

const message = "Four chinchillas"
console.log("Message:", message) // => Message: Four chinchillas

const encrypted = encrypt(privateKey, message)
console.log("Encrypted:", encrypted) // => Encrypted: ớ֪൯⿟᭏䂦䁅宍㿵䂦䁅宍垐垐⣮ 

const decrypted = decrypt(publicKey, encrypted)
console.log("Decrypted:", decrypted) // => Decrypted: Four chinchillas

A few things you might be thinking at this point:

• Wait, this is shorter than the other code snippet. If that doesn’t seem right, it’s because it isn’t. This is only the asymmetric part. In real life you’d do some reversible encryption (“padding”) rounds before you use your asymmetric key so the encrypted text couldn’t be cracked by a letter-frequency attack. But that’s not the whole story either. Typically a message sender asymmetrically encrypts a randomly-generated key, uses that key to symmetrically encrypt the message, and sends the symmetrically encrypted message and asymmetrically encrypted key together. (This is because symmetric encryption is faster.)
• Hey, this looks a lot like a Diffie-Hellman key exchange! Well, that’s because in both cases we’re looking for a computation that’s easy to do but hard to reverse, and we’re looking for a way to encrypt and decrypt a message using numeric counterparts. Prime numbers are easy to multiply and the result is hard to factor—that’s part one. And part two: exponents and moduluses have mystical properties that allow numbers to travel between dimensions unharmed.
• Good grief, this is complicated. And that’s why you should never do it yourself. Make even one tiny mistake and your security goes down the drain. You should always use a popular, well-vetted cryptography library in whatever language you’re programming in. This bears repeating: never implement an encryption algorithm on your own.

Some banks use asymmetric key pairs in credit card chips. This creates an opportunity for a few extra security features. For example, if the bank has their own public/private key pair, they can publish their public key and use their private key to sign your public key, which creates a chain of evidence linking your card to them. When you use your card, it can send its public key to the terminal with a cryptographic signature from the bank proving they issued it! The payment terminal just needs to know the bank’s public key to verify the signature. Then when the card signs a transaction, the terminal can check that it matches the signed public key. This allows offline, computational assurance that a card is authentic.

Unfortunately, complete security is impossible. A computer is only secure until it gets into the wrong hands. Your card’s microchip is engineered not to reveal its private key, but all bets are off when it comes to physical access. So if you lose your wallet, you still need to call your bank.

The future of credit cards

Many stores are reluctant to upgrade their payment terminals—it’s a hard cost with fuzzy benefits—but most of them did so in 2015, when card issuers updated their agreements to make stores liable for credit card fraud if their terminals didn’t have EMV chip readers. Liability is a powerful force in the business world. So now most of the places you shop let you insert your card’s microchip to pay, and quite a few also have contactless tap-to-pay terminals.

What’s next?

It would be great to get rid of visible credit card numbers and magnetic strips. The credit card fraud industry would be left gasping for air. One major holdout is online shopping. You still have to type in your name, card number, expiration date, and CVV code to buy something from a website. But the world is ripe for change; most smartphones made in the last five years have NFC chips, and roughly half of all e-commerce happens on smartphones. So with a little work on the software side, it’s not hard to imagine a world where you could pay for something by waving your credit card over your phone screen.

Then again, that may be too many steps. Both iPhone and Android have mobile wallet functionality so you can program your cards into your phone and use your phone to pay both in-person (at tap-to-pay terminals) and at some online stores. This doesn’t need to go away; perhaps there’s a version of the future where you add cards to your mobile wallet using a direct connection to the issuing bank instead of a few easily-stolen strings of digits.

The ideal credit card would be one that couldn’t be used fraudulently unless it was physically stolen by someone with advanced technology and plenty of time on their hands. You couldn’t reveal its secrets to a scam caller even if you wanted to.

Like so many other things, we’ll leave it in the capable hands of a microchip.

Acknowledgments

Thanks to the following authors, without whose work I wouldn’t understand this subject at all:

• Daniel Cuthbert, Behind the chip on your credit card
• Nadia Heninger, Symmetric Cryptography
• Vicki Hyman, Swiping left on magnetic stripes
• David Ireland, RSA Algorithm
• Tom Leek, Exact cryptography depends on…
• EMVCo, LLC, A Guide to EMV Chip Technology
• Wikipedia.org: Advanced Encryption Standard, Contactless smart card, Digital signature, EMV, Public-key cryptography, RSA (cryptosystem)

The post Credit card chips and encryption in plain JavaScript appeared first on ProdSens.live.