[#59] From Card Networks to Credential Networks: Visa & Mastercard’s Next Big Move?

Moves by Visa, Mastercard, and even RBI's FY25 payment's vision suggest that the burden of first level authentication is moving away from issuers

So I recently read RBI’s FY25 payments vision. RBI’s FY25 payments vision talks about weaving in alternate forms of authentication, and moving away from OTP based forms of auth, because of general risk related to phishing, and release of confidential customer details. So I generally expect a lot of authentication based innovations, both from existing and new players to come in from the next year. It’s already started: with things such as Mastercard Passkeys (biometric based approach), Silent Mobile Verification (a telecom based approach), and I’m sure others coming in. This is something I was discussing with Anitha (Associate Director - Product @ Razorpay)

But the thing here is: it’s not that easy to launch new authentication systems. Authentication has always been issuer bank driven (this is the customer bank), where after payment, it’s the issuer bank’s job to do the verification of the user entered credential: this could be the PIN, in the case of UPI, or the OTP, in the case of card payments (in India). In the US, 2FA is not mandated, so card payments are way more seamless. In India. RBI has mandated OTP based auth for online payments.

But there have been some changes in the ecosystem that make it seem that there is an opportunity to move the burden of first level authentication away from the issuer bank, to other parties. Which could be: a telecom player, it could be mastercard / Visa itself, or even a third party, which is plugged into one of these ecosystems.

In some of these newer forms of authentication (Mastercard Passkey), the burden of first level authentication lies with a party that is NOT the issuer bank. In others, the credentials & the unique key pair sit behind a layer of biometric authentication, which unlocks the card credentials that are then sent to the issuing bank for verification (such as Face ID, and other forms of biometric auth)

But to understand where the disruption in authentication is coming in, first we need to understand how payments authentication currently works

It’s different for cards & UPI, and other methods, but overall, the flow of customer information remains the same: in its current form, all authentication, both first level (customer input) and second level (fraud, customer behaviour checks) are done by the issuer bank. Also, there’s a concept of Multi Factor Authentication. 2FA, stands for 2 Factor Authentication, which means that 2 factors out of the multiple need to be authenticated for the payment to go through.

Multi Factor Authentication:

1) Something you have: Phone, Device
2) Something you know: Password, Pin
3) Something you are: Face ID, fingerprints, retina scan

All the existing and newer authentication processes (atleast for India) will have to meet 2FA. Cards for example handles 2FA through: Something you know: Card number, CVV & Something you have: Device (which receives OTP)

1) Payment authentication for cards (could be debit or credit)

Let’s say a payment request is triggered at a merchant checkout. Then 2 things happen:

1) 3DS Secure Authentication - this is the OTP step in card payments: For those merchants / geographies where 3DS secure is mandatory, the merchant sends the auth request (with the customer BIN number) to the MPI (merchant plug-in), which connects to the network DS (Directory Server). The DS is a 3rd party database of mapped card numbers to appropriate ACS (Access Control Server) of each issuer bank. Each network has its own DS. At the merchant side the BIN number (first 4-6 digit of the cards) is used to identify the network, and thus, which DS to send the card details to, which in turn checks its central mapper, and sends the ACS url of the appropriate bank. The ACS of issuer banks are enrolled with the DS by providing BIN ranges of issued cards. That’s how the DS identifies the correct card, and sends the appropriate ACS url.

2) Issuing bank conducting BE checks: The DS then lets the acquiring bank (the merchant’s bank) know of the successful authentication. The acquiring bank routes the request, along with customer card details to the issuing bank (customer bank) via the network -> which could be Visa, Mastercard, UPI, Rupay or any other payment rail. The issuing bank then conducts various fraud checks, such as unusual spending patterns, if the card is valid, if there are sufficient funds available. And then after auth, the issuing bank transfers money to the acquiring bank, post which it goes to the PA escrow account, and is then deposited into the merchant account (less fees). If the card is tokenized, then it’s just an extra layer of security, because here the sensitive card details are not stored by merchants. Note: In the US, there is no mandate for OTP, but in India, OTP is mandated for all online payment flows, including tokenized cards.

