AIS & PIS integrations
Production-grade account information and payment initiation services on TrueLayer, Plaid, Tink and Yapily — with the consent flows and customer-facing disclosures the FCA / CMA require.
02 — Open banking
Open banking platforms — AIS and PIS that don’t fall over at month-end.
Most open banking integrations work for the demo and break under real volume. The aggregator’s SDK doesn’t surface rate limits until you hit them, the consent renewal flow has edge cases that only show up at 90-day reconnect, and the categorisation accuracy that looked great in testing degrades when real customer data arrives.
FCA · UK CFPB · US FCAC · Canada
01 — Problem
Where open banking builds usually go wrong.
We’ve shipped open banking integrations on TrueLayer, Plaid, Tink and Yapily — and we’ve migrated platforms between aggregators when commercials shifted. That migration experience is the part you can’t get from a vendor: every aggregator has a happy-path SDK that hides the things that break in production. Rate limits that aren’t documented. Consent refresh windows that vary by bank. Categorisation taxonomies that look the same but aren’t.
The platforms we build assume real volume from day one. Multi-aggregator routing is wired in even if you launch on one — because the second aggregator gets added later, when commercials change or coverage gaps emerge, and rebuilding the consent layer at that point is the most expensive thing you can do. Consent renewal is automated and audit-trailed. Categorisation has both rule and model layers so improvements can land without retraining everything.
And the affordability layer sits above all of it — because most clients aren’t really buying “open banking data,” they’re buying the affordability decision the data enables.
02 — What we build
End-to-end, audit-ready, in production.
Consent management
Multi-aggregator consent ledger, refresh logic per bank, customer-facing reconnect flows that don’t leak — and a full audit trail of every consent state change.
Categorisation engines
Transaction enrichment with both rule and model layers — so you can ship improvements incrementally and explain every category to a compliance reviewer.
Affordability scoring
Real-income calculation, regular-outgoings detection, headroom modelling — wired to your decisioning layer, with the evidence trail to defend against Consumer Duty challenge.
Variable Recurring Payments
Sweep configurations, ceiling controls, customer-facing limit management — and the audit hooks the FCA expects to see if a sweep ever goes wrong.
Multi-aggregator routing
Coverage-based and cost-optimised routing across aggregators — so a bank outage at one provider doesn’t take down the customer journey.
Open banking analytics
Engagement, drop-off and consent-completion funnels — with the lender-side data quality signals to drive aggregator selection and renegotiation.
FCA / CMA compliance
Consent flows, customer-facing disclosures, refresh prompts, opt-out pipelines — all the things the regulator looks for in an open banking journey.
03 — Patterns
Build patterns we ship from.
AIS engine
Production AIS layer with multi-aggregator support, retry strategy, rate-limit awareness and full event sourcing for replay.
TrueLayerPlaidTinkYapily
PIS engine
Single and bulk PIS payment flows with refund handling, scheme-routing-aware retry and customer-facing status surfaces.
TrueLayer PISTink PayToken.io
Consent platform with refresh / renewal automation
Consent ledger, bank-specific refresh windows, customer-facing reconnect flows and proactive expiry warnings.
Postgres event-sourced consent ledgerAWS Step Functions
Multi-aggregator routing layer
Coverage-and-cost-aware routing with automatic failover — so an aggregator outage doesn’t break your journey.
AWS Step FunctionsOpenTelemetryInternal routing DSL
04 — Regulations
What this work has to comply with.
UKUK PSRs 2017UKCMA OrderUKOpen Banking Standards (OBL)EUPSD2USSection 1033 (stayed)USFDX StandardsCAConsumer-Driven BankingUKFCA Consumer Duty
05 — Stack
What we build with.
Aggregators
TrueLayerPlaidTinkYapilySalt Edge
Categorisation & enrichment
MoneyHubBudNordigenInternal rule + model layer
Infrastructure
AWS Step FunctionsPostgres (event-sourced consent ledger)Kafka / SQSOpenTelemetry
06 — Recent build
A consents and affordability engine, productionised in 9 weeks.
A UK consumer credit broker had outgrown a single-aggregator AIS integration. Coverage gaps were costing them ~7% of applications at the eligibility stage, and the existing consent flow was generating a steady trickle of complaints — most about 90-day reconnect prompts that weren’t landing cleanly.
We delivered a multi-aggregator AIS engine on TrueLayer and Plaid, with a consent ledger that handled both providers’ refresh windows; a categorisation layer that combined the aggregator’s enrichment with our own rules for credit-specific signals; and an affordability scoring pipeline that produced a Consumer-Duty-defensible “disposable income” figure for every applicant.
Within four weeks of full rollout the client’s eligibility-stage drop-off had closed by 5.4 percentage points, the consent-related complaint volume had dropped by ~80%, and the affordability layer cleared the firm’s internal Consumer Duty controls review on first submission.
9 weeks
Build to production
5.4pp
Drop-off recovered
80%
Complaint reduction
07 — FAQs
Questions we get every time.
How long does a TrueLayer / Plaid integration take to productionise?
For a single-aggregator AIS integration with a working consent UI and one downstream consumer (say, affordability), 4–6 weeks. Adding PIS extends that by 2–3 weeks because the operational layer around refund handling and customer-facing status is non-trivial. Multi-aggregator from the start is 8–10 weeks — most of the extra time is in the consent ledger and the routing layer, not the second integration itself. Migrating between aggregators on an established platform is usually 6–8 weeks if the consent layer was designed multi-aggregator from day one, or 12–16 weeks if it wasn’t.
What’s the right architecture for multi-aggregator open banking?
Three layers, separated cleanly: (1) a normalised consent ledger that owns the canonical state of every customer consent across aggregators; (2) per-aggregator adapter clients with no business logic in them; (3) a routing layer above that picks which aggregator to use per-call based on coverage, cost and current availability. The non-obvious part is keeping the consent ledger as the source of truth — not the aggregator. When you migrate or add an aggregator later, the consent ledger doesn’t change; only the adapter does.
How do you handle 90-day consent renewal without dropping the customer?
Two things: a proactive customer-facing “your bank connection is about to expire” flow that fires 14 days before expiry with a one-tap reconnect link; and a per-bank refresh-window registry — because the regulatory 90-day cap is the maximum, but several banks enforce shorter windows or behave inconsistently around the boundary. Plus telemetry on the reconnect funnel itself, because the loss-rate at reconnect is the single biggest driver of long-term coverage degradation.
What’s the right pattern for VRP sweep with customer-controllable limits?
Customer-controllable ceiling (with a regulator-aware minimum), an event-sourced sweep ledger keyed to the underlying VRP consent, a cooldown / circuit breaker that pauses sweeps if anomalies are detected, and a complete audit trail of every sweep event keyed back to the consent state at the time of the sweep. The cooldown is the bit most builds skip and the FCA’s commercial-VRP guidance asks about.
How do you switch from one open banking aggregator to another without rebuilding the journey?
If the consent ledger is properly separated from the aggregator (as in answer 2), the switch is largely an adapter change. The customer journey stays identical. Existing consents stay where they are — you don’t re-prompt customers on day one of the migration; you let consents drain naturally as they expire and reconnect via the new aggregator. In practice we run both aggregators in parallel for 30–90 days with the new one taking new traffic, then shut the old adapter when the consent set has fully transitioned.
— Adjacent practices
Most builds combine two or three.
Scoping a open banking build?
Send us a few sentences. We’ll come back inside three business days with a credible delivery plan and a date.