How does Realtime Dataprovisioning work?

This method allows for the most up-to-date check results. Each time SurePay receives a request for one of your accounts we fetch the account data in real time via your data provisioning API. The data will be as up-to-date as you present it to SurePay. However, this method requires some extra work on the ASPSP side, as a data provisioning API needs to be created.

image

Routing

In case the bank exposes multiple endpoints for Realtime Data Provisioning the routing logic should be provided to SurePay. This routing logic describes for which bank codes (and possibly sort codes) which data provisioning endpoints are to be called. It is assumed this is a simple deterministic routing table. Furthermore, the bank must specify whether access tokens are usable across these endpoints or not.

Non functional aspects & security

The Online Provisioning API should include the following security controls:

  • TLS (minimum TLS 1.2) or MTLS
  • OAuth 2.0 client credentials grant flow
  • IP whitelisting (optional)

TLS-MA (UK ONLY REQUIREMENTS)

The transport layer security will be implemented according to TLS-MA standard (minimum TLS 1.2). High level process of verifying the certificates is the following:

  • Both consumer and provider have to possess certificates signed by Open Banking (acting as CA)
  • Both consumer and provider can verify if the certificates are signed by Open Banking, by retrieving the corresponding public certificates
  • Additionally, the provider will verify if the consumer’s certificate is present on the Open Banking revocation list
  • The certificates has to comply with the following list of possible ciphers: EECDH+AESGCM, EDH+AESGCM, AES256+EECDH, AES256+EDH

OAuth 2.0

The application layer security should be implemented according to OAuth 2.0 standard, with the client credentials grant type. The standard specification of this type of flow is available online: https://tools.ietf.org/html/rfc6749#section-4.4.

Technical Details
SurePay expects to get the following from the API provider:

  • The exact endpoints for both production and test environment
  • Client credentials (either via dynamic registration or manually)
  • /token endpoint to be used with the above client credentials, to retrieve the access token

Performance and availability

The Online Provisioning API should comply with the highest availability standards, as it should be available 24/7, allowing the SurePay solution to function without downtimes. Such extreme availability requirement implies at least active-active infrastructure setup on the API provider side which should be abstracted by highly available DNS service towards consumers.

In case of any downtime of the Online Provisioning API, SurePay will respond to requests with an internal server error.

The latency of the Online Data Provisioning API determines the overall latency to a large degree. The response time target is 150ms. From our experience a fast yet realistic response time is between 50 and 100ms, but it is often dependent on all types of bank legacy.

Regarding support, resolution time, etc, a separate SLA document is to be specified in cooperation with the bank providing the service.

Encoding & Special Characters

The API requests and responses must use a UTF-8 character encoding. This is the default character encoding for JSON (RFC 7158 - Section 8.1). Body parameters are case sensitive for both request and response. From SurePay solution perspective, all the special characters provided by the API are excluded or replaced during the matching phase, however in case of name suggestions, SurePay will provide the exact data that was provided by Online Provisioning API.

Previous
Next