To see how the flow of information works, please see below:

2) UPI Auth follows the same process in terms of rails: but here, there is an entry that is compared to a saved data point (which is the PIN)

In the case of UPI, there is a one time PIN set up, at which time the PIN is set up , encrypted and shared with the issuer bank. So when a customer comes and authorizes a payment using their PIN, it is encrypted and shared with the issuer bank (through something called a CL, which is NPCI’s Common Library). The issuer bank then compares the customer entered PIN, with the one stored in their systems, and if it matches, then the payment is authorized. And post transaction money movement happens. Money moves from issuer, to acquirer, to PA escrow, to the merchant account.

Now, for all cards, and all accounts such as UPI, the credentials for each are different. Each savings account, for UPI needs a separate PIN set up (you can obviously set up the same PIN for multiple accounts, but you still need to go through the set up process).

Takeaways: one credential per account, and all first level authentication is issuer based

1. Each account / card has a specific credential - which can be card number / CVV and then subsequent OTP. And for the PIN, it’s a separate PIN for each account. You cannot use one credential in another transaction

2. While the other third party players act as routers, the validation and authorization at the end of the day, happens by the issuer bank. They are taking the burden of first level authentication of the customer. There are also other checks that happen from a fraud / risk perspective which is more back end, but here, the issuer bank also takes responsibility for validating the customer input. Nothing wrong with this, but the story then becomes the same: Outdated systems, and slower to build & innovate, and actually implement some of these newer and more secure forms of authentication. Also banks are notoriously slow in any sort of innovation, and changes here would require time and investment from banks. This is the same logic as to why payment fintechs are investing in their own infra, such as card and UPI switches. More control = faster GTM.

So now, here is where Visa’s Flexi Credential & Mastercard One Credential comes in, they’re trying to 1) reduce the number of credentials that a customer needs to use multiple accounts and 2) reduce the burden of auth from the issuer bank

By reducing the number of credentials a customer needs, you’re reducing “credential fatigue”, but more than that, you’re also in a way trying to standardize authentication across different methods. And this also helps to make issuer banks more efficient → you have to store less data.

Let’s look at Visa Flexi Credential first: at its core, it’s trying to map all VISA cards in one issuer bank to one card, instead of having one card per account

Visa has basically come in and said: Hey! A lot of customers have multiple cards / funding sources from one issuer: it could be a debit card, multiple credit cards and so on. Why do they need to save / tokenize a separate card, and remember a separate CVV for each one? They should just be able to save one VISA card on let’s say HDFC, and that should allow them to access all Visa - HDFC accounts. Mastercard has launched something similar called One Credential.

So, the payment request is triggered the same way. It goes to the DS, which routes it to the ACS, which then authorizes the payment, and then the issuer does all its fraud checks. But now, here there are additional steps not from a customer input perspective, but an issuer account routing perspective:

1) While authentication happens the same way, now, the same credential is linked to multiple accounts. So the issuer has to manage their systems to ensure that multiple accounts are mapped to one card. While this will require a change in systems (and is not an easy task), it could help to reduce the amount of information stored in these bank systems, and optimize them.

2) The Flexi / One Credential offering also provides APIs & infra (if the issuer bank wants it) to set up pre-defined rules for routing the payment to the specific customer account. For example: as a customer, I may want all my transactions above INR 2k to happen via my credit card. And below 2k to happen on my debit card. These rules can be set up at app level (example: Gpay / Apple Pay) and are communicated to the issuer system through APIs, but the issuer has to manage and implement them. So here, after authorization, based on the pre-defined rules that the customer has set up, the issuer bank has to route the transaction to the correct account, and communicate the same to the acquiring bank.

