A licensed payment institution is not a standard business. Its balance sheet coexists with client funds it does not own. Its quarterly reporting answers to a national competent authority (NCA) — the ACPR in France, the FCA in the UK, BaFin in Germany — not just to an external auditor. And since January 2025, DORA has imposed a digital operational resilience framework that few fintech CTOs had anticipated.
As a result, when a CFO or CTO at a regulated fintech evaluates an ERP or financial information system, they cannot apply the same criteria as an industrial SME. Requirements around segregation accounting, regulatory traceability, and fund auditability radically transform the selection criteria.
This guide is written for the leadership teams of payment institutions (PIs), electronic money institutions (EMIs), crowdfunding intermediaries, and licensed investment advisors regulated under PSD2/PSR — entities that must reconcile rigorous accounting, demanding prudential obligations, and an information systems architecture capable of keeping pace as transaction volumes grow.
The Information System of a Regulated Fintech: A Special Case
What Sets a PI/EMI Apart from an Ordinary Business
An industrial company or professional services firm uses its ERP to manage procurement, sales, production, and accounting. Funds flow between supplier and customer accounts, and the balance sheet reflects the entity’s economic reality.
A payment institution works differently. It receives client funds, holds them temporarily, routes them to beneficiaries, and collects a commission on that flow. These client funds do not belong to the institution — they constitute a liability toward end users and must be kept separate from the institution’s own assets. This mandatory separation, called safeguarding, is the pivot of every PI’s accounting and IS architecture.
Without an IS designed to reflect this duality — the institution’s own funds on one side, safeguarded client funds on the other — day-to-day compliance becomes impossible to maintain. A generic ERP configured in a hurry simply does not cut it.
Which Entities Does This Guide Cover
Across the EU and EEA, the entities subject to these constraints span several regulatory statuses:
- Payment institutions (PIs) — licensed to execute credit transfers, direct debits, card payments, payment initiation services, or account information services under PSD2/PSR
- Electronic money institutions (EMIs) — issue electronic money (digital wallets, prepaid cards)
- Specialised credit institutions — finance companies licensed for specific lending operations
- Crowdfunding intermediaries and investment advisors — subject to lighter registration or licensing regimes but with analogous compliance obligations
All supervised entities are listed in public registries: the EBA Register covers the EU-wide view; national registries such as France’s REGAFI (relaunched as a unified banking and insurance portal in July 2026) provide country-level detail. These entities fall under the supervision of their national competent authority — the ACPR in France, the FCA in the UK, BaFin in Germany, De Nederlandsche Bank in the Netherlands — with cross-border oversight coordinated by the EBA.
The 4 Regulatory Constraints That Shape ERP Selection
Safeguarding of Client Funds
Safeguarding is the requirement that most radically distinguishes a payment institution’s IS from that of an ordinary business. The EU Payment Services Directive (implemented as PSR 2026 in France via Article L. 522-17 of the Code monétaire et financier, and as the Payment Services Regulations in the UK) requires that funds received from clients remain separate from the institution’s own assets.
Concretely, by the end of the next business day following receipt, the corresponding amount must be held in an account opened with an authorised credit institution or invested in secure liquid assets, clearly identified as a safeguarding account in the account agreement. It cannot be used to fund the PI’s operating expenses.
For the IS, this means:
- A chart of accounts capable of distinguishing at all times between the institution’s own funds and safeguarded client funds
- Daily reconciliation between the balance of the safeguarding account(s) and the total outstanding liabilities to clients (which the ERP must calculate automatically)
- Audit trails that allow every fund movement to be reconstructed in the event of an NCA inspection or insolvency
NCAs verify the correspondence between safeguarded amounts and funds actually owed to clients through periodic reviews. A persistent discrepancy can trigger a formal notice. Tracking virtual IBANs (one IBAN per client or wallet) has become a widely recommended best practice, as it enables automated line-by-line reconciliation.
Prudential Reporting: Own Funds, Ratios, Annual Report
Beyond day-to-day accounting, NCAs require regular prudential reporting. For a PI, this reporting covers:
- Regulatory own funds, which must exceed the higher of the minimum initial capital and the capital calculated under one of three methods (Method A, B, or C) depending on the type of payment services provided
- The own-funds coverage ratio relative to the volume of payment transactions processed (TPV — total payment volume)
- The annual internal control report submitted to the NCA
The ERP or accounting system must be able to calculate and export these indicators in the required formats. Most PIs rely on a standard accounting module augmented by specific dashboards developed in-house or by their implementation partner. No mid-market ERP currently covers this reporting natively without dedicated configuration.
AML/CFT and Sanctions: KYC/KYB Connected to the ERP
Anti-money laundering and counter-terrorist financing (AML/CFT) obligations require PIs and EMIs to verify the identity of clients (KYC for individuals, KYB for businesses) and monitor transactions. These obligations apply from onboarding and throughout the client lifecycle.
The fintech’s IS must integrate or connect to a KYC/KYB engine (Sumsub, Ondato, ComplyCube, or an in-house build), and the ERP must be able to block or suspend payment flows when a compliance alert is triggered. Records of compliance decisions must be logged and archived.
NCAs also expect a formalised AML/CFT risk mapping and an asset-freezing mechanism compliant with EU consolidated sanctions lists (OFAC and EU Consolidated List). The ERP or financial middleware must screen each counterparty against these lists in real time.
DORA Compliance: Digital Operational Resilience Since January 2025
Regulation DORA (EU 2022/2554) has applied since 17 January 2025 to PIs and EMIs, on the same basis as banks and insurance companies. It imposes an ICT risk management framework covering four main obligations:
- Mapping of critical ICT systems — the accounting ERP, internal ledger, banking connectors, and payment interfaces must be documented as critical assets
- Business continuity and recovery plan — formalised RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for each system
- Resilience testing — significant entities (high transaction volumes) must conduct TLPT (Threat-Led Penetration Testing) every three years
- Third-party risk management — contracts with ERP vendors and cloud hosts revised to include DORA clauses
Smaller fintechs benefit from DORA’s proportionality principle, but the obligation to document and test IS resilience applies to all entities, with no full exemption threshold.
IS Architecture for a Fintech in 2026
Core Banking vs. Standard ERP: Understanding the Distinction
The IS question for a regulated fintech pits two logics against each other.
A standard ERP (Odoo, NetSuite, Sage Intacct, SAP) manages procurement, sales, general and management accounting, payroll, and fixed assets. It addresses the fintech’s internal financial needs well — billing clients, paying suppliers, producing financial statements, consolidating entities.
A core banking or payment ledger (Mambu, Thought Machine, Railsr, Module Finance) manages user accounts, payment flows, real-time balances, multi-currency wallets, and high-frequency reconciliation. This is the layer that carries safeguarded funds and payment transactions.
These two layers are not mutually exclusive — most mid-size PIs run both: a core banking or internal ledger for payment operations, an ERP for back-office finance and general accounting. The challenge is integration between the two.
Common Stacks in European Fintechs
For a fintech with fewer than 50 employees and below €5 million in monthly processed volume, the most common stack is lightweight:
- Odoo 17/18 for general accounting, B2B invoicing, supplier management, and expense reports
- Stripe or a third-party PSP for inbound/outbound payment flows, with an API feeding Odoo via connectors
- Xero or Pennylane for very small fintechs or those in a pre-licence phase, before volumes justify a full ERP
This stack has significant limitations for a licensed entity: Odoo does not natively handle safeguarding or NCA prudential reporting. Bespoke modules or complementary tools must be built, generating meaningful technical debt if not planned from the outset.
For fintechs that have passed Series A (€10–100 million in monthly volume):
- Oracle NetSuite Financial Services or Sage Intacct for multi-entity accounting, bank reconciliation, and investor financial reports. Oracle NetSuite natively covers revenue recognition (ASC 606/IFRS 15) and multi-currency consolidations, essential for internationally structured fintechs.
- A separate payment ledger (Mambu, Thought Machine, or an in-house build on Postgres/Redis) for user accounts and real-time reconciliation
When Is a Dedicated Core Banking System Necessary?
A dedicated core banking system becomes necessary when three signals appear simultaneously:
- Transaction volume exceeds 100,000 operations per day
- End-of-day reconciliation can no longer be done manually or via a spreadsheet export
- The PI operates in multiple countries with distinct safeguarding requirements (separate safeguarding accounts per jurisdiction)
Below these thresholds, a well-configured ERP with API connectors to the PSP is sufficient for the vast majority of licensed fintechs. Investing in a core banking platform like Mambu entails significant licensing and integration costs that are only justified beyond a certain volume.
Managing Safeguarded Funds: The Critical IS Building Block
Accounting Principles for Fund Segregation
Accounting-wise, safeguarded funds do not appear on the fintech’s balance sheet as available assets. They are recorded in a third-party account (liability to clients) on the liabilities side, with their counterpart asset being the balance of the safeguarding account held at the partner bank.
The bookkeeping pattern is simple, but its automation is complex at scale. Each fund receipt generates a credit entry in the client account (liability) and a debit entry in the safeguarding account (asset). Each outgoing payment reverses the pattern. The daily close must verify that the asset balance of the safeguarding account always equals or exceeds the sum of client credit balances.
The ERP must produce this safeguarding statement daily, automatically, and archive it for NCA reviews.
What the ERP Must Report Daily
The finance team at a PI needs to monitor four indicators continuously:
- Total safeguarded balance — total client funds held, by currency and bank account
- Per-client or per-wallet breakdown — ability to decompose the aggregate into individual balances to reconstruct liabilities in the event of default
- Coverage ratio — safeguarded funds / client liabilities ratio, ideally close to 100% with a safety margin
- Movement log — timestamped history of every inflow and outflow, with counterparty identification and reason
These data points must be exportable in standardised formats for annual audits and NCA reviews. The absence of this automated reporting is the primary gap in generic ERPs that have not been configured for this sector.
The Audit and Fundraising Cycle: Preparing Your IS for Investors
Investor KPIs in the ERP
A regulated fintech in growth mode regularly goes through fundraising cycles. Investors (VCs, debt funds, family offices) request, during financial due diligence, metrics that must come directly out of the ERP or CRM:
- MRR and ARR — monthly and annual recurring revenue
- NRR (Net Revenue Retention) — revenue retention rate excluding new clients
- CAC (Customer Acquisition Cost) and LTV (Lifetime Value) by segment
- Gross and net churn by cohort
- TPV (Total Payment Volume) processed per month and per quarter
These metrics must be calculable automatically from the IS, without manual reconstruction in a spreadsheet. An ERP configured to produce them in a few clicks significantly simplifies the data room process and accelerates deal closing.
IS Auditability for Investors and NCAs
A Series A/B data room and an NCA licence renewal dossier share a common requirement: full traceability of transactions and financial decisions.
An auditable IS for a regulated fintech must meet three criteria:
- Immutable audit trail — every transaction, every account modification, every payment approval must be recorded with a timestamp and the identifier of the user or automated process
- Standardised exports — transactions must be exportable in structured formats (CSV, XML, JSON) compatible with auditors’ analysis tools
- Retention for a minimum of five years — in line with legal obligations under the Payment Services Directive and the AML/CFT policy
Modern cloud ERPs (NetSuite, Sage Intacct) integrate these features natively. Open-source solutions (Odoo) offer them through third-party modules or bespoke developments that must be validated before going live.
Practical Recommendations for Fintechs with 5 to 100 Employees
Four IS decisions are most structurally important to make early:
1. Separate the operational payment layer from the accounting layer from day one. Do not try to have client wallets managed by a standard ERP module — it is a dead end. Use a PSP or ledger for transactions and reserve the ERP for general accounting and reporting.
2. Model the chart of accounts for safeguarding before any ERP implementation. The chart must distinguish safeguarding accounts (asset) from the fintech’s own accounts, and enable automatic daily reconciliation.
3. Integrate DORA requirements into the ERP specification. Contractual clauses with the ERP vendor, documented RTO/RPO, and the resilience test plan are DORA deliverables, not optional extras. ERP integrators specialised in financial services know these requirements — generalists do not anticipate them.
4. Prepare the IS for investors from Series A onwards. SaaS/fintech metrics (MRR, NRR, churn) must come out of the ERP in a few clicks — not from a reconstructed spreadsheet. A poorly configured ERP can slow a fundraising cycle by several weeks.
To explore adjacent topics, see our guide to DORA and ERP for the financial sector, our analysis of ERP and open banking PSD2, and our guide to ERP for insurance and Solvency II.
