Operational Best Practice

Open banking ecosystems thrive on the value created through collaboration. Multiple ecosystem participants cooperate to offer their mutual end customers a higher service quality (e.g. through automation) or entirely new services all together. In this context, ecosystem participants can take on the role of Service User and Service Provider (see chapter What's bLink), i.e. they either consume or provide data-based, API-enabled services within the ecosystem. At the core, in whatever role, collaboration is beneficial to all ecosystem participants.

info

Find more benefits of collaboration at https://blink.six-group.com

Central to the delivery of value is the concept of value co-creation. Value co-creation is a collaborative, coordinated and ongoing process to ensure that end customers truly benefit from the services jointly offered by Service Providers and Service Users. It starts with the stability and reliability of the service integration.

Two guiding principles help establish the right processes and support systems for a successful service integration and its operation via bLink:

• End customers see connectivity as a single product – in their eyes, there are not two parties offering two separate products.
• The jointly offered products and services must be provided with the expected quality by both the Service User and Service Provider to be actively used by the end customers.

Consider the following example to better understand the principle of “one” product: Let’s say a Service Provider needs to transmit financial statements requested by an end customer. In order to transmit the financial statements, the Service Provider needs to generate the statements at some point in time. Service Users, on the other hand, need to retrieve those statements, transform them into a usable format, and aggregate them so that the end customers can view in their application interface. Even though the user journey for this use case from the customer’s perspective only takes place within the Service User's business application (that is, after the initial consent flow is completed), the user experience and the quality of the service as a whole is also heavily influenced by the Service Providers.

The same goes vice versa. For example, if a customer submits a payment within the Service User’s application and the Service Provider doesn't allow the execution of the payment in the e-banking because it contains invalid characters – perhaps because the customer entered them incorrectly and the Service User allowed them to be submitted – the inconvenience for the end customer will now occur in the Service Provider’s application, although it was initially caused by the Service User.

If the needs of the end customers are (repeatedly) not met, individual Service Providers or Service Users may run the risk of losing customers to others with better service quality – or, in the worst case, the entire ecosystem may lose customers because they perceive a corresponding product as unreliable. In either case, end customers will stop using the offered products, services or applications and look for alternative ways to meet their needs, essentially hurting the ecosystem participants that provide low quality services. In summary, it’s the responsibility of both Service Users and Service Providers to ensure that the end customer is supported beyond the offering that their respective product addresses. This requires all parties to think in terms of user journeys (see chapter below), rather than only in new product features or new products.

bLink User Journey for Accounts and Payments (AIS and PSS)

A user journey describes the experience of a user interacting with an application or a service enabled by that application. It includes a specific need (e.g. to make a payment) and all related activities to fulfill that need (e.g. logging in, creating and executing a payment). In ecosystems, a user journey is usually not covered and fulfilled by one application alone. Rather, it's a flow between two or more applications that ideally co-create a seamless experience for the user on his journey.

This could look like the following for Account Information Services, where the end customer integrates his bank account data into a Service User’s application:

End customers see a single product or service that they have enabled through their consent, not two separate applications that work together through connectivity. It is therefore the responsibility of both the Service Users and Service Providers to meet user expectations by ensuring the quality of the service through a seamless, coordinated customer journey.

info

A customer journey includes all the actions needed by the end costumer to achieve his desired goal. For example, if the end customer wants to retrieve bank statements, the customer journey would include the initial consent flow to connect their bank accounts, retrieving bank statements, and, if necessary, the display of error messages and support instructions on how to deal with errors that potentially occur.

This can be achieved by adhering to the following principles when integrating bLink enabled services and products:

• Enable a high degree of self-service
• Create seamless flows when crossing application boundaries a) for the initial customer consent and b) the operational connectivity setup
• Ensure data availability and consistency
• Create appropriate and efficient support processes

Self-Service for Your End Customers

Every support touchpoint that occurs during the customer journey means that the journey is inefficient. Therefore, the goal of all service participants should be to reduce the need for them. The most important assurance lies in the right design of the connectivity-based product or service.

