Thornfield Digital Finance Ltd, a Manchester-based fintech with £22m ARR and FCA authorisation as an Account Information Service Provider (AISP), is preparing to extend into payment initiation. The board is presented with three infrastructure options: use the Open Banking Implementation Entity (OBIE) APIs directly, partner with a TPP aggregator, or apply for full PISP authorisation. The £250,000 compliance cost differential between options is real — so is the liability allocation under the Payment Services Regulations 2017.
Account Information Service Provider (AISP)
A payment service provider authorised under Regulation 18 of the PSRs 2017 to access, with explicit customer consent, payment account information held at account servicing payment service providers (ASPSPs — primarily banks). AISPs are subject to FCA registration or authorisation, professional indemnity insurance of at least £149,000, and data protection obligations under UK GDPR. Capital requirement: £50,000 if holding client funds; PII otherwise.
Payment Initiation Service Provider (PISP)
A payment service provider authorised to initiate payment transactions on behalf of a user from an account held at an ASPSP. PISPs require FCA authorisation (not merely registration), professional indemnity insurance of at least £370,000, and must comply with Strong Customer Authentication (SCA) requirements. The PISP bears strict liability under Regulation 92 of the PSRs 2017 for unauthorised transactions resulting from its services.
Variable Recurring Payments (VRPs) represent the most commercially significant extension of Open Banking in the UK. Mandated initially for sweeping (Thornfield's core use case), the FCA and PSR's 2024 roadmap requires banks to offer VRP APIs for third-party commercial payments by 2025. VRPs allow TPPs to initiate payments within pre-agreed parameters — amount cap, frequency, merchant category — without returning to the SCA authentication step for each transaction.
| Licence | FCA Requirement | Capital/PII Minimum | Liability Position | Thornfield Relevance |
|---|---|---|---|---|
| AISP registration | FCA registration | PII £149k or £50k capital | Limited — no payment initiation | Current — AISP registered |
| PISP authorisation | Full FCA authorisation | PII £370k | Strict liability PSR Reg 92 | Planned — PISP extension |
| EMI authorisation | Full FCA authorisation + PRA notify | Initial capital £350k | E-money issuer obligations | Future — embedded wallet product |
| Small EMI registration | FCA registration | No minimum capital | Transaction limits apply (€3m/month avg) | Not applicable — above threshold |
Thornfield selects the full PISP authorisation route, accepting the £370,000 PII cost in exchange for avoiding the aggregator margin of 0.12% per transaction, which would have cost £264,000 annually at current volumes. The FCA application process takes 6 months; the PISP designation also opens access to the premium VRP sandbox, enabling Thornfield to build the variable recurring payment functionality before the commercial mandate goes live. The first payment initiation product — an automated cash sweeping service for SME treasury management — launches with a £2,500 per year subscription, targeting the 40,000 UK SMEs currently using manual bank transfers for daily liquidity management.
⚠️Treating AISP registration as sufficient for payment initiation features
→ AISP and PISP are distinct authorisations with different liability regimes. Adding payment initiation to an AISP product without PISP authorisation violates the PSRs 2017 and is an FCA enforcement risk — ensure the correct authorisation before building payment features.
⚠️Assuming SCA exemptions are unconditional
→ SCA exemptions under the PSRs 2017 (trusted beneficiary, low-value, low-risk transaction analysis) are conditional on the ASPSP accepting the exemption claim. Build fallback SCA flows for all payment journeys — never assume the ASPSP will honour the exemption.
⚠️Underestimating the strict liability position of PISPs under Regulation 92
→ Unlike card schemes where liability is allocated across multiple parties, a PISP bears direct strict liability to the user for unauthorised payments it initiates. Build fraud monitoring and transaction velocity checks before go-live, not as a post-launch enhancement.