OBIE approach and clarifications regarding adjustment period

Problem statement

On 5 February 2020, the FCA updated its website in relation application of Strong Customer Authentication. This update included an additional section providing further clarity on the use of eIDAS certificates at the end of the adjustment period, which concludes on 14 March 2020.

Following this adjustment period, TPPs must identify themselves to ASPSPs using an eIDAS certificate. ASPSPs must be able to accept an eIDAS certificate from the TPP directly. Additionally, TPPs may use an alternative identification certificate issued by an API Programme, e.g. OBIE, provided that those TPPs have registered their eIDAS certificate with that API Programme and the API programme continues to perform checks of the status of the eIDAS certificate.

OBIE has received requests on the potential impacts on the OBIE Standard and OBIE Directory as some participants are still uncertain how this will affect them after the conclusion of the adjustment period.

Recommendations

OBIE has considered the impact on the use of the OBIE Directory and OBIE Standard for participants in the OBIE ecosystem following the adjustment period. The recommendations below are intended to assist participants to ensure that they understand the relevant impacts.

Ultimately, it is up to each participant to ensure that they meet their applicable regulatory requirements and ensure they raise any concerns in this regard directly with the FCA or their internal legal teams, as appropriate.

Use of certificates for purposes of identification

Each ASPSP must be able to accept a connection from a TPP who identifies themselves via an eIDAS certificate. The EBA Opinion on the use of eIDAS certificate under PSD2 contemplates that it is the choice of the ASPSP to determine whether it wishes to support a QWAC or QSEAL for the purposes of identification. For ASPSPs implementing the OBIE Standard, it is expected that ASPSPs will be supporting only QWACs for the purposes of identification.

The OBIE Standard requires the use of MATLS for secure communication. The act of establishing a MATLS connection is an act of identification, as it requires the ASPSP and TPP to identify each other.

An ASPSP does not need to identify themselves using an eIDAS certificate, so could use any appropriate certificate to establish a MATLS connection.

ASPSPs and TPPs also may agree to allow the TPP to use OBIE issued certificates for this purpose. As contemplated in the FCA publication, ASPSPs can enable this alternative identification certificate to a TPP that has enrolled with the API programme, such as OBIE, using its eIDAS certificate to identify itself.  The API provider will then continue to check  the validity of that eIDAS certificate on behalf of the ASPSP.

Regardless, each ASPSP must also be able to accept a valid eIDAS QWAC from a TPP for every MATLS connection.

Message signing

Message signing in itself is not considered an act of identification. 

The OBIE Standard and FAPI profile make use of message signing in a number of scenarios (e.g. to facilitate non-repudiation for payment initiation). ASPSPs and TPPs can use an eIDAS QSealC, any other signing certificate, or signing keys, to sign messages. The OBIE Directory can be used by ASPSPs and TPPs to facilitate any of these methods.

Use of software statements to connect

As defined in the OBIE standard (DCR specification), an ASPSP can require a TPP to generate a software statement as part of the connection process to access their API. An ASPSP can engage a service (e.g. the OBIE Directory) to facilitate such connection; however the ASPSP must make it clear to the TPP that this is the ASPSP’s part of their connection process.

After 14 March 2020, TPPs will be required to upload a valid eIDAS certificate to the OBIE Directory in order to create any new software statements.

Further questions

Should you have any questions regarding this the FCA’s communication, we would encourage you to contact the FCA direct. 

If you have any further specific questions regarding implementation of the OBIE Standard or use of the OBIE Directory post 14 March 2020, please contact us direct via the OB Service Desk.

eIDAS (ETSI) certificates

What is the process for UK Banks to transition to eIDAS?

This is one for the ASPSPs to answer, but at a high level, ASPSPs have implemented validation for eIDAS trust chains in their gateways.  eIDAS is challenging as it would need to include root certificates from all ASPSPs. Many ASPSPs are keen to continue using an OBIE root certificate in their Trust Store so they do not have to do the above. In which case, the FCA has stated that an ASPSP may request that a TPP registers with an API programme, e.g. OBIE, using their eIDAS certificate and then use OBIE eIDAS-like certificates to register and transact with the ASPSP. However, the expectation is that ASPSPs must be able to accept eIDAS certificates of a TPP.

Will OBIE offer services to validate QSEALs at the network layer?

