Open Banking App Development UK: Build an AISP or PISP
AI Summary: Open banking app development UK projects start with the regulated services the app performs. Account information and payment initiation have different permissions and operational responsibilities under the UK framework. Choose the appropriate authorised or partner route, then build consent, authentication, API connectivity, payment or data workflows, security and evidence retention around it. |
US "open banking" conversations often mean aggregators and bank-linking UX. In the United Kingdom, Account Information Services (AIS) and Payment Initiation Services (PIS) are regulated payment services under the Payment Services Regulations 2017, supervised by the Financial Conduct Authority (FCA), with standardised APIs and a participation directory. Building a UK Open Banking app starts with which permission you need—not which React wallet template you like.
This guide is for founders and product teams shipping UK AIS, PIS or combined experiences: affordability checks, personal finance dashboards, pay-by-bank checkout, sweeping and related flows. It covers FCA routes, aggregator versus direct bank connectivity, architecture, standards, compliance features, and cost and timeline drivers. For conceptual differences between open banking and embedded finance, see Open Banking vs Embedded Finance. For provider comparisons that include UK-capable aggregators, see Best Open Banking API Providers for Developers in 2026 and our Plaid vs Tink vs TrueLayer comparison. The US aggregator model is covered separately in How Plaid Supports Open Banking in the USA—do not treat that stack as a drop-in for FCA permissions. For licences across markets, see our Fintech Licensing Requirements 2026 guide.
Open banking app development UK: AIS and PIS are different products
The FCA summarises the two services on its account information and payment initiation page:
Service | What the user enables | Typical products | Core software objects |
AIS | Read account data (balances, transactions, some standing data) with explicit consent | PFM, affordability, accounting sync, credit decisioning inputs | Consent, account access, data refresh, categorisation, revocation |
PIS | Initiate a payment order from the user's account at their ASPSP | Pay-by-bank checkout, disbursements user-authorises, bill pay | Payment consent, SCA redirect, payment status, reconciliation |
Combined | Both | Banking apps that show balances and move money | Shared identity and consent UX with separate permission gates |
Scope questions—whether your feature is in or out of regulated AIS/PIS—are discussed in the FCA Handbook PERG 15. Get that determination early; "we only show balances" can still be AIS.
FCA routes: registration, authorisation or agent
Route | Typical use | What to expect | Trade-offs |
Registered Account Information Service Provider (RAISP) | AIS-only firms that meet registration conditions | FCA registration path aimed at AIS-only providers; see RAISP applicants | Cannot rely on RAISP if you need PIS; still need robust controls and directory participation |
Authorised payment institution (or EMI with permissions) | PIS, or AIS+PIS, broader payment services | Full authorisation under the payment institution / e-money application process; capital, governance, safeguarding where relevant | Longer timeline; more ongoing obligations |
Agent of an authorised principal | You operate under a principal's permissions | Principal due diligence, agency agreement, often principal-branded regulatory disclosures | Faster market access; less control; principal can constrain product |
Pure software / technical service provider | No regulated AIS/PIS in your name | Careful perimeter so you are not providing the regulated service | Narrower commercial model; banks still care about security |
Directory enrolment, certificates and bank onboarding follow after (or alongside) the regulatory path. ASPSPs will not treat you as a TPP because your pitch deck says so—you need the regulated status and technical enrolment the ecosystem expects.
Safeguarding, capital and organisational requirements depend on which permissions you hold. Use current FCA materials—including the FCA's payment services and e-money approach documents—as the source of truth rather than secondary blog summaries of capital numbers.
Aggregator versus direct ASPSP connectivity
Approach | Pros | Cons | When it fits |
Open Banking aggregator / TPP platform | One integration, many UK banks; hosted consent UX; faster MVP | Vendor dependency; pricing per user/payment; constraints on UX and data retention | Most startups; mixed AIS+PIS roadmaps |
Direct to each ASPSP using OB standards | Control, potentially better unit economics at scale | Many onboarding queues, oddities per bank, heavier ops | Mature volumes; specialised latency/control needs |
Hybrid | Aggregator for long-tail banks; direct for top banks | Two consent and cert stacks | Scale-up phase |
UK Open Banking API specifications are published on the Open Banking standards site. Even if you never call a bank directly, your mental model should match those resources: accounts, balances, transactions, payment initiation, consent, dynamic client registration patterns and security profiles. Aggregators abstract the pain; they do not remove your responsibility for consent clarity and purpose limitation.
Reference architecture
Layer | Components | Notes |
Channel apps | Mobile/web, partner embed (checkout) | Separate AIS connect vs PIS pay entry points |
Consent UX | Purpose, duration, account selection explanation, revocation | Match what you will actually do with data |
AuthN with ASPSP | Redirect / decoupled SCA flows per bank capabilities | Store correlation IDs end-to-end |
TPP / aggregator adapter | Token lifecycle, webhook ingestion, replay protection | Treat vendor outages as first-class failure modes |
Data plane (AIS) | Account store, transaction sync, categorisation, refresh scheduler | Retention limits tied to consent |
Payment plane (PIS) | Payment draft, user confirmation, status machine, reconciliation to merchant order | Idempotent payment keys |
Identity of your customer | Your KYC if you have wider permissions; else merchant/customer linkage | Do not confuse ASPSP SCA with your onboarding KYC |
Audit and MI | Consent log, access log, payment audit, support tooling | Needed for FCA and bank reviews |
Security | eIDAS-style certs or aggregator-managed certs, HSM/secrets, pen-test evidence | Align with directory requirements |
Consent is not a boolean "connected". Store purpose, scopes, creation time, expiry, revocation time, and which accounts were included. Every AIS refresh and every PIS initiation should reference that consent record.
Key APIs and standards
Open Banking Read/Write APIs for accounts and payments as implemented by ASPSPs and aggregators
Directory / dynamic client registration flows for production enrolment
Webhook / event notifications for payment status and sometimes data availability
Your merchant or credit APIs if PIS is checkout infrastructure
Category enrichment (optional) for PFM—keep models from silently expanding purpose beyond consent
Operational APIs for support agents to revoke consent and trace a payment without raw log diving
Compliance features to build
Explicit, informed consent with plain-language purpose; easy revocation in-product
Purpose limitation so engineering "just one more field" cannot expand use without a new consent
Strong Customer Authentication journeys that tolerate bank-specific friction without dropping auditability
Data minimisation and retention aligned to consent life and your regulatory record-keeping duties
Incident response playbooks for aggregator outages and suspected unauthorised access
Complaints handling suitable for an FCA-regulated firm (or clear routing to your principal if you are an agent)
Vulnerable customer and fraud considerations on PIS (push payment scam awareness in UX where appropriate)
Change management so API version upgrades (OB standards evolve) do not break consent or payment status machines
Variable Recurring Payments and other evolving payment types may be available through ecosystem initiatives on timelines that change—treat them as roadmap items gated by current scheme rules, not as assumed MVP scope.
Consent UX details that reduce drop-off without cutting corners
Conversion pressure tempts teams to hide duration, bundle purposes or reuse a single "connect bank" button for AIS and PIS. Resist that. Instead:
Explain why you need access in the merchant or app context (affordability vs pay this invoice)
Show what will happen next (redirect to bank, approve, return)
Offer narrower scopes when your product can work with them
Make disconnect as obvious as connect
After return, confirm success with the bank name and a timestamp the user can recognise
Banks and aggregators will change screens. Your analytics should attribute failures to stages (start consent, redirect, authenticate, authorise, callback, token exchange) so you fix the real leak.
Payment reconciliation for PIS checkouts
A PIS payment is not complete when the redirect returns. Your platform needs a status machine that can handle pending, completed, rejected and ambiguous states, with safe retries and a support tool that can answer "was the merchant paid?" using idempotent payment IDs tied to the order. Settle merchant payouts only on terminal success criteria you define with finance—not on a deep-link open event.
Agent vs own-permission operating model in software
If you launch as an agent, encode the principal's constraints in configuration: permitted journeys, brand/disclosure strings, data retention maxima and escalation paths for complaints. When you later move to your own permissions, you will swap certificate identity and legal entity fields—design customer notices and re-consent flows before you need them, not during the cutover weekend. Keep a matrix of which environments (sandbox, production) and which legal entity own each client_id so operations never rotate the wrong certificate during a serious production incident at peak traffic.
Cost and timeline drivers
Driver | Why it matters |
Regulatory path | RAISP vs full authorisation vs agent changes months of critical path |
AIS-only vs PIS | PIS adds payment status, reconciliation and richer fraud UX |
Aggregator vs direct | Direct multi-bank is an organisation, not a sprint |
Checkout conversion work | PIS success rates depend on UX polish as much as API correctness |
Data product depth | Raw transactions are easy; reliable categorisation and credit features are not |
Ongoing conformance | Certificate renewal, standard version upgrades, bank quirks |
Build plan
Perimeter memo: AIS, PIS or both; own permissions or agent
Choose connectivity: aggregator for MVP unless you have a clear direct thesis
Consent and security design before screens
Implement one killer journey (for example affordability AIS, or single pay-by-bank)
Operational tooling: revoke, trace, replay, MI dashboards
Regulatory application / principal onboarding in parallel with build
Limited production pilot, then expand bank coverage and journeys
FAQs
Is UK Open Banking the same as using Plaid in the US?
No. The US market has historically relied heavily on aggregators under a different legal framework. The UK has regulated AIS/PIS under the PSRs with standardised bank APIs and FCA registration/authorisation. See our US Plaid open banking article for the US angle, and keep the stacks conceptually separate.
Can we start as an agent and move to our own authorisation later?
Often yes commercially, but plan data portability, consent re-papering and directory identity changes. Agents inherit constraints from principals that can block roadmap items.
Do we need PIS permission to show balances?
Balances and transaction history are AIS territory. PIS is about initiating payments. Many products need both; some need only one. Confirm against PERG 15 and counsel.
Should we build direct bank integrations first?
Usually not. Aggregators exist because bank-by-bank variance is real. Revisit direct connectivity when volume, latency or commercial terms justify a second stack.
How does this relate to embedded finance?
Open banking connects to accounts the customer already has; embedded finance often creates or distributes financial products inside a non-finance UX. They can combine (for example pay-by-bank inside a vertical SaaS checkout) but they are not synonyms—see Open Banking vs Embedded Finance.
What fails in production first?
Expired consents and unhandled payment status transitions. Build scheduler and status machines with explicit terminal states and clear customer messaging before you invest in categorisation ML features for PFM.
Build your UK Open Banking app with Fintegration
Fintegration helps fintech teams design regulated account-information and payment-initiation experiences: consent architecture, aggregator integration, payment status operations and the audit trails FCA-minded reviews expect. Talk to our team to scope your UK AISP/PISP product.
