Payments engineering for regulated UK, US and Canadian fintechs.

It depends on which acquirer and what your existing platform looks like. Typical first integrations land in 6–10 weeks for a programme that already has the legal and BIN sponsorship in place. We’ve done shorter (4 weeks) for clients on top of a flexible payments-as-a-service provider, and longer (12–16 weeks) where the client is also doing scheme-direct work for the first time. The honest answer is “6 weeks if you’re not also onboarding the acquirer.”

Three things working together: (1) an event-sourced ledger where the customer-balance position is always derivable from the rails events, never stored as a denormalised number; (2) a real-time match between those events and your safeguarded-account balance sweeps; and (3) an evidence pack — generated daily, retained for the regulatory window — that any auditor can pick up and answer “were customer funds segregated continuously?” with one query. The May 2026 regime makes the third item non-optional.

Yes, but we recommend you bring one anyway — they earn their fee just by sense-checking architecture decisions early. Where we add value is in keeping you out of in-scope environments wherever possible: network tokens, customer-tokens, BIN-routed flows and clean iframe / hosted-field patterns mean we typically build platforms where the PAN never touches your servers. That collapses the assessment from a SAQ D job to an SAQ A in many cases.

Scheme-aligned workflow with calendar-aware deadlines for every dispute state, a built-in representment pipeline that pulls evidence directly from your transaction event store, and a separate channel for cardholder-initiated disputes vs. fraud chargebacks. We’ve found that automating the evidence-collection step — even when humans still write the cover letter — typically drops chargeback write-offs by 25–40% in the first quarter.

Event-sourced, sub-ledger granularity, multi-currency at the entry level (not summed). The non-obvious bit is that you want one ledger per legal-entity-per-currency, not one ledger per customer. The customer’s balance is a view on top of multiple ledger positions. That structure scales cleanly to multi-region and to programme-as-a-service models where a single customer holds positions across several legal entities.