Open banking introduces new attack surfaces through third-party API access to customer financial data. This article explains the cybersecurity controls CBUAE expects banks and fintechs to implement for secure open banking operations.
The CBUAE's Open Finance Framework is transforming how financial data flows between institutions. While open banking creates significant innovation opportunities for consumers and fintechs alike, it fundamentally changes the cybersecurity landscape by introducing third-party access to sensitive customer financial data through APIs. ITSEC works with both banks and third-party providers navigating the security requirements of open banking, and the challenges are substantial — because open banking, by design, does exactly what traditional banking security was built to prevent: it grants external parties access to customer accounts.
Traditional banking security focused on protecting a relatively closed system. Perimeter defenses, network segmentation, and access controls all operated on the principle of keeping external parties out. Open banking fundamentally inverts this model by creating authorized, API-mediated pathways for third parties to access customer accounts and transaction data.
Each API connection represents a potential entry point that must be secured. Each third-party integration extends the trust boundary beyond the bank's direct control. Each customer consent decision creates a data-sharing relationship that must be enforced technically, not just contractually. The cumulative effect is a dramatic expansion of the attack surface that banks must defend.
For banks, the challenge is enabling innovation while maintaining the security posture that regulators and customers expect. For third-party providers — fintechs, aggregators, payment initiators — the challenge is meeting security standards equivalent to those expected of entities handling bank-grade financial data, often without the security budgets or organizational maturity that banks possess.
ITSEC has observed that the most common security failures in open banking implementations occur not at the API level but at the boundaries — where different security models, different trust assumptions, and different organizational capabilities intersect.
Open banking APIs must implement security-by-design principles that go well beyond standard API security practices. Financial-grade API security requires controls that most general-purpose API gateways do not provide out of the box.
Authorization must implement OAuth 2.0 with Financial-grade API security profiles as defined by the OpenID Foundation. Standard OAuth 2.0 is insufficient for financial services because it was not designed to resist the level of attack sophistication that financial APIs face. FAPI adds critical protections including pushed authorization requests that prevent authorization code injection, JWT-secured authorization requests that prevent parameter tampering, proof-of-possession tokens using mutual TLS certificate binding that prevent token theft and replay, and sender-constrained access tokens that ensure tokens can only be used by the party they were issued to.
Transport security must implement mutual TLS for all server-to-server communications between banks and third-party providers. This provides both encryption and bilateral authentication — each party cryptographically proves its identity to the other on every connection. Certificate management must be automated with monitoring for expiration, revocation, and unauthorized certificate changes.
Request integrity must be enforced through request object signing using JSON Web Signatures. Every API request must be signed by the requesting party and verified by the receiving party, preventing man-in-the-middle modification of request parameters. Response signing should also be implemented to prevent response tampering.
Rate limiting must be calibrated to prevent abuse while supporting legitimate traffic patterns. ITSEC recommends implementing tiered rate limits based on the sensitivity of the endpoint — account balance queries may tolerate higher rates than payment initiation endpoints. Rate limiting must be accompanied by anomaly detection that identifies patterns indicative of credential stuffing, data harvesting, or automated account enumeration.
Input validation must protect against injection attacks across all API endpoints. This includes SQL injection, NoSQL injection, XML external entity attacks, server-side request forgery, and business logic manipulation through parameter tampering. Validation must be applied at the API gateway level as a first line of defense and again at the application level for defense in depth.
API versioning and deprecation must be managed securely. When API versions are deprecated, they must be decommissioned completely rather than left accessible — ITSEC has found deprecated API endpoints with weaker security controls still accessible in production during multiple assessments.
Customer consent is the legal and technical foundation of open banking data sharing. From a cybersecurity perspective, consent is not just a compliance requirement — it is a security control that defines and enforces the boundaries of authorized access.
Consent capture must occur through secure channels with strong customer authentication. The customer must clearly understand what data they are sharing, with whom, for what purpose, and for how long. Consent records must be stored with cryptographic integrity protection and immutable audit trails.
Consent enforcement must be implemented technically at the API layer. When a third party requests data, the API must verify that a valid, current consent exists for the specific data scope being requested. If a customer has consented to share account balances but not transaction history, the API must enforce that boundary — not rely on the third party to limit its own requests. Granular scope enforcement is critical because over-scoping is one of the most common open banking privacy failures.
Consent revocation must be effective immediately. When a customer revokes consent, all active tokens associated with that consent must be invalidated, ongoing data feeds must be terminated, and the third party must be notified to delete data obtained under the revoked consent. The technical implementation must ensure that revocation cannot be circumvented by cached tokens or delayed processing.
Consent lifecycle monitoring must track consent usage patterns and flag anomalies — for example, a third party accessing data far more frequently than the consented use case would justify, or accessing data outside the hours when the consented service operates.
Banks cannot simply trust that third-party providers maintain adequate security. CBUAE holds the bank accountable for the security of customer data regardless of where it is processed, and the bank's open banking program must reflect this accountability.
Pre-onboarding due diligence must assess the third party's security posture before granting API access. This includes reviewing security certifications — SOC 2 Type II, ISO 27001, or PCI DSS depending on the services — and evaluating not just whether certificates exist but the scope and findings of the underlying assessments. Architecture review should assess the third party's data handling practices including where customer data is stored, how it is encrypted, who can access it, and how it is disposed of when no longer needed.
Ongoing monitoring must verify that third-party security posture is maintained over time. This includes API usage analytics that track request patterns, data volumes, error rates, and access timing for each third party. Behavioral baselines should be established during the initial period of access, with automated alerting when usage patterns deviate significantly. Periodic reassessment through questionnaires or on-site reviews should occur annually at minimum, with triggered reviews when the third party experiences security incidents, changes ownership, or modifies its technology architecture.
The bank must maintain the ability to revoke API access immediately if security concerns arise. Revocation procedures must be documented, tested, and executable within minutes — not dependent on manual processes that require business hours to complete. ITSEC recommends implementing automated revocation triggers for specific scenarios such as repeated authentication failures, anomalous data access patterns, or notification of a security incident affecting the third party.
Open banking transactions that access customer account data or initiate payments must be protected by strong customer authentication. SCA requires at minimum two independent factors from the categories of knowledge such as passwords or PINs, possession such as mobile devices or hardware tokens, and inherence such as biometrics.
The SCA implementation must be resistant to common attack techniques including real-time phishing where attackers relay authentication challenges to the genuine customer while simultaneously authenticating to the bank, SIM swapping that defeats SMS-based authentication factors, social engineering that manipulates customers into approving fraudulent transactions, and session hijacking that exploits authenticated sessions after the customer completes authentication.
ITSEC recommends app-based authentication with device binding and transaction signing — where the customer confirms the specific transaction details on their registered device — as the strongest SCA approach for open banking. This provides both possession and knowledge factors while making real-time phishing significantly more difficult because the customer sees the actual transaction details they are approving.
Dynamic linking must ensure that authentication is bound to the specific transaction amount and payee. A customer authorizing a payment of one thousand dirhams to a specific merchant must not be able to have that authorization repurposed for a different amount or different payee.
Security incidents in an open banking environment create multi-party complexity that traditional incident response plans do not address. A breach affecting the API layer may simultaneously impact the bank, multiple third-party providers, and thousands of customers — each with different notification requirements and different timelines.
Incident response plans must include specific procedures for open banking scenarios including compromised API credentials where a third party's access tokens are stolen or leaked, mass data exposure where a vulnerability allows unauthorized access to customer data across multiple third parties, consent manipulation where an attacker modifies consent records to expand data access, payment fraud initiated through compromised third-party integrations, and API infrastructure failure affecting availability of open banking services.
Multi-party communication protocols must define how the bank notifies affected third parties, how third parties notify the bank, and how customer communication is coordinated when multiple parties are involved. These protocols must be agreed in advance and tested through joint exercises — ITSEC recommends including key third-party providers in tabletop exercises at least annually.
ITSEC helps banks and third-party providers secure their open banking implementations with services including FAPI-compliant API security architecture design and review, API penetration testing with financial-grade attack scenarios, third-party risk assessment programs tailored to open banking, consent management security review, strong customer authentication implementation assessment, and open banking incident response planning. We understand both the technical requirements and the regulatory expectations, ensuring that security enables innovation rather than blocking it. Contact ITSEC to secure your open banking platform.
Get a comprehensive security assessment from our expert team. Protecting businesses since 2011.