ASPSP rate limits API requests for individual or groups of TPPs (e.g. to x requests per second) due to one or more of the following limitations:

• fixed capacity in API layer, and/or
• fixed capacity in connection to/from core systems.

More likely to be an issue for AIS use cases where the AISP requests large batches of transaction data 4 times every day for a large number of PSUs. If this happens, the TPP may not be able to update their systems, and may thus not be able to meet their SLAs for one or more of their PSUs.

PIS use cases are more likely to have at most a similar traffic profile to existing direct online payments, where PSU is present and authenticating each payment. 

1. ASPSPs must ensure capacity supports at least the same performance as their best performing PSU interface. 
2. But this may not be enough, so ASPSPs should also consider:
   1. using/migrating API infra to auto-scaling cloud environments, and
   2. implementing a cloud data lake to provide highly available read access.
3. Where an ASPSP does have a hard rate limit in place, the following details on the rate limit should be provided:
   1. the parameters on which the rate limit is calculated (e.g. by TPP & by ASPSP brand & by API Version), and
   2. the rate limit (e.g. 150 Transactions Per Second).
4. ASPSPs must stress test their APIs to ensure they perform well under load and that this load is based on a realistic prediction of future demand.
5. TPPs should work with ASPSPs to help model future demand volumes.
6. ASPSPS should only rate limit responses for a valid business reason (e.g. to protect against DDoS attacks). 
7. AISPs should limit requests for recent transactions, and not make requests every day for the last 90 days' transactions for each PSU.
8. AISPs may reduce and/or spread out bulk requests over the day.

At least one ASPSP is doing this currently.

Several ASPSPS are currently using cloud based API infra and several are planning to implement cloud data lakes.

ASPSP's API is not be available at any point of time due to either:

• planned downtime, e.g. to implement a fix or update, and/or
• unplanned downtime, e.g. where there has been an unplanned outage in one or more components.

It is important to note that downtime of the API may still occur if the API platform itself is available, but one or more downstream systems is not available or working correctly.

Lack of availability of an API, will effect a TPPs service and could cause detriment to the end PSU.

This is particularly critical for PIS services, as PSUs cannot.

If the TPP is aware in advance, they can minimise this detriment by adapting their platform and potentially offering alternative services to the PSU.

If this is unplanned or planned but the TPP is not aware, then the TPP will not be able to take steps to reduce this detriment.

1. ASPSPs must ensure at least the same availability as their best performing PSU interface.
2. This may not be enough for some (especially PISP) use cases, so ASPSPs should consider:
   1. planned downtime during non core hours,
   2. communicating to all TPPs (e.g. via OBIE) all planned downtime,
   3. real-time notifications to all TPPs (e.g. via OBIE) of all outages and restoration of service, and
   4. taking further steps towards 100% availability (e.g. introducing change via blue-green deployments).
3. TPPs should consider consumption of ASPSP communications and notifications and adapt their platforms accordingly where possible.
4. OBIE should (use tools to) better measure the availability of the ASPSPs' APIs. This will improve the notifications and TPP support.

Latest CMA9 availability was an average of 97% in May 2019, with a range of 90-100%.

See https://www.openbanking.org.uk/providers/account-providers/api-performance/.

OBIE expects this level to improve by Sep 2019.

ASPSP's API takes a long time to respond to requests either:

• temporarily at periods of high traffic/load, or
• at all times.

Less likely to be an issue for AIS use cases, as APIs will almost always be faster than screen scraping.

PIS use cases require fast response times so the PISP can notify the PSU in real time. However, since most PIS payloads are small, this is also less likely to be an issue.

Some CBPII use cases require a confirmation of funds in under 500ms.

1. ASPSPs must ensure at least the same performance as their best performing PSU interface, although in practice APIs and websites cannot easily be compared.
2. ASPSPs must stress test their APIs to ensure they perform well under load and that this load is based on a realistic prediction of future demand.
3. ASPSPs should consider implementing technology (e.g. auto scaling cloud infrastructure) which delivers significant speed enhancements and can better cater for peaks in traffic. 
4. ASPSPs should especially focus on the CBPII funds check API.
5. OBIE should (use tools and work with TPPs to) better measure response time of the ASPSPs' APIs.

