Accountants for
fintech startups

Safeguarding is the most important accounting distinction for any fintech holding customer funds under the Payment Services Regulations 2017 or the Electronic Money Regulations 2011. Customer funds are not the company’s money and cannot appear on the company’s balance sheet as cash. Safeguarded balances sit in segregated accounts with an authorised credit institution, or in permitted investments such as secure low-risk assets, or under an insurance or comparable guarantee. The daily reconciliation between the safeguarded balances and the corresponding customer liabilities is the core control that the FCA expects to see functioning, and the annual safeguarding audit required for most authorised payment institutions and e-money institutions specifically tests that reconciliation.

The practical accounting consequence is that the chart of accounts needs a clear structural separation between safeguarded customer money and company operating cash, with customer liability accounts mirrored against the safeguarding accounts. Daily reconciliation differences need to be investigated and resolved within defined internal tolerance periods, and unexplained differences flagged to compliance. The FCA’s published thematic review work on safeguarding has consistently found that breaches trace back to reconciliation control failures rather than intentional misuse: same-day processing delays, cut-off timing mismatches between payment rails and bank statements, fee deductions taken from the wrong account, or manual intervention that bypasses the reconciliation. Accountants in our network build the safeguarding reconciliation function at authorisation and carry it through every period, rather than treating it as a compliance-only responsibility.

The capital regime that applies depends on the authorisation held. Investment firms authorised under MiFID II fall under the Investment Firms Prudential Regime (IFPR), which uses K-factors (based on activity, risk, and client exposure), fixed overheads requirement, and permanent minimum capital. Authorised payment institutions and electronic money institutions sit under the capital requirements in the Payment Services Regulations 2017 and Electronic Money Regulations 2011, typically calculated under Method B or Method C for payment institutions, with a permanent minimum capital floor. Small payment institutions and small e-money institutions have lighter capital requirements but tighter activity thresholds. Consumer credit firms sit under CONC and the threshold conditions, with their own capital framework.

The practical accounting work is calculating own funds correctly each reporting period and reconciling to the relevant FCA return. Own funds start from Common Equity Tier 1 capital (issued share capital, retained earnings, accumulated other comprehensive income), with deductions for intangible assets, deferred tax, and any other items prescribed under the applicable regime. Additional Tier 1 and Tier 2 capital may be included subject to limits. For a growing fintech raising successive rounds, the own funds calculation changes with each share issue, each period of retained profits or losses, and each material balance sheet movement, and needs updating in step with the regulatory reporting cycle rather than retrospectively at year-end.

Fintech R&D claims have faced specific and increasing HMRC scrutiny since the merged scheme took effect in 2024. HMRC has published guidance and enquiry letters indicating that routine financial software development, standard RegTech integration, typical payment rail connectivity work, and generic compliance automation do not meet the qualifying R&D bar under the merged scheme. Enquiry rates on fintech claims are materially higher than the cross-sector average, and first-time claims built around activities in the routine category are now regularly rejected.

The qualifying work that does exist on fintech products typically covers narrower ground than founders initially assume. Novel risk modelling where the existing approaches do not resolve the specific uncertainty qualifies, as does algorithmic pricing, credit scoring, or fraud detection that goes meaningfully beyond standard commercial approaches. New cryptographic, consensus, or settlement mechanisms in crypto-asset or blockchain infrastructure qualify where they address genuine scientific or technological uncertainty. Specialist compliance technology that goes beyond off-the-shelf RegTech (for example, novel approaches to regulatory reporting data reconciliation, or transaction monitoring systems that use techniques not previously deployed) can qualify. What does not qualify is standard KYC integration, routine payment rail connectivity, typical card issuance workflow, standard PSD2 strong customer authentication implementation, generic compliance rule engines, and conventional reporting pipelines.

The documentation standard for fintech claims should assume enquiry is more likely than not. Technical narratives need to identify specific scientific or technological uncertainty rather than generic complexity. Cost allocation needs clear separation between qualifying work and the routine financial software development that funds the fintech’s core business. Subcontractor arrangements and externally provided worker relationships need agreements that support the R&D credit claim methodology. A specialist fintech accountant preparing the claim should assume that HMRC will ask pointed questions and structure the claim so the answers are already documented at the point of submission.

