WHITE PAPER
09/2015
Connected Finance Reference Architecture
By Asanka Abeysinghe
VP, Solutions Architecture, WSO2
Table of Contents
With advances in technology, a customer's requirement is not just good customer service;
they're constantly looking for ways to easily interact with their respective banks on the go
and carry out all banking transactions online. Customers today want to feel empowered and
want to do things on their own, prompting banks to increasingly incorporate the concept of
self service for all banking requirements. Customers today are also opting for systems that
are socially connected as well as simple and useful.
On the other hand, while financial enterprises would aim to provide an efficient service
to their customers, they have their own technology challenges that need to be addressed
as well. In the long run, financial enterprises' ultimate goal would be to develop a nextgeneration
financial infrastructure that will seamlessly connect with all the backend systems
in place and in turn, offer value added services to customers.
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.
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.
Figure 03
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.
Monitoring - Gateway Pattern
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
Enterprise Cloud Platform
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
6. Conclusion
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.
For more details about our solutions or to discuss a specific requirement