Currently, ASPSPs can check via the OCSP endpoint (or via CRL if OCSP is unavailable) plus the certificate is checked every 10 mins. Alternatively, ASPSPs can hit the OB Directory certificate validation endpoint. For details on how to use that endpoint see the DIR-API swagger specification linked to from Directory 2.0 Technical Overview v1.3 and Technical Directory Services.

Is a TPP allowed to include the certificate in the header?

Yes.

What are the technical possibilities for enrolling with an EU eIDAS certificate – MTLS doesn’t allow certificates not in the Trust Store. What options are provided by OBIE?

FAPI allows for the use of QSeals, so the OBIE will allow DCR using QWACs or QSeals.  ASPSPs could do the same and this is an active topic in TDA. But OBIE cannot mandate that ASPSPs do this. Also, OBIE ingests roots and issuing certificates from the national Trust Lists and makes them available to ASPSPs via a JKS file to facilitate their Trust Store set up / maintenance.

When ASPSPs authorise TPPs using eIDAS, does this occur only during registration or are there other validations as well?

ASPSPs do not authorise TPPs. NCAs authorise TPPs. eDIAS certificates identify the TPP and  will also contain their relevant PSD2 roles and authorisation number. It is ultimately for each ASPSP to determine any additional validation that needs to take place, noting that some eIDAS certificates will only contain PSD2 authorisations based on a snapshot at the time of issuing the certificate, as well as, relevant regulatory considerations.

Is there going to be an updated Security Profile which takes into account eIDAS checks?

ASPSPs are required to be compliant with FAPI. We are not aware of a need to update it in this regard, nor of any plans.

Is there any documentation on how/where exactly in the current process we should be using eIDAS certificates in the future?

Yes please refer to the Usage Guidelines and the Swagger API documentation. See Technical Directory Services for links.

If we are using certificates to authenticate with ASPSPs, do we still need to register with them?

Yes, you still need a client to onboard.

In which authorisation domains can eIDAS certificates be used?

PSD2 only. They cannot be used in the Pay,UK or Crown dependency domains.

OB ETSI like certificates

What TPP feedback is there on obtaining an eIDAS certificate?

1. Feedback from an AISP in mid 2019 – "It took 9 months. We had to fly the QTSP CEO to Portugal and hire a Portuguese speaker. We had to correct their forms. QTSPs are not ready for this."
2. Mainland EU countries are not accepting EU certificates from other EU countries.
3. Some QTSPs do not have an EU-issuing country.

Obtaining an eIDAS Certificate

Can I use a test QWAC/QSEAL with any ASPSP?

Yes, orovided thar the ASPSP has implemented eIDAS into their Test Facility and Production Interface. You can use Production eIDAS certs in the OBIE Directory Sandbox. However, you cannot use the Certificate Validation service in the OBIE Directory Sandbox to validate Test eIDAS certificates and you cannot upload these in the OBIE Directory Sandbox . 

OBIE legacy certificates

Where can I find the Open Banking root and issuing certificates?

They can be downloaded from this confluence page in the Collaboration space:   /wiki/spaces/OBT/pages/1144294132

What is the Organization for the Directory transport certificates?

The Organization for the chain are:-

• root certificate: OpenBanking
• issuing certificate: OpenBanking
• transport certificate (leaf): OpenBanking

What is the organization unit (OU) for the Directory transport certificates?

The OUs for the chain are:-

• root certificate: does not have an OU.
• issuing certificate: does not have an OU.
• transport certificate (leaf): Open Banking Directory.

What are the Common Name (CN) for the OBIE domains to perform the TLS MA handshake?

For MATLS for OBIE Directory services, the Directory presents a legacy OBIE transport certificate. 

The common names for the chain are:-

• root certificate: OpenBanking Root CA
• issuing certificate: OpenBanking Issuing CA respectively
• transport certificate (leaf): matls  

What is the Common Name (CN) for the OBIE legacy signing certificate?

The common name = signing.

In which authorisation domains can OBIE legacy certificates be used?

Pay.UK (COP) and Crown Dependencies only. They cannot be used in the PSD2 domain.

CSR validation

What CSR (certificate signing request) validation is undertaken?

This depends on the certificate type. For OB legacy transport and signing certs we check that:-

• The incoming CSR contains an RSA public key of 2048 bits.
• The Distinguished name contains the org id in OU and software statement id in CN.
• If the CSR contains a Subject Alternate Name that the requesting org is an ASPSP.

For OBWAC/OBSEAL we check that:-

