The glaringly average record on regulatory compliance front is beginning to be bugbear for banks. While the big banks usually are well equipped to take the onslaught of the ever changing regulatory regimes, it is the mid and small tier banks that get caught unawares and unprepared. Regulatory conformity is more often seen to be the premise of the compliance desks and not broadly participative. Most of the banking applications RFPs / RFIs floated have little or no mention of the ability of vendor offering to be able to adapt to amendments in existing regulations or embrace new regulations.

Changing the orientation:

In this era of acute regulatory spotlight, track it real time, as it happens, is the new ethos and rightly so. While the banking paradigm is increasingly becoming real time, compliance is usually seen to be an after the fact activity. Studies have found cost of adherence is a lot lesser when checks and balances are built within the in-flight trajectory of transactions. This means ability to ensure that the data is accurately and holistically captured, monitoring probes are placed in the transaction frames to watch out for deviations.

Arrows that make the quiver:

A close study of different regulations reveals a common set of system requirements. Following section describes some best practice embedded system capabilities that banks prefer to see in mission critical platforms, in order to score well on regulations:

-          Data dynamism – Ability to continuously evolve the data model through a high configurable data dictionary that can be used to define new data elements required by a regulation. Data element repository needs to be able to adapt to the rigors of new and upcoming regulations. Creation of new data elements as well as the ability to maintain their attributes is an important requirement. For example the new same day ACH guideline published by NACHA refers to a threshold of USD 25000 for a payment to be eligible for SDA treatment. This amount threshold would need to be definable as say ‘SDA threshold’ and be made a part of the payments data model in order to be used in validating payments for same day ACH, both at ODFI’s end as well as the RDFI. The payment platform used by both these banks would be served well if it carried a data dictionary that facilitated evolution of the data universe for a business context.

-          Transaction template molding – This deals with an application’s ability to support incorporation of the newly created data elements in the data dictionary, onto existing transaction templates used by both the client and bank user groups to create transactions. All this done using minimally invasive techniques with immediacy of the changes in the data capture forms. Once a part of the transaction screen, enriched data capture is facilitated inline with the requirement of the regulation. It is said that once the data is created, it can be used for context building, subjected to scrutiny and reporting to regulatory bodies and external agencies. For example

• when DFA 1073 required banks to bring transparency in charges applicable on a payment request for host bank as well as the transit banks in a payment chain, many banks were paralyzed by the prospect of getting pricing data for self and the payment chain as well as the rendering of those the new data elements on existing screens.
• The need to associate a Legal Entity Identifier (LEI) with every client id was another task that flummoxed banks in terms of figuring out impact on existing client on-boarding screens

 -          Timely data submission is an important capability when it comes to regulatory reporting. Inadequate automation support to churn reports that respond to regulatory asks is very often a common ailment. Slow paced response to data requests is often associated with the perception of inadequacies in a bank’s system capabilities

-          Rule writing ability in a solution can take care of basic validations at the field level, cross field validations. New validations linked to existing data elements, changes to existing validations should be configurable through intuitive UI(s) associated with rule scripting. For example validating if a healthcare payment in the US, is within 3 business days of receiving a electronic remittance advice (ERA), at a simplistic level requires comparing effective entry date of the CCD SEC code based ACH with that of an EDI 820 based remittance advice for matching trace numbers (which is another rule)

-          A process map definition component allows the control of the flow of client on-boarding, transaction related work items. Introduction of additional manual stages for additional scrutiny of exception items takes a solution closer to better regulatory adaptability. For instance, Travel Rule for filtering of ultimate originator and ultimate beneficiary for cross border payments requires conditional checks (mostly manual), to be enforced by intermediary banks in a payment chain. A process modeler facilitates changes to existing business flows with rule based routing of payments through extra hops for interdiction checks

 -          Using a format designer new data extract layouts as well as for input of new data upload formats can be configured making regulatory reporting much easy. Some examples being SAR filing, FINTRAC extracts of cross border payments sent / received from or into Canada, filing of CTRs, using a strong formatter component reduced the compliance time frames for many banks just for the extract design part of the requirement.

-          Most compliance activity requires timely notifications that can draw the attention of the compliance desk to side stepping of regulatory guidelines in regular operations. Such notification components feed off of granular business exceptions library that banks can use to define triggers for alerts.

-          Regulatory risk visualization is increasingly allowing banks to make ‘easy to understand’ data presentation, all pervasive and in real time. Availability of dashboards with real time updated color coded RAGs status lends to stream lined monitoring of regulatory norms. The dashboards are created using the feed from monitoring probes that sniff breach of bank defined SLAs. For example the payment flows with more than acceptable levels of cases, defined as a count based threshold of cases in a day, week or a month, related sanctions screening, can sound off early alarms that can bring attention to errant ordering customer or counterparty profiles.

-          Executive dashboards that specifically focus on compliance efficiency through the display of count of regulatory violations represented as tickets that are automatically created from base monitoring of transactions as they occur and as they are routed through the compliance desks. Thus, while these tickets are being investigated and resolved by the in-house regulatory inspection teams, a parallel feed of violations ticket summary keeps the Senior Management abreast of real time happenings right from the channels and front office or the factory or anywhere else in the transaction workflow leading up to the end point.

The shift to a superior compliance infrastructure that rides on top-of-the- line system capabilities delivers on efficiency and saved costs and is seen to ably support banks in taking the challenge of regulatory compliance head on.