Fintech MVP Development: Licences, Partners and Scope

Most fintech MVPs in the EU do not need their own licence on day one. The usual route is to build on licensed partners: an open banking aggregator for account data and payment initiation, and a payments platform or banking-as-a-service provider for moving or holding money. With Easify the software for such an MVP typically costs €10,000 to €25,000 over 6 to 12 weeks, while legal advice, partner fees and security testing are separate and can cost as much again or more.

Below: which regulated activities a fintech MVP usually touches, when a partner covers them and when it does not, which build route fits, the build step by step, KYC and anti-money-laundering, DORA, the security that matters at this stage, a minimum feature set, what to leave out, a worked example, a typical scope and price, how to tell whether it worked, a pre-launch checklist, common mistakes, a brief you can copy, and when not to hire us. Nothing on this page is legal advice; it is orientation so you can ask a lawyer better questions.

At a glance

The regulated activities a fintech MVP usually touches

The EU regulates activities, not products, so start by naming what your product actually does with money or account data.

• Reading a user's bank accounts. An "account information service" under the Payment Services Directive (PSD2) is an online service that provides consolidated information on payment accounts held with other providers (Article 4). A provider offering only this needs registration rather than full authorisation (Article 33), but it is still regulated.
• Starting a payment from a user's bank account. A "payment initiation service" (Article 4) needs authorisation as a payment institution.
• Holding or moving other people's money. Collecting funds from one user and paying them to another is usually a payment service. Article 37 requires Member States to prohibit anyone who is neither a payment service provider nor explicitly excluded from providing payment services.
• Stored value, wallets and prepaid balances. "Electronic money" under the E-Money Directive is stored monetary value, issued on receipt of funds, used for payments and accepted by people other than the issuer (Article 2). Issuing it needs an e-money licence.
• Lending, investment and crypto. These have their own regimes, and are outside what this page covers. Treat them as a separate legal question from the start.

The exclusions in PSD2 are narrow. Article 3(b), for example, excludes payments through a commercial agent who acts for only the payer or only the payee, which is not the same as a marketplace acting for both sides. Do not assume an exclusion applies because it sounds close.

PSD2 is due to be replaced by a third Payment Services Directive and a Payment Services Regulation. The agreed texts were published by the Council in April 2026, but formal adoption and publication in the Official Journal were still to follow at that point, according to Matheson's summary. Until they apply, PSD2 is the law to plan against.

If you cannot tell which box you are in, your national financial regulator may be able to help before you spend on a build. National authorities across the EU run "innovation facilitators", typically innovation hubs and regulatory sandboxes, and they have coordinated through the European Forum for Innovation Facilitators since 2019, according to the EFIF's procedural framework for cross-border testing. An innovation hub conversation does not replace a lawyer, but it is a cheap way to learn how your regulator reads your model.

When a partner covers you, and when it does not

The partner route is what makes a fintech MVP affordable, but it has edges.

• Open banking through an aggregator. Aggregators hold the licence and give you an API. Tink, for example, states on its legal page that it is an authorised payment institution for account information and payment initiation in the EEA, and also that its licences do not cover activities carried out by its customers or partners. The aggregator covers the account access; it does not cover what you then do with the money.
• Payments between users through Stripe Connect or similar. The platform provider handles the regulated money movement and the verification of the accounts it pays out to. Your product decides who gets paid, when and how much.
• Accounts, cards and wallets through a banking-as-a-service provider. The provider, or the bank or e-money institution behind it, issues the regulated product, and you act under its programme. Expect onboarding questions about your business model, your compliance staff and your controls before you get production access.

Three questions to put to every partner, and to your lawyer, before scope is fixed:

1. Exactly which activities does your licence cover in my flow, and in which countries?
2. Which obligations stay with me: customer communications, complaints, record-keeping, sanctions screening, fraud monitoring?
3. What do you need from my product before you switch on production, and how long does that review take?

The answer to the third question is often the critical path. Partner onboarding can take longer than the build.

Which build route fits

There are four realistic ways to get a fintech MVP in front of users. They differ less in price than in what you can change later and who carries the regulated part.

Our work is the second row. If the first row has already shown demand, the Prototype Check tells you what in the prototype is safe to keep. For the general version of this choice, see agency vs freelancer vs no-code.