Best practice has shown that the following measures heavily reduce the need for support:

• Guide the user through the connectivity-based product by designing a clear, step-by-step user flow (from giving consent to using the service).
• When touchpoints are required (e.g. signing a legal waiver), make sure to direct the end customer to the actor or source that can resolve his issue.
• Create support articles that are available to the end customers (e.g. in your help center) to support them along their journey.
• Provide workarounds for system interruptions (e. g. enabling the manual upload and download of bank statements or payment files).

When designing the connectivity, ensure to keep messages (general or for support) short and precise for the readers. If possible, use generic support sources or links that remain stable over time for easy maintenance.

Pay attention to the onboarding flow

Experience shows that end customers sometimes struggle with the onboarding. This includes giving consent and completing the setup for the connectivity-based service. However, once the end customer has agreed to and set up connectivity, the service runs smoothly. It pays off to consider the best practices above when designing the onboarding journey.

Seamless Cross-Application Flows

When crossing system boundaries during the user journey, end customers expect it to work seamlessly and like any other integration they have used before. This is especially true when it comes to A) initiating connectivity, i.e. when end customers connect their bank accounts, generally referred to as the initial consent flow and B) working with the shared data once the accounts are connected – referred to as the operational connectivity setup.

A) Initial Consent Flow

The consent flow refers to the initial process by which connectivity is established between a Service User’s application and a Service Provider’s systems. This requires that end customers are redirected from the Service User’s application to the Service Provider’s online banking where they confirm their identity (using 2FA) and select the bank accounts they wish to connect (based on OAuth 2.0) to the Service User's application. The Service Provider then issues a token that reflects the end customer's consent and allows the Service User to access the end customer's banking data through his application.

There are different ways for Service Users to technically handle customer consent on bLink. Find out more about this in the section Consent Management: Permissions and Tokens in the chapter Architectural Decisions for Service Users

note

The OAuth 2.0 based flow allows a Service User to automatically access customer data at the Service Provider on behalf of his customers, i.e. with their explicit consent. This allows for automation within the Service User’s application and enables a higher service level to the customer.

The end customer user journey for the consent flow begins within the Service User’s application. There are two different starting points, depending on the use case or how the application is set up. If the Service User already knows which Service Provider end customer wants to connect to, the consent flow can be initiated directly with the Service Provider in question. This is usually the case when an application (e.g. an accounting application) has already asked end customers to provide their bank accounts as an integral part of setting up the application, e.g. for generating account ledgers and accounting reports. If this isn't the case (this could be the case for an expense analysis tool), then the Service User would need to provide the end customer with a list of Service Providers for which connectivity is available. Such a list can be retrieved via bLink. Which of the two starting points applies, depends on your application.

When creating the consent flow, it is advisable to make use of standardized flows and practices. Best practice shows that customers are used to the OAuth flow in digital products. This means that the following, summarized steps are best created by analogy to existing products:

1. Once the end customer selects the Service Provider to connect to, display a confirmation message, explaining that the end customer is now being redirected to the respective Service Provider.
2. On the Service Provider side, well-known and familiar login and 2FA pages should be used.
3. After the login, the end customer can confirm the consent by accepting the legal requirements on the Service Provider side.
4. In the next step, the end customer can select the scope of the permission or token. The scope regulates which accounts and operations are available to the Service User. The customer then confirms the scope (via 2FA).
5. Once this step is completed, the end customer is prompted with a success message and redirected back to the Service User Application to finalize the connectivity setup.

The closer the design of these 5 steps of the user journey is to the standard OAuth flow, the easier it is for the end customer to navigate through the connectivity setup enabled by bLink. This, in turn, greatly increases customer satisfaction.

B) Operational Connectivity Setup

The finding of transmitted data should correlate with existing user expectations and experiences. If it is possible to create, edit, manage or upload transactions or payments within your application, the end customers expect transactions or payments coming from another (external) source to be in the same place as internally created transactions or payments. Even if it’s technically or legally a different service, it’s not perceived as such by the end customer.

