Payments architecture is the discipline of designing how money actually moves through a platform — which entity holds funds, which partner is on the hook to the network, where the licensing perimeter falls, and how the economics work once interchange, scheme fees and sponsorship costs are counted.
It is rarely a technology problem. The failures we see are structural: a platform that built on a BaaS partner which later de-risked it, an acquiring relationship with no sponsor-bank continuity plan, funds held without a documented safeguarding basis, or an interchange model that was never viable at scale.
We design the architecture and then get it signed — sponsor bank, processor, card network and, where required, the licensing that supports the model.
- You are launching a card, wallet, payout or merchant-acceptance product and have not settled who holds funds or who sponsors you.
- Your BaaS or processor partner has changed its risk appetite and you have no continuity plan.
- You are expanding into a new market and need to know whether it is a licensing question, a sponsorship question, or both.
- Interchange or scheme economics are not covering the cost of the current architecture.
Who holds the money, and on what basis
Safeguarding, settlement and the legal basis for holding customer funds determine both the licensing perimeter and whether a sponsor bank will accept the flow.
Sponsor-bank continuity
A single sponsor-bank relationship is a single point of failure. We structure for continuity, and for what happens when a partner de-risks you.
Unit economics designed in
Interchange, scheme fees, sponsor margin and processing cost are modelled together, because an architecture that cannot pay for itself is not an architecture.
- Money-flow and entity architecture diagram, with funds held at every step identified
- Sponsor-bank, processor and scheme relationship strategy
- Licensing perimeter analysis (EMI, PSP, MTO, MSB, state MTL) per market
- Safeguarding, settlement and reconciliation design
- Interchange, scheme-fee and sponsorship cost model
- Partner shortlist and introductions, plus coordination through to signed agreements
- 01
Map the flow
Every step money takes — authorisation, clearing, settlement, payout — with the entity that holds it at each point. Most structural problems become visible here.
- 02
Set the perimeter
Which activities require authorisation in each market, and which are legitimately carried by a licensed partner. The split determines the entity plan.
- 03
Design the architecture
Sponsor, processor and scheme structure; safeguarding model; settlement and reconciliation; and the fallback for each critical partner.
- 04
Model the economics
Full cost stack — scheme fees, sponsor margin, processing, licence cost — tested against your pricing.
- 05
Sign and integrate
Partner introductions, commercial negotiation support and coordination through integration and go-live.
Architecture review
A written read on your existing or proposed money flow, perimeter and economics — with the structural risks named.
Design and partner selection
Full architecture design, licensing perimeter analysis and managed partner selection through to signed agreements.
Launch programme
Design through integration and go-live, with the licensing workstream run alongside.
- Teams seeking cheapest-possible processing rather than a durable architecture — this work is not a procurement exercise.
- Builds already contractually locked to a sponsor with no flexibility on entity or flow.
Frequently, yes, and it is often the right first step — but only when the sponsor arrangement is genuinely durable and the funds-holding is documented. The risk is that a partner-licence model leaves you with no licence, no direct network access and no leverage if the partner changes its appetite. We design the partner model with an explicit migration path.
It depends on whether you hold funds and where you serve. Registration regimes permit narrower activity than an EMI authorisation, and the difference usually shows up at the banking step rather than the filing step. Getting this wrong is expensive because it is discovered by a bank, late.
Onboarding typically takes far longer than the technical integration. That is why we begin the partner workstream early and in parallel, rather than treating it as a step after licensing.
It follows from your market, your average transaction value and your risk profile — not from the brand. We model the economics for each viable scheme and shortlist on the basis of what actually clears.