How to build a fintech MVP, step by step

1. Write the one question, and how you will measure the answer. For example: will freelancers let an app sweep a share of each invoice into a tax pot? Everything in the scope should help answer it. The measures are covered further down.
2. Name the regulated activities. Use the list above. Write down, for each step of the flow, whether money or account data moves and who moves it.
3. Shortlist two partners per regulated step and start onboarding. Ask the three questions above. Open sandbox accounts in the first week, because their APIs and their review process shape the scope.
4. Get a written legal view on the flow. Give the lawyer the flow diagram and the partner answers. A short opinion on whether you need your own licence is cheaper than a rebuild.
5. Fix the scope and price. Features in, features out, user flows, data model, ledger rules and the launch market. This is what our €900 Scoping Sprint produces, and its fee is credited in full against the build if you build with us.
6. Build on sandboxes. Sign-up, KYC states, the one money flow, the ledger, webhooks and the admin view, all against the partner's test environment, with test data only.
7. Test the failure paths. Declined payments, duplicate webhooks, a user who fails KYC halfway, a partner outage, a reconciliation mismatch. These matter more than the happy path.
8. Security test and partner review. A penetration test on the finished MVP, fixes, then the partner's production review.
9. Launch to a small, invited group. One market, a cohort you can talk to, limits on amounts if the partner allows them.
10. Measure, then decide. Use the measures you set in step 1. Expand, change the flow, or stop.

Steps 3 and 4 run alongside the build, not before it, but they must start first. If the partner's review needs something the product does not have, you want to know in week two, not week ten.

KYC and anti-money-laundering

Payment and e-money institutions are obliged entities under EU anti-money-laundering law, currently the Anti-Money Laundering Directive. The new Anti-Money Laundering Regulation applies from 10 July 2027 (Article 90). If you use a licensed partner, it carries the formal duty, and you implement its requirements in your product.

What that means for the build:

• Use the partner's hosted onboarding where you can. Stripe recommends its hosted Connect onboarding so that Stripe handles the basic KYC obligations, and notes that requirements change over time (Stripe Connect identity verification).
• Do not treat the partner's check as yours. The same Stripe page says platforms should not rely on Stripe's verification to meet any independent legal KYC or verification requirements, and must still monitor for and prevent fraud.
• Design for incomplete verification. Users will be part-verified, paused or asked for more documents. Every screen that moves money needs a state for "not allowed yet".
• Keep an audit trail. Who did what, when, with what verification status. Regulators and partners ask for it, and it is much cheaper to build in than to reconstruct.

DORA basics

The Digital Operational Resilience Act (DORA) has applied since 17 January 2025 (Article 64). Article 2 lists who it covers, including credit institutions, payment institutions, account information service providers, e-money institutions, crypto-asset service providers and crowdfunding service providers, and it also brings in ICT third-party service providers.

• If you hold no licence, DORA applies to your partner, not directly to you. Expect the partner's contract to carry some of its requirements down to you, such as incident reporting, access and audit rights, and exit plans.
• If you will hold a licence, you need an ICT risk management framework, incident classification and reporting, resilience testing and a register of ICT third-party arrangements. Article 30 sets the key terms your contracts with ICT providers must contain, and that includes the agency that builds your product.

For an MVP, the practical point is to design for it now: know every third-party service the product uses, log incidents, keep infrastructure as code, and be able to move hosting if you have to.

Security that matters at MVP stage

You do not need a bank's security programme for an MVP, but a few things cannot be added later without rework.

• Strong customer authentication. PSD2 Article 97(1) requires payment service providers to apply strong customer authentication when the payer accesses a payment account online, initiates an electronic payment, or does anything through a remote channel that may imply a risk of fraud or other abuse, as reproduced in this EBA single rulebook Q&A. On a partner, the partner usually runs it inside its own flow. Your job is to send users into that flow at the right moments and handle the result, and to put two-factor sign-in on your own app as well.
• Keep card numbers off your servers. Stripe's integration security guide says a business that handles sensitive card data directly may have to meet more than 300 PCI DSS controls, and that its low-risk integrations send payment details to Stripe without passing through your servers, which reduces your PCI obligations. It also notes you still attest to compliance every year. For an MVP, use the hosted fields or hosted pages, always.
• Verify every webhook. The same guide says to use TLS on webhook endpoints and to verify webhook signatures. Combine that with idempotent handling from the checklist below, and a forged or repeated event cannot move money.
• Secrets and access. Partner API keys in a secrets manager, never in the code or the frontend. Separate sandbox and production keys, and as few people as possible with production access.
• Test against a standard. The OWASP Application Security Verification Standard, currently version 5.0.0, is a list of security requirements for web applications. Use it as the checklist for the build and for the penetration test brief.
• A penetration test before real money. Book it for the finished MVP, not the design, and leave a week to fix what it finds. It is a separate cost from the build.

