Digital Banking: Digital banking has transformed how customers engage with financial services, shifting traditional branch-based operations into intuitive,
always-available digital experiences.
This evolution has empowered customers with greater autonomy, while FinTechs continue to accelerate innovation and challenge the boundaries of traditional banking models.
This page reflects my structured understanding of digital banking concepts, based solely on publicly available information.
The snippets and diagrams presented here are conceptual summaries
informed by industry standards and best practices.
Content:
1. Issuer Mobile Banking App
2. Issuer Wallet
Figure 1 - Brief Overview:
In modern digital banking ecosystems, financial institutions offer an Issuer Mobile Banking App that allows
customers to perform a wide range of banking activities directly from their mobile devices.
To accelerate go-to-market (GTM) for features that require significant engineering effort, issuers can choose to
integrate third-party SDKs that abstract complex workflows and reduce resource overhead.
For example, implementing Push Provisioning for major Digital Wallet Providers (Apple, Google, Samsung) typically requires issuers to review and
integrate three separate API specifications. By using an SDK, the issuer’s mobile banking app can rely on a reduced number of APIs to implement the required feature,
streamlining integration.
Because the mobile banking app displays sensitive card information, plaintext card data cannot be exchanged between the Issuer Mobile Banking app SDK and the third-party SDK’s APIs.
To protect cardholder data, an encryption key1 is used to encrypt sensitive fields such as the PAN, expiration date,
and CVV2 before transmission.
SDK: Software Development Kit
Push Provisioning: A wallet-provider feature that allows cardholders to push card information (e.g., PAN, Expiry Date) from the issuer’s app into xPay wallets.
Encryption key: A key composed of an API key and shared secret, used to encrypt sensitive data (PAN, Expiry Date, CVV2).
PAN: Primary Account Number. It is the 16-digit number identifying a physical or digital payment card.
CVV2: Card Verification Value. The 3-digit code printed on the back of the card, used during provisioning and certain e-commerce transactions.
Public documentations:
1. Visa's VDE SDK Push Provisioning
2. Mastercard's Push Provisioning to Wallet
3. Mastercard's Google Pay Push Provisioning Sequence Diagram
Figure 2 - Brief Overview: In markets where xPay wallets are not available or due to regulatory restrictions, issuers may choose to develop their own NFC enabled issuer-branded wallet.
In this setup, the issuer becomes the Token Requestor and is identified by a unique Token Requestor ID (TRID).
A specific range of the issuer’s BINs is configured within the network scheme’s systems to support the issuer's card tokenization.
An issuer-branded wallet requires two major implementation components:
1. Token Requestor implementation, and
2. Issuer implementation
When an xPay wallet is used, the xPay wallet provider handles the Token Requestor responsibilities and provides a ready-to-use interface. The ready-to-use interface provided eases integration allowing issuer to focus on the Issuer Implementation only.
In contrast, an issuer wallet must integrate with several parties:
1. the Token Gateway Service provider's APIs,
2. the scheme's network tokenization APIs for Token Requestor and
3. the scheme's network tokenization APIs for issuers.
While Issuer branded wallet implementation is complex, it provides the first step to be platform ready for Tokenization.
Issuer wallets have been mostly implemented as HCE wallets and rely on Limited Use Keys (LUKs) to generate device-bound cryptograms.
LUKs are dynamic keys with a set of parameters that controls its lifespan.
When any one of those parameters is exceeded, the network scheme generates a new LUK and notifies the issuer wallet to fetch it or the wallet can notify the network scheme
to generate a new LUK if the device LUK parameter has exceeded.
The issuer wallet then loads the new LUK onto the device and uses it to generate subsequent cryptograms for future payments.
During installation of the issuer wallet, the cardholder will be authenticated and Identity Verification (ID&V) will be performed.
Once authenticated, the device is registered and the issuer wallet retrieves and displays issuer’s own card arts.
Each card arts represent a card with an associated PAN. It must be tokenized before it can be used for NFC payments.
Tokenization follows the green flow path returning response code 00 (Approved) for the Token Activation Request (TAR) —because the cardholder has already
completed a rigourous Identity Verification (ID&V) when the issuer wallet was installed and after logging into the issuer wallet.
Device-bound cryptogram: A cryptogram generated by the wallet based on data elements from the device, the wallet and the HCE token in the wallet.
Green flow path: There are several colored paths for Tokenization: Green, Yellow, Orange, Red. Each determines how a token will be created based on risk parameters.
A green path means that no further identity verification is required, the token must be created and activated immediately.
Response code: This is a code that is returned by the Issuer or the Scheme's network in STIP in a response message.
TAR: Token Activation Request. It is an ISO based 0100 request message.
1 more info: RFC 7516 - json web encryption (jwe)