The Regulatory Reality
Open Banking is no longer a competitive differentiator — in most regulated markets, it's a compliance requirement. PSD2 in Europe, CDR in Australia, and equivalent frameworks across Asia-Pacific and North America are forcing financial institutions to expose standardised APIs.
The engineering challenge is that most core banking systems were never designed for this.
What 'Open Banking Compliant' Actually Means Engineering-Side
- Consent Management: Users must be able to grant, view, and revoke third-party access to specific data scopes. This requires a consent registry that's auditable and near-real-time.
- API Standards: Most frameworks mandate OpenID Connect for authentication and OAuth 2.0 for authorisation. Your token lifecycle management needs to be bulletproof.
- Sandbox Environment: Regulators require a functional sandbox that mirrors production behaviour — not a stripped-down mock.
- SLA Requirements: PSD2 mandates 98.5% API availability with defined response times. Your infrastructure needs to be designed for this from the start.
The Data Sovereignty Trap
The most common engineering mistake in Open Banking projects is treating it as a pure API problem. The real complexity is data residency — where data is stored, processed, and logged as it transits between your systems and third-party providers.
Our Recommended Architecture Approach
For most institutions, we recommend an API gateway layer that sits in front of core banking systems, handling:
- Consent validation on every request
- Rate limiting per TPP (Third-Party Provider)
- Request/response logging for regulatory audit trails
- Token introspection and refresh flows
This prevents you from having to modify the core banking system itself — which is almost always the wrong approach.