Connected Finance Reference Architecture

Mobility - Today many people use mobile and smart devices to carry out their financial activities. Hence, all data and systems should be able to facilitate this requirement.

Location - Customers today deal with different financial institutes and do this on the move as well. Therefore, they need to be able to access their data from wherever they might be.

Connectivity - Based on the location and need, customers might use different financial institutions. Hence, these institutions should be able to communicate with each other and share information; therefore, connectivity between these institutions is key.

Social - Social features are required with financial applications and are becoming increasingly popular in this domain, e.g. technology today allows you to take a picture of a cheque, upload, and deposit it in your account.

Virtual payments - This has been increasing and all backend systems should be able to support old virtual payment systems as well as the current ones coming into the market today.

Mobile payments - A mobile payment ecosystem is not simple and has to integrate with many systems as well as be secure due to the sensitive nature of the business. Most people use this function for their financial transactions, hence financial systems should be able to support current mobile systems (including devices and sensors) as well as new systems that will enter the market in the future as well.

To address the challenges explained above, your enterprise would need to be able to connect everything to a central ecosystem to facilitate a real-time system as opposed to a batch-mode one that was prevalent in the old world architecture. To this end, your enterprise would require a next-generation financial infrastructure, as depicted in Figure 1, that will connect all backend systems. These would typically include day-to-day operations like HR and CRM systems and financial-related applications that come from the old world as well as many new systems that would eventually be included. There are also various business user needs, such as dashboards and reports, which would require you to pull out data from the current repositories and provide these in a format that would meet business user requirements; such requirements would include reporting, monitoring, managing, etc. Another key feature is a bigdata store with different types of data formats that come from the old world as well as new applications, hence the enterprise would need some sort of master data management as well as ETL-type solutions built on top of the data that's available. Moreover, the infrastructure would need to include regular, day-to-day functionalities as well as call center-type functionalities, virtual payments, credit card payments, payment gateways, etc.

Figure 01

Source: https://www.teradata.com

The first step in this direction is to connect everything in different systems, thus connectivity is crucial in building your next-gen finance architecture. There are many key backend components that need to be seamlessly connected:

Services and APIs - In terms of services and APIs, in the modern world, services are implemented and APIs makeup the consumable unit; therefore, enterprises would typically expose all back-end functionalities as a service and then services are exposed as APIs.

Financial protocols - There are many financial protocols that your connectivity or the integration should be able to support, e.g. as in the diagram shown in Figure 2, the integration layer should be able to support common protocols, such as (Financial Information eXchange) FIX and subsets of this like FpML and FIXML. Although most backend systems work with financial protocols, modern application systems that you would bring in would use open standards like HTTP, JMS, MQP, MQTT, etc.

Figure 02

Bridging financial protocols with open protocols - You can describe which parts of your financial message or protocol bridges into the open standard (SOAP, REST, etc.) and do the conversion. Figure 2 illustrates an example of converting FIX to HTTP and Figure 3 shows another use case of how FIX can be converted into AMQP for instance, which has become a popular protocol in the financial sector today.

Bridging security - Your enterprise might be using different security standards, therefore you would need to bridge security between these different systems, e.g. backend systems might be secured using Kerberos and the frontend might be using an OAuth or SAML type of security.

Cloud connectors - There are many cloud applications that support business functionalities, including those in the financial sector. Therefore, your internal systems need to connect to the cloud via a set of cloud connectors. Given that the financial industry is a highly regulated one, there might be limitations on how much data you can move to the cloud and some data may need to be maintained in local data centers. In such situations, it's useful to use a hybrid deployment where some processes and data are run in your data centers and some are moved to the cloud with proper processes for those architectures; you would then need to bridge the cloud and data centers using a secure channel. of security.

Secured connectivity - All connectivity needs to be secured via a proper way of securing and then sharing messages across systems due to the sensitive nature of the industry of security.

Support patterns - Integration is primarily built on top of enterprise integration patterns and message exchange patterns; therefore, any technology or architecture should be able to support integration as well as message exchange patterns, such as request/response or publish/subscribe type of message exchange patterns.

Routing - You might need to route messages and this can be header-based as well as payload or message-based routing as well. You can also use different rule sets in the integration to enable static or dynamic routing too, e.g. as illustrated in Figure 4, based on the symbol, a message will be communicated to the trading floors. Likewise, it can be in the form of a header or a value in the message body as well.

