Visiting Money20/20 with the entire Sipios team, it is clear that FinTech is more demanding than ever.

Customer experience expectations are progressively approaching those observed for B2C digital products. In addition, go-to-market issues require drastically reducing the lead time to launch a new digital initiative.

The response from FinTechs and corporates is identical today: it is about moving away from a model where everything is built in house and approaching a vision where each major product functionality relies on the reference player in the FinTech ecosystem.

In this article, we describe the 3-step method we use at Sipios to architect state-of-the-art FinTech products.

Identify critical performances and major functions

Building an architecture requires to clarify :

• The critical performances of the product. These are the expectations of the different customer segments
• the major functions to be integrated into the product to achieve these performances

Identifying critical performance is a key task that stems from customer analysis (go & see fieldwork, customer interviews in a second phase, as well as competitor analysis). At Sipios, this is not our first neobank, but we systematically carry out a complementary analysis in order to identify the differentiating elements of the product we are to launch. Here are a few examples of critical performances that are typically found in online banks:

• autonomy of users to provide the information and documents requested: this can be measured by the number of requests made to third parties (bankers, accountants, etc.)
• cost transparency: this can be measured by identifying where in the conversion funnel the full cost is presented to the customer

Identifying the functions that enable these performances to be achieved is a more traditional Product Management task: it involves defining the main product functions. On the other hand, having previously determined the critical performances allows us to make sure that we do not forget any major function and especially to eliminate unnecessary functions. Again, some examples of functions on online banks:

• Document collection
• Identity verification
• E-signature...

 

Make the technological choices to implement these functions

Participating in trade shows such as Money2020 allows us to identify all the technological options we can rely on to architect a digital product. For each function, we build a "Technology Decision Record" that will benchmark and compare :

• external solutions, often FinTechs offering APIs: these solutions have the advantage of being generally easier to integrate and offer a more fluid user experience
• internal solutions on which an existing player can rely: these solutions often have the advantage of being compliant with the constraints of the IT department but also of embedding data and customer knowledge stored in the information system
• an in-house build solution

It is then possible to compare these different solutions (typically 3 external solutions, 1 internal solution and the custom build option) based on critical performance. For example, we evaluate technologies that implement identity verification based on :

• Rejection rate
• Coverage of compatible identity documents
• Lead time for processing an identity verification

Being clear on these criteria allows you to ask the right questions to the players rather than getting caught up in demonstrations that often mask the real hard points for the technology brick.

A fictitious example of Technology Decision Record for the "Identity Verification" function

 

Pack this information with a product architecture diagram

Each of these "Technology Decision Records" facilitates decision making and synthesizes the product architecture in the form of a synthetic diagram that can live throughout the delivery phase of the digital product.

This diagram allows to visualize simply if the solution built is :

• Mostly an internal solution (IT bricks + custom development): this is a more secure solution where collaboration with the IT department is simpler, but where the time to market is generally longer
• An application relying essentially on an "all in one" player: this would be the case, for example, of an online bank or a neobank relying mainly on a solution such as TagPay (managing customer repositories, card management, accounting, etc.). One then benefits from an optimal time to market but one then often lacks flexibility which makes it more difficult to attack a niche customer segment with exotic critical performances.
• An "Open Banking" application based on a multitude of FinTech players. This provides a good time to market and excellent flexibility. On the other hand, this option generally requires investing in architecture robustness patterns: resilience to bug or scalability issues that can be encountered on each of the players on which you rely.

An example of a product architecture diagram on a credit granting platform

 

---

This 3-step method is strategic for making good products, but it requires regular monitoring of :

• Typical functions in the different areas of FinTech (payment, insurance, financing, asset management, etc.)
• The most efficient technologies of the moment to implement them.

 

Therefore... attend Money20/20 next year!