Architectural Decisions for Service User

Connectivity is a commodity that the end customer expects to work. However, it is the responsibility of the Service User to add value to the connectivity within his business application, where the business logic takes place and is offered to the end customer.

bLink as a scalable middleware layer between Service Providers and Service Users (find out more about how you can benefit from bLink on our website) is the basis on which value is added. An example of added value could be the use of transaction data to automate payment reminders for end customers. To ensure that value is created on the basis of bLink, a number of fundamental decisions need to be taken. This guide aims to shed light on the integration possibilities for Service Users with bLink by addressing the following key questions:

1. Is an additional adapter service required between bLink and the Service User’s business application?
2. How is consent management (permissions or tokens) handled?
3. How do you ensure that data is interpreted correctly?
4. How do you ensure that data is not duplicated in the Service User’s application?
5. What test setup is required to ensure that connectivity remains stable and usable?

In the following chapters, an adapter service approach will be used as the basis for a bLink integration by the Service User, as it’s the most commonly used integration strategy in software projects. When we talk about the business application, we mean the application layer that you provide to your customers. The adapter service refers to a separate instance within the Service User application that handles the integration with bLink. The visualization below shows a sample setup.

Based on the above-mentioned questions and subsequent decisions, a robust foundation can be laid for a successful integration.

Adapter Service Setup

bLink enables efficient 1:n connections between Service Providers and Service Users, compared to multiple direct 1:1 connections. However, this requires that the implementation is built in a generic way to handle the consent flow and all subsequent API calls to the connected banks and the differences between banks that may occur. These differences mainly concern camt.053 files, the acceptance criteria for pain.001 files and the same for the JSON formats (see section Interpreter).

An adapter service setup ensures that differences on the Service Provider side do not affect the business flows in your application. This approach decouples the data from the source and gives the Service User the flexibility to act within his domain. At the same time, it enhances the security of the bLink integration through the architectural setup. In this context, the adapter service has two responsibilities:

1. Handling access to service provider systems, see section Consent Management: Permissions and Tokens
2. Ensuring that domain language/data is transformed into bLink domain language/data and vice versa for both AIS and PSS, see section Interpreter.

Consent Management: Permissions and Tokens

Regarding the technical handling of customer consent, which allows a Service User to access a customer's data held by the Service Provider, bLink offers two types of integrations. Connecting directly to bLink using Consent Management 2.0 or using Consent Management 2.0 with Consent-as-a-Service (CaaS), a standardized token store service that is provided by SIX.

Details on the difference between the two integration paths can be found here. In short:

1. Consent Management 2.0 uses tokens that access Service Provider systems directly.
2. Consent Management 2.0 with CaaS uses permissions to access the tokens stored by SIX.

Either way requires that the tokens (integrating with your own token store) or the permissions (integrating with CaaS) are

• bound to the correct entity in your product and
• stored correctly

Token Binding

An entity in this case refers to your end customer, i.e. it’s business entity, using your application. The permission or token gives the Service User access to a bank account that is tied to a specific e-banking contract with the Service Provider. The permission or token is created in the context of the so-called consent flow on bLink, which is completed by the end customer to give the Service User permission to access his bank account and consume the corrsponding data. If possible, the permission or token should be bound to an individual user of the Service User’s application who completed the consent flow. In edge cases, permissions or tokens may be tied to an entire (business) entity. Such cases require a restriction on the user side that the permission or token can only be invoked by the initial consent doner, i. e. the individual user who initially completed the consent flow. This ensures that the consent donor only allows the data to be passed on to other users, without sharing the permission or token. An internal permission framework in the application gives the consent donor the flexibility to decide with whom the data can or cannot be shared. Access to the data could be granted to anyone with a valid e-banking contract and the right to access the financial data of the connected bank account – be it a business owner, asset manager, accountant or fiduciary.

This can lead to the following setup:

Multiconsent

Multiconsent refers to the possibility that an e-banking contract can have multiple valid tokens (or permissions) at the same time. This is not (yet) supported by all banks. If possible, the Service User should not rely on multiconsent, and in cases where it is not otherwise possible, this limitation must be communicated to end users. If two consent flows are performed with the same Service Provider and the application user uses the same login to log into his/her e-banking both times, the token issued for the first completed consent flow will be revoked by the second consent flow (see also Token Management).

Secure Store

Storing permissions or storing tokens require different security measures for a Service User. Both integrations give you access to the resource on the Service Provider side, and both tokens and permissions need to be handled securely. However, the audit requirements for a non-CaaS setup are more extensive and not discussed here (for more information see chapter Admission Criteria). The following section applies only to permissions and can only serve as an inspiration for token handling.

Permissions are as sensitive as passwords. Therefore, similar security requirements apply. From an architectural point of view, the storage of permissions should be separate from the business application and ideally also separate from other credentials such as passwords for your application. If you are working with an adapter service setup, you can increase security by storing the permissions securely in the adapter service and tying it to the user through an anonymized user tag. This setup might look like this:

Third-Party Secure Storage Solutions

There are multiple third-party secure storage solutions that can be used off the shelves to store permissions.