Data, hosting and the GDPR

Financial data is not a special category under the GDPR, but it is the data people least want leaked. We deploy client products to EU data-centre regions, so your product is hosted in the EU. That is not the same as the data never leaving the EU: our engineers work from India, so any access they have to production data is a transfer that needs a valid mechanism under Chapter V of the GDPR, and the safest MVP gives them as little of it as possible. Use test data and the partners' sandboxes during the build, and production access only when it is needed.

Minimum feature set checklist

• Sign-up with email verification and two-factor authentication
• KYC through the partner's hosted onboarding, with states for pending, rejected and more-information-needed
• The one financial flow you are testing, end to end, on the partner's API
• Clear display of fees, timings and who the regulated provider is
• Ledger of every money movement in your own database, reconciled against the partner
• Webhook handling that is idempotent, so a repeated event never moves money twice
• Admin view of users, verification status and transactions
• Audit log of user and admin actions
• Complaints and support contact, as the partner requires
• Terms, privacy policy and the partner's required disclosures

What to leave out of version one

• Your own licence. Test demand on a partner first, unless the licence is the business.
• More than one money flow. Pick the one that answers the question: top-up, pay-out, split, or account view.
• Multiple partners and countries. One aggregator, one payments partner, one launch market.
• Native apps. A responsive web app with strong authentication is enough to test most fintech ideas.
• Automated credit or risk decisions. Credit scoring of individuals by AI is high-risk under the EU AI Act. Keep a person making the decision until you know you need more.
• Cards. Card programmes add issuing, scheme rules and physical logistics. Add them once the core flow works.

Worked example: a tax-pot app for freelancers

A fictional product, to show how the decisions above turn into a scope. It is not a client project, and the price is illustrative, not a quote.

The idea. The app helps freelancers in one EU country set money aside for tax. The user links their business bank account, the app spots incoming client payments, and it suggests moving a percentage into a savings account the user already has.

The one question. Will freelancers approve a suggested transfer most months, or do they ignore the prompt?

Regulated steps and who covers them.

In version one: sign-up with two-factor authentication, bank linking through the aggregator's hosted flow, detection of incoming payments with a simple rule the user can edit, a monthly suggestion with one-tap approval into the aggregator's payment flow, a record of every suggestion and transfer, an admin view and an audit log.

Left out: holding money in an in-app wallet (that would raise the e-money question), tax calculations presented as advice, more than one country, native apps, cards, and any automatic transfer without the user's approval.

Where it lands. Read-only open banking plus one initiated payment sits between the first two rows of the table below, so roughly €14,000 to €19,000 and 7 to 9 weeks of build. Not included: the aggregator's fees, a legal view on the flow and on how the tax wording is presented, and a penetration test.

Typical scope and price

Illustrative ranges inside our €5,000 to €25,000 MVP band, not a quote. They cover the software only. Rates are on the pricing page, and the MVP cost calculator gives a range for your own scope.

The honest note: the build is often not the largest cost in fintech. Legal opinions on whether you need a licence, partner set-up and monthly minimums, a penetration test before launch, and compliance staff are separate, and a licence application is a project of its own. Budget for them before you budget for features. For how MVP prices compare more widely, see what an MVP costs in Europe.

What drives the price in fintech

• The number of money flows. Each pay-in, pay-out or transfer type brings its own states, failure cases, ledger entries and reconciliation. This is the largest single driver.
• Who holds the money. Read-only data is the cheapest; initiating payments costs more; holding balances through a partner costs the most.
• Verification depth. Individuals only, or businesses with directors and beneficial owners, which multiplies the onboarding states.
• Countries. Each market can bring different partners, languages, disclosures and tax handling.
• Back office. How much your team must do by hand (refunds, disputes, manual reviews) and how much needs a screen for it.

