Before your application can call any PSD2 ASPSP's open banking API in production, someone in the chain needs to be an authorised Third Party Provider. Understanding when that needs to be you, when it can be your infrastructure provider, and what the registration process actually involves — including the timelines that regularly surprise founders — is the starting point for any open banking product roadmap.
What a TPP is and what authorisation covers
Under PSD2, a Third Party Provider is a Payment Service Provider authorised to access account data (AISP — Account Information Service Provider) or initiate payments (PISP — Payment Initiation Service Provider) on behalf of Payment Service Users. The authorisation is granted by a national competent authority — the FCA in the UK, the Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) in Germany, the Autorité de contrôle prudentiel et de résolution (ACPR) in France, and so on across EU member states.
The authorisation is not a software certification. It is a regulatory permission to provide specific payment services, and it comes with ongoing obligations: conduct requirements, complaint handling processes, record keeping, operational resilience requirements, and in many jurisdictions, minimum capital requirements.
AISP authorisation
An AISP is authorised to access account data — balances, transactions, account metadata — with the PSU's consent. AISP registration does not permit payment initiation. In the UK, AISP registration is a lighter-touch process than full PISP authorisation: the FCA requires registration (not full authorisation), minimum professional indemnity insurance (typically at least €50,000 for the first claim), and a complaints handling procedure. AISP registrants are listed on the FCA Register under the Payment Services Regulations 2017.
PISP authorisation
A PISP is authorised to initiate payments from a PSU's account. PISP authorisation in the UK requires full FCA authorisation (not just registration), higher capital requirements (minimum own funds of €50,000 or an alternative calculation based on the average of the previous year's payment volume), and compliance with a wider set of conduct requirements including safeguarding obligations.
In practice, many fintech products need both AIS and PIS functionality. The FCA allows a single authorisation application to cover both AISP and PISP activities.
The FCA application process: what it actually involves
The FCA's authorisation process for payment institutions is managed through the Connect system (the FCA's online regulatory portal). The application requires:
Business model and regulatory analysis
A description of your business model, the regulated activities you intend to carry out, and an analysis of how your activities fall within the definitions in the Payment Services Regulations 2017. This section requires legal analysis — a technically accurate description of your product must be mapped to the PSR's service definitions. Ambiguity here delays applications.
Programme of operations
A description of your planned payment services, target market, and geographic scope. If you intend to passport into EEA markets (note: post-Brexit passporting does not apply to the UK; UK firms need separate authorisation in each EEA state), this is where you indicate that intent.
Governance and fit and proper assessments
Key persons — directors, senior managers with responsibility for the payment services business — must undergo fit and proper assessment. This includes disclosure of criminal convictions, regulatory sanctions, insolvencies, and civil proceedings. The FCA checks against the Register and may ask for additional information. Non-UK directors require translated documentation.
Risk management framework
A description of your risk management procedures covering operational risk, fraud risk, data security, and the controls you have in place. For open banking TPPs, this specifically includes how you secure access tokens, manage consent data, and handle data breaches. The FCA expects this to be substantive — not a list of bullet points, but a description of actual implemented controls.
IT security and data protection assessment
This section is more technical than most founders expect. The FCA asks for documentation of your technical architecture, data flow maps showing where PSU data is stored and processed, access control mechanisms, encryption standards, and your incident response procedures. GDPR alignment is assumed — but explicitly documenting how your consent management and data retention practices satisfy UK GDPR obligations is expected.
Financial information and capital requirements
For PISP applicants, evidence that you meet the minimum capital requirements. For AISP registrants, evidence of professional indemnity insurance cover. Management accounts, projected financials, and ownership structure (including ultimate beneficial owners).
Typical timelines and where delays occur
The FCA's statutory assessment period for payment institution authorisation is three months from receipt of a complete application, or twelve months from receipt of an incomplete application. In practice, most applications are not complete on first submission.
The FCA will issue a "complete" or "incomplete" determination, typically within 10 business days of receipt. An incomplete determination comes with a list of information gaps. Each round of questions typically adds 4–8 weeks to the timeline. First-time applicants should budget for two to three rounds of information requests.
Applications that stall most commonly stall on:
- Regulatory analysis section: founders who have described their product technically rather than in PSR terms, creating ambiguity about which regulated activities they are seeking authorisation for
- Fit and proper assessments: incomplete disclosure by key persons, or key persons who are not yet identified at application time (applying before you have hired all senior management creates delays)
- Risk management framework: frameworks that are evidently aspirational rather than implemented — the FCA expects the controls to exist at application time, not be planned for after authorisation
- IT security documentation: absence of penetration test results, incomplete data flow maps, or infrastructure that does not meet the minimum security standard implied by the FCA's Approach Document
Total timeline from starting document preparation to receiving authorisation: plan for 9–14 months for a straightforward PISP application. AISP registration is faster — 4–6 months from complete application is achievable — because the review is less intensive than full authorisation.
The eIDAS certificate requirement (EU TPPs)
EU TPPs — and UK TPPs connecting to EU ASPSPs — must use an eIDAS QWAC (Qualified Website Authentication Certificate) or QSeal (Qualified Electronic Seal) certificate issued by a Qualified Trust Service Provider. These certificates encode your TPP status and authorisation details, and ASPSPs use them to verify your identity and permissions when you connect.
QWAC certificates are used for TLS mutual authentication (mTLS) when connecting to ASPSP APIs. QSeal certificates are used for signing JWS objects, including payment consent bodies. Both certificates are time-limited (typically 1 or 2 years) and must be renewed. Certificate renewal requires re-registration with your QTSP and updating your certificate across all ASPSP integrations — a maintenance task that is easy to miss if it is not in your calendar with a 90-day advance reminder.
UK TPPs use OBIE-issued certificates for connections to UK ASPSPs. These are separate from eIDAS certificates. A UK TPP connecting to both UK and EU banks needs to maintain certificates from both issuers.
When you do not need your own TPP registration
If you are building a fintech application that uses account data or initiates payments, but you integrate through a regulated AISP/PISP aggregator rather than directly against ASPSPs, you are not performing regulated payment services yourself — the aggregator is. Your application is a customer of the aggregator's regulated service, not a regulated entity in its own right.
This is the route that most early-stage fintech products should take for their first 12–18 months. The reasons:
- Time to market: an API key takes days to obtain; FCA authorisation takes months
- Regulatory overhead: a regulated TPP has ongoing conduct obligations that distract from product development
- Technical complexity: maintaining direct ASPSP integrations across 2,000+ institutions requires dedicated engineering resource
The case for getting your own authorisation: products that reach a scale where aggregator per-transaction fees are significant; products that require direct ASPSP relationships for commercial or technical reasons; and products where regulatory self-ownership is a competitive differentiator (some enterprise customers require their providers to be directly regulated).
BankLyra is not a bank, does not hold user deposits, and does not provide regulated financial advice. We are an FCA-authorised AISP and PISP. When fintech teams connect through BankLyra's API, they use our regulatory permissions for the data access and payment initiation activities the API performs. This covers the majority of account aggregation and PIS use cases without requiring the engineering team to hold their own authorisation — until their scale or business model makes direct authorisation the right call.
Passporting and the EU position
Post-Brexit, UK payment institution authorisation does not passport into EEA states. A UK-authorised TPP must seek separate authorisation in each EEA member state where it wants to operate, or establish an EEA-based subsidiary and apply through that entity's national competent authority.
For EU-focused products, applying through a member state with a relatively efficient competent authority process is common: Lithuania (Bank of Lithuania), the Netherlands (De Nederlandsche Bank), and Luxembourg (CSSF) have published processing timelines and clear application guidance. Once authorised in one EEA state, a firm can passport into other EEA states with shorter regulatory formality.
For most teams building European open banking products, the practical question is not "which NCA should we apply to?" but "should we apply for our own authorisation at all, or use an aggregator's permissions for now?" That question should be answered honestly against your product roadmap before spending the legal fees and engineering time that a direct authorisation application requires.
