Open Banking Risk

Consent abuse, data leakage, fraud and third-party dependency

Risk at the connection boundary

Open banking introduces interactions among customers, account-servicing institutions, regulated providers and technical intermediaries. Risks arise when authority, data scope, payment state or operational responsibility is unclear. Connectivity does not remove the need for fraud, confidentiality or resilience controls.

Assess the actual service and framework. A provider that the bank must serve under an access duty is not necessarily a supplier the bank may select through procurement. Controls should meet legitimate legal and security needs without creating unjustified access barriers.

Permission and data abuse

Threats include unsupported scope expansion, unauthorised account enumeration, continued access after withdrawal and use for an unapproved purpose. Test the relevant enforcement points, not only the permission screen. A valid technical credential should not permit information from an unrelated account.

Minimise fields and history to the authorised service scope. Restrict logs and onward disclosure, with applicable retention and purpose controls. Data previously collected may still have lawful retention requirements after future sharing stops. Withdrawal and deletion need separate analysis.

Purpose enforcement has limits: a bank may observe endpoint use without seeing every downstream recipient action. Combine technical controls with the framework's oversight, contracts, recipient duties and appropriate investigation. Do not claim that a gateway can directly observe every use of data after delivery.

Fraud and authentication journeys

Threats can include impersonated providers, phishing bank pages, manipulated redirect parameters, stolen sessions and customer deception. The chosen security profile should protect the actual flow, including registration and redirect configuration. A certificate check alone does not establish customer authority for a payment.

Authentication and scam prevention are distinct. A customer can complete a legitimate bank authentication journey while being deceived about the intended payment. Show meaningful transaction details and apply appropriate risk intervention and assistance. Strong authentication is not a guarantee of reimbursement outcome or freedom from fraud.

The FAPI 2.0 Security Profile defines a high-security OAuth profile under stated assumptions. Follow the actual ecosystem profile and test it; assembling a few named features is not evidence of conformance.

Dependency and uncertain outcomes

Map bank interfaces, authorisation services, directories, aggregators and providers supporting the customer journey. Shared dependencies can interrupt multiple integrations together. Define degraded modes and customer communication without weakening required access controls to preserve nominal availability.

An initiation timeout may leave the payment outcome uncertain. Use enquiry, instruction references and safe duplicate control before replay. Do not assume a fallback method is lawful or supported in every market; establish its rules and controls first.

Worked example: withdrawal reaches only one adapter

In this fictional incident, a customer stops a connection, but one product adapter continues supplying information because it missed a status event. The bank contains further access, identifies the recipient and data disclosed, and assesses the population affected by the same defect.

Operations preserves the evidence, legal and compliance teams assess the applicable reporting and customer duties, and engineering fixes propagation or enforcement. The team verifies denial at every relevant path. A green dashboard or a reset token alone is insufficient proof of containment.

Measures and assurance

Monitor denied scope, credential or authority failures, access after withdrawal, unexplained traffic, data incidents, uncertain outcomes and shared-dependency interruptions. Distinguish suspicious activity from confirmed abuse and evaluate legitimate customer friction.

Sample permissions and requests end to end. Test wrong roles, expired authority, failed updates, provider status changes and recovery. Investigations need correlated evidence across parties; legal liability follows the actual event and framework rather than a universal hand-off formula.

The EBA PSD2 rulebook and Australian CDR guidance illustrate different access and data safeguards.

Takeaway

Open-banking risk controls preserve authority, data scope and honest payment states across an additional party. They need effective containment and evidence when the connection fails or is abused.

Continue to Embedded Finance.