Visa Flexi Credential enables all of this by providing APIs to issuers for seamless integration in their system. There is a card enrollment API, a relationship management API (that helps manage the mapping between the card, and the multiple funding sources, which is needed for dynamic routing. There are also 2 models for rule management: Visa offers both storing rules in Visa infra OR the issuer maintaining and managing rules in their own Infra.

The multiple credential problem is solved, which makes issuer systems more efficient, because there is no need to save multiple credentials for multiple accounts, but rather, one credential per person. But is this better from an end customer perspective?

I am not too convinced.

1. I don’t have to save multiple cards on my consumer payments app: So 1 step saved here. But this is a one time step, and not something I have to do every time. So this feature in Visa Flexi Credential is saving me a one time saved card set-up that anyway does not take too long.

2. Pre-defined rules for routing saves 1 step: Instead of opening the app, and selecting a card, I can now select Visa, and leverage dynamic routing based on rules set up by me (the end customer).

3. Setting up rules for routing: This adds 1 step, but it is a one time set-up.

4. It doesn’t work yet on merchant website / apps: Currently merchants today store credentials as static Device Account Number (DANs) or tokens, tied to a specific funding source. There’s no way (yet) for a merchant to “ask” the credential: which account do you want to debit today? So currently, each funding source needs to be saved separately on the website. But this is something that can come in, in the future if there are ecosystem changes -> The tokenized credentials can point to a Flexi ID, or a phone number, instead of a specific funding source / or integrate with Visa APIs / issuer side logic to determine funding source at checkout.

Together, both these steps of saving multiple cards, and selecting a card at the time of payment, are solved, and one step: that of adding rules for routing is added. But is this really something that the customer needs solved? From a customer experience perspective: making payments is a dynamic process, there are a lot of decisions that go into this: it could be some offer that is available at the point on a certain method of payment and so on. It’s tough to account for all of this while setting up these dynamic rules for payment. So I don’t know if customers will take to this. I personally would have apprehensions.

Consumer side apps are anyway solving for multiple payment methods, from multiple networks, and multiple issuers.

In fact, in the US, where 2FA is not mandated, the only extra step the customer has to do is select the card / fund source they want to pay through. And in India, 2FA is mandated, so no matter what you do, the OTP step is required.

So this “credential fatigue” thing is already being solved at the app level. Even things such as routing can be solved at app level, where I can scan / tap the payment device o the QR, and depending on routing rules, the app can auto select the method that I want to pay through, and take me to that specific authentication process. Saving the customer the “1 extra step” of having to save their cards is not a serious value add in my opinion.

Another challenge of Visa Flexi Credential is that it only works across cards on the same network, and on the same issuer bank

And there are challenges of this Flexi Credential: It only works on cards from the same bank & network. So, it’ll work across all your VISA cards from HDFC bank. But if you want to use, let’s say a VISA card from Axis bank, you’ll need to save another card for that.

You can’t use this across different issuing banks even if the network is the same, since

1) Each issuer is responsible for managing their own fraud risk checks
2) Visa doesn’t have a centralized view across issuers, so it can’t map one credential across multiple issuers, and help route it to banks accordingly (just yet). And even in the the case of rules for dynamic routing, this sits with the issuer
3) Visa Flexi Credential does offer an option, where rules are stored with Visa, which manages the tech aspect of this, but even in this case, Visa only helps to facilitate communication, and rule management. It doesn’t manage account level decisions.

So in Visa Flexi Credential, it’s solving for issuer side efficiency. But from a customer perspective. But the challenge of the first level auth being issuer led still remains. Although, the way Flexi Credential has been set up, it’s possible that the vision for this product: own more pieces of the authentication across issuers until it’s completely offloaded to Visa. And this is just the first step to get user feedback and gauge PMF.

Mastercard Passkey solution is different: it retains control on the first level check of the customer, the issuer only does the backend checks, which do not require customer input

The Mastercard Passkey solution is slightly different from how authentication is currently done. (Even Flexi Credential for all its bells and whistles, at the end of the day still depends on 2FA / issuer side authentication and authorization)

Mastercard Passkey utilizes cryptographic keys that sit behind a biometric authentication layer (this is face ID). How does this work?

1. When the customer sets up their passkey, they are required to set up their biometric ID, which is done using device APIs (Android or iOS APIs)