Running costs after launch

Ask each partner for its full price list before the scope is fixed, because these costs scale with users, not with the build:

• partner platform fees and any monthly minimum;
• per-transaction or per-API-call fees;
• identity checks per user, including repeat checks;
• hosting, monitoring and logging;
• support time for disputes, failed payments and verification questions;
• ongoing maintenance as partner APIs and rules change.

For how founders fund the build and these early costs, see the guide to MVP grants and funding in Europe and EU funding for startups.

How to tell whether the MVP worked

Set these before the build, write them into the scope, and build the tracking with the product. Example measures, to be replaced with your own thresholds:

Pre-launch checklist

Treat these as gates. If one is open, the launch waits.

• Every money movement in your ledger reconciles with the partner's report, and a deliberate mismatch has been tested and traced
• A failed payment, a duplicate webhook and a partner outage have each been rehearsed from detection to resolution
• Penetration test done and its findings fixed or formally accepted
• Partner production review passed, in writing
• Lawyer has read the flows, the disclosures and the terms
• Fees, timings and the name of the regulated provider are shown before the user commits
• Production data access limited to named people, with access logged
• Incident contact and process agreed with the partner
• Complaints route live and tested
• Transaction limits set for the pilot, if the partner allows them

Common mistakes

• Building before talking to a partner. The partner's onboarding questions change the scope. Build first, and you may end up rebuilding the KYC and ledger parts.
• Trusting the partner's balance as your only record. You need your own ledger to answer support questions and to spot reconciliation gaps.
• Treating "pending" as done. A payment request is not a payment. Show pending states until the partner confirms.
• Assuming an exclusion applies. As above, PSD2 exclusions are narrow. Get it in writing from a lawyer.
• Launching in several countries at once. Each one adds partners, disclosures and support languages to a product that has not yet proved anything.
• Leaving security testing to the end with no time to fix. Book the test date when you book the build.
• Measuring sign-ups. In fintech the useful signal is a completed, repeated transaction.

A brief you can copy

Send this to any developer, including us. Filling it in will also show you what you have not decided yet.

Product in one sentence:
The one question the MVP must answer:
Target users and launch country:
What the product does with money or account data, step by step:
Partners considered (aggregator, payments, BaaS) and onboarding status:
Do you hold or plan to hold a licence? Legal advice so far:
Must-have features for version one:
Deliberately left out:
Success measures and thresholds:
Admin and back-office tasks your team will do:
Deadline, and what drives it:
Budget range for the build, and separately for legal, partners and security testing:

Questions to ask a fintech MVP developer

1. Which partner APIs have you integrated, and can we see how you handle their webhooks and failure cases?
2. How do you design the ledger and reconciliation, and who owns that code?
3. How do you keep card data and production data away from your developers?
4. Where will the product be hosted, and who on your team can access production?
5. What is in the fixed price, and what is a change request?
6. What happens when the partner's review asks for changes after the build?
7. Will you work with our lawyer and our penetration tester directly?

More general questions are in how to choose an MVP development agency.

Start with the Scoping Sprint

For fintech, the €900 MVP Scoping Sprint is the step we recommend before anything else. It is credited in full against the build if you build with us. In about two weeks you get, in writing: the one question the MVP must answer, the smallest feature set that answers it, what is deliberately left out, the main user flows, the technical and hosting plan, and a fixed price and timeline for the build. For a fintech product, the flows also show exactly where money and data move and which partner handles each step, which is the document your lawyer and your partner's onboarding team will both want. The scope is yours to keep whatever you decide.

If you already have a working prototype from a tool such as Lovable or Bolt, the €99 Prototype Check is a smaller first step: in 48 hours you get the top risks in writing, and the fee is credited against the build.

When not to hire us

• You need a licence before the first user. If the product cannot launch on a partner, start with a regulatory lawyer, not a build.
• You want an agency with fintech case studies. We have none yet. We take fintech work, and we will not pretend otherwise.
• The product is the core banking system. A ledger that a regulator will rely on is a different scale of project from an MVP.
• You have not spoken to a partner. Talk to two aggregators or payments partners first; their constraints shape the scope more than any feature list.

For how we run MVPs generally and what you own at the end, see MVP development.