FSC - Financial Modelling - Financial Accounts

In the first blog of the series, we gave an introduction to Salesforce Financial Services Cloud (FSC) and touched upon the extensions that come with it. In this blog we discuss Financial Modelling and in particular, Financial Accounts.

In Financial Services, the customer relationship is primarily defined by the products and/or services that an individual (or household, but more on them another time) holds with a given financial institution. Salesforce’s Financial Services Cloud allows us to model all the products a customer is associated with (loans, investments, policies etc).

In this section we will cover Financial Accounts, Financial Account Roles, Financial Account Transactions, Charges & Fees, Billing statement, Revenues, Securities, Financial Holding and the corresponding set of components.  It won’t cover the mortgage and insurance related aspects in any detail as these will be covered in the future.

Language – US and Wealth centric

Financial Accounts is where we start to see the origins of FSC in the US and the wealth market come to the fore. The terminology and language used as standard does not reflect the conventions of retail banking outside North America, and of course as FSC is a managed package, some of these you are simply stuck with. This theme recurs across FSC and although in some ways quite cosmetic in itself, it is symptomatic in the overall slant, whereas in other areas (particularly Mortgages) the impact is more significant in what comes straight out of the box in the UK and other countries. As a very simple example here is the list of values from the FinancialAccountType__c field:

The customer’s products

The primary purpose of Financial Accounts is to provide a clear view of what products the customer has a relationship with (and in the wealth space this goes far beyond simply owning a product), the types of product, the value of those products (to both the customer and the financial institution) and the activity on those accounts.  This further enables a full picture of the customer’s financial position to be created and monitored.  Salesforce uses a single fairly extensive object to model financial accounts (rather than split into different objects for different products, or different families of products) – although Insurance Policy is the exception to this rule perhaps reflecting how much deeper the Insurance side of FSC is.  A single object means rolling up to a Household/Group level is simplified, and calculating overall net/debit positions is also straight forward.

Interestingly, products held with a financial institution are held on the same object as those that are not i.e. if this Salesforce instance is for Bank X and they have product Y, we are also recording that this customer has product A with Bank B.  These are differentiated (out of the box) by a “Held Away” marker.

This is interesting because every financial institution will have incumbent account opening systems (probably multiple based on the product family i.e. loans, current accounts, credit cards etc) and Salesforce will not be originating those products.  So users will need to be given Create rights to allow them to record those products held away, but we wouldn’t want them to be able to create products held by the company they work for -these would be fed in and have an External ID associated with them.  There are some obvious ways around this (record types of course) but each instance may have its own unique challenges in this space. In the UK there is also the possibility of leveraging the Open Banking APIs (gaining the relevant customer consent not withstanding) in order to automatically feed-in those held away products.

It also raises the topic for next time – account origination and opening, the ability to connect Leads/Opportunities to Financial Accounts and how Life Events/Financial Goals interconnect into these processes.