Chapter 28: Key Takeaways — RegTech APIs, Open Finance, and Interoperability

1. APIs Are Data Flows — and Data Flows Are a Compliance Responsibility

An Application Programming Interface is a defined contract between two software systems that specifies how they communicate and what data they can exchange. For compliance professionals, every API connection is simultaneously a data flow, a third-party relationship, and a potential source of regulatory exposure. Governing API connections — knowing what data goes where, on what legal basis, with what controls — is a compliance obligation, not merely an IT concern.

2. PSD2 Created Three Distinct Roles with Different Compliance Profiles

The EU's Second Payment Services Directive (PSD2) established the foundational structure for Open Banking through three regulated roles. Account Servicing Payment Service Providers (ASPSPs) — banks like Verdant — must provide dedicated API access to customer account data. Account Information Service Providers (AISPs) are authorized to read customer account data for information purposes, with the customer's consent. Payment Initiation Service Providers (PISPs) are authorized to initiate payment transactions on the customer's behalf. Understanding which role your firm occupies — or whether it occupies multiple roles — determines which compliance obligations apply.

3. OAuth 2.0 Governs Consent Authorization — But Compliance Professionals Must Understand Why

The OAuth 2.0 Authorization Code Flow is the mechanism through which a customer authorizes a TPP to access their bank data without sharing their password. The customer authenticates at the bank, grants consent via a structured consent screen, and the bank issues a scoped, time-limited access token to the TPP. Access tokens define both what data the TPP can access and for how long. Compliance professionals must understand this flow because its properties — scoped authorization, time limitation, revocability, and auditability — are the technical implementation of consent management obligations.

4. FAPI Provides Higher Security Assurance Than Standard OAuth 2.0

The Financial-grade API (FAPI) security profile, mandated by UK Open Banking and adopted by several other national implementations, adds material security protections beyond standard OAuth 2.0. These include mutual TLS (both parties authenticate with certificates), certificate-bound access tokens (tokens cannot be used by a party other than the one they were issued to), Pushed Authorization Requests (preventing manipulation of the authorization flow), and signed authorization responses (preventing tampering). FAPI provides the security assurance that underpins the liability framework: it gives the ASPSP confidence that the entity calling its API is genuinely the authorized TPP.

5. Banks Must Actively Verify TPP Authorization — Not Accept Self-Certification

As an ASPSP, a bank cannot simply accept a TPP's claim that it is FCA-authorized. It must verify the TPP's authorization by validating the eIDAS certificate (in the EU) or OBIE certificate (in the UK) presented with every API connection. Verification means checking the certificate against the national regulator's machine-readable register. If a TPP's authorization lapses, the bank must immediately suspend API access. This verification obligation is continuous — authorization can be withdrawn at any time — not a one-time onboarding check.

6. Banks Must Not Discriminate in API Access

Under PSD2 and the UK Open Banking standards, ASPSPs are explicitly prohibited from treating TPP access differently from direct customer access. An API that serves slower responses to TPPs than to the bank's own app, or that imposes conditions on TPP access not imposed on direct access, violates the non-discrimination principle. The EBA has issued guidance on what constitutes discrimination, and national supervisors have taken enforcement action in some jurisdictions. The compliance team should include API performance monitoring as part of its Open Banking oversight.

7. The Consent Object Is the Foundation of Open Banking Compliance

Customer consent in Open Banking is not a checkbox in an app — it is a structured data object that records the TPP, the permissions granted, the customer who consented, the date and time of authorization, and the expiry. Every API call must be validated against the authorizing consent object before data is returned. This consent object is also the foundation of GDPR data subject access request responses: when a customer asks "what data have you shared about me, and with whom," the consent audit trail — derived from the consent objects and API call logs — provides the answer.

8. Open Finance Extends the Scope Beyond Payment Accounts

Open Banking covers payment accounts (current accounts, prepaid cards). Open Finance extends the data portability model to mortgages, pensions, savings products, investments, and insurance. The UK's Smart Data initiative (backed by the Data (Use and Access) Act 2024) and the EU's Financial Data Access (FiDA) framework represent the regulatory direction of travel. Compliance professionals must anticipate that the consent management, TPP verification, and API governance infrastructure they build for Open Banking today will need to scale across a substantially broader range of data types and counterparty relationships.

9. The API Inventory Is a Compliance Artifact

Every external API connection must be documented in an API inventory: the counterparty, the data types exchanged, the legal basis for data transfer, the authentication mechanism, the version in use, and the data retention arrangements on both sides. An incomplete API inventory means the compliance team does not have full visibility of the firm's data flows — a regulatory and GDPR governance failure. API inventory maintenance should be a change management requirement: no new API connection should go live without compliance review and registry update.

10. RegTech Integration APIs and API-Based Regulatory Reporting Are Reshaping Compliance Operations

Beyond Open Banking, APIs connect compliance systems to each other and, increasingly, to regulators directly. The EBA's IReF, the Bank of England's data collection initiatives, and OFAC/HMT real-time sanctions list APIs are indicators of a direction in which regulatory reporting becomes a continuous, machine-to-machine data exchange rather than a periodic batch submission. Compliance professionals who understand API governance today will be best positioned to manage this transition.