What is at stake in account linking security
An open banking consent token is not just data — it is ongoing access. When a user links their GTBank, Access Bank, or Zenith account through an aggregator, the consent token stored by the fintech application allows continuous retrieval of that account's transaction data. A token that persists for six months provides six months of live financial surveillance: every debit, every credit, every merchant name, every transfer amount. An attacker who obtains this token does not need to break into a bank. They have a legitimate, API-authorized view of the account.
Nigerian fintechs use this data for income verification (lending), spending analysis (financial planning), and automatic payment deduction (direct debit products). All three use cases create a high-value target from the consent token. Compromise of a lending platform's aggregator tokens does not just expose transaction history — it exposes the income verification data that was used to approve every loan on the platform, enabling targeted fraud against those users.
1. Consent token storage and transmission security
After a user completes the account linking flow, the aggregator returns a consent token to the fintech backend. We audit how this token is stored and transmitted. Critical checks include: the token is not logged in application logs (which are often stored in plaintext in cloud logging services), the token is stored encrypted in the database rather than as a plaintext string, the token is not included in error responses or exception stack traces, and the token is transmitted only over HTTPS and never included in URL query parameters.
2. Consent initiation CSRF vulnerability
The account linking flow begins when the fintech application initiates a consent request to the aggregator on behalf of a user. We test whether this initiation endpoint is protected against Cross-Site Request Forgery. A CSRF vulnerability in the consent initiation flow means that a malicious page can trigger a new consent request on behalf of an authenticated user — potentially initiating a re-linking flow that replaces the user's existing consent with one pointing to an account the attacker controls (in cases where the flow allows account selection).
3. State parameter validation in the OAuth callback
Open banking consent flows use an OAuth-style redirect with a state parameter to prevent CSRF attacks in the callback. The state parameter is set by the fintech application at the start of the linking flow and must be validated when the aggregator redirects back with the authorization code. We test whether the state parameter is validated strictly — a missing or incorrect state parameter must reject the callback, not proceed with the token exchange.
4. Scope of data access versus scope claimed
Aggregator consent should be scoped to the minimum data required for the fintech's stated purpose. A loan income verification tool should request transaction data access only, not account balance, direct debit setup authorization, or payment initiation. We audit the consent scopes that the fintech application requests against what its product actually needs, and test whether the aggregator enforces scope restrictions when the fintech API client attempts to access data beyond the consented scope.
5. Token revocation and session termination
When a user removes a linked account from the fintech application, the consent token must be revoked at the aggregator level, not just deleted from the fintech's database. A token that is removed from the application's database but not revoked at the aggregator remains valid and can be used to continue pulling data if an attacker has a copy of it. We verify the full revocation chain: user action in the app triggers a revocation API call to the aggregator, and the aggregator's revocation is confirmed before the user-facing success message is shown.
Consent tokens stored as plaintext in shared database column
During a security assessment of a Nigerian lending platform that used Mono for income verification, we reviewed the database schema. Mono consent tokens were stored in a varchar column in plaintext alongside the associated user ID and BVN. The table was accessible through a general-purpose database admin credential that was shared across the development and production environments. Any developer with database access could read the consent tokens and use them to pull transaction data for any linked user account. Fix priority: critical. Remediated by encrypting all consent tokens at rest using application-level encryption with a key stored in AWS Secrets Manager, and rotating the shared database credential to per-role credentials with column-level access controls.
Using Mono, Okra, or another open banking aggregator in your fintech product? Book a security assessment of your entire account linking integration.
Book an Open Banking Security AuditFrequently asked questions
What is the consent token in an open banking integration and why is it sensitive?
When a user links their bank account through Mono or Okra, they authorize the aggregator to read their account data. This authorization produces a consent token that the fintech application stores and uses to pull transaction data on behalf of the user. The token is equivalent in sensitivity to a read-only API key for the user's bank account — whoever holds it can read the account's transaction history for as long as the token remains valid.
What is a re-consent attack in open banking?
A re-consent attack occurs when an attacker causes a user to grant consent through an aggregator's linking flow for an account they did not intend to share. This can happen through phishing that redirects the user to a legitimate aggregator consent page pre-populated with an attacker-specified account, or through a CSRF vulnerability in the consent initiation flow that triggers a new consent request without the user's knowledge.
How does account linking security differ from payment API security?
Payment APIs authorize individual transactions. Account linking authorizes ongoing data access. The risk profile is different: a compromised payment API can execute one fraudulent transaction. A compromised account linking consent token provides continuous read access to the linked bank account for months — enabling account surveillance, income verification fraud, and targeted social engineering using real transaction data.
Related reading
Blog: Embedded finance security testing · Open banking API security Nigeria · OAuth security audit
Services: Penetration testing · API security