Open Banking API Development

The account information API is built to the Open Banking UK Read/Write API specification or the Berlin Group NextGenPSD2 standard depending on the regulatory jurisdiction. Endpoint coverage includes accounts, balances, transactions, direct debits, standing orders, and scheduled payments -- the full data set the regulation requires, not a subset. Authentication uses OAuth 2.0 with PKCE and the FAPI profile that the Open Banking UK specification mandates for security-critical financial APIs. Refresh token management operates within the customer consent window, re-prompting for consent when the window expires rather than silently retaining access. Performance is built to meet the regulatory response time standards -- 99th percentile response times within the limits set by the EBA's interface performance requirements. API availability is monitored continuously and reported through a regulatory dashboard that meets the competent authority's reporting requirements for API uptime and error rates.

The payment initiation endpoint accepts domestic payment instructions and initiates the payment via Faster Payments, SEPA Credit Transfer, or the relevant domestic payment rail for the jurisdiction. Strong Customer Authentication is integrated into the authorisation flow so the customer confirms the payment through the bank's SCA mechanism -- not through the TPP's interface -- which is the regulatory requirement under PSD2 RTS. Idempotency key handling ensures that duplicate payment submissions from a TPP that retries on timeout are rejected rather than double-posted to the payment rail. A payment status webhook delivers the outcome -- accepted, rejected, or pending -- back to the initiating TPP so the TPP's customer-facing experience can reflect the payment result without polling. Refund handling covers the cases where the payment scheme supports return payments, with the refund lifecycle tracked against the original payment instruction and reported back via webhook.

The customer-facing consent dashboard shows all active TPP connections with the data scope, permitted actions, and expiry date of each consent in plain language -- not regulatory boilerplate. The consent grant flow is integrated into the bank's digital banking application, so when a TPP redirects the customer to the bank to authorise access, the customer sees a clear summary of what the TPP will access and for how long before confirming. Consent revocation is available from the dashboard at any time with immediate effect on API access -- the TPP's API calls fail from the moment the customer revokes, not at the next token refresh cycle. A consent audit log records every grant, modification, scope change, and revocation with timestamp, channel, and the TPP identity, providing the evidential record the bank needs if a customer disputes what access was authorised. TPP registration verification uses eIDAS certificates or the equivalent national regulatory credential to confirm the TPP's identity and regulatory authorisation before consent is presented to the customer.

Integration with the Open Banking Directory (UK), the OBIE TPP register, or the equivalent national directory gives the API a live authoritative source for verifying whether a TPP is currently registered and what permissions it holds. The dynamic client registration endpoint allows registered TPPs to onboard programmatically using their directory-issued credentials without a manual operator action from the bank's team for each new TPP. Certificate validation runs on every inbound API call, verifying the TPP's current registration status and confirming the requested data scope falls within what the TPP is authorised to access under its regulatory permission. A sandboxed test environment is provided for TPPs to develop and validate integrations against realistic synthetic data before requesting live access, which reduces integration failures and support load after go-live. An API portal with full specification documentation, test credentials, and integration guidance materials supports TPP developers without requiring the bank's team to provide individual onboarding support for each integration partner.

The consumer-facing account aggregation application connects to multiple banks via their open banking APIs and presents all accounts in a single customer view, covering current accounts, savings accounts, and credit cards across institutions. Transaction data is normalised across institutions into a consistent schema -- different banks return transaction data in different formats, with different date fields, merchant name conventions, and balance types, and the normalisation layer resolves those differences before the data reaches the display layer. Spending categorisation uses MCC codes and merchant name resolution to assign transactions to categories -- groceries, travel, utilities, dining, subscriptions -- with customer-editable overrides for transactions the automatic categorisation assigns incorrectly. A net worth view aggregates balances across all connected accounts and presents a single figure that updates as balances change. Data refresh management balances the API rate limits each bank's open banking implementation imposes against the data freshness customers expect, using background refresh schedules and on-demand refresh triggers appropriately. Export to accounting software is included for self-employed customers who use the aggregation view for bookkeeping and tax preparation.

Transaction data analysis for mortgage and loan affordability assessment replaces stated income with verified income drawn from the applicant's actual bank transactions, accessed with the applicant's consent through the open banking API. Income verification identifies salary credit patterns -- the regular large credit from an employer, net of tax and national insurance -- across connected accounts and flags the income source, amount, and payment cadence for the underwriter. Regular committed expenditure is identified from direct debits and standing orders, categorised by type -- rent or mortgage, loan repayments, insurance premiums, utility direct debits -- to give the lender an accurate picture of fixed monthly outgoings. Discretionary spending pattern analysis reviews transaction categories by period to identify recurring patterns in variable spending that affect affordability, presented by category and trend rather than raw transaction lists. The affordability report is generated in the format the lender's underwriting team requires, formatted to the fields and structure of their credit assessment process rather than a generic data export. The open banking consent flow is embedded directly into the loan application journey so the applicant grants access as part of the application rather than as a separate step that introduces drop-off.