Connecting...

W1siziisinrozw1lx2fzc2v0cy9uzxdzlw9ulwnvbxbsawfuy2uvanbnl2jhbm5lci1kzwzhdwx0lmpwzyjdxq

It's All About Relationships: A Cost-Effective Boost To Anti-Money Laundering Compliance

W1siziisijiwmtcvmdmvmzavmdcvmjkvndevntivyw1slwjsb2cxlmpwzyjdlfsiccisinrodw1iiiwindmwedmymfx1mdazyyjdxq

It's All About Relationships: A Cost-Effective Boost To Anti-Money Laundering Compliance

In a previous blog post, Forbes looked at the problems and inefficiencies (such as huge numbers of false positive alerts) inherent in the transaction monitoring systems (TMSs) used by financial institutions to detect money laundering and trading with sanctioned parties. Together with a data quality initiative, a relationship-based approach can complement a TMS and ease many of these issues (see the recent Forbes Insights report, sponsored by Pitney Bowes, “Don’t Blame the Transaction Monitoring Systems: How a Relationship-Based Approach Improves AML Compliance and Reduces Cost”).

But how does such a relationship-based approach work?

Where transaction monitoring systems take a fine-focus approach to identifying AML or sanctioned parties, and do it on a transaction-by-transaction basis, a relationship-based approach complements that with a much broader view.

It does this by bringing in other known and inferable information—some of it enriched by outside data sets—to contextualize transactions, the parties involved and their relationships, all with the aim of reducing the pile of false positives and easing investigations while increasing actual detection rates. Significantly, as the technology is more widely adopted, it is likely that regulators will begin to expect increased levels of detection from financial institutions.

A central component to the relationship-based program is a graph database. Where a traditional relational database stores information in separate tables and columns, requiring complicated code to join connected data and construct relationships, a graph database stores the information as “nodes” and “relationships.” For example, a customer might be expressed as a node, connected to other nodes, such as a business, by lines that express the nature of the relationship, whether it’s as employee, owner or something else.

That allows technology using graph databases to do a couple of useful things, such as identifying and grouping “like” alerts where a TMS would miss the relationship, such as where a John, J.M. and Johnathan Doe are the same person. Combined with a thorough data quality initiative, the graph database can resolve multiple transactions and accounts to the sole parties responsible. Graph databases help FIs achieve a reduction in false positive alerts, which will ultimately allow them to save on staffing and investigation costs as well as improve the quality of compliance overall.

Because a holistic view focuses on relationships, links can be found among accounts even in non-obvious ways, such as via IP address or with names that are close enough to likely be the same. That allows investigators to more easily identify rings of associated users. Together, these measures allow compliance officers to research groups of related transactions at one time, rather than having separate investigators looking at separate pieces; this ensures judgments based on that data are made in proper context.

Some takeaways and advice:

• The view you have is not necessarily the view you need. Linking the customer identities and relationships behind transactions can start to sound a lot like a “single view” of the customer — but that is typically the language of marketing, not compliance. That presents an issue when discussing the implementation of master data management projects, as the marketing “view” is not a sufficient one for compliance. Compliance teams should request more information if IT says it has the single view covered.

• Start with data, not a new TMS. The TMS is only as good as the data that goes into it. Before writing another RFP for a new TMS or case management tool, look for solutions that work with your systems to consolidate the entities behind the transactions, not more of the same.

• Test prospective solutions on your own data. Get any prospective vendor to test out their solution with your own data. Results should begin to be realized quickly, even if the entire solution takes longer to deploy.

• Look for transparency. You should be able to drill down into any alert and see why it was flagged. Not all monitoring and screening systems offer that kind of transparency, so look for solutions where the workings aren’t hidden in a black box.

Source: Forbes

By Pathay Singh on 03/30/17