2. The biometric creds (which could be Face ID, fingerprints) are encrypted, and stored within the device, within something called a Secure Enclave. And at this time, a passkey is created, which is a public - private key pair. The Private key is stored within the device, and the Public key is stored in Mastercard servers.

3. At the time of authentication, the biometric creds unlock the access to the private key, which then signs a challenge, and sends it to Mastercard servers, which compares it to the public key that it has, and confirms that the customer is who they say they are.

This meets the 2 Factor Authentication Framework through: 1) Something you have: Phone (where private key is stored) 2) Something you are: Face ID

4. After successful biometric authentication, the acquiring bank then sends customer encrypted details to the issuer bank via Mastercard rails which does backend checks (which do not require user input) to authorize the transaction. The issuer still performs fraud checks and approves or declines the payment based on its own criteria. But this is second level checks: primary check is done by Mastercard.

So this is promising because here the first level authentication of biometric credential & private - public key authentication is happening by a 3rd party, which is not the issuing bank. And since issuers are notoriously slow at innovating, by carving this out, it could help increase the speed of innovation. Not to say the Passkey method is perfect, it currently involves multiple redirections, and it’s definitely not a seamless process today but these are things that can be worked on.

This may seem similar to Apple FaceID, but there is a key difference: Apple FaceID just unlocks access to the stored tokenized card details. Post biometric auth, the tokenized card details are still routed to the issuer for authentication

This is slightly different from Apple FaceID: Here, when the card is saved in ApplePay, a DAN (Device Account Number) and a public - private key pair is created. The DAN and the private key is stored in the device, and the public key is stored with the issuer bank (sent by the network). The DAN is created by the network. At the time of payment, the FaceID authenticates the user, and unlocks access to the DAN and the private key. A dynamic cryptogram is created (this is different every time), using the private key, signing the details such as the DAN, the timestamp, transaction amount and merchant info. This is passed to the merchant’s acquirer, then to the card network, and finally to the issuer bank. The issuer sees the DAN, decrypts it to get the actual card number, verifies the cryptogram, and approves or declines the transaction.

Mastercard Passkey also has potential to enable cross device passkey sharing

Mastercard Passkey is a browser based solution, so it automatically opens up authentication on Desktop Web: and it allows cross device passkey sharing. You can even actually do this for your google accounts, where you can sign in onto your desktop google account by using the passkey saved on your phone. UPI in comparison can only happen through the mobile device.

But an interesting point here is “cross device passkey sharing.” I’m sure all of us have used google password manager, or iCloud keychain. At its basic: these are password / passkey managers. You’ve basically got to download these password managers on all your devices, and sign in on all devices through the same account. Then when you create a password on one account then it’s automatically synced across devices.

The logic for passkey sharing here is similar. There is still a layer of biometric authentication. The catch here though is setting up biometric credentials is device specific. You can’t do a one time set up across devices. You have to set it up on your phone, your laptop, and whatever other device you choose to pay through. The passkey manager allows for communication between the two devices (assumed you’ve signed into both using the same account).

The private & public key pair is a one time set-up, and is managed using cloud services (such as your password manager). Then when you choose to authenticate, let’s say on your desktop, you can select to pay through passkey (assuming you’ve set up your public private key on your mobile, and set up your biometric creds on your mobile and your desktop). That’s when you’re redirected to the mastercard page to enter biometric creds. Your biometric creds are authenticated against the locally stored and encrypted biometric creds (the browser to mobile communication happens through webAuthN protocols). The communication to unlock the private key in the mobile through cloud services. This can also happen through QR code pairing: for mobile & desktop.