• The incoming CSR contains an RSA public key of 2048 bits.
• The Distinguished name contains the ETSI organizationIdentifier in its own field, and OB org ID is in the CN.
• The QC Statement indicates that the type of cert (WAC/SEAL) is consistent with the requested type.
• The QC Statement does not claim any PSD2 roles that the organisation does not have.

Both categories will also do simple checks, e.g., all expected name components are present, not duplicated, in the right order, etc. etc​.

QTSP certificates and services

Do we have an eIDAS QTSP in the UK yet? Can you recommend a QTSP in the UK? 

There is no UK QTSP yet. We cannot recommend a QTSP.

Should we be checking the validity of certificates against a QTSP, or will revoked QTSP certificates be available within the Open Banking certificate revocation list?

There will  always be a gap in the revocation of a certificate by a QTSP and OBIE becoming aware. eIDAS certificates uploaded by participants to the OBIE are checked every 10 minutes and moved to the revoked store if revoked. As they are not OBIE CA certificates they will not appear in the OBIE CA's CRL (certificate revocation list).

JKS stores in S3

Where can we find the QTSP JKS files in Sandbox?

 QSealC

https://obdqtspkeystore.openbankingtest.org.uk/artefacts/QTSP/EU/latest/qseal/data.jks

QWAC

https://obdqtspkeystore.openbankingtest.org.uk/artefacts/QTSP/EU/latest/qwac/data.jks

Where can we find the QTSP JKS files in Production?

QSealC

https://obdqtspkeystore.openbanking.org.uk/artefacts/QTSP/EU/latest/qseal/data.jks

QWAC

https://obdqtspkeystore.openbanking.org.uk/artefacts/QTSP/EU/latest/qwac/data.jks

SCIM QTSP resource/endpoint

How do we filter/query the QTSP endpoint?

This is described in the SCIM Swagger specification. Linked to from Appendix A in the Directory 2.0 Technical Overview Draft 1.2 (about to be updated to 1.3).

Root and intermediate certificates

If a TPP submits an eIDAS certificate to an ASPSP and the ASPSP doesn’t have the QTSP root certificate in the Trust Store, what happens?

It will not work. You cannot transact.

Where can we get the endpoint for root certificates for QTSPs?

This is specified in the SCIM swagger specification in GitHub. Have a look at Directory 2.0 Technical Overview Draft 1.2 (about to be updated to 1.3), and you will see a link to GitHub in Appendix A (this includes root and intermediary certificate info).

Why can't I find a QTSP root or intermediate certificate in the SCIM QTSP resource?

If the QTSP does not publish its root or intermediate certificates on the national list, we have no way of obtaining them.  The national supervisory body that manages the national Trust List may have a policy of not publishing root certificates.

The root certificate may be a cross certificate, i.e., it might be used to sign qualified issuing certificates (intermediate certs) and non-qualified issuing certificates, e.g., SSL certificates. 

How can I find a QTSP certificate chain, root or intermediate certificate in the SCIM QTSP resource?

1) Have a look at the client certificate's Issuer name and then do a search on the X509SubjectName attribute of the OBQualifiedTrustServiceProviders SCIM resource.
2) The result of 1) should be a list of certificates, most likely intermediate certs, but just to make sure, compare Subject name and Issuer name inside each of those certs to see if they are the same.
3) If they are, you have found a root certificate.
4) If they are different, you have an intermediate certificate in which case you need to take Issuer name for each intermediate certificate and search on the X509SubjectName attribute of the OBQualifiedTrustServiceProviders SCIM resource.
5) If the certificates returned have identical Subject name and Issuer name then they are root certificates if they are not... go back to step 4).

Validation checks

Does an ASPSP do their own QTSP checks?

ASPSPs can either check with the QTSP themselves or use OBIE Directory services.

Accessing the Directory Frontend Interface (DFI)

There are no questions/issues related to this. 

Consuming OB Directory APIs and endpoints

MATLS setting up a transport connection with Directory services

There are no questions/issues related to this. 

Getting an access token

There are no questions/issues related to this. 

Payloads

Can we use X5C attributes in the payload itself?

Yes.

Software statements

Which schemes are supported in Redirect URIs?

Only https.

Signing and encryption keys

What values can I expect in the 'use' attribute for the OBIE JWKS?

We have values "enc", "sig" and "TLS" to indicate the use for encryption, signing or TLS (transport).

Software Statement Assertions (SSAs)

What eIDAS information is included in the SSA?

