MuleSoft Accelerator for Financial Services

Core banking foundation enables a 360 view of your customer’s financial information. It delivers accurate account balance data and transaction history to enable your tellers and support representatives to effectively engage with customers.

Overview

• Description
• Glossary
• Solution overview
• Assumptions and constraints
• High-level architecture
• Processing views
• Systems involved

Core banking foundation views

• Customer view
• Customer service representative (CSR) view

See also

• Downloadable assets

This use case leverages a generic Core Banking system, with Salesforce Financial Services Cloud as the system of engagement. The APIs and templates enable you to accelerate time to value. Use the assets as they are, or extend them to suit the needs of your own organization. For example, you can reuse the APIs provided to expose data to additional channels, such as mobile applications, and consumers.

Description

The use case covered in this version of the solution allows for the display of a customer’s financial summary from multiple systems. There are two views supported in this solution:

1. Customer view
2. Customer Service Representative (CSR) view

Glossary

Solution overview

The purpose of this solution is to get a holistic view of the financial summary of the customer, either from a mobile application, a generic Core Banking system, or from Salesforce Financial Services Cloud. While the assets built for this solution will be relevant for many different banking and financial industries, we will focus specifically on Retail Banking to ensure we are building and testing against a set of real use cases.

Before you begin

The Getting Started with MuleSoft Accelerators guide provides general information on getting started with the accelerator components. This includes instructions on setting up your local workstation for configuring and deploying the applications.

Goals

• Support for viewing Demand Deposit accounts associated with a customer (e.g., savings and checking) from Core Banking and FSC.
• Support for viewing Credit Card and Bank Card information associated with a customer
• Support for managing controls and limits for Credit Cards and Bank Cards
• Full two-way synchronization of Customers, Accounts, Transactions, and Cards between multiple systems

Use case considerations

• Must support a comprehensive view of Accounts for a given customer.
• Must be able to retrieve transactions for a given account.
• Must provide support for a customer to dispute a transaction.
• A generic Core Banking system will represent the system of record for financial data.
• A Global Data service will provide the golden copy of the customer profile, along with account, transaction, and card information replicated from Core Banking.

Technical considerations

• Use CIM as the canonical model, where applicable (e.g., for Customers).
• A custom canonical model for financial accounts, transactions and cards has been created.

Assumptions and constraints

1. The Core Banking system must be polled to pick up changes to customer and account information.
2. The Credit Card system must be polled to pick up changes to credit card information.
3. The customer is only able to view the banking summary and credit card information.
4. A MariaDB database will be used as the back end for the generic systems.

High-level architecture

The following diagram represents the portion of the overall solution that pertains to this use case:

Processing views

The following diagrams illustrate the processing sequences for the integrations and data synchronization activities included in this release.

Customer profile management in Global Data

A Process API created specifically for managing customers in a generic Global Data solution was first published with Release 1.7. Since this process is reused as-is in different synchronization scenarios, a separate diagram has been created to provide a more detailed view of the activity.

• A Party can be either an Individual or an Organization in this scenario.

Customer update sync from Core Banking

The following activity diagram describes the process of synchronizing updates made to customers in the Core Banking System to downstream systems:

• Refer to the Customer profile management in Global Data diagram above for more details on the customer upsert process. For all other target systems, the upsert process consists of a lookup followed by a create or update request (not shown for clarity).

Customer update sync from FSC

The following activity diagram describes the process of synchronizing updates made to customers in Salesforce Financial Services Cloud to downstream systems:

• Refer to the Customer profile management in Global Data diagram above for more details on the global party upsert process. For all other target systems, the upsert process consists of a lookup followed by a create or update request (not shown for clarity).

Financial data management in Global Data

The management of financial accounts, transactions, and cards in Global Data follows a similar process as for customer profiles but is implemented in a separate Process API.

Financial accounts

The following diagram shows the activity flow for upserting financial accounts, which requires a lookup of the associated owners (customers):

Financial transactions

The process for upserting transactions is similar, except that the debit and credit accounts need to be looked up instead of customers (either or both, depending on the type of transaction).

Financial cards

Finally, the process to upsert financial cards is similar but requires an additional lookup of the customer as well (cards are owned by customers but associated with accounts):

Financial data sync from Core Banking

