Payments and Transaction Banking Customer Experience – Client Integration as Competitive Edge for Banks

In the past, banks have had a single minded view of product delivery and customer service for transaction banking:
  • handhold large corporate clients through their integrations to bank channels
  • build custom file format mappings for large and medium-size individual clients
  • underserve small clients
  • ignore ERP and Treasury vendors. 
Their primary focus was on managing people and relationships and they tended not to innovate around the customer service processes. But 21st century businesses can’t just manage people and relationships, they have to deliver frictionless digital services using technology. Frictionless services doesn’t just mean frictionless on ‘Day two’ when clients are up and running with the bank. It also means frictionless immediately, during the onboarding process.
Onboarding is an area where successful new payment FinTechs like Stripe and Plaid have lead the way. They make the registration to the product really easy.  If a client wants to register for a service, they make the client journey as smooth and as simple as possible. 
Banks can use the ideas of these FinTechs as inpiration for creating a competitive edge around this same area.

Three Philosophies for Client Integrations

 At banks, registration for a product might not be so simple due to KYC, AML and other processes but there are no excuses for creating a smooth technical onboarding to the product. Typically, banks use the term client integration for technical onboarding of the client to transaction banking products like payments. There are two major hurdles here: 
  • connectivity – how to transfer data in a secure manner between client and bank
  • alignment of data/file formats between client systems and bank systems
In this post, we’ll focus on the file format problem. XMLdation have identified three philosophies for alignment of file formats in client integrations. A bank will often choose a different philosophy for different client segments. Each philosophy requires a different type of technical solution and process at the bank in order to deliver a winning customer journey.
The three philosophies are:
  1. Promote bank standard to clients
  2. Build customisations for clients 
  3. Encourage vendor testing

Philosophy 1: Promote bank data format standard to clients

The first philosophy is to encourage and make it easy for clients to adhere to bank data format standards. This requires work and commitment on the part of the client, but usually results in a more robust integration and lower long-term costs for the client and the bank. If clients all use bank services in a standard way, there is reduced risk of error, and the bank will be able to roll out new services and enhancements to its client base more easily. This will be valuable to clients as they look to increase levels of automation in their treasury department.
Here are the things that the bank can do to make it easy for clients to adhere to standards:
  • Publish high quality, up-to-date information on the data formats – documentation, guides, schemas, etc. The can cover the bank versions of standards ISO 20022, SEPA, US ACH, US Wires, or even the bank proprietary file/message formats. 
  • Provide sample files that the client can learn from
  • Provide self-service sandboxes so the client can build and test according to their own timetable.  
  • Monitor client activity to ensure a client is making progress and proactively contact the client with offers of support if they notice that the client is encountering problems
  • Define a process: Clear steps that the client can follow to achieve readiness for acceptance testing (banks often refer to this stage as UAT = User Acceptance Testing)
This approach is suitable for clients who have the necessary developers and other IT resources available to work on the bank integration within their Treasury function. The client is in control, and can build the integration according to their own project timeline. If the bank guides the client through a well-defined process using a combination of self-service tools and targeted support, client experience will be positive and onboarding will go faster. 
But some clients have limited access to IT resources, and might look to the bank to play a more active role in the onboarding process. This is where Philosophy 2 comes into play.

Philosophy 2: Build data format customisations for a client

The second philosophy is for the bank to manage the integration work on behalf of the client by building mapping customisations for the client. The bank does more of the work, but clients still need to be involved in the integration and especially in the testing of the integration.
Here are the things that the bank can do to make the client journey easier
  • Define a process: Clear steps so that the client understands what is going to be done by both sides to achieve readiness for acceptance testing, including how the data formats will be mapped.
  • Provide self-service tools to allow clients to test the mapping customisations that the bank creates for them;
  • Over time, categorise clients and build accelerators that implement common mappings that can be reused across clients;
  • Archive realistic files from each client and use in automated testing. Run regression tests periodically to check that client files are processed correctly, especially when bank systems are changed. 
This approach is suitable for clients who are either not able, or don’t want to make changes to their treasury product. The approach is often of interest to smaller clients.
The challenges clients face in a banking integration are usually related to the treasury product that they have in use. And this leads in to the third philosophy. Simplify a client’s integration journey by supporting the treasury vendors.

Philosophy 3: Encourage vendor testing

This is not a common philosophy but we believe it is fast becoming a very important one. Support the ERP and treasury vendors to build their products so that they easily integrate with the bank. This way, the bank and the treasury vendors join forces to make the client journey smoother. 
Here are the things that the bank can do to support vendors:
  • Provide an easy signup process for vendors to do banking testing
  • Publish high quality information on the file formats
  • Provide sample files containing data that can be used in their testing
  • Provide self-service sandboxes so the vendor can build and test 
For key vendors, the bank might also decide to build mappings from the vendor file format to the bank standard file format, and make this available to clients.
While vendor testing with banks is unusual in the area of file based payments, it is becoming the norm in the world of open banking and APIs. In Europe, banks have been mandated to provide test facilities to vendors regulated under the European Payments Service Directive 2 (PSD2). In fact, this is also the approach that Stripe and Plaid adopt – focus on supporting vendors so consumers can access traditional bank services with zero friction.
In our view, it is increasingly important for banks to work closely with vendors. It can help resolve longstanding difficulties that result from uncoordinated and reactive approaches to client file format mappings. But vendors are also key to frictionless bank connectivity. In retail banking, clients can sign up to use a vendor App for their banking services. The App can connect to bank systems via API. Within the App, the client gives consent to the vendor to connect to their bank accounts. Client signup, connecting to the bank, and client consent are all simple, digital processes. This is the future for business payments. Banks need to support and collaborate with vendors in order to deliver the experience that bank customers will demand.

Competitive Edge

Banks can create a competitive edge by combining elements from these tree philosophies – best in class banks have all three of these in use. Whichever philosophy you choose to implement, XMLdation can provide solutions to allow your bank team to deliver a winning customer experience.

  • Help clients that want to align with your bank standard by opening the XMLdation Client Testing solution to them
  • Help clients that need customisations by leveraging the XMLdation’s capabilities to map different file formats and messages
  • Help vendors to streamline client integrations with your bank by opening the XMLdation solution to them with standard file formats and mappings

About XMLdation

XMLdation is a world leader in testing for payments messaging and APIs, covering ISO 20022, SWIFT MT along with national and proprietary payments formats.

Our solutions Request a demo today

Stay up to date

Subscribe to our newsletter

Menu