What Actually Decides Whether Your Payments Product Ships

Quick answer: Four things decide whether a cross-border payments product exists, and none of them are engineering: whether you hold a licence or operate under a partner's, whether you can reach the payment rails for your corridor, what KYC/AML obligations you must carry, and what it costs you to move one unit of money. Licensing and compliance requirements differ by jurisdiction and must be confirmed with a qualified lawyer. Settle all four before you scope a build — good engineering cannot rescue an unlicensed corridor or negative unit economics.

Eight articles in this series have been about building the thing well: start with a monolith rather than microservices, get the ledger right on day one, split the system only when a real boundary appears, hire when the work is defined rather than before. All of that is worth doing. None of it decides whether your product ships.

This last part is about the other half — the half where good engineering earns you nothing. Our founder spent two and a half years on Wise's core payment platform team, owning payment creation and the full payment lifecycle, and we have since built cross-border crypto-to-fiat transfer products and a real-time market surveillance platform for regulated markets. Almost everything that killed a payments idea in that time was a decision made before the first commit.

One thing stated plainly before anything else, and it will be repeated: this is not legal or regulatory advice. What activities require authorisation, what an agent or distributor arrangement permits, what your compliance obligations actually are, and whether you can serve a given country at all — these differ by jurisdiction, by business model and by year. They must be confirmed with a qualified lawyer in each market you intend to touch, before you commission code.

What are the four things that decide feasibility?

Everything that kills a cross-border payments product reduces to one of four questions:

• Under whose authorisation do you operate? Your own, a partner's, or none — with the third being a decision that has ended companies. This determines timeline, capital, and who can shut you down.
• Can you reach the rails? Money has to physically enter and leave in each corridor. That means a partner, a bank relationship, or scheme access — and access is granted, not bought off a shelf.
• What compliance obligations do you carry? Identity verification, sanctions and PEP screening, transaction monitoring, reporting, record-keeping, audits. Some of it is your partner's problem; much of it becomes yours, and which is which is a legal question.
• What does one transfer cost you? Not the app, the transfer. If moving €200 costs you more than you earn on it, no amount of growth fixes that. Volume multiplies the loss.

Notice that all four are answerable on paper, in weeks, for the price of a lawyer and a few partner conversations. Founders routinely spend six months and a six-figure build finding out the answers instead.

Should you get your own licence or operate under a partner's?

This is the largest fork in the road, and it is genuinely a choice — both routes are legitimate, and the right one depends on your corridor, your capital and your timeline.

Operating under a BaaS or licensed partner means someone else holds the authorisation and you distribute a product built on top of it, in whatever capacity your lawyer confirms is permitted where you operate. Obtaining your own authorisation means going to a regulator yourself, with capital, a compliance function, governance, and named responsible people.

All figures above are broad estimates, not quotes, and the categories themselves vary by jurisdiction — confirm with a lawyer.

The failure mode to plan for is not regulatory. It is partner concentration. A single licensed partner who can reprice, restrict a corridor, decline a customer segment, or leave the market is not a vendor — it is a single point of failure for the entire business. Read the termination and change-of-terms clauses more carefully than the API documentation. Ask what notice period you get. Ask what happens to in-flight transfers and customer balances if the relationship ends. Then ask what your second option would be, and how long switching would take, because "we would find someone else" is not a plan until you have named them.

The route most first products should take is the partner route, deliberately, with the own-licence question revisited once volume makes partner margin the dominant cost line. Renting the licence buys you the only thing that matters early: the chance to find out whether anyone wants this before you have spent the capital to be allowed to sell it.

Why is every new corridor a commercial decision, not a backlog item?

"We'll launch one corridor and add more later" is said in every payments pitch, and it hides the most consistently underestimated commitment in the business.

Each corridor — each currency pair and country combination — brings its own version of everything:

• Its own partner. New contract, new diligence, new certification, new API semantics, new commercial terms. Few providers cover every corridor you want at a price you want.
• Its own settlement behaviour. Cut-off times, business-day calendars, batch versus real-time, national holidays, and whether you must pre-fund. Pre-funding is not an engineering cost; it is working capital permanently parked in another country.
• Its own regulation. Local registration, permitted activities, reporting, data residency. Confirm each market with a lawyer in that market — an EU passport, an agent arrangement or a partner's coverage does not automatically extend everywhere you would like it to.
• Its own fraud profile. The patterns that drain money in one corridor are not the patterns in another. Your rules, thresholds and manual review load are corridor-specific and must be re-learned each time.
• Its own support burden. New language, new timezone, new dispute patterns, new volume of "where is my money" from people for whom that money is not discretionary.

We put a number on the engineering half of this in what it costs to build a money transfer app: a second corridor typically lands at 40–70% of the first one's cost, not the 10% founders budget. The commercial half is worse, because it does not end. A corridor is a permanent obligation to maintain a partner relationship, a fraud model, a compliance position and a support capability. Adding one is closer to opening an office than to shipping a feature.

Where does a payments product actually make money?

Three places, and only three: FX spread, explicit fees, and float — interest earned on balances while money is in your system, where holding it is permitted and where your model even allows it. Everything else is a variation on these.

The problem is that the costs of a single transfer are fixed-ish while the revenue is a percentage. Here is an illustrative walk-through of one €200 transfer. These are assumed figures for the shape of the argument, not benchmarks — your real numbers depend on corridor, partner, volume and negotiated rates.

Three things fall out of this table, and they are the whole commercial argument.

Small transfers are where products die. A percentage-based margin on a €50 transfer cannot absorb a fixed per-transaction cost stack, let alone a support contact. Many remittance corridors are dominated by small amounts sent frequently — which is exactly the profile the economics handle worst.

KYC amortisation is a retention problem wearing a cost mask. You pay for identity verification once per customer, including for the ones who abandon onboarding or never send anything. If the average customer sends twice and leaves, that cost lands almost entirely on those two transfers. Acquisition cost is not in the table above at all, and it is usually larger than everything in it.

Support contact rate is the most underrated number in the business. At a few euro of agent time per contact, moving contacts from one in five transfers to one in fifty changes the contribution line more than renegotiating your payout rail. That is the commercial argument for a correct ledger, clear transfer states and back-office tooling that lets an agent answer "where is my money" in seconds.

Why is compliance a permanent cost centre, not a launch task?

Founders budget compliance as a project with an end date. It is a function with a payroll.

What continues indefinitely, in some form, subject to what your lawyer confirms applies to you: transaction monitoring and alert triage; ongoing sanctions and PEP re-screening of your existing customer base, not just new sign-ups; suspicious activity reporting; periodic regulatory and partner reporting; record retention; policy maintenance; internal and external audits; penetration testing; and the people who do all of it. Partners audit you too, and a partner audit failed is a corridor closed.

The staffing reality is that alerts need human review, and alert volume scales with transaction volume, not with revenue. Automation reduces the ratio; it does not remove the function. Any financial model that shows compliance as a one-off launch line item is wrong in a direction that gets worse as you grow.

How should you sequence a launch to minimise risk?

The sequence that survives, in order:

1. Confirm the regulatory position first, with a lawyer, for the specific corridor and specific model you intend to run. Before design. Before hiring. It determines the architecture, the partner shortlist and the cost base.
2. Pick one corridor and one customer segment. Not one region. One direction, one currency pair, one identifiable group of people with a reason to switch to you.
3. Launch under a partner's licence. Rent the authorisation. Spend the capital on finding out whether the product works.
4. Prove the unit economics with real transfers. Real support contacts, real fraud, real failed payments, real average transfer size, real repeat rate. Every number in that table above, measured rather than assumed.
5. Only then widen — a second corridor, a second segment, or your own authorisation, whichever the numbers say is now the constraint.