Latest CMA9 stats are showing an average response time of 900ms in May 2019, with a range of 500-1000ms.

See https://www.openbanking.org.uk/providers/account-providers/api-performance/.

There is no indication this is likely to change significantly by Sep 2019.

API responds to valid API requests with high error rates either:

• consistently due to a persistent issue (e.g. a defect), or
• intermittently (e.g. due to infrastructure reaching a performance threshold).

This should not be considered an issue where the error message is the correct response, i.e. due to an incorrectly formatted TPP request.

1. ASPSPs must ensure that errors messages are attributable to  errors caused by the ASPSP when responding to valid TPP requests. 
2. ASPSPs using the OBIE Standard must ensure they respond with the correct error messages for each scenario.

Latest CMA9 stats are showing an error rate of 2.8% May 2019.

See https://www.openbanking.org.uk/providers/account-providers/api-performance/.

There is no indication this is likely to change significantly by Sep 2019.

ASPSP does not respond to TPP issues in a timely manner (e.g. taking several days or even weeks), due to lack of effective service desk offering for TPPs.   

Likely to delay TPPs migrating PSUs and/or bringing new services to market, and hence delay benefits for the PSUs.

1. ASPSPs must offer a level of support including problem resolution to TPPs, which is as stringent as for their direct PSU interface.
2. ASPSPs should employ dedicated L2/L3 support staff who can effectively manage and resolve TPP issues.
3. ASPSPs should also follow OBIE's OGs in this regard.
4. OBIE should (continue to) track and facilitate resolution via Service Desk and TWG.

Several TPPs have reported lengthy delays in ASPSP response times to issues raised.

This is being tracked at TWG, and OBIE expects the situation to improve by Sep 2019.

ASPSP publishes an API which does not (fully) conform to the OBIE standard due to one or more of the following reasons:

• lack of vendor support for the required element,
• defect introduced in error, and/or
• deliberate choice to diverge from the standard.

This lack of conformance can equally apply to the Security Profile, API Specifications (inc. DCR), CEG or OGs.

Will create difficulties for TPPs to integrate with APIs and delay their ability to launch services to PSUs.

Even more of an issue if these deviations are not documented and/or large deviations from the standard.

1. ASPSPs must make documentation available to TPPs on their website/developer portal.
2. ASPSPs should follow the standard correctly and without deviation.
3. Where the ASPSP does deviate, this should be for a valid deviation and must be noted in the relevant documentation.
4. ASPSPs should use the OBIE and/or OIDF conformance tools/checklists to fully test their API implementation.
5. ASPSPs should also apply for certification to OBIE and/or OIDF to attest and demonstrate conformance. 
6. ASPSPs should use the OBIE service as part of this to publish discovery file(s) for their APIs.
7. TPPs should 'subscribe to' these discovery files.

Several ASPSPs have certificated to the OBIE Security Profile, not the Functional or CEG certification. These are requirements for CMA9 and expected to be completed before Sep 2019.

See latest status Conformance Certification Service.

ASPSPs do not implement APIs which work the same as other ASPSPs, because either:

• they have not followed any standard,
• they have each followed different standards, or
• they have followed a standard but not implemented it correctly.

With c6000 ASPSPs across the EU and c25,000 globally, there will likely be fragmentation for TPPs entering the market. 

This in turn could limit the ability of TPPs to offer services which benefit PSUs.

