How a European bank built its PSD2 strong authentication on its own identity foundation
How a European bank built its PSD2 strong authentication on its own identity foundation
A bank that sets out to add strong customer authentication usually expects the hard part to be the authentication itself: which factors to combine, which app to roll out, how to clear the regulator’s bar. The harder question often sits one step earlier. Where do the user identities actually live, and can anything authenticate against them today?
We worked with a private bank in Europe that came to us for strong customer authentication, SCA in the language of PSD2, for the customers using its online banking. The requirement was clear, regulator-driven and on-premises by necessity. What became clear as we looked closer was that the project was wider than the request. The bank had moved on this ahead of where many peers in the same segment still are, and the scope kept widening as the work progressed.
Where the user identities actually lived
The bank’s customers had no directory of their own. Their identities existed only inside the previous e-banking solution, held in its database, where they had accumulated over the years. That is a common situation, and it works well day to day. It starts to show its limits when you need to apply a consistent authentication layer in front of those users, which is where strong customer authentication enters the picture.
So modernizing authentication started one step earlier, by giving those identities a directory of their own. We stood up an on-premises OpenLDAP for the bank’s customers and migrated their identities out of the previous e-banking database into it. Accounts that had only ever existed inside the application could now be managed centrally through WebADM, our core IAM console that provides web-based directory administration, runs OpenOTP and the on-premises identity provider, and federates on-premise and cloud identity sources.
Why the identity layer had to stay on-premises
For a bank, where authentication data sits is not a deployment preference, it is part of the control surface. Here the directory, the authentication server and the access policies all run on-premises, inside the bank’s own environment, with nothing about customer authentication leaving it. We deployed WebADM and OpenOTP (our multi-factor authentication server) as a high-availability cluster, fronted by two reverse proxies that expose only the end-user facing services to the outside, and we built the whole thing across separate UAT and production environments so that changes could be validated before they ever reached live customer access.
What PSD2 strong customer authentication asks for, beyond a second factor
The bank framed its need in terms of Strong Customer Authentication (SCA). In practice, SCA is more than a second prompt at login: it defines how authentication factors are combined and, for a bank, extends to payment authorization itself. We first delivered strong authentication as the foundation: an on-premises identity provider backed by WebADM and OpenOTP, providing MFA for the bank’s online banking customers. In an open-banking context, however, authentication should be distinguished from customer consent: login verifies the user’s identity, while consent to access account data or initiate payments must be captured through the applicable PSD2/Open Banking flow.
Securing the payment itself, not just the login
Login authentication answers one question: is this the right person? PSD2 asks a second question at payment time: did this person approve this specific transaction, for this amount, to this payee?
That is transaction approval, and it is where the scope widened again. We implemented it so that, when a payment is initiated, the transaction is presented to the user in the mobile app for explicit validation, with the payment details clearly displayed before it can proceed.
The authentication factor is therefore no longer used only to prove identity at the door. It is also used to confirm a specific operation, cryptographically and contextually linked to the transaction being approved.
Integrating with the Open Banking System and interbank payments already in place
A bank does not run authentication in isolation. Both strong authentication and transaction approval had to fit into two systems that were already in place: the Open Banking system used for the bank’s online and open-banking services, and the domestic provider the bank relies on for interbank payments.
Neither system was going to be replaced to suit an authentication vendor, and neither provided a ready-made integration point for the required approval flow. We therefore developed custom middleware to carry the payment context through to validation and to connect the authentication and transaction-approval flows into both systems.
The request was for Strong Customer Authentication. Meeting it properly meant giving identities a dedicated authentication layer, keeping that layer on-premises, extending authentication beyond login into payment approval, and writing the integration code needed to work with the systems already in place rather than around them.
Yes. Where user identities exist only inside an application, they can be migrated out into a dedicated on-premises directory first, so they can be managed and have authentication policies applied, before any MFA is added.
No. Beyond authenticating at login, SCA reaches into payments through transaction approval, where the user validates the specific transaction, amount and payee on a mobile app before it can proceed.
Yes. The directory, the authentication server and the access policies can all run on-premises inside the bank’s own environment, deployed as a high-availability cluster.
Yes, RCDevs is a European vendor and OpenOTP can be deployed fully on-premises, with all identity data, authentication policies, transaction approval flows and logs remaining within the bank’s own environment. There is no dependency on a non-European cloud, and customer authentication data does not transit through a vendor tenant.
When a payment is initiated, the transaction details, including the amount and the payee, are displayed in the customer’s mobile app for explicit validation before the payment can proceed. This links the authentication factor to the specific operation being approved, which is what PSD2 dynamic linking requires.
Not necessarily. When there is no Active Directory in place, identities can be held in an on-premises OpenLDAP managed by WebADM. RCDevs also provides its own Directory Server for environments without any existing user directory.