Again: not perfect. But adds an extra layer of security, since biometric creds are that much harder to fake. And opens up cross device authentication, for other payment methods such as UPI (although should it be more passkey based, or more like Apple Face ID is something to be figured out. It also depends on how much control the issuer is willing to let go of, UPI anyway is a seamless payment method, which invites frauds_

So while Flexi Credential is more of a one credential fits all, and the issuer is still doing first level checks, in Mastercard Passkey, while the issuer does backend checks, the first level checks are being handled by mastercard.

So there are some interesting implications of both of these. But the key here is that players such as VISA and Mastercard are looking to own a bigger piece of the authentication landscape. These solutions are not optimized just yet, but this is just the first iteration. Eventually, it’s possible that the first level authentication of these “alternate creds” moves to 3rd parties. This will definitely drive innovation.

It’s unlikely that this is the end game. This is probably just the first step in a series of steps to redefine how authentication works. Eventually, it looks like, atleast with Mastercard Passkey, that they want to move out first level authentication from being a issuer play, to a Visa / mastercard play. Issuer banks still take care of backend fraud checks, but that is not a user input.

Authentication in itself is a big TAM, with a lot of complexity, and could provide opportunities to build, but the right to win remains with established players

The TAM is big: The passwordless authentication market is projected to hit ~$33B by 2033 (source). And this is something that is charged per attempt, like how SMS OTP based auth is charged. Maybe that’s why Mastercard and Visa want to get in deeper here. But the right to win for newer players is tough. This is a highly regulated market. And consumer and stakeholder trust is paramount, which bigger players who have been operating in this space have. Distribution also matters: the more consumers use your product, the more value it has, and you can offer it as an alternate way to authenticate. And even from going deeper into the issuing side: these are conversations that are had with banks over years. So the Right to Win (RTW) is more for existing players: Ex: Mastercard, Visa, even PA/PG or UPI players such as Razorpay, PhonePe and so on. Distribution, brand name and regulatory burden should be taken by the bigger fintechs (ex: Visa, Mastercard). The opportunity for newer players here could be more on the backend side, in terms of actually innovating on some of the passkey, and biometric flows, which can then be integrated with existing systems of fintechs and banks.

But if systems like Mastercard Passkeys & Visa Flexi Credential become widely adopted, there is a potential to take away auth burden from the issuer, and expand into auth & log-in services (think google account sign in to multiple accounts)

1. Third-party networks like Mastercard & Visa could centralize authentication across multiple issuers: And that’s probably what they’re headed towards. Visa Flexi Credential already offers a solution where rule management can happen within Visa’s infra. While VFC is currently issuer-centric, Visa could theoretically expand its role in the future by creating a "network of networks" that enables multi-bank routing, through a centralized rule engine. Here’s how it might work:

   1. Visa infra has rules, and integrated with multiple banks, so it can allow rules, across multiple issuers. Right now, routing can only happen to accounts within an issuer. But in the future, if Visa has that visibility, it can be routed across multiple issuer banks. Visa can act as the intermediary that enforces these rules during transactions.For example:

      1. "Use my Bank A debit card for transactions under $50."

      2. "Switch to my Bank B credit card for purchases over $50."

2. Issuers would offload authentication responsibilities while retaining control over authorization and fraud management. Biometric authentication or PIN authentication burden shifts to a third party (Mastercard, Visa, Razorpay, Phonepe), streamlining payments while maintaining security through globally accepted standards

3. Payment experiences would become more seamless & interoperable globally as biometrics replace traditional methods like OTPs and passwords. And biometrics & passkey based solutions are interoperable: for example today how you can sign into multiple places using your google account, tomorrow you could sign in / authenticate using a Mastercard / Visa type passkey solution, where these players take the burden of authentication, and confirm it with the requesting party, which could be for payments, identity verification, log-in or anything else. In fact, this is a key for blockchain based payments:

There will be challenges here: Banks may resist giving Visa more control over their customers' transactions due to competitive concerns, Customers may have privacy concerns about sharing their account preferences and data with a central entity like Visa, and Coordinating real-time routing across different banks' systems would require significant technical upgrades and global standardization.

But the Mastercard Passkey is promising, from an issuing play. And Visa with its Flexi credential looks like it’s taking the first step in a road to playing a bigger role in authentication.And maybe this is an avenue of disruption and innovation.

Credits: Shoutout to Anitha Krishnakumar, who helped me think through some of this stuff.