In addition to the above actions (for #6):

1. OBIE should work together with OIDF to support and champion the global adoption of a single best in class security layer (i.e. their FAPI and CIBA profiles).
2. OBIE should continue to work with other EU and global market initiatives to understand differences and close any gaps between the functional APIs post Sep 2019.

Several TPPs (including the large tech giants) have voiced their concern.

However there are now c100 TSPs in the OBIE ecosystem, and many of these offer services specifically to solve this problem.

OBIE has been working with other market initiatives and standards bodies to understand and address differences where possible.

ASPSP introduces a change to an API at any time which causes a lack of connection or failure in TPP service due to either:

• defect introduced in error,
• deliberate change to fix previous defect(s), or
• deliberate change to introduce new functionality.

This is most likely to apply to either the Security Profile or API Specifications.

In addition to the above actions (for #6):

1. ASPSPs must give at least three month's notice of any breaking changes.
2. ASPSPs should follow OBIE OGs in regards to parallel running, deprecation and notification of change. 
3. TPPs should 'subscribe to' any notifications.
4. TPPs should update their systems in a timely manner in line with ASPSPs changes.

Many ASPSPs still introducing breaking changes to fix conformance issues and meet their deadlines for Sep 2019.

OBIE expects there to be more stability from Sep 2019 onwards.

ASPSP makes a change in their system which results in losing the record of account-access-consent for one or more PSUs, where the PSU has NOT revoked consent at the TPP NOR access at the ASPSP.

This could be for one or more of the following reasons:

• incorrect implementation of 90 day re-auth (i.e. deleting record and/or access token after 90 days), and/or
• losing records when upgrading/changing systems or certificates.

1. ASPSP must not deny access to a TPP using a valid access token without a valid reason.
2. ASPSP must not lose, delete or otherwise invalidate access tokens (or their system of record to check these tokens) unless instructed by the TPP or PSU or for valid and objective reasons (e.g. suspicion of fraud).
3. ASPSP must protect and maintain the ability to validate these access tokens, regardless of any changes the ASPSP makes to its systems.
4. The access token intent must be forward compatible, as specified in API Specs and OGs.

To date, at least one ASPSP has incorrectly implemented 90 day re-auth.

Over the last 6 months two have made changes resulting in lost/invalidated access tokens.

API appears to be working correctly as per specification, but some data is either:

• missing (e.g. gaps in transaction records),
• incorrectly formatted (e.g. truncated), or
• otherwise incorrect (e.g. transposed or duplicated, potentially across more than one PSU account).

TPP may present an inaccurate analysis to its PSU based on the inccorect information provided, which could have a negative impact on the customer and the service offering provided.

Will be difficult for TPPs and ASPSPs to identify if this is happening, which could result in delays to resolution. 

1. ASPSP must ensure TPPs only access information for which PSU has given explicit consent to its AISP as per the data clusters submitted by the AISP.
2. ASPSP must ensure all information supplied via APIs is accurate and complete to match existing PSU interface.
3. ASPSPs and TPPs should use OBIE DMS to help speed up resolution of issues.

ASPSPs have interpreted the OBIE Standard in different ways due to:

• ambiguity (which may be due to optionality in the regulatory requirements),
• conflicting statements (e.g. between API Specs and CEG), or
• lack of explanation and clear examples.

ASPSPs likely to implement APIs which work differently, which could cause limit/slow take-up by TPPs and, in turn, delay services for PSUs.

Potentially this could introduce breaking changes in the future which may disrupt services for PSUs.

1. ASPSPs and TPPs should report any such issues to OBIE as soon as they are noticed via the OBIE Service Desk.
2. OBIE must keep a log of all 'known issues' against each published version of the standard.
3. OBIE must continue to address/remediate  these issues in future versions of the standard.
4. As an interim (e.g. between versions) OBIE should continue to issue guidance notes in the event of any ambiguity.

See Known Specification Issues

This is being continually tracked, and each subsequent version of the Standard is more robust.

ASPSPs that currently accept OB certs may decide to stop supporting them and require TPPs to switch over to use eIDAS certs for:

• TLS (e.g. QWAC), and/or
• Message signing (e.g. QSealC).

If an ASPSP requires TPP to switch from OB to eIDAS certs, this is a breaking change, as all previous access tokens will be invalidated.

PSUs will be required to go through full authentication journey, including account selection. As above, this will cause drop off in usage of TPP services and potential detriment to PSUs.

1. ASPSPs and TPPs must comply with RTS requirements and EBA/NCA guidelines regarding use of certificates.
2. ASPSPs must give at least three month's notice of any breaking changes.
3. ASPSPs should follow OBIE OGs in regards to parallel running, deprecation and notification of change. 

Currently all CMA9 and most other ASPSPs in OBIE ecosystem support OB certs. All are planning to also support eIDAS certs. 

It is not currently known how many ASPSPs will require TPPs to only use eIDAS certs.

Any regulated party's NCA authorisation number may change due to:

• change in regulatory status, or
• change in company ownership/structure.

If any party's NCA number changes, then any of their eIDAS certificate(s) would no longer be valid and would need to be revoked.

This is likely to have the same effect as above, and would result in PSU's being forced to go through a full authentication journey.

1. Both ASPSPs and TPPs must revoke their eIDAS certificates if they are no longer valid (e.g. contain incorrect information).

OBIE directory services are not available due to:

• outages (e.g. while introducing an update or under extreme load), or
• missing or defective functionality (e.g. lack of regulatory status check updates).

ASPSPs and TPPs may not be able to enrol during any outages, which could delay introduction of services for PSUs.

ASPSPs may not be able to validate the regulatory status of TPPs during outages or if the status check service is not working using the Directory.

1. Both ASPSPs and TPPs must revoke their eIDAS certificates if they are no longer valid (e.g. contain incorrect information).
2. ASPSPs must not block access to authorised TPPs, based solely on Directory outages.
3. ASPSPs should cache (locally in their systems) any critical directory services, especially if they chose to rely on the data from these to be highly available and/or validated for every API call.
4. OBIE should make any updates to the directory during non-core hours.
5. OBIE should notify all participants regarding all planned and unplanned downtime.

Some ASPSPs have not been caching critical directory services in the past, which has resulted in outages in their APIs.

Some ASPSPs have not allowed access to TPPs because they have not been able to check the regulatory status of TPPs using the Directory.

OBIE believes these incidents are now much less likely to happen.

ASPSP introduces additional steps during authentication because they:

• do not allow the PSU to use their existing authentication method (e.g. mobile app biometrics),
• replay consent,
• add additional information (e.g. CRM warnings), or
• add unnecessary screens (e.g. repeated confirmation steps).

Too much friction will significantly reduce take-up of services by PSU, especially relating to PIS.

1. ASPSPs must not introduce obstacles during re-direction.
2. ASPSPs should follow the OBIE CEGs regarding steps for each AIS/PIS/CBPII use case.
3. ASPSPs must allow PSUs who have and use biometrics in their mobile banking app to 
4. ASPSPs should implement app-app wherever relevant without interstitial mobile web pages.
5. ASPSPs should implement decoupled authentication to cater for relevant use cases.
6. OBIE should conduct further research into the route causes of high PIS drop-off rates.
7. OBIE should work with participants and regulators to better understand the requirements, solutions and implications of both CoP and CRM for PISP journeys.

Most ASPSPs following OBIE Standard are working to follow CEGs in this regard by Sep 2019.

App-app is a requirement under the CMA Order and is being implemented by all CMA9.

Few ASPSPs are likely to implement decoupled by Sep 2019.

Initial reports from PISPs indicate an average failure or drop-off rate of over 50% and in some cases as much as 80%.

This re-authentication acts as a reminder to PSUs that they are still allowing an AISP to access their account.

However, there are several scenarios where this extra friction may result in PSUs losing access to useful/important services (e.g. PFMs, Accounting Software and Sweeping).

1. ASPSPs must not introduce obstacles during re-direction.
2. ASPSPs should follow the OBIE Standard regarding the shorter re-authentication journey.
3. ASPSPs should implement decoupled authentication to cater for relevant use cases.
4. OBIE should work with ASPSPs and TPPs to investigate options (e.g. including premium APIs) to mitigate the negative impact on PSUs.

A number of TPPs have reported significant drop off (i.e. PSUs abandoning the service) when this re-authentication is required every 90 days.

At least one ASPSP has not implemented the shorter journey as per the OBIE Standard.

As ASPSPs improve their SCA journeys, OBIE expects this drop off to improve.

ASPSP does not allow a 90 day exemption under RTS Art 10. This may be because the ASPSP either:

• has chosen to not provide this functionality in their dedicated interface, or
• has implemented a fallback instead, which will not likely support this.

ASPSP will require the PSU to authenticate for every account request from an AISP. 

This will make any ongoing service (e.g. PFM, Accounting Software or Sweeping) effectively unusable.

1. ASPSPs must include details of whether/how they support the Art 10 SCA exemption in their API documentation. 
2. All ASPSPs should support the Art 10 SCA exemption.

At least one ASPSP in EU has stated they will not support the Art. 10 SCA exemption in their dedicated interface. 

OBIE are not aware of any ASPSPs in UK who are taking this stance.

However, any ASPSPs implementing a fallback are unlikely to be able to support this SCA exemption.

ASPSP does not support any of the allowable SCA exemptions for payments in their direct channel and accordingly these are also not available for PISP payments, for example:

• payments to trusted beneficiaries,
• payments to self,
• repeating payments of the same value, same payee and
• low value payments.

1. ASPSPs must not introduce more friction (e.g. more SCA steps) for a PISP journey as for a direct payment in the online channel.
2. ASPSPs should follow the OBIE standard regarding SCA exemptions (P8) published in v3.1.2.
3. OBIE must develop a standard to support VRP as per the published CMA Order roadmap.

It is not known how many ASPSPs are supporting SCA exemptions for PIS use cases for Sep 2019.

OBIE is working with a number of participants to test VRP propositions under the FCA Regulatory Sandbox in the 2019 cohort.

ASPSP does not provide a unique and immutable identifier for each transaction record in the GET transactions endpoint because:

• this is not something they hold in their core systems, or 
• this is not something they hold or display to PSUs in their existing online channels.

Without an immutable transaction ID, AISPs face a number of challenges, including:

• having to repeatedly request previously called transactions,
• difficultly in matching transactions to other records (e.g. in accounting software), and
• lack of certainty in the providence and stability of data.

This in turn could limit the accuracy of AIS services, and potentially result in misleading PSUs.

1. ASPSPs must include details of whether/how they support transaction IDs in their API documentation. 
2. ASPSPs should take all possible steps to generate or provide a unique transaction ID either:
   1. from their core systems, or
   2. by supplying a method to allow TPPs to calculate this.

OBIE has asked all ASPSPs to update their entry in the OBIE Transparency calendar with this information.

The majority of CMA9 have committed to provide a solution by Sep 2019, see /wiki/spaces/DZ/pages/1010074155.

Lack of account holder name(s) for AIS

ASPSP does not provide the name of account holder(s) to AISPs in the Account and Transaction API.

Without the name of the account holder(s) many AIS use cases (e.g. application for lending products) are less useful than current solutions (e.g. paper statements or screen scraping).

This could limit the value and adoption of such services by PSUs.

1. ASPSPs must provide the name of the account holder(s) to the AISP.

Currently not all ASPSPs are providing this.

It is expected that most, if not all, will be providing this by Sep 2019.

ASPSP does not provide a status for each payment beyond the immediate response to PISP's POST for the payment resource, which is often 'Pending'.

This is because the ASPSPs either:

• cannot easily update the status of the payment in their online channel, or
• choses not to update this status as there is no regulatory requirement.

It is not expected for the PISP to receive a status of 'Accepted Settlement Complete' (i.e. payment has been received in the payee account) as many online channels do not inform the PSU of the execution of payments.

However, if the PISP does not receive a status of 'Accepted Settlement in Progress' (i.e. payment has been debited from the PSU's account) they will not be able to inform the PSU (and/or merchant) that the payment order has been accepted by the ASPSP. This will limit the value/utility of many PIS use cases.

1. ASPSP must provide the status of the payment initiation immediately after the receipt of the payment order (i.e. immediately after the POST by the PISP to the payment resource).
2. ASPSP should provide a RESTful response to subsequent GET requests to each payment resource, at least up to and including 'Accepted Settlement In Progress' and, if/where possible, 'Accepted Settlement Complete'.

OBIE have further updated the standard (in v3.1.2) to include status codes for all payment types through to execution.

Currently several ASPSPs are not providing a RESTful response, and all subsequent GET requests to the payment resource only return a status of 'Pending'.