In general, this means that orienting the implementation of the connectivity-based product towards existing products improves the usability for the end customer. Connectivity products extend the existing offerings of both the Service User and the Service Provider. The user expects to use these extensions in the same place as he uses the core product.

Data Availability and Consistency

The primary function of bLink is to enable standardized, efficient and secure data exchange between multiple ecosystem participants. This requires data availability and consistency across all ecosystem participants. Service Providers that don't offer intraday data need to ensure that data is always available at the right time and in the right, standardized format. Since most Service Users automatically retrieve data overnight, the right time to provide data would ideally be before 4 am to give Service Users enough time to synchronize data from all customer accounts in time before the start of official business hours.

There are many instances where data needs to be fetched more than once (e. g. to ensure that the business application is up to date). Best practice shows that is advisable for Service Providers to enable the retireval of transaction statement files (Account Information, AIS) for the last 90 days. The responsibility for appropriate duplicate handling rests with the Service Users.

info

Find out more about duplicate handling in the section Duplicate Checks Are the Responsibility of the Service User in the chapter Architectural Decisions for Service Users.

Support Processes

The support process for the connectivity product should be efficient and user oriented. The expectation of the end customer is that you will be able to resolve an issue efficiently or communicate it transparently and proactively. Even if the issue is outside your domain as a Service User or Service Provider, remember that the end customer may still be using the service and related support functionalities within your application.

The following points should guide you in creating a robust support setup for your end customers. This includes:

1. Communication with Service Providers or other Service Users should ideally always take place through bLink (via the bLink Support Portal) and, if possible, not directly with another individual platform participant (1:1). This centralized approach ensures transparency, quick problem identification and gives the issue the importance it deserves. It also ensures that changes are not only applied to one participant – potentially disrupting connectivity for all other participants – but are communicated and applied holistically among the affected participants. When creating a bLink ticket in the Support Portal, always describe the issue and attach a sample call with a Correlation-ID. This helps to speed up the support process.

2. Communication to the end customer must be as timely as possible. The best proactive communication is done by displaying standardized error messages. More about this can be found in the section Generic Error Codes in the chapter Error Codes and Monitoring. In exceptional cases, such as downtimes, there may be issues that need to be communicated directly to the end customer before he uses the connectivy-enabled service (e. g. on the homepage of the application or through proactive mailings). Best practices for communicating with end customer include the following:

   • Use standardized messages.
   • Use the same messages in-app (1:n) and in direct (1:1) customer support communications.
   • Refrain from finger pointing and use neutral language until the issue is resolved.
   • Communicate workarounds to the end customer (e.g. “In urgent cases, please download the transaction manually until the issue is resolved”).
   • Avoid reffering the end customer to the other ecosystem participants, as this may result in the end customer getting lost in different communications with the Service Provider and the Service User without getting a swift solution.
   • Once the issue is resolved, transparently communicate it together with its resolution to the end customer.

   These steps are cricital to earning and maintaining the trust of the end customer. Issues can occur – the key is how the user feels about the support communication.

3. Monitoring of the interface(s) helps to identify issues early on and communicate them proactively. You can read more about this in the section Interface Monitoring in the chapter Error Codes and Monitoring.

4. To be able to follow the above recommendations, it is crucial to establish the right operational setup. bLink as a product needs to be supported throughout your organization. Besides the regular support setup and training, it requires that someone takes clear responsibility for all bLink support tickets and responds to them in a timely manner. Establishing standardized handover processes both internally and to other participants in the bLink ecosystem will help to resolve issues efficiently and effectively.

We advise Service Users and Service Providers to really put the above-mentioned measures into practice in order to reap the benefits of the new co-created offering and add value to it. To ensure that your end customers benefit from your participation on bLink, you need to be an active ecosystem participant. It is therefore critical to set up coordinated processes and to ensure that the end customer is supported throughout the entire lifetime of the offering.