Founders who launch broad do it for a defensible-sounding reason: more corridors means a bigger addressable market, and the pitch deck looks better. What actually happens is that fixed costs multiply — five partners, five compliance positions, five fraud models, five support languages — while volume in each corridor stays too thin for any of them to reach contribution. The money runs out before any single corridor becomes profitable, and because everything was launched at once, there is no evidence about which one would have.

One corridor that works is a business. Five corridors that half-work is a burn rate.

What was all the engineering advice for, then?

This series has argued for a set of unglamorous engineering positions: build a modular monolith rather than a distributed system you do not need yet; design the ledger correctly before the first real payment; split services only when a real boundary appears; hire specialists after the work is defined rather than before.

The reason for all of them is the same, and it is commercial rather than technical. Those choices keep you cheap enough and fast enough to still be alive while you solve the problems in this article. A team that spent its first year building infrastructure for scale it does not have, or that must stop for six months to migrate a broken money model, does not get to run the sequence above. It runs out of runway during step four — which is exactly the step where the answer to whether the business works finally arrives.

The app is the easy part. The engineering decisions in the earlier parts exist to buy you the runway to find out whether the hard part is solvable at all.

That is the end of the series. If it has been useful, the most valuable thing you can do with it is spend the next month on a lawyer and a spreadsheet rather than a sprint.

FAQ

Do I need my own licence to build a money transfer product?
Not necessarily — many products launch under a licensed partner's authorisation. Whether that route is available to you, and in what capacity, depends entirely on your jurisdiction, your corridor and your business model. It must be confirmed with a qualified lawyer in each market. Do not treat any blog post, including this one, as an answer.

How much does it cost to launch under a BaaS partner versus getting your own licence?
As broad estimates only: the partner route typically starts in the low tens of thousands plus commercial terms and integration; own authorisation commonly runs to high six figures or more once application costs, legal fees, regulatory capital and compliance hires are counted, over a much longer timeline. Both figures vary enormously by jurisdiction and model.

What is the biggest risk of operating under someone else's licence?
Concentration. The partner can reprice, restrict a corridor, de-risk your customer segment, be acquired, or exit. Before signing, read the termination and change-of-terms clauses, establish the notice period, understand what happens to in-flight transfers, and name a viable second option.

Why do small transfers lose money?
Because much of the cost of a transfer is fixed per transaction — rail fees, screening, amortised KYC, and any support contact — while revenue is a small percentage plus a fee that competition pushes down. Below a certain transfer size the fixed stack exceeds the margin, and volume only scales the loss.

How many corridors should we launch with?
One. Each corridor carries its own partner, settlement behaviour, regulatory position, fraud profile and support burden, and those costs are permanent. Prove contribution in one before adding a second — the engineering cost alone is typically 40–70% of the first corridor, and the commercial cost never ends.

When should we move from a partner licence to our own authorisation?
When partner margin has become your largest cost line and the corridor economics are proven with real transfers, not projections. Until then, the licence is not the constraint on the business — demand is. The timing question should be modelled with your lawyer and your actual volumes.

Before you write the spec, settle the four questions

If you are early enough that the licence route, the corridor and the partner are still open questions, that is the right time to talk — those four decisions shape the architecture, and reversing them later is what makes payments products expensive.

We have built cross-border crypto-to-fiat transfer products and a real-time market surveillance platform for regulated markets, and our founder spent two and a half years on Wise's core payment platform team owning payment creation and the full payment lifecycle. We are engineers, not lawyers — we will tell you where the legal question sits and build around the answer once you have it, including telling you when the honest answer is that the corridor does not pay.

Send us your corridor, your intended licence route and your target launch date, and we will tell you what is buildable and what it will cost. Request a quote → or book a call with our engineers →.

GPO-Tech designs and builds connected products and commercial software end to end — from one team in Tallinn, Estonia.

Request a quote →