Credit, Collections & Insolvency News
Does your business run on several collections systems? Do you have multiple product lines that have developed multiple collections strands?
You are not alone, many tier-one banks, financial services companies and BPO’s do so as well. They have evolved within Financial Services through product-led sales such as mortgages, credit cards, loans, overdrafts, or risk-related products, some of which require specialised collections, and some have been built through acquisition/merger so use different reference numbers and data structures.
It doesn’t stop there. We’re all aware that central government agencies, such as HMRC, DWP and the DVLA don’t share data. Within most of those agencies however, there are multiple strands of revenue recovery, all with separate departments that are also in the dark regarding the activity of the same customer. Local government has it’s challenges as well, being unable to view how other parts of their organisation are treating the same customer, such as rent arrears and council tax and even the existence of a Court of Protection Order.
Worse still, multiple agencies within the same organisation could also be unaware that their customer is experiencing a form of vulnerability. This may have been recorded by another department, but if not across the organisation, they are unable to employ the same level of consistent care.
Why don’t we share the same view?
Traditionally we have backed off trying to create a customer-centric view because as mentioned above, some products do require specialised treatment, but that does not mean that we should be unaware of how they are being treated or their condition. Another argument is that the customer may have some accounts in arrears with others up to date, but surely, we need to be able to see the full picture to treat that customer fairly. The first and last excuse for not incorporating customer-centric collections is that it is complex and expensive.
The difficulty is normally getting different systems with different data formats talking to each other. Different pieces of information, both with internal and external feeds presented in different ways have meant that we have backed away from the challenge of bringing them into a single view. The expense comes with the long lead development times forecasted by IT and the inevitable overruns to complete the multiple strands of coding required.
Most large organisations see the value of having one view of the customer should they experience financial difficulty. Some have even gone as far as to try and build that model in-house, but without the resources to overcome the integration challenges or specialised skills required to develop the requisite collections database schemas and other related functionality, many have failed.
How can we view the same customer?
Enabling a customer-centric view is dependent upon several key, and often complex, collection software design principles. First, a database schema and security model that supports ‘many to many’ relationships (e.g., one customer linked to multiple accounts, multiple customers linked to one account) and multiple product types is required. Explicit here is the ability to hold information on accounts that are not past due as well as those that are. Secondly, a software security model design that supports the display of all related accounts (whether to be actioned by the collection agent or not) such the agent can see, and if permitted by configuration rules, take action on all account relationships without further navigation (there are use cases where visibility of accounts for the same customer will not be permitted)
Another key requirement is for the information (e.g., balances, payment history, contact data, customer status and other updates) pertaining to the customer and the multiple accounts to be up to date. This requires sophisticated integration capabilities including management of real-time updates.
Over and above the complex software design requirements, knowledgeable and experienced software solution implementation consultants play an important role in overall configuration design to meet each client’s unique needs in this area.
What does Telrock’s Optimus solution provide in this area?
Optimus was designed from the ground up to meet the requirements of a customer-centric view. With a sophisticated database schema consisting of over 15,000 attributes, the solution is designed to manage any number of product and account types for the entire collections lifecycle. The database schema and security model design support the complexities of managing configurable ‘many to many’ relationships to meet each client’s unique needs.
Optimus’ Role Based Access Control (‘RBAC’) allows clients to configure via rules what data panels and data panel content they want agents to be able to see within the collector UI (the Optimus ‘Collector Workbench’) and which to act on. Specifically, as this relates to a customer view, this configurability enables clients to determine whether they want to display all customer relationships to agents based on the agents’ role, the product types, or the process that the accounts are being subject to.
As it relates to integration with other systems, e.g., product host systems, Optimus incorporates several key components including a standard suite of real-time inbound API’s that support real-time updates from host systems. If client host systems cannot support integration via real-time API’s, Optimus’ ‘Data Integrator’ component simplifies and removes the complexities historically associated with file-based integration. ‘Data Integrator’ has been structured such that a business analyst can quickly and easily map and test inbound and outbound files within minutes/hours without IT support. Optimus’ job scheduler can detect and process new inbound and outbound files based on client configuration, e.g., every minute, every ten minutes, every hour, every day etc.
Last, but not least, Optimus incorporates a further component, ‘SmartIntegration’, that enables business analysts to transform outbound Optimus created files to conform to client and third-party application published API’s and thus support real-time update of information to client host systems where immediacy of update is important. For example, if a consumer identifies themselves as vulnerable to a collection agent that status change in Optimus can be immediately notified to the client host(s).
For more information: Telephone: 07971 418914 or email: bruce.turnbull@telrock.com
About the Author: Following an executive management board role with an operating subsidiary of Lloyds Banking Group, Bruce Turnbull has spent the past 20 years providing collections management consultancy services to several blue-chip lending companies including Courts International, GE Capital and Provident Group.
More recently Bruce has served as Managing Director of two UK operating subsidiaries of CoreLogic, Inc. (NYSE: CLGX), a $3 billion-dollar global data, analytics, and related services company. Bruce is currently a Director of the Vulnerability Registration Service and provides business consultancy to Telrock Systems.
This article has been brought to you by Telrock, a global technology provider of SaaS-based on-demand collections software solutions that serves major lenders, processors, and BPOs across Europe, Asia & North America through their offices in London and Atlanta.