Most of a payment product’s compliance lives in its code and its data model. Before you take real money, you need five things working: a licence route (your own licence or a licensed partner’s), customer checks at sign-up, a record of every money movement that nobody can quietly change, strong authentication where your market requires it, and tight rules on who sees customer data. Regulators and payment partners look for these before they let you go live. This guide lists what to build, links each regulator’s own page, and shares what partners checked on our payment builds in Cameroon and Japan. It isn’t legal advice. A licensing lawyer in each market you sell in has the final word.
Every payment product runs under someone’s licence. Either you get your own, or you build on top of a company that already holds one: a payment provider, an e-money institution or a bank. This choice decides your launch date more than any feature does.
| Route | What it means | Fits when | What you still build |
|---|---|---|---|
| Your own licence or registration | You hold the permission and answer to the regulator directly | You plan large volumes and want full control of the money flow | Every control in this guide, plus the policies, forecasts and people the regulator asks for |
| A licensed partner | The partner holds the licence, and your product runs on its rails | You want to launch on a known timeline and test demand first | The customer data, records and controls the partner’s checks require |
The rules for the first route differ by country, and the regulators publish them. In the UK, the FCA’s authorisation page says a firm can register as a small payment institution if its monthly average payment transactions stay at or under €3m over 12 months, and must apply as an authorised payment institution above that. An application needs policies and procedures, financial forecasts and evidence of the team’s knowledge and experience, and the fee isn’t refunded. In the US, the FinCEN registration page says most money services businesses must register within 180 days of being set up and renew every 24 months. A business that is only an agent of another one generally doesn’t register.
Koncierge, a payment platform we built for Japan, took the second route. The payment provider holds the licences. Merchants, mostly FX brokers, take deposits from customers in Japan through licensed local agents, because foreign brokers can’t hold local bank accounts there directly. The product still had to work under Japan’s strict anti-money-laundering rules, with full customer data on record.
A licence route tells you who answers to the regulator. The product still has to prove, every day, who paid whom. These are the controls we would build into a first release, with examples from our own projects.
| Control | What to build | Example from our builds |
|---|---|---|
| Know your customer | Sign-up that collects every field your partner’s or regulator’s checks need, and refuses to create a half-complete customer | Koncierge needs full details for customers created from a withdrawal, including a name in Latin letters |
| Match every payment to a person | A reference or account per customer, plus a queue for anything that doesn’t match | Each Koncierge customer gets a payment reference for life, one katakana character and four digits. Unmatched deposits wait for a person |
| A record nobody can erase | Soft delete, an event log and balances you can rebuild from it | Koncierge never erases records. IPOPBOOKS logs every posted entry |
| Approval before money moves | Admin approval for new merchants and for limit changes | AggloPay merchants register themselves, and an admin approves each one |
| Strong authentication | A second check at login and at payment where the market requires it | AggloPay checks payments through Flutterwave with CVV, PIN, one-time codes and 3D Secure |
| Need-to-know access | Roles that show each person only their own data | Each Koncierge party sees only its own data. IPOPBOOKS bookkeepers never see client contact details |
| Rules as settings | Limits, fees and plans an admin can change without a release | AggloPay admins set up and assign tariff plans |
Two more items belong on the list even though they’re mostly about what you don’t build. Keep card numbers off your own servers when you can. The PCI DSS standard applies to anyone who stores, processes or transmits cardholder data, so a provider’s checkout that takes the card number for you keeps a lot of work off your plate. And treat personal data as a liability from the first day. The European Commission’s GDPR guide for businesses lists the duties, notifying data breaches among them.
In our builds, partner checks were often the slowest part of the schedule. Plan for that from week one.
On AggloPay, a payment platform for merchants in Cameroon, the security checks of the payment provider Flutterwave were extremely strict, and getting through them took a lot of fine-tuning. The product still went from first sketches to a working product in 2 months, because we tested the payment integrations in a pre-development phase, before the main build. On IPOPBOOKS, a bookkeeping platform for US small businesses, the first bank data provider asked for a stack of security policies before it would sign. We moved the bank feeds to another provider so the launch didn’t wait on that paperwork, and kept the first provider in the code for later.
The same habit helps with your own team. During the IPOPBOOKS build, only one person at Rocketech could see client data. A partner or an auditor will ask who had access and when. It’s easier to answer that question when the answer is short.
The EU’s standards for strong customer authentication under the second Payment Services Directive (PSD2) are a good example. According to the European Banking Authority, an amendment made banks stop applying the extra check when customers use an account information service, and it applied from 2 October 2023. A product with its rules in code needs a release for a change like that. A product with its rules in settings needs an admin and an afternoon.
More changes have landed since then. Ask your lawyer which ones apply to you.
| Rule | Date | What it means for the product |
|---|---|---|
| PCI DSS v4.0.1 future-dated requirements | Mandatory from 31 March 2025 | The PCI Security Standards Council says two of them, 6.4.3 and 11.6.1, make sure scripts on a payment page are authorized, checked for integrity and monitored for tampering |
| EU Digital Operational Resilience Act (DORA) | Applies from 17 January 2025 | The European Banking Authority says payment and e-money institutions now report major incidents under DORA, not under PSD2. Incident logs and alerts belong in the first release |
| UK safeguarding rules, FCA PS25/12 | In force from 7 May 2026 | Payment and e-money firms reconcile the customer money they safeguard at least once a day, except weekends and public holidays, and send the FCA a monthly safeguarding return. That needs a ledger the reconciliation can run on |
| EU Anti-Money Laundering Authority (AMLA) | Started operations in summer 2025 | AMLA plans to pick 40 firms for direct supervision during 2027 and start supervising them during 2028 |
So keep limits, fees, plans and check thresholds in the admin panel. Log every change to them, with who made it.
Before you sign with a partner, you can run your idea through our project estimate. It works in four steps:
Here is an example run of our estimate’s math with sample inputs, for a mobile payments app on a licensed payment provider with an identity check vendor. The inputs are assumptions, not a forecast: each active user brings in $6 a month at a 60% margin, stays 18 months and costs $25 to win, and 400 new users arrive each month. With those guesses, the build comes out at $8,700 to $18,000 over 4 weeks. Each user brings $4 of profit a month and $72 over their lifetime, which leaves $47 after the cost to win them. 285 users pay for the build. The app earns more than it spends from month 7 and pays the build back in month 13.
Our fintech app development page lists the questions to ask any fintech software development company, with our own answers. The full builds are in the Koncierge case study and the AggloPay case study. If you plan a full banking app with accounts and cards, read our guide to building a neobank app next.
Not always. A payment product can launch on a licensed partner, such as a payment provider, an e-money institution or a bank, and the partner holds the licence. Whether that works for you depends on your markets and on where the money sits. A licensing lawyer in each market should confirm the route before you build.
At minimum: complete customer data at sign-up, a way to match every payment to a person, a record that can’t be erased, admin approval before new merchants or limits go live, strong authentication where the market requires it, and roles that show each person only their own data.
The PCI Security Standards Council says PCI DSS applies to entities that store, process or transmit cardholder data. If a payment provider’s checkout takes the card number and your servers never see it, far less of your own system falls under it. Check the details with the provider and an assessor.
There is no fixed number. In our builds they were among the slowest items. Flutterwave’s security checks for AggloPay took a lot of fine-tuning, and IPOPBOOKS switched bank data providers so the launch didn’t wait on a stack of security policies. Start them in the first week.
No. We build the product and the controls, and we work with the checklists your lawyer, regulator and payment partners give you. The regulator pages linked in this guide are the place to start reading.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.