SSAs include the NCA ID, Org ID (enough details for the ASPSP to put together the org identifier) but does not include the NCA org identifier. OBIE is considering adding this. The org ID and the organisationIdentifier are in the eIDAS certificate  The org ID is in the SSA. ASPSPs can query the TPP endpoint using the org ID to fetch the organisationIdentifier and check whether it matches the eIDAS certificate.

How many ASPSPs trust self-signed SSA’s?

The consensus was that these are not trusted. In this scenario, ASPSPs would push TPPs to OBIE. NOTE – the SSA is the front door key to all OBIE ecosystem ASPSPs.

What is the meaning of the "organisation_competent_authority_claims" "Status" attribute?

The "status": "Active" attribute indicates that the organisation is Active within the UK Open Banking ecosystem. The SSA API endpoint returns a list of objects that represent PSD2 roles grouped per country. When one of the roles is revoked/withdrawn (not Active) they do not appear on the list returned by the SSA API.

When an organisation has the following claims on its SCIM record:-

{
    "urn:openbanking:competentauthorityclaims:1.0": {
        "Authorisations": [{
            "Psd2Role": "AISP",
            "MemberState": "GB",
            "Active": true
        }, {
            "Psd2Role": "PISP",
            "MemberState": "GB",
            "Active": true
        }, {
            "Active": true,
            "MemberState": "IE",
            "Psd2Role": "PISP"
        }, {
            "Active": true,
            "MemberState": "IE",
            "Psd2Role": "AISP"
        }]
    }
}

the SSA will have the following "authorisations"

"authorisations":  [
                {
                    "member_state": "GB",
                        "roles": [
                            "PISP",
                            "AISP"
                    ]
                },
                {
                    "member_state": "IE",
                        "roles": [
                            "PISP",
                            "AISP"
                    ]
                }
            ]

Should one of the "Authorisations" be marked as "Active": false as in

{
    "urn:openbanking:competentauthorityclaims:1.0": {
        "Authorisations": [{
            "Psd2Role": "AISP",
            "MemberState": "GB",
            "Active": true
        }, {
            "Psd2Role": "PISP",
            "MemberState": "GB",
            "Active": false
        }, {
            "Active": true,
            "MemberState": "IR",
            "Psd2Role": "PISP"
        }, {
            "Active": true,
            "MemberState": "IR",
            "Psd2Role": "AISP"
        }]
    }
}

the SSA will have the following "authorisations"

"authorisations":  [
                {
                    "member_state": "GB",
                        "roles": [
                            "AISP"
                    ]
                },
                {
                    "member_state": "IR",
                        "roles": [
                            "PISP",
                            "AISP"
                    ]
                }
            ]

ASPSP authorisation servers

What format should the file with the EISCD codes be in?

The file should have a .csv suffix.

Certificate validation service

Validation checks

For QWAC and QSEAL certs we check:

• That the certificate is signed by a recognised QTSP by validating the trust chain up to the root certificate

• The certificate is RSA (or soon a supported EC curve)
• The certificate has a QC statement indicating the right cert type, containing at least one role
• The certificate applies to the organizationIdentifier registered in our directory against the right entity
• Validity checks
  • has it expired?
  • has it been revoked?
  • has its issuer (QTSP) been revoked?

​The Service will also return the NCA data related to the organisation regardless of whether they are participants or not if the NCA data is available.

NCA authorisation data

What is the timeframe for validation of PSD2 authorisation for participants and non-participants via DCR?

Currently, manual daily checks are performed for participants’ PSD2 authorisations. OBIE is working on automated checks of participants only (release date TBC). OBIE does not check PSD2 authorisations for non-participants manually.

The Certificate Validation Service returns the NCA data related to the organisation regardless of whether they are participants or not if the NCA data is available. There is a roadmap for ingestion of NCA data here: Technical Directory - scheduled deliverables

How are the new validation services supported in the Sandbox? Are the TPPs asked which certificate types they will support?

Directory services are released to both environments, so they mirror each other. You cannot use the Certificate Validation service in the OBIE Directory Sandbox to valid test eIDAS certificates. There are plans to enable this capability.

If you consider it a risk, TPPs could upload their Production QWACs / QSeals to Sandbox Directory for use against ASPSPs’ Test Infrastructure.

OBIE does not ask TPPs which certificate types they will support through the service.

How do I validate non-OB participants?

You can use the Certificate Validation service. Or directly use the OCSP or CRL endpoints in the eIDAS certificate for validation of the certificates.

