Topic starter
15/01/2026 3:51 pm
TL;DR: Creating banking APIs only for compliance can depress API uptake and business value, according to Curity's analysis of a Gartner report, while stronger identity, consent, lifecycle, and standards-based controls help banks support real-time data sharing, monetisation, and ecosystem integration.
Editorial analysis by NHI Mgmt Group, based on content published by Curity: “Secure Online Banking with A Competitive Edge”.
By the numbers:
- the increase in banks recognizing fintechs as strategic partners to close their API and digital capability gaps rose to 89%
Key questions
Q: What breaks when banking APIs are built only for compliance?
A: Compliance-only API programmes often expose data without creating a durable governance model.
Q: Why do open banking APIs need identity controls as well as standards?
A: Standards help systems interoperate, but they do not by themselves control who may access data, under what consent, or for how long.
Q: How should banks govern fintech partner access in open banking?
A: Banks should treat fintechs as governed identities, not one-time integrations.
Practitioner guidance
- Define consent as an access control boundary Map each open banking data flow to a specific authorisation scope, revocation point, and identity subject so that consent can be enforced and audited, not merely recorded.
- Govern partner access as a lifecycle Create joiner, mover, leaver rules for fintech and ecosystem partners, including onboarding approval, scope changes, credential review, and offboarding when the relationship ends.
- Separate customer, partner, and workload identities Assign distinct authentication and authorisation patterns to end users, third-party organisations, and calling services so that one access model does not mask another.
Bottom line: Open banking APIs create value only when they are governed as identity-aware services rather than treated as compliance artefacts.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 5:08 pm
Compliance-only API design is a governance ceiling, not a strategy. When banks build open banking interfaces solely to satisfy regulation, they often stop at exposure and miss the operating model that makes APIs reusable, governable, and valuable. That leaves consent, partner access, and lifecycle enforcement as afterthoughts. The implication is that API programmes must be treated as identity programmes, not as one-time compliance projects.
A question worth separating out:
Q: What is the difference between screen scraping and consent-driven APIs?
A: Screen scraping relies on a third party handling customer credentials, which broadens credential exposure and weakens accountability. Consent-driven APIs use scoped authorisation and revocation so the bank can govern what is shared without handing out login secrets. The difference is not only technical, but also who controls access and how quickly it can be withdrawn.
👉 Read our full editorial: Banking APIs need identity controls beyond compliance for open banking