FCA regulatory reporting runs in parallel with the statutory accounts and uses the same underlying ledger but different cuts of the data. Authorised payment institutions typically submit CCR001 (capital adequacy and financial information), FSA056 (complaints), and safeguarding-related returns. Electronic money institutions submit FIN060 and related returns. Investment firms under IFPR submit MIF001 (capital), MIF002 (concentration), MIF003 (liquidity), MIF004 (K-factors), and MIF006 (information on group structure). Consumer credit firms submit CCR001, CCR002, CCR003 or CCR004 depending on permission type, CCR005, and CCR007. Crypto-asset registered firms submit specific returns under the money laundering registration regime.

The practical accounting requirement is that each return needs to reconcile to the general ledger and the statutory accounts, with documented reconciliation workings for any differences. Differences typically arise because regulatory returns use definitions that differ from the accounting definitions (own funds is not equity, regulatory revenue is not IFRS revenue, regulatory capital deductions are not accounting deductions), and the reconciliation needs to show the mapping. FCA thematic review work and Section 166 skilled person reviews consistently find that weakest regulatory data quality sits in firms where the reporting function is disconnected from the finance function. Accountants in our network who work with fintech startups build the regulatory reporting as a view on the same ledger as the statutory accounts, with mapping rules documented and reviewed each period.

Fintech revenue models diverge sharply from the generic tech startup patterns and carry specific IFRS 15 or FRS 102 recognition questions. Interchange revenue (fintech earning a share of card scheme interchange on transactions) typically recognises at the point of transaction, as the performance obligation is the processing of each individual transaction, with any volume-based rebates or scheme fee adjustments treated as variable consideration. Foreign exchange markup revenue recognises on transaction date at the spread actually earned, with cost of goods sold equal to the wholesale FX rate applied. Float income (interest earned on customer balances held under safeguarding arrangements) recognises as interest income and is distinct from commission or fee income; the cash belongs to the customers but the interest, under permissible arrangements, often accrues to the fintech.

Subscription overlays on payment accounts (a monthly fee for a premium payment account with additional features) recognise rateably over the service period in the standard IFRS 15 pattern. Lending revenue recognises under the effective interest rate method under IFRS 9, with expected credit losses recognised immediately on origination under the three-stage model. B2B2C partnership revenue (a fintech providing white-label services to another financial institution) frequently has a mix of transaction-based and minimum commitment components that need performance obligation separation. Accountants in our network set a revenue recognition policy document at first year-end that covers every revenue stream explicitly, because mixed-model fintechs have the most internally inconsistent revenue reporting of any startup vertical.

Fintech audit requirements typically exceed the statutory audit alone. An authorised payment institution or electronic money institution holding customer funds is ordinarily required to commission an annual safeguarding audit conducted by an auditor acceptable to the FCA, performed in accordance with the FCA’s expectations, and reported with a specific form of opinion. Investment firms holding client money or custody assets under CASS rules are required to commission a CASS audit alongside the statutory audit, with a specific scope covering CASS 6 and CASS 7 requirements. Firms holding customer crypto-assets face additional audit considerations under the FCA’s crypto-asset registration regime and the developing prudential framework.

The practical consequence is that the audit engagement needs an auditor experienced in the specific fintech audit requirements. Not every audit firm is set up to conduct safeguarding or CASS audits, and switching auditor at year-end to accommodate specialist requirements is expensive and delays the regulatory filing timeline. Accountants in our network who work with fintech startups engage with the audit planning from the first accounting period, ensure the chosen statutory auditor can conduct the specialist audits or has a clear arrangement with a specialist firm, and structure the audit evidence so the three audits (statutory, safeguarding, CASS where applicable) can be conducted efficiently rather than as three separate exercises.

UK fintech exits carry an additional valuation component that does not appear in other tech verticals: the FCA authorisation itself is a valuable asset to an acquirer that does not already hold the relevant permission. Post-Brexit, the UK-only scope of UK FCA authorisations means that a non-UK acquirer seeking UK market access faces a lengthy and uncertain authorisation process if acquiring technology without the licensed entity. A UK fintech with clean FCA standing, clean regulatory reporting history, and a robust compliance and risk framework trades at an acquisition premium that reflects the licence optionality, often materially above what the revenue multiples alone would suggest.

The practical implication for accounting is that the licence value is realised only if the regulatory record is clean. Previous enforcement action, outstanding Section 166 reports, unresolved FCA thematic findings, or any suggestion of systemic control weakness in the audit files reduces the licence value at exit. The accounting function supports the licence value by maintaining clean regulatory reporting, clean audit trails on safeguarding and capital adequacy, and clean board-approved policies that map to the FCA threshold conditions. Accountants in our network treat the licence value as a live commercial consideration throughout the growth phase, not a discovery at exit negotiation, and structure the reporting and audit files with acquirer diligence in view.