Dynamic Linking, and the limitations of 2FA in Payments
Authentication is what matters when money movement is centralized. But figuring out who you are is a process where you are the weakest link.
The craziest payment trivia I know is this: banks are OK with you sharing your credit card information in a phone call.
Yes, it’s PCI compliant. Yes, it’s out of the scope of SCA.
We’ve got this intuition that online communication is extremely secure thanks to encryption and other mechanisms. Or at least more secure than phone calls, which can be eavesdropped, or even tapped.
Yet banks, and the payment systems that are bank-based, trust phone calls more than the Internet.
Here’s another crazy thing: phone calls are perceived to be safer for payments not because bank executives are old-fashioned. It’s because it makes perfect sense.
This is why: banks are meant for everyone.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. Go spend 5 minutes on Youtube and you’ll see tons of tutorials on how to pass software design interviews that use payment systems.
But there’s not much that teaches you how to build one for real users and real money.
The reason I know this is because I’ve built and maintained payment systems for almost ten years. I’ve been able to see all types of interesting conversations about what works and what doesn't behind closed doors.
And I thought, “you know what? It’s time we have these conversations in public”.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extract tactics from it.
Today, we’re going to look at something called Dynamic Linking, which looks a lot like two-factor authentication, but it’s tailored to the needs of banks and payments.
But I want to tell you a story first.
A couple of years ago, I got my iPhone stolen. A few days later, I got an email telling me how to get it back.
It was a totally legit email from Apple, nudging me into logging into their site so that I could pinpoint the location of my device.
Except it wasn’t legit, and it wasn’t an official site.
I am quite familiar with how fraudsters operate online, and I have to tell you, it was very persuasive. I even had to visit an Apple store and ask someone, face to face, to confirm if I had gone mad for thinking that the email looked just a bit suspicious.
“No, that’s not us.” was the polite response from their staff.
Encryption protects us from “man in the middle” attacks online. But if someone sets up a website that mimics the site you want to deal with convincingly, they might trick you into sharing sensitive information with them.
This is known as phishing.
Identity theft is relevant in payments because moving money online is all about identity. The “who” is more important than “what” is being exchanged, because each individual payment can be reversed, but an exchange system where people cannot be trusted is unusable.
Making sure you’re who you claim to be is the most important task for any payment system. “You” has to mean “you” often enough for this to work.
The problem is that “you” is also the weakest link in the system.
“You” can be tricked, can be cajoled, can be persuaded. “You” can be distracted and in a hurry. “You” can be an educated engineer, but “you” can also be a 70 year old lady with an old flip phone.
Payments, like banks, are meant for everyone. This means that all the trade-offs that involve ever more sophisticated ways to certify and authenticate the identity of payers and payees must work for the lowest denominator possible.
Yes, banks are nudging you into their banking apps, with more secure push notifications. However, not everyone has a smartphone, and therefore can’t have banking apps. Even when they have a bank account.
Here’s why all those crazy trivia aren’t so crazy. Why SMS is still the de facto authentication method for banks, not push notifications. Why the PSD2 directive says that PSPs must ensure that encryption is applied “when exchanging data by means of the internet”, but not when done via SMS.
Because it has to work for everyone.
Now, that doesn’t mean that regulators are OK with bank-based payments becoming wild-west-y, no. The system must be, at the same time, very safe.
Which is why banks have leaned into Out Of Band authentication.
OOB, Dynamic Linking, and You
Relying only on SMS communication is probably a bad idea. There are plenty of well-known ways that hackers can intercept an SMS, like SIM swaps and Mobile number port-out scams.
In SIM swaps, the hacker calls the target’s mobile provider and requests a “replacement” for the victim’s SIM card, that small chip we introduce into our phone to have signal. In mobile number port-outs, the hacker calls, not to replace the SIM, but to transfer the account to another provider.
In both cases, the victim’s phone no longer receives any SMS. It’s now the hacker’s.
The question is “why on earth would you trust such a system?”. And the answer is that you don’t trust SMS communication alone.
That’s what Out Of Band means: the use of both the Internet and wireless communication channels as a verification method.
The 3DS protocol (of which we’ve talked about already for American and European merchants) establishes that payers must verify their identity in at least two of the three possible ways they consider:
Knowledge: An access key or a password (card data doesn’t count)
Possession: A push notification on your phone or keying in a PIN code
Inference: A biometric confirmation on your smartphone (face or finger scanning)
If this sounds like your typical implementation of two-factor authentication, you’re right.
But here’s what makes OOB so cool: the usual two-factor authentication isn’t enough.
Most banks use something called Dynamic Linking, which builds on top of two-factor authentication and enforces a few caveats:
The authentication code is associated with the amount and the recipient of the payment.
The amount and the recipient are shown in the message.
Multiple authentication codes can be sent via any channel, but as soon as one gets validated, the rest are unusable.
Any change in the amount or the recipient invalidates the authentication code.
There’s this pervasive idea that security is about making sure that no one can get in without permission. And that rings true, but it’s incomplete. Everyone can get in, given enough resources. Security is about making it as costly as possible.
We talked about a similar trade-off in Exemptions and Data Science: The European Way of Building 3DS: product decisions impact saints and sinners equally, and almost always making it hard for hackers means making it difficult for customers.
Banks can’t decide not to trust anyone, because banks are in the business of trust.
Which is why Dynamic Linking makes a lot of sense, even when it deviates from more common two-factor authentication protocols and forces banks to implement their own solutions in-house.
Dynamic Linking makes it easier for non tech-savvy customers to realize when they’re being fooled.
Session-based vs Transaction-based
Most consumer-grade authentication systems operate like this: Users provide their credentials to obtain a “session”, which is a window of time on which they can perform any action. After the clock runs out, they’re unauthenticated, and have to log in again if they want to continue.
You’ve probably guessed why that’s problematic in payments: hackers who obtain a session, either by getting the username and the password or by cookie poisoning, can do anything during the lifetime of that session.
Dynamic Linking doesn’t operate that way. It is transactional-based, which means that each authentication is tied to a specific action.
Even when the customer has to do a little bit of extra effort, it pays off because hackers would have to overwhelm the customer with authentication requests. Even the most clueless would scratch their heads when they received their third SMS.
And that’s my biggest takeaway from my research on Dynamic Linking. I’m very used to receiving short notifications from my bank. I have never before stopped to think about them.
But they are so clever. These SMS are very forgettable for all of us individually. But we are quick to pick unfamiliar patterns (like multiple authentication SMS in a few short seconds), and that’s what makes this channel unbreakable.
Even for 70 year old ladies with an old flip phone.
And that’s a kind of trade-off that I hadn’t encountered before.
Now it makes sense why banks are not worried about how vulnerable SMS communication is. They’ve created a system that leans into that vulnerability to provide widespread access to banking.
The Internet was engineered to make open communication possible, but encryption and cleverness makes us trust it too much. We’re now flooded in online chitchat, unable to separate the insight from the noise.
Hackers thrive because we click links mindlessly.
We don’t receive SMS that often anymore. And that’s why they work.
We pay much more attention to them.
This has been The Payments Engineer Playbook. I’ll see you next week.
PS: I want to ask you a question.
You’re in the middle of a multi-year long software project. You’ve nailed some things, but you also made some mistakes along the way. You certainly have a clearer picture of what the project needed in the beginning, and what was superfluous.
This is my question: How much would you paid, back in the early stages of the project, to have access to someone with that insight?
I believe that the biggest reason software projects fail is not a lack of technical knowledge, but a lack of domain knowledge.
But because most companies hire for technical skills, those engineers who have a deep understanding of the domain their in (read: they’ve made the same mistakes before) are seen as better, indispensable. They’re promoted faster. They are paid attention more often. They have influence and leverage.
Building payment systems, I’ve already nailed some things and made some mistakes. Thanks to it, I have a clearer picture of what payment systems need, and what is superfluous.
And I’m offering you access.
Every Wednesday, you’ll get an article, just like this one, full of insight, lessons learned and common mistakes, about a particular aspect of payment systems. All tailored to engineers who build money software. Payments engineers.
For $15 a month, or $149 a year, you can read them all.
If being able to avoid the mistakes your competitors are making when building payment systems is worth to you, I suggest you pledge a subscription for 2025.
Because at the beginning of next year, the price is going up. And as an early subscriber, I don’t want you to miss the chance.
And if someone you respect shared this article with you, do me a favor and subscribe. Every week I feel I’m getting better at this. That means that my best articles on how to build payment systems are probably yet to be written.
You can only find out if you subscribe to The Payments Engineer Playbook. I’ll see you around.