MuleSoft Accelerator for Financial Services

Jumpstart your bank modernization initiatives and simplify the delivery of Customer 360 initiatives by unlocking your Jack Henry SilverLake Core.

Consumer expectations of what makes for a great experience has changed over time. Today, most consumers expect uncomplicated, intuitive processes that make their lives easier. This use case leverages MuleSoft’s API-led approach to enable banks and credit unions to easily unlock data from their Jack Henry SilverLake core and enable real-time relationship management and connected experiences. Ultimately, data within the core systems can be exposed and made easily accessible across the organization to support the delivery of a financial ecosystem that meets consumers’ expectations for personalized experiences.

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

Description

This use case leverages a Jack Henry Core Banking system, jXchange, which is a single, real-time interface between JHA products and consuming channels, and Salesforce Financial Services Cloud as the system of engagement. The APIs and templates 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.

While the provided assets are architected based off of Salesforce Financial Services Cloud, customers can make use of the solution to integrate with other similar systems in their environments. There are two views supported in this solution:

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

Glossary

Solution overview

Banks need the ability to unlock their core in order to support digital transformation efforts, as well as support partnerships with external third parties to provide new and innovative offerings. This solution delivers an expanded view into a customer's financial account information, including profile data and transactions, using a new system of record in JHA SilverLake. The solution will leverage JHA SilverLake's retail banking core as the source system for all data used in this use case. The SilverLake data objects will be mapped to CIM data objects.

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

• Provide a core banking solution that connects FSC and JHA SilverLake, targeted to credit unions and small to medium-sized banks.
• Sync customer, account, and transaction data objects between FSC and JHA SilverLake.
• Provide support for opening Demand Deposit accounts, such as checking, savings, and money market, associated with a customer.
• Connect FSC to JHA SilverLake in near real-time.
• Provide support to modify a customer's primary address.
• Provide support for closing an account.
• Enable a dormant account to be activated.
• Provide the ability for customers to dispute potentially fraudulent transactions.

Use case considerations

• Must support syncing data between FSC and JHA SilverLake.
• Must support customer onboarding and account opening.
• Must support customer Address modification (Customer 360).
• JHA SilverLake will represent the system of record for financial data.
• Must leverage JHA SilverLake as the backend via jXchange and Salesforce’s FSC.

Technical considerations

• The CIM libraries will be expanded to include support for document images.
• The following applications will be leveraged for this solution: FSC, Core Banking System (Jack Henry SilverLake), and Global Data (generic).

Assumptions and constraints

1. A generic 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 the Unlocking the Jack Henry SilverLake core 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 SilverLake

This activity diagram describes the process of synchronizing updates made to customers in the SilverLake Core Banking System to downstream systems (depicted as Other Sync Targets). Since the Jack Henry Enterprise Event System (EES) only publishes the identifiers of customers that have been created or updated, we must first look them up in SilverLake to retrieve the latest details. Note that Global identifiers are not being written back to SilverLake at this time.

• 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

This activity diagram describes the process of synchronizing updates made to customers in Salesforce Financial Services Cloud to downstream systems, including JHA SilverLake.

• 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 SilverLake

The following activity diagram describes the process of synchronizing updates made to financial data (including accounts, transactions, and cards) in SilverLake to downstream systems. While the diagram only shows the process for Financial Accounts the steps are effectively the same for Financial Cards and Transactions, only the finer details of the upserts made to target systems have variations.

• 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 data sync from FSC

This activity diagram describes the process of synchronizing updates made to financial data (including accounts and transactions) in Salesforce Financial Services Cloud to downstream systems. Again, 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).

Systems involved

• Jack Henry (JHA) SilverLake
• Global Data (generic)
• Salesforce Financial Services Cloud (FSC)

---

back to top

Core banking foundation views

Customer view

End-to-end scenario

1. A new customer goes to a bank branch to open a checking account.
2. The customer does not have an existing account, so they provide the CSR with the relevant PII (i.e., name, email address, mailing address, phone number, etc.) to create the account.
3. The customer now has a checking account.
4. A week later, the customer wants to update their email address.
5. The customer calls the bank and provides their new email address to the CSR, who makes the change in the system.
6. A few months later, the customer's account status is changed to "Dormant" due to inactivity.
7. The customer is notified of their account's status and decides they want to keep the account.
8. The customer calls the bank and has the account reactivated.
9. One week later, the customer decides they no longer want to keep the account.
10. The customer contacts the bank to close the account.

Workflow

This view allows customers to:

• Open an account.
• Change account data.
• Request to have a dormant account reactivated.
• Close an account.

Successful outcome

1. Customer visits a bank branch to open an account.
2. Customer changes their account details over the phone.
3. Customer requests to have a dormant account reactivated.
4. Customer requests to close their account.

---

back to top

Customer service representative view

End-to-end scenario

1. A new customer visits the bank branch to open a new checking account.
2. The CSR begins the process of creating a new customer checking account by opening FSC.
3. Because FSC and JHA SilverLake are in-sync, the CSR first confirms the customer is new and does not have an existing account.
4. Once the CSR has verified the customer does not have an existing account, the CSR enters the relevant information for the new customer data (such as name, email address, mailing address, and phone number) and submits the data.
5. Once the customer is created, the CSR navigates to the FSC account opening page, where the CSR opens the new account.
6. The CSR submits the newly opened account, and the new account is updated in JHA SilverLake.
7. A week later, the CSR is contacted by the customer to update their mailing address.
8. The CSR opens FSC to modify the mailing address, and the change is synced to JHA SilverLake.
9. A few months later, the customer's account status changes to "Dormant" due to inactivity.
10. The CSR is called by the customer to reactivate the account.
11. The CSR updates the account status, and the status change is synced to JHA SilverLake.
12. A week later, the customer calls the CSR and requests to have the account closed.
13. The CSR opens FSC to close the account.
14. The CSR submits the account closure, and the closure is synced to JHA SilverLake.

Workflow

This view allows CSRs to:

• Onboard new customer.
• Open an account.
• Change account data.
• Reactivate a dormant account.
• Close an account.

Successful outcome

1. CSR logs into FSC to open an account for a new customer, which is synced to JHA SilverLake.
2. CSR changes customer data in FSC, and the change is synced to JHA SilverLake.
3. CSR reactivates a customer's account status from a "Dormant" status, and the change is synced to JHA SilverLake.
4. CSR closes an account, and the change is synced to JHA SilverLake.

---

Downloadable assets

FINS System APIs

• Salesforce Financial System API | API Specification | Implementation Template
• SilverLake Accounts System API | API Specification | Implementation Template
• SilverLake Customers System API | API Specification | Implementation Template
• Synergy Documents System API | API Specification | Implementation Template

FINS Process APIs

• Bank Accounts Process API | API Specification | Implementation Template

FINS Experience APIs

• Salesforce Financial Experience API | API Specification | Implementation Template
• Jack Henry Events Experience API | | Implementation Template

Custom components

• Cloud Information Model for MuleSoft Accelerators
• Accelerator Common Core | Source
• Accelerator POM Parent | Source
• FINS Common Resources | 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 Customers Process 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 Salesforce Customers System API | API Specification | Implementation Template

• Accelerator Salesforce Party Event Listener | Implementation Template

• Accelerator Salesforce Financial Account Event Listener | Implementation Template

---

back to top