Figure 04

Unification - You might be communicating using a specific financial protocol version, but internally be using a different protocol. Therefore, you would need some sort of mediation to bridge the different versions as shown in the example in Figure 5. To this end, it's useful to have a unification internally and plug in different versions externally to enable communication.

Figure 05

Event-driven architecture (EDA) is very useful in the financial sector given the time sensitive nature of the industry and because all transactions are carried out real-time. EDA started out with publish/subscribe and the architecture was enhanced to an event-driven one, thus acting as a hub for multiple systems and thereby enabling updates to different aspects of information in a given entity. It allows an enterprise to have a proper looselycoupled architecture as well as a connectivity layer that you can change based on the dynamics of your business.

Figure 06

The example in Figure 6 is an illustration of how the WSO2 platform supports EDA; this example uses symbols as the topics for subscriptions. Here, you can determine how you would want to rearrange your topics because everything is loosely coupled based on the subscription. This enables you to create your topic hierarchy on a daily basis and get subscribers to subscribe to events they are interested in; this way the processing of events are efficient as only the messages the subscribers are interested in will be accepted. Moreover, you can bring new systems into the existing one without any impact on others. A new system will come in and start subscribing to a set of messages and will start processing these; if you want to send these messages back to the system, it will send back to an existing topic, or create a new topic.

In terms of monitoring your connectivity, the gateway pattern (explained in Figure 7) is an advantage as it requires every transaction to flow through the same layer, e.g. you have different systems and subsystems in two sections as well as different protocols; these would be connected by the mediation layer, which can use routing, smart routing, transformation, and persist as well; the API manager would act as your gateway. The gateway pattern in this instance is particularly useful to monitor, manage, and govern financial transactions as these would go through the same gateway layer (i.e. gateway of gateways or cluster of gateways).

Figure 07

WSO2 provides a complete product stack that fits well into a reference model of a connected finance architecture. Figure 8 depicts how modern business requirements map into a connected finance reference architecture. This diagram shows a data layer and the identity layers and many financial clouds, where you could use WSO2 Private PaaS and the dashboards. WSO2 User Engagement Server can be used to build all your analytics needs; the statistics and data that you store can be processed real-time and near real-time using WSO2 Data Analytics Server. WSO2 Message Broker will be your message hub that supports all financial protocols according to your business needs. Workflow processes are handled by WSO2 Business Process Server. The data layer is integrated using WSO2 DSS and WSO2 Applications Server can be used to write services using different service standards. You can expose your financial APIs using WSO2 API Manager and WSO2 ESB will act as the core integration component in this architecture.The WSO2 middleware platform also supports certain standards that govern the insurance industry (a sub-sector of the financial industry space) developed by the Association for Cooperative Operations Research and Development, the global industry’s nonprofit standards developer. ACORD develops and maintains standards for electronic exchange of insurance data between trading partners; these standards are widely used within the US as well as across other countries.

Figure 08

WSO2 offers a complete cloud architecture; Cloud today has become a necessity and you can build a cloud using WSO2’s cloud platform that’s offered as a private PaaS or the public cloud. As explained in a previous section, for the financial industry, a public cloud deployment might not be an ideal option given the nature of the industry. Hence, the private cloud running in a local data center or a private cloud hosted in a public hosting place might be the more suitable options. Thus, given the tight regulations in the financial industry, a hybrid deployment pattern (as shown in Figure 9) would be useful where you would run some processes in your data center and move some of them to the cloud and bridge these via a secured channel.

Figure 09

To be able to meet customer as well as internal requirements, financial industry players should adopt a system that’s made up of a series of smaller systems that’s easy to manage, scale, and maintain. The industry, requirements, consumer space, competition, and regulations are constantly changing and industry players need to adopt a platform that’s lean and flexible. WSO2 offers a complete platform that implements the standard and provides the components and toolkits required to build a connected business.

The WSO2 platform allows you to support systems running both internally and externally without having to worry about including additional components. WSO2 doesn’t just offer an ESB or API manager, rather a complete data to screen platform. WSO2 can complete your integration story and help you become a connected business through its platform and through collaboration with providers, delivery channels and your partners, cloud offerings, and in-house legacy applications.