Module 3

Open Banking Infrastructure

How APIs and payment initiation services enable commerce outside traditional payment networks

---

What Is Open Banking: Regulation That Became Infrastructure

Open banking is not a technology. It is a regulatory framework that forced banks to expose customer data and transaction capabilities through standardised APIs. The regulation came first. The market infrastructure came second. Understanding this sequence is essential because it explains why open banking works: regulators mandated it, banks implemented it grudgingly, and the market discovered unexpected use cases that made the infrastructure valuable.

PSD2 (Payment Services Directive 2), implemented across the EU in January 2018, was the first regulation to mandate open banking at scale. The directive required all banks in the EU to provide APIs that allowed third-party providers to access customer account information and initiate payments on behalf of customers. The goal was to enable competition and reduce the lock-in power of incumbent banks. The consequence was an entire new infrastructure layer for payments.

Open banking regulations were designed to increase competition and reduce bank monopolies. They succeeded by accident at creating new payment infrastructure that is faster, cheaper, and more flexible than anything the banks built themselves.

The regulatory mandate is key. If open banking APIs were optional, banks would provide minimal connectivity and try to monetise access. Because it is mandatory in the EU, all banks must provide APIs with defined performance standards and support requirements. This creates a level playing field where any third-party provider can build payment applications on top of bank infrastructure.

The Two Core Services

PSD2 defines two main categories of services that third parties can provide. The first is Account Information Services (AIS). An AIS provider has permission to view your account information: balance, transaction history, standing orders, direct debits. The customer logs into the AIS application, gives permission to connect to their bank, and the AIS provider can read their data. This enables applications like personal finance management, expense tracking, investment analysis, and financial planning.

The second is Payment Initiation Services (PIS). A PIS provider has permission to initiate payments on your behalf. You are at a merchant checkout. Instead of providing your card number, you select "Pay with Bank Transfer." The PIS provider authenticates you with your bank, you confirm the payment details, and the PIS provider sends a payment instruction to your bank to move the money to the merchant. The entire process is faster and cheaper than a card payment, and you never share sensitive account information with the merchant.

The distinction is important. AIS is read-only access to account data. PIS is permission to initiate transactions. Both require explicit customer consent and can be revoked at any time. This consent framework is central to how open banking works: the customer controls access and can withdraw permission immediately.

---

How a Payment Initiation Payment Actually Works

The Customer Journey from Checkout to Confirmation

