Implement OB Security Profile Implementer's Draft v1.1.2
COMPLETE
Implement FAPI Profile Implementers Draft 2
Phased migration to FAPI 2 by Q1 2020
Update 26/06 - TPPs are reminded that notifications were sent in December 2019 / March 2020. Barclays will likely enforce FAPI rules from 31st July 2020. There are still some TPPs that have not migrated and so we request that this is completed as soon as possible. If there are issues / blockers then please reach out to the team
COMPLETE other than use of PRIVATE KEY JWT
Update 30/07 - Please ensure you review your entire suite of apps that are currently on boarded with Barclays and make the change from client secret authentication to private_key_jwt, as soon as possible if this has not been completed already. We will be removing capability for non-conformant apps within the near future, a date is not yet confirmed for this, but our expectation is you’ll have completed your changes within the next 4 weeks.
Implement CIBA Profile Implementers Draft 1
TBC
Plans to be confirmed
Implement Dynamic Client Registration v1.1
Not Delivered
Implement Dynamic Client Registration v3.1
TBC
Plans to be confirmed
Decommission Read/Write API Specification v1.x/2.x
Plans to decommission AIS v1 / v2 in May - however this has been delayed due to COVID
Decommission OB Security Profile Implementer's Draft v1.x
TBC - No Plans
...
Panel
borderStyle
dashed
title
Method of Identification
Page Properties
id
ID-Production
Commence support for eIDAS QWAC certificates
From Q1 2020
Commence support for eIDAS QSEAL certificates
From Q1 2020
Commence support for OBIE QWAC-like certificates
From 14th September
Commence support for OBIE QSEAL-like certificates
From 14th September
Cease support for OBIE non eIDAS-like certificates for transport
No Plans
Cease support for OBIE non eIDAS-like certificates for signing
No Plans
Support for MTLS token endpoint authentication
No Plans
Support for private_key_jwt token endpoint authentication
June 2019
Cease support for client id and client secret token endpoint authentication
July 2019
Update 2630/06 - Once Barclays enforce FAPI rules, likely from 31st July 2020, you must use private_key_jwt instead of client secret07 - Please ensure you review your entire suite of apps that are currently on boarded with Barclays and make the change from client secret authentication to private_key_jwt, as soon as possible if this has not been completed already. We will be removing capability for non-conformant apps within the near future, a date is not yet confirmed for this, but our expectation is you’ll have completed your changes within the next 4 weeks.
Panel
borderStyle
dashed
title
Implementation
Page Properties
id
TC-IMP
Directory?
Open Banking
Location of Well Known Endpoints?
OB Technical Directory
API Standard Implemented?
Open Banking
Name of Account Holder Implementation Date?
Completed - September 2019
Date of Current eIDAS Implementation?
September 2019
Current Certificates used for Identification?
OB Transport + ClientID + Secret OBWAC
Current Certificates used for Transport?
OB Transport / OBWAC
Current Certificates used for Signing?
OB Signing / OBSEAL
Date of Future eIDAS Implementation?
March 2020
As of the 14th of March, TPP’s will be able to onboard via two routes with Barclays inclusive of, uploading QWAC and QSEAL certificates directly to the OB directory, and will be required to use existing manual / BDN APP to onboarding using the SSA generated on OB directory. The second route is to directly onboard to Barclays by invoking the Barclays Dynamic Client Registration APIs using eIDAS certificates. Please refer to Barclays Developer Network for further information on Barclays implementation of DCR.TPPs with eIDAS certificates who have registered with the Open Banking Implementation Entity and are onboarding with OBWAC/OBSEAL or QWAC/QSEAL certificates, can continue to use manual onboarding via the developer portal. Using this method, the TPP logs onto the developer portal with their Open Banking credentials and can create an application to onboard. This will ensure the TPP can continue to use their existing application on the developer portal that any associated live customer consents will have been created under. If a TPP has an eIDAS certificate, and wants to onboard directly with us, this is possible via our Dynamic Client Registration.
Future Certificates used for Identification?
OBWAC / QWAC
Future Certificates used for Transport?
OBWAC / QWAC
Future Certificates used for Signing?
OBSEAL / QSEAL
Major Milestones
v3.1 –
Delivered Items:
AIS / PIS / COF v3.1.
1 –
Implementation of all AIS / PIS / CoF end points COMPLETE
AIS / PIS / CoF journeys supported for following payment account types:
Current Accounts (Personal and Business)
Current Accounts (Corporate)
Savings Accounts (Personal and Business)
Personal Credit Cards (Barclaycard)
Corporate Credit Cards
Currency Accounts (Personal and Business)
Currency Accounts (Corporate)
Pingit E-Wallets
Please see Note for Important Information *
Future Delivery Dates
4 since
P2 2WR / Event Notification
API – NOW LIVE
API since
P7 Refunds (Payments v3.1.4)
–
since
Future Delivery Items:
P9 - Payment Status – Phased changes to Payment Statuses from
30 Jun
- in some instances, TPPs will need to call the Payment Status endpoint to ensure they have the latest view
Waiver 007 (Payment
Signing, v3.1.4) –
and Event Notification Signing) from
-
No changes are needed before this date.
Once this is completed, it’s important to note validation will be completed against all
v3 payment requests, to avoid payment failures you’ll need to make your changes from our implementation date
Payment requests against v3.1.4 or higher and all /POST event-subscriptions requests. To avoid failures you must not include the b64 claim in the header.
Your requests will fail if they include the b64 claim after this date.
Message Signing functionality for payment requests will also be available in our TPP Sandbox environment from
Relevant AIS / PIS / CoF journeys supported for following payment account types:
Note that Account Holder Name for PCA / BCA / Pingit customers is available through PARTIES end point and through ACCOUNTS end point for Barclaycard UK, Barclaycard Commercial Payment and Barclays Corporate customers
IMPORTANT INFORMATION
In order to complete Open Banking journeys, you will need to establish the Identity Provider (IDP) authentication method for your implementation.
An IDP is a system to authenticate and gain permission from an end user - such as a customer, to access their resources e.g. their account data. For Open Banking, this is used to authenticate the customer providing the consent to the Third Party.
Examples of an IDP in Open Banking includes Barclays app (Personal and Business Banking customers) and iPortal (Barclays Corporate clients), but we have a number of methods depending on the customer type and digital channel that they use. This needs to be considered in your development.
The latest OpenID configuration (OIDC) URLs available are shown below
TPPs are reminded that latest URLS MUST be used and where a legacy URL is still being used then TPP MUST migrate to URLs below
Note - some Business Banking clients will require the Corporate Banking IDP as they use Corporate Banking services to fulfil their business requirements and some Corporate clients will require the Business Banking IDP as they use Business Banking services to fulfil their business requirements
Brand(s)
Security Profile?
Currently Open Banking Security Profile
Phased migration to FAPI 2 by Q1 2020
Update 26/06 - TPPs are reminded that notifications were sent in December 2019 / March 2020. Barclays will likely enforce FAPI rules from 31st July 2020. There are still some TPPs that have not migrated and so we request that this is completed as soon as possible. If there are issues / blockers then please reach out to the team.
FAPI 2 rules enforced from 31st July other than use of PRIVATE KEY JWT
Update 30/07 - Please ensure you review your entire suite of apps that are currently on boarded with Barclays and make the change from client secret authentication to private_key_jwt, as soon as possible if this has not been completed already. We will be removing capability for non-conformant apps within the near future, a date is not yet confirmed for this, but our expectation is you’ll have completed your changes within the next 4 weeks.
Security Profile Certification?
Yes
CIBA
TBC - No plans
Using Open Banking as your eIDAS Trust Framework?
TBC
Are you caching the Directory?
Transaction IDs
March 2019 - Option 3 Supported
...
Panel
borderStyle
dashed
title
PSD2
Page Properties
id
TC-PSD2
Dispute Management System?
Yes
FCA Adjustment Period - Maintaining Screen Scraping?
After Waiver 7 Expiry (16/06/20) option supported: Option 1 - The parameter b64 being set to FALSE OR Option 2 - The b64 claim not being in the header
Option 2 under
Waiver 007 (Payment
Signing, v3.1.4) implementation –
and Event Notification Signing) from
No changes are needed before this date.
Once this is completed, it’s important to note validation will be completed against all
v3 payment requests, to avoid payment failures you’ll need to make your changes from our implementation date
Payment requests against v3.1.4 or higher and all /POST event-subscriptions requests. To avoid failures you must not include the b64 claim in the header.
Your requests will fail if they include the b64 claim after this date.
Message Signing functionality for payment requests will also be available in our TPP Sandbox environment from