Securing payments in fintech today feels like walking a tightrope, every step requires balance. Fall too far into the usability camp, and you risk non-compliance. Overcorrect for security, and your users might walk away. We recently helped a mid-sized EU fintech walk this line by designing a Strong Customer Authentication (SCA) flow with dynamic linking balancing compliance, practicality, and user experience.

Why PSD2 & SCA Are the Real MVPs of Secure Payments

Imagine this: you're approving a payment through your favourite fintech app, and a code shows up via SMS. You enter it, and everything just works. But under the hood, how does your bank or app know that the code is valid, and that it’s tied to the specific payment?

That’s the challenge PSD2 addresses. It mandates that all electronic payments in the EU be authenticated using Strong Customer Authentication (SCA), a combination of:

• Something you know (like a password),
• Something you have (like your phone),
• And something you are (like a fingerprint).

And to prevent fraud, dynamic linking requires the authentication to be tied to both the amount and the payee, so even if a code is intercepted, it’s useless for any other transaction.

A Real-Life Case: What We Built for Our Client

Our client, a growing EU-based fintech, needed a solution fast. They wanted a PSD2-compliant payment flow that was secure, easy to use, and quick to deploy.

Here’s what we built:

• We integrated Twilio’s Verifier API to send users a one-time SMS code at the point of transaction. The code was implicitly linked to both the amount and the payee.
• On the backend, we added a validation layer to confirm that the code the user entered matched the exact transaction they were authenticating. If anything didn’t align, wrong payee, wrong amount, the transaction was rejected.
• We created a simple UI flow that didn’t overwhelm users with information, but still fulfilled regulatory requirements in the background.

This system helped our client check all the boxes for SCA and dynamic linking, while keeping the experience smooth for users.

‍

The SMS Dilemma: Why We Chose It Anyway

Let’s be clear: SMS isn’t the most secure channel out there. SIM-swapping, interception, and spoofing are real threats. But in this case, accessibility and simplicity won out.

• Our client needed broad user coverage across Europe, including users who may not have the latest devices or mobile banking apps.
• They also needed a solution that could be deployed quickly, without months of development.

By combining SMS with robust backend verification, we made it work. Even if someone intercepted a code, it would only be valid for one specific amount and payee, rendering it useless for any fraudulent attempt.

We also scoped out alternatives like app-based OTPs and biometrics, but they would’ve added weeks to the timeline and limited reach. SMS, paired with the right logic, was the right fit.

But It Comes at a Cost

Choosing SMS wasn’t just a security compromise, it was also a cost-conscious decision.

Here’s what we were weighing:

• Infrastructure and tooling: App-based or biometric authentication would’ve required custom app updates, secure storage, and integration with OS-level APIs (like Face ID, Google Authenticator, or device fingerprinting tools).
• Time-to-market: Alternatives could’ve added 4-8+ weeks to implementation and testing, especially in regulated environments with approval gates.
• Maintenance overhead: More sophisticated authentication systems require constant updates, device support testing, and fallback flows for edge cases.
• User support load: Not all users are familiar with in-app OTPs or biometrics. That increases the risk of support tickets and failed transactions.

So while SMS isn’t perfect, it gave us the widest reach, lowest development friction, and fastest path to compliance,without compromising the dynamic linking requirement mandated by PSD2.

‍

In short: SMS wasn’t just the easiest option, it was the only one that met the timeline, budget, and technical reality of the project.

‍

Building for the Future

Not every company is ready to roll out biometric scans or behavioural authentication just yet. And that’s fine. You don’t need to be first, you just don’t want to be last.

This project proved that practical compliance is achievable with modern APIs and smart backend design. Even if your infrastructure isn’t bleeding edge, there’s a path forward.

We’ve already outlined next steps for the client that include:

• Optional app-based authentication for power users
• More robust fraud detection via device fingerprinting
• Adaptive MFA depending on transaction risk level

All of this can be phased in over time, without a total system overhaul.

Main Takeaways: 5 Things to Remember

• Dynamic linking isn’t optional, it’s a key requirement under PSD2. Don’t skip it.
• SMS can still be viable, if combined with strong backend validation and clear user-flow.
• APIs like Twilio’s Verifier gives you the agility to meet compliance without slowing down.
• Real compliance isn’t just about boxes, it’s about system design. Build authentication that checks the right boxes and support users.
• You can evolve over time. Today’s MVP can become tomorrow’s secure, seamless platform, with the right foundations.

‍

Final thought

We’re proud of how this solution came together. It showed us (again) that with the right approach, security and usability don’t have to be enemies. You can walk the tightrope, and make it to the other side.

It goes from “can we do this” to “should we?” and “how much of a mess will it be if we get it wrong?”

These aren’t just technical hurdles - they're business/trust issues. You're putting financial functions closer to your core systems and to your people. That requires confidence, not just curiosity. So let's quickly walk through the biggest concerns we hear- and why they might not be as painful as they seem.

‍