How often can ASPSPs hit the validation service? Are there any capacity constraints?

There is no limit to usage. The service is scalable, so it should be able to cope with any volume, but a caching strategy of certificate checks can be adopted.

Will OBIE offer services to validate QSEALs at the network layer?

Currently, ASPSPs can check via the OCSP endpoint (or via CRL if OCSP is unavailable), plus the certificate is checked every 10 mins. Alternatively, ASPSPs can hit the OB Directory Certificate Validation endpoint.

Dynamic Client Registration (DCR)

All the AKAs

What are all the ways that DCR is referred to?

• DCR.
• Dynamic Client Registration.
• Headless enrolment/registration.
• Automated enrolment/registration.
• Programmatic registration/onboarding/enrolment.

Does DCR with OBIE conform to the DCR spec for registering with ASPSPs?

It does, in principle. The end result is an OAuth client, but the onboarding payloads are different.

The OB DCR payload represents an organisation, the ASPSP DCR payload represents a software statement.

But, in both cases, you get an OAuth client.

QWAC based

There are no questions/issues related to this. 

QSeal based

There are no questions/issues related to this. 

Single Sign-on Service (SSO)

Dynamic registration with QWACS/ QSEALS. How does eIDAS certificate based DCR affect ASPSPs who want to use OBIE as an identity provider for SSO given that there will be no contact details for technical contacts?

Some banks use OBIE as the service provider for ID&V. OBIE undertakes full enrolment & ID&V for technical contacts. No contact details are submitted for DCR, therefore OBIE cannot perform ID&V for technical contacts via DCR. eIDAS is all that is required for PSD2 identification. If an ASPSP wants to offer Developer Portal (to avoid confusion with OB’s Dev Zone) services to a TPP, the ASPSP can send the TPP to OBIE for enrolment, before or after DCR, so that their technical contacts can undergo ID&V checks and can they use their OBIE login to access the ASPSP’s Developer Portal.

Organisational Records

How do we change our National Competent Authority (e.g. Companies House) or National Competent Authority (e.g. FCA FRN) registration number in SCIM?

Please have your Primary Business Contact (PBC) contact Open Banking via the Service Desk at ServiceDesk@openbanking.org.uk if you need to change records.

Multifactor authentication with Ping One

There are no questions/issues related to this. 

Delegated OCSP responder issue and impact on QTSPs

An issue has been raised regarding the use of the OCSP Signing EKU (Extended Key Usage) in issuing CAs. Specifically, where the use of delegated OCSP responders create potential security issues. This is due to the presence of the OCSPSigning EKU on an intermediate certificate. OBL understands that this could affect close to 300 CAs and that it has been discussed at the CA/Browser Forum. Though primarily affecting TSPs that do not provide eIDAS certificates, some QTSPs are also affected. Affected QTSPs have asked their customers to revoke and replace their affected eIDAS certificates by the 31st October 2020.

OBL has raised the issue with five key QTSPs who represent the greatest volume of eIDAS certificates uploaded to the Technical Directory. Of these, 2 have confirmed that they are affected and have taken action, two are not affected, and one has not responded.

DigiCert have posted a very helpful blog that describes the problem: Working with Delegated OCSP Responders and EKU Chaining

POST-BREXIT Certificate Outcomes FAQs

From 1 January 2021,  what type of certificates can be used by UK TPPs (including EEA TPPs operating under TPR or SRO) for the purposes of identification to ASPSPs?  

UK TPPs may use the following certificate types when interacting with UK ASPSPs

1. eIDAS certificates if they have not been revoked
2. OBWac
3. OBSeal
4. Obtransport
5. OBsigning

From 1 January 2021, are there any anticipated changes in relation to certificate use for UK and EEA ASPSPs and TPPs currently providing payment services in Gibraltar ?  

We are unaware of that the use of OBIE certificates (or alternative certificates) is permitted by the GFSC.  We anticipate that entities performing payment services in Gibraltar will continue to use eIDAS certificates.  

From 1 January 2021, are there any anticipated changes in relation to certificate use for UK ASPSPs and TPPs currently providing payment services in the EEA ?  

Provided entities have obtained the relevant permissions to provide payments services in the EEA, they can continue to use eIDAS certificates as per the SCA-RTS.

Are the certificates issued by OBIE designed to support the UK -RTS digital certificate requirements to enable TPPs to identify themselves to ASPSPs?

Yes. 