The following activity diagrams describes the process of synchronizing updates made to financial data in the Core Banking System to downstream systems. The Financial data management in Global Data diagram above has more details on the global financial account upsert process. For all other target systems, the upsert process consists of a lookup followed by a create or update request (not shown for clarity).

Financial account sync

Financial transaction sync

Financial card sync

Financial data sync from FSC

The following activity diagram describes the process of synchronizing updates made to financial accounts in Salesforce Financial Services Cloud to downstream systems. The diagram references Financial Accounts only but the process applies to all financial data entities.

• The Financial data management in Global Data diagram above has more details on the global financial account upsert process. For all other target systems, the upsert process consists of a lookup followed by a create or update request (not shown for clarity).

Scheduled and on-demand sync of specific entities

In addition to using schedulers to publish updates on a regular basis, the Core Banking Poller Process API also supports the on-demand synchronization of specific entities to ensure all downstream systems are up-to-date. These requests are processed in a synchronous fashion, similar to how the scheduled process works, and support any valid global or external identifier. The above diagrams therefore indicate where the flows start from the schedulers vs. synchronous requests, where appropriate.

Systems involved

• Core Banking System (generic)
• Credit Card System (generic)
• Global Data (generic)
• Salesforce Financial Services Cloud (FSC)

---

back to top

Core banking foundation views

Customer view

End-to-end scenario

• A customer logs into the Mobile App to check their balance and transaction history.
• The customer views their account information across multiple products from the Bank.
• The customer reviews transactions for an account and chooses to dispute one.
• The customer calls the Bank to talk to their Customer Service Representative.

Workflow

This view allows customers to:

• View their latest financial summary.
• Retrieve account transactions.
• Dispute a transaction.

Successful outcome

1. Customer logs into the Mobile App to check their balance and credits.
2. Customer selects an account to view transactions.
3. Customer can filter transactions by date, amounts, and check numbers.
4. Customer chooses to dispute a transaction.

---

back to top

Customer service representative view

End-to-end scenario

• The Customer Service Representative (CSR) pulls up the single view of the Customer from within the Financial Services Cloud.
• The CSR performs an action to sync the latest data from the underlying systems (including FIS, Credit Card System API).
• The CSR extracts information on the disputed transaction and discusses it with the customer.
• The CSR resolves the disputed transaction and ends the call.

Workflow

This view allows CSRs to:

• View the customer’s financial summary.
• Refresh the customer's financial information from back-end systems.
• Resolve a disputed transaction.

Successful outcome

1. CSR logs into FSC to lookup a particular customer.
2. CSR selects financial accounts to display financial summary for the customer including bank accounts and credit cards.
3. CSR chooses to refresh the information from back-end systems.
4. CSR views transactions for an account.
5. CSR resolves a disputed transaction and saves it.

---

Downloadable assets

FINS System APIs

• Core Banking Accounts System API | API Specification | Implementation Template
• Core Banking Customers System API | API Specification | Implementation Template
• Credit Card System API | API Specification | Implementation Template
• Salesforce Financial System API | API Specification | Implementation Template

FINS Process APIs

• Bank Accounts Process API | API Specification | Implementation Template
• Core Banking Poller Process API | API Specification | Implementation Template
• Credit Card Poller Process API | API Specification | Implementation Template

FINS Experience APIs

• Mobile Experience API | API Specification | Implementation Template
• Salesforce Financial Experience API | API Specification | Implementation Template

Custom components

• Cloud Information Model for MuleSoft Accelerators
• Accelerator Common Core | Source
• Accelerator POM Parent | Source
• FINS Common Resources | Source
• FINS Financial Account Sync Lightning Web Component | Source
• ID Graph Lightning Web Component | Source

Shared APIs (can be used across any use case)

• Accelerator MariaDB Global Financial Account System API | API Specification | Implementation Template

• Accelerator MariaDB Global Party System API | API Specification | Implementation Template

• Accelerator Global Financial Account Process API | API Specification | Implementation Template

• Accelerator Global Party Process API | API Specification | Implementation Template

• Accelerator Customers Process API | API Specification | Implementation Template

• Accelerator Salesforce Customers Experience API | API Specification | Implementation Template

• Accelerator Salesforce Customers System API | API Specification | Implementation Template

• Accelerator Salesforce Party Event Listener | Implementation Template

• Accelerator Salesforce Financial Accounts Event Listener | Implementation Template

---

back to top