News & Insights

The INNOPAY Experience Lab architecture

The INNOPAY Experience Lab contains realistic models of banks exposing services for ‘access to the account’ (XS2A) through API gateways. Hoeksma: “We’ve worked with providers of top tier tools and software to assure that our model is representative for the real world.” The API gateways make it easy to change the behaviour of the banks under the ecosystem, by changing the policies under which they operate. With even more ease, parameters in the INNOPAY Experience Lab Dashboard can be changed, to demonstrate certain behaviour changes on the fly. Hoeksma continues: “Our ecosystem provides a unique opportunity to test multi bank scenario’s. It uses a shared test currency and includes clearing and settlement. Testing ideas and services is always a problem based on real services, due to their sensitive nature. Services that are available for testing, usually only cover a part of a system. Our ecosystem is complete and realistic.”

Two TPP’s, MyUros and Maintenant, each with their own interaction model, demonstrate how a TPP might use XS2A services to offer innovative payment and information services. “These apps and models can be changed to answer ‘what-if’ questions too, as all programming code is under our control”, Hoeksma explains.

“To create realistic insights that are easy to understand, several store front pages and POS models are available to experiment with.

As a stepping stone to more complicated (and valuable) interaction scenario’s, an aggregator and other service providers are available, ready to be experimented with.”

The architectural components of the INNOPAY Experience Lab are visualised below.

Learnings from the INNOPAY Experience Lab

Mounaim Cortet, Thought Leader PSD2 and open Banking Strategy at Innopay explains: “We observe that banks seem to have varying interpretations regarding the interaction model they are required to support to enable XS2A in a compliant manner. Sure, access can be more seamless based on the design decisions made by the bank.

At the centre of PSD2 we find requirements on strong customer authentication (SCA). These requirements help to ensure that security of funds and information is guaranteed even when communicating through TPPs outside the bank’s domain. In addition to an interaction model supporting ‘always SCA’ in the bank domain, PSD2 offers the possibility to exempt SCA in certain well-defined cases which are elaborated in the Regulatory Technical Standards. The exemptions allow for a more seamless customer experience when a customer uses a TPP to interact with its bank.

With the Experience Lab dashboard, we can configure various parameters including SCA exemptions to simulate the interaction with a bank at the flip of a switch. This gives valuable insight in how the customer journey of TPPs and a bank’s customer can be made more seamless. We support banks to come to an informed strategic decision regarding the interaction model with TPPs and customers they seek to support as part of PSD2 compliance. This sets the baseline for future interaction models (e.g. based on access tokens) that a bank might be willing to support as part of its Open Banking strategy in partnership with third parties.

In addition to SCA exemptions and interaction models, we have seen some traction around API standardisation. While these standardisation efforts are still premature, it is obvious that an aggregator could simplify the API landscape for TPPs through a technical and operational aggregation service. While this might seem a compelling service from a conceptual point of view, we have identified some challenges and pitfalls that potential aggregators might run in to in elaborating their business model.”

Next steps

Hoeksma: “Now that standardisation initiatives are gradually releasing their specifications for market consultation, the Experience Lab provides an opportunity to learn how they would work in practice and whether they would help to create value. We have started to implement the Berlin Group specification and expect to be able to use it shortly. Other standardisation initiatives will follow.” And that’s not all: “We intend to build many more demonstrators and tools under our themes of Openness, Customer in Control and Digital Transformation. Our security, machine learning and blockchain teams for instance are eager to use the Experience Lab in their projects.” 

How can you use the INNOPAY Experience Lab?

The INNOPAY Experience Lab is available to our customers as a tool for strategy development and strategy validation. There are several possible approaches to this. One such approach to support strategy development is depicted below.

Hoeksma: “We can install the MyUros (TPP) app on the devices of key stakeholders in the strategy development and implementation process. In an interactive session at the start of the cycle, we then discuss experiences and align visions to create a back log for a combined consultancy and development sprint to analyse and show alternative implementations or optimisations. After this, we install a new version of the app on the devices and discuss new questions to be addressed in a consecutive cycle. This process makes your strategy development process and implementation approach more fact based and can be repeated as desired.”

Cortet adds: “Another option is to use the INNOPAY Experience Lab in the validation and refinement phase of your strategy and design. If your strategy is already more developed, you may want to benefit from a second opinion on PSD2 compliance design, based on INNOPAY’s interpretation of legal text (PSD2, RTS). The INNOPAY Experience Lab can optionally be used to validate the design, to make it tangible and to show potential improvements and alternatives.”

The INNOPAY Experience Lab can be used in other ways too and we would gladly explore how you could optimally benefit from it.

---

Written in collaboration with Ronald Hoeksma