Under Article 34 of the UK RTS, in addition to eIDAS certificates, UK ASPSPs should accept “at least one other form of identification issued by an independent third party that is not unduly burdensome for payment service providers to obtain” We refer to this as an “Alternative Certificate”.

OBIE is an independent third party certificate issuer and its certificates are designed to meet the requirements for digital certificates (pursuant to UK-RTS, Article 34 (8)) in order to enable TPPs to identify themselves to ASPSPs. 

 It is up to each ASPSP to satisfy themselves that OBIE certificates meet the required attributes of the UK-RTS when choosing to accept them for TPP identification. 

Are certificates issued by OBIE subject to any terms of use?  

Yes. 

OBIE as a Certificate Authority issues OBIE Certificates in accordance with OBIE Certificate Policy and associated documentation, which can be found at http://ob.trustis.com/production/policies/). 

ASPSPs and TPPs using OBIE Certificates must ensure that they familiarise themselves with all the relevant documentation and understand relevant criteria that underpins their use.

I am a UK TPP or EEA TPP (TPPs operating under TPR or SRO). How can I obtain an OBIE certificate? 

If you have enrolled with the OBIE Directory you can generate one via the self-service user interface (Directory Frontend Interface, DFI) or programmatically via DIR-API.

I am an ASPSP operating in the UK. How can I check the validity of an OBIE certificate when identifying a TPP? 

Any OBIE issued certificates can be validated at any time by one of 4 methods:  

a) CRL endpoint on the certificate 

b) OCSP endpoint on the certificate 

c) JWKS active trust store 

d) the Certificate Validation Service (available only to ASPSPs enrolled with OBIE) 

What can ASPSPs use OBIE certificates for?

In addition to eIDAS certificates, ASPSPs can, if they choose to, use an OBIE certificate as an Alternative Certificate  for the purpose of confirming the identity of a TPP (i.e. to confirm that the entity presenting them with the OBIE certificate is the TPP to which OBIE has issued the certificate). 

What are the obligations on ASPSPs when they accept an Alternative Certificate for TPP identification purposes under UK RTS Art 34?

ASPSPs must also:

1. verify that any certificate-holding TPP is authorised or registered to perform the applicable payment services (in a way that does not present an obstacle to the provision of those services);  
2. satisfy itself that the issuer of the Alternative Certificate is suitable and has sufficient systems and controls to verify the information contained in the Alternative Certificate and 
3. make public the forms of TPP identification they accept. 

Are OBIE certificates revoked when a TPP loses their relevant regulatory authorisation?

OBIE performs regular checks on competent authority registers to ensure that TPPs participating in the Open Banking Ecosystem have the necessary regulatory permissions to do so. OBIE will revoke an OBIE certificate when a TPP has had their regulatory permissions revoked by their competent authority and this has been reflected in the competent authority register 

Can ASPSPs rely on OBIE certificates to provide confirmation of the regulatory permissions of a TPP for their relevant payment service (s)?

OBIE does not recommend this approach as a way for ASPSPs to verify that the TPP has the necessary authorisation to perform the relevant payment service(s), as OBIE Certificates are statically designed to support TPP identification only.   

Ultimately it is a decision for each ASPSP to determine the most appropriate way to perform the relevant regulatory checks in line with their obligations under the UK- RTS. 

OBIE recommends that ASPSPs confirm the regulatory status of a TPP through additional means – e.g. by consulting the register of the relevant national competent authority, through the Open Banking Directory or via another suitable alternative directory. 

Does OBIE provide any services that enable ASPSPs to verify the regulatory status of a TPP? 

Yes, OBIE provides three distinct services:

1. The OBIE Directory TPP SCIM endpoint - This API can be used by ASPSPs to check the authorisations of any UK TPP (including TPR and SRO) as well as certain EU TPPs (including passporting rights from one EU member state into any other EU member states), provided these TPPS are also enrolled on the OBIE Directory. The use of this API is subject to the OBIE Directory SLA, which is agreed between OBIE and ASPSPs enrolled onto the OBIE Directory.
2. the Certificate Validation Service - This service allows the ASPSP to submit the TPP’s certificate and returns confirmation of the validity of the certificate and the TPP’s authorisations regardless of whether that TPP is enrolled on the OBIE Directory or not. 
3. NCA API - This API can be queried to get authorisation data for any TPP in the UK or EEA regardless of whether that TPP is enrolled on the OBIE Directory or not.