Fintech development studio: what to vet on KYC, PSD3 and DORA

A fintech development studio is a product team that designs and builds regulated financial software, carrying the compliance constraints (identity checks, payment permissions, operational resilience, accessibility) into the interface and the code instead of adding them in a review before launch. The distinction matters in 2026 because the European rulebook a fintech ships under is being rewritten on five separate calendars, and three of them land after a product started this year goes live.

This is a buyer's brief. It covers what changed between 2025 and 2028, the four questions worth asking before you sign, and where the boundary sits between a build partner and the licensed institution and lawyers you also need.

What a fintech studio does that a generalist studio does not

Any competent studio can build a dashboard, a signup and a card checkout. A regulated financial product adds three obligations that change the shape of the software: the user's identity has to be verified and re-verified, the money movement has to sit on someone's licence, and the whole system has to survive a supervisor asking for evidence rather than screenshots.

Those obligations move ordinary decisions. Onboarding stops being a three-field form and becomes a state machine with a manual review queue behind it. The database stops being one schema and grows an append-only ledger that nothing updates in place. The incident channel stops being a Slack thread and becomes a reporting duty with a clock attached. A team that has never worked under those constraints will quote the dashboard accurately and meet the rest in month three.

What changed in the EU between 2025 and 2028

Five dates set the frame. Two have already passed and two of the remaining three land after most products started in 2026 are live, which is why they belong in the architecture conversation now.

• DORA has applied since 17 January 2025. Financial entities have to govern ICT third-party risk, keep a register of information on every ICT arrangement, classify and report incidents, and hold exit plans for the providers they depend on. The European Supervisory Authorities published the first list of designated critical ICT third-party providers in November 2025, which moved the regime from guidance into supervision (EIOPA, DORA).
• The European Accessibility Act has applied since 28 June 2025. Consumer banking services, payment terminals and financial e-commerce are in scope, which covers the app, the website, the statements, the support channel and the cancellation flow (Bird & Bird). The practical route to conformance is EN 301 549 v3.2.1, which carries WCAG 2.1 level AA in full and adds requirements for hardware, documentation and non-web software (ETSI EN 301 549 v3.2.1).
• The EU anti-money-laundering rulebook applies from 10 July 2027. The single AML Regulation replaces the divergent national transpositions that firms currently map one country at a time. The Anti-Money Laundering Authority has been operating from Frankfurt since 1 July 2025 and takes over direct supervision of up to 40 cross-border groups from January 2028, with the selection made during 2027 (AMLA).
• PSD3 and the Payment Services Regulation are through negotiation. Parliament and Council reached provisional agreement in November 2025 and COREPER endorsed the texts in April 2026. Publication in the Official Journal is expected in the second half of 2026, and the substantive rules are targeted to apply around 2028 once the transposition window for the directive runs out (Norton Rose Fulbright).
• EU Digital Identity Wallets are due from member states by 24 December 2026. Banks, payment institutions and e-money institutions have to accept them as an identification and strong-authentication method roughly a year later. Reporting in August 2026 put several national wallets behind schedule, with Germany naming 2 January 2027 for its own launch (Forbes).

How do you check a studio's fintech claim?

Four questions separate a team that has shipped a regulated product from a team that has read about one. Ask them in a call, not in an RFP, and listen for specifics.

1. Whose licence does the product run on?

There are two shapes. In the agent model you distribute a licensed institution's permissions: the principal stays responsible for the regulated activity and you cannot offer anything outside its scope, which is why this route can be live in weeks. In the direct model you hold your own payment or e-money authorisation, and the calendar changes completely. Published licensing guides put processing at roughly three to six months in Lithuania and twelve to eighteen months at the UK regulator, before the product build even starts (Crassula, EMI licence guide).

A studio that cannot tell you which shape your product sits in, and what each one does to the signup flow, has not built one. The two models produce different onboarding, different data retention, different reconciliation and different failure states.

2. Is KYC a screen or a decision system?

Every vendor demo shows the happy path: a clean applicant, a sharp document photo, a green check in eleven seconds. The engineering is in the other states. A thin file with almost no verifiable history. A document that scans badly on an old phone in bad light. A name that hits a sanctions or politically-exposed-person list and needs a human decision. A rejection that has to be delivered without explaining the reason in detail.

Ask the studio to walk you through those four states and the analyst review loop that sits behind them, not the SDK integration. Onboarding conversion in a regulated product is mostly decided in the ugly states, and they are the part nobody prototypes.

3. What does the audit trail look like?

DORA turned vendor management and incident handling into documented duties with named artefacts: the register of information, contractual audit and exit rights, incident classification against reporting windows. In product terms that means every state change needs a durable event carrying an actor, a timestamp and a reason, and it means the app database is not the record of truth for money.

Adding an event log to a CRUD application after launch is a rewrite, not a sprint. Ask to see how a studio models events and ledgers on a project they have already delivered. If the answer is updated_at, you have your answer.

4. Where does accessibility live?

Since June 2025 the Accessibility Act covers the consumer-facing surface of banking services, and the parts teams forget are the statements, the terminal, the support channel and the cancellation path. Ask which conformance route the studio uses, who runs the testing, and whether contrast, focus order and target size are settled once in the design system or re-decided on every screen. We wrote about that split in accessibility-first design after the EU Accessibility Act.

What a fintech studio should not sell you

A studio is not a law firm, not a compliance consultancy and not a licence. Anyone offering regulatory sign-off bundled with the build is selling something that is not theirs to sell, and the buyer carries the consequence.

The split that holds: your counsel and your compliance lead own the interpretation of the rules, the licensed institution owns the permissions, the studio owns the product that has to satisfy both and the evidence that proves it did. Get the interpretation in writing from people qualified to give it, then hand it to the build team as constraints with acceptance criteria. That is also the cheapest way to keep the scope honest, which we covered in how to brief a software development agency.

The parts of the 2026 stack that carry the constraints

The technology choices in a regulated build are not exotic. What changes is which decisions are load-bearing.

• Identity through a hosted vendor, behind your own interface. You will change provider at least once for coverage, price or a data-residency requirement. Keep the decision logic and the applicant states in your code, not in the vendor's dashboard.
• A ledger separate from the application schema. Append-only, double entry, reconciled against the institution's statements on a schedule. Balances are derived, never stored as a mutable column.
• Row-level authorisation at the database, not only in the API. Postgres row-level security holds the tenant and role boundary even when an endpoint is wrong, and it stays fast if you write the policies for the query planner (seven patterns we use).
• Jurisdiction as configuration. Verification requirements, retention periods and disclosure text differ per country. When they are branches in the code, the second market costs as much as the first.
• A design system that owns the accessible defaults. Contrast, focus, error text and target size are decided once, then every screen inherits them.

When a generalist studio is the right call

Not every product in the sector needs this. A pre-authorisation prototype used to raise a round, a B2B analytics tool that reads bank data through a provider and never touches funds, an internal console for an institution that already has its controls: all normal software builds, and paying a regulated-build premium for them is waste.

The constraints start to bite when consumer money moves, when identity has to be proven and retained, and when a supervisor can ask for evidence after the fact. If two of those three are true, hire for the constraint. If none are, hire for the product.

Sources

• EIOPA: Digital Operational Resilience Act (DORA)
• Anti-Money Laundering Authority (AMLA)
• Norton Rose Fulbright: PSD3 and PSR, from provisional agreement to 2026 readiness
• Forbes: the December 2026 eIDAS deadline
• Bird & Bird: European Accessibility Act, focus on financial services
• ETSI EN 301 549 v3.2.1
• Crassula: Electronic Money Institution licence guide