Example Adapter Service Setup

If the Service User decides to work with an adapter service, the end customer permission can be stored in a separate secure storage that only the adapter service can access. Any API request to the Service Provider is routed through the adapter service, while a flag on the application user (i.e. the end customer) indicates the permission or token that needs to be used. If the Service User chooses not to store camt or JSON files for AIS , the adapter service could host the interpreter and link the data back to the relevant bank account using the IBAN as the identifier in your domain-specific format. By transmitting only relevant data, the risk of exposing sensitive data is reduced. Duplicate checks are performed within the business application. For PSS, the pain files or JSON files can be created by the adapter service and transmitted to the bank, making the adapter service stateless, except for the secure storage for permissions or tokens. This setup is robust and secure.

Interpreter

An interpreter provides the functionality to transform data from the Service Provider to the Service User and vice versa, for both AIS and PSS . This transformation is required to extract the data from the form in which it is provided (e.g. camt.053 or JSON files) to fit your internal data model. It is advisable to use the same interpreter for both data that is queried via the APIs as well as for data that is uploaded manually (allowing the manual upload of files will give you an advantage in support cases, as the user will still be able to act if a connectivity isse occurs).

As mentioned earlier in the Adapter Service Setup section, there are slight differences in the files received from the bank.

1. camt.053: bLink only accepts camt.053 with details. However, there may be differences between banks in the implementation of the camt.053 according to the Swiss Payment Standards (SPS). The interpreter must be able to handle these differences generically.
2. pain.001: A pain file according to the SPS will be sufficient to submit a payment. Therefore, the pain.001 file should be created accordingly by the Service User.
3. JSON: The JSON schema is verified by bLink in both AIS and PSS. However, there are slight differences in data points between Service Providers in accordance with the scheme. As with camt.053 and pain.001 files, similar measures must be taken by the Service User for the JSON files.

For security reasons, it is advisable to limit the data flow to only the data relevant to the use case. The bank's data can then be enriched in the business application of the Service User with its own data. This is especially beneficial when dealing with sensitive data such as bank statements. Selecting relevant information from the bank statement and enriching it with data available in the business application increases the security of your application by limiting the exposure of Client Identifying Data (CID). This is particularly relevant for bank files, such as JSON or camt.053 files.

Once the file is interpreted, the Service User needs to determine if there is any additional benefit to storing the transaction file. Storing the camt.053 or JSON files provides the following benefits:

• Transparency of the transmitted data: This transparency allows you to track what information was conveyed through the interface at specific points in time, which helps with audit trails and comprehensive record-keeping.
• Simplifies the duplicate filter, as it can check whether the file has already been retrieved or not.

On the other hand, not storing the file has the following benefits:

• The file remains bank property and is sensitive information. Not storing files ensures that the bank's properties remain secure.
• Both options require the data to be transformed into your application. Therefore, not storing the file ensures that data is passed on without compromising data privacy, making it sharable with other aspects of your application.
• Duplicate filtering can be as robust as when the files are stored if the Service User chooses to work with either the File ID or the Account Service Reference Number, which will be discussed in the next chapter Duplicate Checks Are the Responsibility of the Service User.

Overall, the interpreter needs to transmit the relevant information to all other relevant parts of the application. The decision to save the files should be taken based on the specific use case and the added value it gives to the service or the end customer.

Not storing files

If you choose not to store the files, you will need to find other ways to ensure a reliable audit trail for your end customers. For example, this could be done by not allowing your end customers to delete transmitted transactions (e.g. they can archive transactions, but they can't store them).

Duplicate Checks Are the Responsibility of the Service User

Duplicate checks for transaction information (AIS) remain the responsibility of the Service User and are critical to the usability of your business application, especially if (multiple) ways of uploading files are offered. Duplicate checks can be done in several ways, either file-based or transaction-based:

• On a file basis, the file ID can be used, even if the file itself is not stored in the application.
• On a transaction basis, the Account Service Reference Number (AcctSvcrRef) allows individual transactions to be identified.

This is possible for both camt.053 and JSON transaction files.

For payment submission (PSS), the responsibility for identifying duplicates lies with the bank. However, the following principles must be followed by the Service User:

• Use unique IDs on your payments submitted to the bank to identify the payment.
• Indicate in some way to the user which payments he has already transmitted.

These principles improve the usability for all participants.

Test Setup: Think of How to Ensure Connectivity Is Tested in Every Release

Once your bLink integration into your product is live, the connectivity needs to be tested continuously with each release of your own application as well as with each version upgrade of the APIs on bLink. Integrate connectivity testing into your standard release cycle. Separate test environments are not recommended.

In general, there are two testing strategies. Testing using the bLink simulator or mocking bLink and a Service Provider:

• If you can connect to external systems with your test system, the bLink simulator is an ideal way to test. Be aware that the simulator has some discrepancies with individual Service Providers' productive environments.
• An alternative to the simulator would be to mock bLink in your own test environment. This allows further automated testing but also requires that updates are performed in accordance with the updates to the bLink simulator or bLink's productive system.