A customer is checking out at an online merchant. They select "Bank Transfer" as their payment method. The merchant redirects them to a PIS provider (or the merchant integrates the PIS provider's UI). The PIS provider presents a login screen and asks the customer to select their bank.

The customer selects their bank and is redirected to their bank's authentication interface. They log in with their normal online banking credentials. The bank's authentication system runs PSD2-compliant Strong Customer Authentication (SCA): typically a combination of username/password plus a one-time code sent to their phone or generated by an authenticator app.

Once authenticated, the customer sees a confirmation screen showing the payment amount and recipient. This is the explicit approval: the customer confirms they want this payment to go to this merchant for this amount. The confirmation is not just a display. It is a security checkpoint. The bank confirms that the customer explicitly approved this specific transaction.

The customer confirms, and the payment is initiated. The PIS provider sends a payment instruction to the customer's bank. The bank processes the payment (typically through a real-time payment network in countries with them available, or ACH in the US). The payment settles within seconds (if RTP) or within 24 hours (if ACH). The merchant receives the payment. The customer sees confirmation in their bank account.

The entire process, from merchant checkout to payment confirmation, takes two to five minutes for a customer familiar with the system. First-time users take longer because the setup of the PIS permission is new to them. But the core UX is straightforward: redirect to bank, authenticate, confirm, done.

What Happens Behind the Scenes

The technical flow is more complex. The merchant integrates a PIS provider's SDK or API. When a customer selects bank transfer at checkout, the merchant sends the customer to the PIS provider with payment details (amount, merchant account, reference). The PIS provider redirects to the bank's authentication endpoint. The bank authenticates the customer.

Once authenticated, the bank's system retrieves the customer's account information relevant to the payment (available balance, linked accounts, etc.) and prepares the confirmation screen. The customer approves. The bank generates a one-time authorisation code and sends it to the PIS provider.

The PIS provider uses this authorisation code to call the bank's payment initiation API, instructing the bank to move the money from the customer's account to the merchant's account. The bank validates the authorisation code, confirms the customer approved it, and processes the payment through its internal systems or through the real-time payment network.

Throughout this flow, the customer's full account information or card details are never shared with the merchant or the PIS provider. The PIS provider only receives authorisation to execute the specific payment that was approved. This is a fundamental security difference from card payments, where merchants receive card credentials that can be used for future transactions (until the card expires).

---

Strong Customer Authentication and the SCA Framework

Two-Factor Authentication That Actually Works

PSD2 requires Strong Customer Authentication (SCA) for all payment initiation. SCA means the customer must authenticate using at least two of three factors: something they know (password), something they have (phone, security key), or something they are (biometric). Most implementations use password plus a one-time code or biometric, which satisfies the two-factor requirement.

The significance of SCA in the open banking context is that every payment initiation has built-in fraud prevention. A fraudster might compromise a customer's online banking password, but they cannot initiate a payment without the second factor (the phone or security key). This creates a structural advantage over cards, where fraud can happen with just the card number and CVV (which are often visible or easily captured).

SCA applies to all open banking payments regardless of amount. There is no threshold where small payments bypass SCA. This means that even micro-transactions require two-factor authentication, which creates friction for certain use cases but dramatically reduces fraud for all use cases.

The Three Implementation Approaches

Redirect approach: The merchant redirects the customer to the bank's authentication interface. The customer authenticates with the bank and confirms the payment. The bank redirects the customer back to the merchant. This is the most secure approach because the customer authenticates directly with their bank, but it requires multiple redirects and can break the user experience if not implemented smoothly.

Embedded approach: The merchant embeds the bank's authentication interface within the merchant's own checkout page using an iframe or Web Component. The customer sees a login form that appears native to the merchant experience, but the credentials are sent directly to the bank's server (not through the merchant). This improves UX but requires more technical sophistication and careful security implementation.

Decoupled approach: The merchant initiates a payment request, the bank sends an out-of-band confirmation to the customer (via phone notification or bank app), the customer approves in the bank app, and the merchant learns that the payment was approved and processes accordingly. This is the smoothest UX but requires the customer to have the bank's app installed and the bank's infrastructure to support decoupled approval.

Each approach involves different tradeoffs between security, user experience, and technical complexity. The redirect approach is most secure and most standardised but creates friction. The decoupled approach is smoothest UX but requires infrastructure most banks are still building out.

---

PSD3 and the Payment Services Regulation: What Changes

The Shift from Directive to Regulation

PSD2 was a directive, which meant member states had to implement it within their own national laws. Different countries implemented it slightly differently, which created fragmentation. PSD3, becoming the Payment Services Regulation (PSR), shifts from directive to regulation, which means a single standardised rule applies across all EU countries with no national variation.

This shift matters because it removes the fragmentation. Under PSD3/PSR, all EU banks must implement identical standards. A payment initiation service built to work across one country will work identically across all EU countries. This is a significant advantage for pan-European payment service providers and merchants.

New Capabilities Under PSD3

PSD3/PSR introduces several new capabilities that extend beyond PSD2. It requires banks to provide access to standing orders and direct debit information through open APIs. This enables PIS providers to offer customers the ability to set up and modify recurring payments through open banking interfaces, not just one-time payments.

The regulation also introduces "variable recurring payments" (VRPs), which allow customers to give permission for recurring payments with variable amounts (like a utilities bill that changes monthly). This is a direct competitor to direct debits and card subscriptions. A customer can give a VRP permission to their utility provider to collect whatever the monthly bill is, up to a pre-defined maximum, without needing a new authorisation each month.

PSD3/PSR also mandates "premium API access" where certain applications can pay for faster, more reliable API access than the standard tier. This is controversial because it introduces tiering into what was meant to be egalitarian infrastructure, but it allows banks to recover infrastructure costs and provide better service to higher-volume users.

Liability Framework Changes

PSD3/PSR clarifies liability for fraud and failed payments in ways PSD2 left ambiguous. Banks are liable for unauthorised payments unless the customer was negligent in protecting their authentication credentials. Third-party providers (PIS and AIS providers) are liable if they fail to follow the security and authentication requirements. Merchants are liable if they fail to authenticate customers properly.

This liability framework creates incentives for everyone in the chain to implement strong fraud prevention. A PIS provider that ignores security issues loses customers and faces liability. A bank that implements weak SCA faces customer complaints and liability. A merchant that accepts payments without proper verification accepts fraud risk. The clarity of liability drives security investment.

---

Open Banking Beyond Europe: Different Models, Same Goal

The United States: Market-Led Vs. Regulatory-Led

The US has no open banking regulation equivalent to PSD2. Instead, the market developed open banking platforms through companies like Plaid and MX. These platforms built connectors to hundreds of US banks, enabling third-party applications to read account data and initiate payments through proprietary APIs rather than standardised bank APIs.

The advantage of the market-led approach is speed. Plaid and MX moved faster than regulation would have required. The disadvantage is fragmentation. Each bank integrates differently. The APIs are not standardised. Plaid and MX have significant power because they are the gatekeepers between applications and banks. The regulation-led EU approach is slower but produces more open infrastructure with fewer gatekeepers.

The US is gradually moving toward more open frameworks. The Consumer Financial Protection Bureau (CFPB) has signalled that open banking regulation may be coming. If the US adopts regulation similar to PSD2, it would likely mandate bank APIs rather than relying on intermediaries like Plaid. This would reduce Plaid's power but increase access for smaller PIS and AIS providers.

Australia: Consumer Data Rights

Australia implemented the Consumer Data Right (CDR), which is similar in spirit to PSD2 but applies more broadly than just payments. CDR requires banks and other financial institutions to provide APIs that allow customers to share their data with third parties. It includes banking data, but also insurance data, telecommunications data, and energy data.

The advantage of the broader approach is that it creates a framework for data portability across the entire financial ecosystem. The disadvantage is that it is more complex to implement and still developing. Australia is moving carefully and has been phasing in CDR implementation across sectors rather than all at once.

Brazil: Open Finance

Brazil implemented Open Finance, which has similar goals to PSD2 but with mandatory participation and more aggressive timelines. Brazil's central bank required banks to provide APIs and began imposing penalties for banks that did not meet the technical standards and response time requirements.

The aggressive regulatory approach accelerated adoption. Fintechs were able to build on top of Brazilian bank infrastructure much faster than in markets with softer regulatory requirements. The quality of the infrastructure varies (some banks provide poor APIs while technically compliant), but the breadth and speed of adoption is impressive.

---

The Platform Stack: Tink, TrueLayer, Token.io, GoCardless, Volt

The Consolidation of Open Banking Infrastructure

Open banking infrastructure is consolidating around a small number of platform providers. Companies like Tink, TrueLayer, Token.io, GoCardless, and Volt build on top of bank APIs and provide standardised, developer-friendly interfaces for merchants, lenders, and other applications to access open banking capabilities.

Tink (acquired by Visa) started as a data aggregation company, then added payment initiation services. They now provide PIS and AIS APIs across 29 European countries. Merchants can integrate Tink's APIs and offer bank transfer payments to customers across the entire EU with a single integration.

TrueLayer (acquired by Mastercard) provides similar capabilities with a focus on payment initiation. They operate across Europe and have expanded into other regions. Their infrastructure handles the complexity of integrating with hundreds of banks and standardising the APIs so merchants do not have to.

GoCardless focuses on recurring and direct debit payments. They use open banking infrastructure to set up and manage Variable Recurring Payments, providing an alternative to traditional direct debits. This is particularly valuable for subscription businesses and utilities.

Token.io provides API infrastructure for open banking across multiple countries. They focus on making the technical integration simpler and more reliable.

Volt provides both PIS and AIS services with a focus on customer experience and compliance. They handle the complex SCA authentication flows so merchants do not have to.

Why Card Networks Acquired Open Banking Platforms

Visa acquired Tink. Mastercard acquired TrueLayer. Why would the card networks acquire open banking platforms that are, in many ways, competitors to card payments? The answer is strategic: they are hedging against the shift away from cards.

Card networks make money from interchange. Open banking payments have no interchange. As volume shifts from cards to open banking payments, card network revenue declines. By acquiring open banking platforms, card networks own the infrastructure they cannot control. They can offer open banking as a payment method through their existing merchant relationships. They maintain revenue by collecting a percentage fee on open banking payments (even if lower than card interchange).

This consolidation has a downside: the independence of the open banking infrastructure is compromised. When card networks own the open banking platforms, the platforms have an incentive to steer customers toward card payments when the margin is better. The goal of regulators was to create independent infrastructure that would compete with card networks. The consolidation has blurred that line.

---

Use Cases: Where Open Banking Replaces Cards

eCommerce Checkout

Open banking is increasingly offered as a payment option at checkout. A customer selects "Bank Transfer" or "Pay with Open Banking" at checkout. They authenticate with their bank and confirm the payment. The transaction settles instantly or within 24 hours (depending on whether RTP is available). The merchant receives notification of payment.

The advantage for the merchant is lower cost (no interchange). The advantage for the customer is lower fraud risk (no card details shared with merchant). The disadvantage is slightly more friction in the checkout flow (additional redirects and authentication).

Subscription and Recurring Billing

Open banking enables Variable Recurring Payments, which are an alternative to card subscriptions. A customer sets up a VRP with a streaming service. Each month, the service bills whatever the customer's current plan costs, up to the agreed-upon maximum. The payment recurs automatically without requiring re-authentication each month.

VRPs are attractive for subscription businesses because they reduce failed payment recovery efforts (which are expensive with card subscriptions) and reduce chargeback rates. VRPs create a more direct relationship between customer and provider than cards do.

Bill Payments and Utilities

Utilities and telecom companies are increasingly offering open banking as a payment method. Customers can set up a VRP to have their bill automatically paid each month. This reduces late payments and improves cash flow visibility for the provider.

Lending and Credit Decisions

Open banking enables lenders to access account information to make better credit decisions. A lending platform can request AIS permission to view 12 months of transaction history. Based on income patterns, spending patterns, and existing debt service, the platform makes a credit decision. This enables faster lending decisions and better risk assessment than traditional credit bureau approaches.

Payroll and Gig Work

Payroll platforms and gig economy platforms use open banking to disburse payments. Instead of using cards, they initiate bank transfers to workers' accounts. The cost is lower and the experience for workers is better (money hits their account, not a card that has to be converted to cash).

---

The Global Shift: From Cards to Open Banking to RTP

The architecture stack is becoming clear. Real-time payment networks provide the settlement infrastructure. Open banking provides the payment initiation interface and customer experience. Together, they offer an alternative to card payments that is cheaper, faster, and safer.

The shift is not universal yet. In countries without real-time payment networks, open banking still routes payments through ACH, which introduces delays. In countries without open banking regulation, the infrastructure is fragmented or non-existent. But in markets where both RTP and open banking exist (EU, UK, Australia, Brazil), the shift is accelerating.

The card networks are not disappearing. They are consolidating around use cases where their advantages (rewards, universal acceptance, consumer protection) matter most. But the default for B2B payments, recurring billing, and cost-sensitive commerce is increasingly open banking on top of real-time payment infrastructure.