Secure, governed banking APIs for authorised third parties and partners, built around the whole consent lifecycle and a version commitment you can actually keep.
Building an API is the short part of an open banking programme. What follows is the long part: a consent that was granted with a scope, is in force, will expire, may be renewed, can be withdrawn at any moment, and has to be visible to the customer throughout.
A consent is not a flag on a record. It is an object with a lifecycle, and each state in that lifecycle has a requirement attached that is routinely missing.
Consent is stored as a permission, not an object
So scope, history and expiry have nowhere to live.
Revocation does not propagate
The record changes and the access continues.
The customer cannot see what they granted
Which is both a control gap and a support driver.
Every API was designed for its first consumer
And the second one needs a different shape.
A version was published with no deprecation policy
So it is now supported indefinitely by default.
The sandbox does not behave like production
So partners integrate against a fiction.
Partner onboarding is a technical queue
When most of the elapsed time is due diligence.
The programme delivered the mandate and stopped
Compliance achieved, no commercial value created.
Revoke a consent in a test environment and then try to use the access it granted. Immediately, and then again in an hour. If anything still works, revocation is updating a record rather than stopping access, and the gap between those two things is the exposure. Then do the same with a consent that lapses rather than one that is withdrawn, because that path usually has no mechanism at all. Both tests take an afternoon and they are the two most important tests in an open banking implementation.
An internal API can be changed by agreement with its consumers. An external one cannot. Once a partner has built against a version, that version is a commitment, and the commitment outlasts the team that made it.
So the design question is not what is convenient to expose now. It is what can be supported for years, extended without breaking, and eventually retired through a process the institution has already published.
Step 1
Assess API readiness across the systems that hold the data
Step 2
Prioritise by use case and by consumer, not by data availability
Step 3
Design each API as a product with an owner and a contract
Step 4
Design the consent model across all seven states first
Step 5
Design identity and authorisation to recognised standards
Step 6
Publish a versioning and deprecation policy before the first version
Step 7
Build the sandbox to behave like production, including its failures
Step 8
Design partner onboarding end to end, including due diligence
Step 9
Implement rate limiting and fair use as a protection control
Step 10
Test adversarially: scope violation, replay, revocation, expiry
Step 11
Deploy with partner-visible status and version usage reporting
Step 12
Manage the lifecycle: adoption, versions, deprecation, retirement
Ask which version of each API every partner is currently using. If the answer requires asking the partners, the institution cannot manage its own API lifecycle and every version it has published is supported indefinitely by default. Version usage per consumer is straightforward telemetry, it is almost never collected, and without it the deprecation policy is unenforceable however carefully it was written.
Grouped by what each part is responsible for. The consent group is the foundation and the lifecycle group is the one that decides whether the estate is still manageable in five years.
API products
Banking API development across account information, transaction history, payment initiation and the services your market requires
API productisation: a contract, an owner, a support model, documentation, onboarding and a commercial position per product
Additive, backward-compatible evolution as the default, with versioning only where a breaking change is genuinely necessary
API gateway configuration including authentication, rate limiting, quotas and fair use enforcement
Internal reuse of the same API products, so an external capability is not built twice
Consent and identity
A consent model covering all seven states, with scope held as data and history retained
Revocation and lapse propagation to tokens, sessions, caches and scheduled access
A customer-facing view of what has been granted, to whom, with what scope, and a route to withdraw it
Authorisation flows to recognised standards, with the profile and authentication strength your security function specifies
Identity integration with your existing customer authentication rather than a parallel mechanism
Partner enablement
A developer portal with documentation, worked examples and self-service onboarding where your framework permits
A sandbox that behaves like production, including error cases, latency and rate limits
Partner onboarding end to end, with the due diligence hand-off to your financial crime function per our KYC & Customer Due Diligence page
Partner entitlement and credential administration, on the delegated model described on our Customer & Partner Portals page
The full partner lifecycle: registration, approval, credential rotation, recertification, suspension and offboarding, each as a designed operation rather than a manual task
Offboarding specifically, including credential revocation, consent closure and the customer communication, because a partner relationship that ends is as operationally real as one that begins
Lifecycle and operations
Version usage telemetry per consumer, which is what makes deprecation enforceable
A published deprecation policy and the process to execute it
Partner-visible status, incident communication and a support route that is not your retail contact centre
Monitoring that separates partner faults from your own, as described in section 8
Every use case below is a different consent shape. The technical work is similar across all of them. The question of what the customer agreed to, and for how long, is different every time.
Authorised account data sharing
A third party reads account and transaction data on the customer’s instruction, usually to provide a service the bank does not.
Payment initiation
A third party initiates a payment the customer has authorised, through an interface the bank exposes rather than a channel the bank owns.
Fintech partnerships
A named partner integrates a banking capability into their own product under a commercial agreement.
Embedded finance
A banking service appears inside a non-financial product, where the customer may not be thinking about their bank at all.
Banking as a service connectivity
A partner offers banking products on your licence and your balance sheet, through your APIs.
Financial management applications
Aggregators and personal finance tools that read across several institutions on the customer’s behalf.
Internal and enterprise consumers
Your own channels and enterprise partners using the same API products, which is the reuse case that makes the investment defensible.
For each live consumer, ask what scope they were granted and what scope they actually use. The gap is usually wide, and it is the clearest evidence of whether the consent model is doing its job. A consumer granted full account history who reads only the last ninety days has more access than their service requires, which is an exposure nobody chose and a conversation worth having at the next review.
We work within the institution’s existing platform decisions, identity services and hosting policy. Where a recognised standard applies we implement to it. Where one does not, we make the choice explicit and documented rather than incidental.
Architecture components
API layer
REST interfaces with versioned contracts, designed additively.
API gateway
Authentication, rate limiting, quotas, routing and telemetry.
Authorisation
OAuth 2.0 and OpenID Connect flows, with the security profile your security function requires.
Consent service
The seven-state model, scope as data, history retained.
Identity integration
Your existing customer authentication, not a parallel one.
Core adapters
Per Core Banking Integration, which owns that boundary.
Developer portal
Documentation, sandbox, onboarding, credential self-service.
Observability
Per consumer, per version, per endpoint, as section 8 sets out.
Standards and specifications
REST and JSON for the API surface, with a documented contract per version
OAuth 2.0 and OpenID Connect for authorisation and authentication flows
Financial-grade API security profiles where your market or your security function requires them
Any market-specific open banking specification that applies to your institution, which is your compliance function’s determination rather than ours
Message and data standards where the use case involves payments, per our Payment System Integration page
Most of this section is ordinary engineering discipline applied to an external boundary. One part is not: the customer’s ability to see what they have granted and withdraw it without help.
Customer authorisation
Authenticated, scoped, recorded, with what the customer was shown retained.
Consent lifecycle
All seven states, with propagation on both revocation and lapse.
Customer visibility
A view of every active consent, with a working withdrawal route.
Third-party access control
Credentials, entitlements, status and the ability to suspend a consumer quickly.
API authentication
To the standards and strength your security function specifies.
Data minimisation
Scope-appropriate responses, reviewed when the API changes.
Monitoring and audit
Who accessed what, under which consent, with which scope, when.
Change governance
Contract change, version change and deprecation under your change process.
Connect banking systems, payment platforms, and external services to enable secure data exchange and connected financial experiences. From core banking and payment integration to open banking APIs, application connectivity, and integration platform modernization, help banks streamline workflows, improve interoperability, and support digital innovation.
API dashboards fill up with availability, latency and call volume, all of which are easy to collect. The measures that predict a problem are narrower and less commonly instrumented.
The four that warrant an alert
Consent failure rate, broken down by stage, because a rise usually means an authorisation journey has broken rather than that customers changed their minds
Revocation and lapse propagation latency, which is the measure behind the institution’s actual exposure and is almost never instrumented at all
Error rate per consumer rather than in aggregate, since one partner failing badly disappears inside a healthy overall number
And your own channel performance under third-party load, which is the first thing customers will notice and the last thing API dashboards show
The rest, which belong on a dashboard and in a review
Availability and latency per endpoint and per consumer, with percentiles rather than averages
Version usage per consumer, which makes deprecation possible
Version migration progress against the deprecation plan, which is the measure that tells you whether a retirement date is realistic while there is still time to move it
Adoption: active consumers, active consents, call volume by use case
Partner onboarding time instrumented by stage, per section 5, so the bottleneck is visible
Rate limit breaches per consumer, which identify polling behaviour worth a conversation
Scope usage against scope granted, which is the minimisation evidence
Sandbox to production defect correlation, which tells you whether the sandbox is faithful
If one partner’s integration broke an hour ago, would you know before they told you? Aggregate error rates say no, because one consumer failing completely is invisible inside a healthy total. Per-consumer error monitoring is a grouping change on data already being collected, and it converts a partner complaint into an outbound call where you already know what happened. That is the whole difference between a programme that looks managed and one that is.
Outcomes depend on your estate, your market and your partner strategy. These are the changes the work is aimed at.
Partner integration moves faster because the bottleneck is now visible and most of it was never engineering
API services are reused internally and externally rather than built twice for the same data
Data sharing is controlled at the scope the customer actually agreed to, and the evidence exists
Revocation and lapse both stop access, within a stated time, everywhere
Customers can see what they granted and withdraw it without calling anybody
Support volume falls because the sandbox is faithful and errors say what is wrong
Old versions can be retired, because usage per consumer is known and the policy predates the version
And the institution can suspend a consumer within the hour, which it has tested
Bring us the result, or bring us an API you cannot retire, a partner onboarding time you cannot explain, or a consent model that stores a flag where it needs an object. We will map the gap and define a first piece of work with an acceptance test you can check yourself.
CaliberFocus builds governed banking APIs around the whole consent lifecycle and a version commitment you can actually keep. We model consent as an object across all seven states, make revocation and lapse stop access everywhere, design APIs as products with a published deprecation policy, and build a sandbox that behaves like production.
- A consent model covering all seven states, with scope held as data
- Revocation and lapse propagated to tokens, sessions and caches
- Versioning and deprecation policy published before the first version
- Per-consumer monitoring and the ability to suspend a consumer quickly
Security & Compliance
