Posted by infotrellis on Monday, Aug 8, 2016 @ 7:04 AM

Banking Regulations

Banking Regulations – Overview

Managing regulatory issues and risk has never been so complex. Regulatory expectations continue to rise with increased emphasis on the institution’s ability to respond to the next potential crisis.Financial Institutionscontinue to face challenges implementing a comprehensive enterprise-wide governance program that meets all current and futureregulatory expectations. There has been a phenomenal rise in expectations related to data quality, risk analytics and regulatory reporting.

Following are some of the US regulations that MDM and customer 360 reports can be used for compliance:

FATCA (Foreign Account Tax Compliance Act)

FATCA was enacted to target non-compliance by U.S. taxpayers using foreign accounts. The objective of FATCA is the reporting of foreign financial assets. The ability to align all key stakeholders, including operations, technology, risk, legal, and tax, is critical to successfully comply with FATCA.

OFAC (Office of Foreign Asset Control)

The Office of Foreign Assets Control (OFAC) administers a series of laws that impose economic sanctions against hostile targets to further U.S. foreign policy and national security objectives. The bank regulatory agencies should cooperate in ensuring financial institutions comply with the Regulations.

FACTA (Fair and Accurate Credit Transactions Act)

Its primary purpose is to reduce the risk of identity theft by regulating how consumer account information (such as Social Security numbers) is handled.

HMDA (Home Mortgage Disclosure Act)

This Act requires financial institutions to provide mortgage data to the public. HMDA data is used to identify probable housing discrimination in various ways.

Dodd Frank Regulations

The primary goal of the Dodd-Frank Wall Street Reform and Consumer Protection Act was to increase financial stability. This law places major regulations in the financial industry.

Basel III

A wide sweeping international set of regulations that many US banks must adhere to is Basel III. Basel III is a comprehensive set of reform measures, developed by the Basel Committee on Banking Supervision, to strengthen the regulation, supervision and risk management of the banking sector.

What do banks need to meet regulatory requirements?

To meet the regulatory requirements described in the previous section, Banks need an integrated systems environment that addresses requirements such as Enterprise-wide data access, single source of truth for customer details, customer identification programs, data auditability & traceability, customer data synchronization across multiple heterogeneous operational systems, ongoing data governance, risk and compliance reports.

How MDM can help?

master data management

Enterprise view of customer data

MDM solutions providean enterprise view of all customer data to ensure that a customer is in compliance with Government imposed regulations (e.g. FATCA, Basel II/III, Dodd Frank, HMDA, OFAC, AML etc.) and facilitate data linking for easy access.

Compliance Users

Users who satisfy the compliance criteriawill be able to retrieve the customer information such as name, address, contact method and demographics from the MDMsolution. They will be able to ensure customer compliance while creating reports, performing reviews and monitor the customer against watch lists.

Compliance Applications

FATCA supporting applications, Dodd Frank reporting applications, HMDA compliance reporting applications, Basel II & III compliance applications receive a data extract from the MDM solution containing detailed customer information such as name, addresses, contact methods, identifiers, demographics and customer to account relationships that enhance compliance reporting and customer analytics.

Compliance users can ensure compliance with all FATCA laws, create reports, link customer information to create HMDA reports and provide complete financial profile of all commercial customers to ensure compliance with Basel II & III regulations

Regulatory Risk Users

Regulatory risk users will be able to use customer data from MDM solution, create reports on an ad hoc basis, and perform annual reviews to ensure customer is compliant with risk regulations. These users will also be able to check if customers are on existing watch lists through pre-configured alerts and update the MDM solution as required during annual reviews.

Regulatory Risk Applications

MDM solution supplies detailed customer information such as name, addresses, identifiers, demographics, and customer to account relationships to Applications supporting AML, OFAC data, KYC, fraud analysis so that they can determine compliance to regulations such as AML. OFAC standards, determine if the proper KYC data has been captured for all customers and monitors fraudulent activities of any customer.

MDM solution will receive a close account transaction from the AML applications if the regulatory risk user determines the customer relationship must be exited for AML non-compliance.OFAC applications update customer’s watch list status within the MDM solution and send add/update/delete customer alert transactions to monitor customers on OFAC watch lists.


MDM solutions when implemented properly, can provide critical information to banks who have to comply with a number of regulations across many countries. At InfoTrellis, we have helped many organizations achieve these goals through IBM MDM implementations. You can contact us for further queries by sending an email to

 About the Author

Greg Pierce

Greg is a Senior MDM Business Architect at InfoTrellis. He has helped many clients across banking, insurance and retail clients actualize value out of their MDM investments.

Topics: Banking RegulationsX data lake for banking Data Management Consulting Services IBM MDM Master Data Management Master data management Banking Regulations master data management tools

Leave a Reply

Your email address will not be published. Required fields are marked *

Posted by Kevin Wright on Friday, Dec 11, 2015 @ 12:00 AM

With the introduction of IBM Master Data Management v11, IBM has created a new implementation style combining the strengths of both MDM Physical and Virtual editions. While MDM Physical is more suited to the “centralized” MDM style (system of record), and MDM Virtual is aligned with the “registry” MDM style (system of reference), MDM Hybrid uses a “coexistence” style to provide a mixed system of reference & record. This article will give an overview of the MDM Hybrid implementation style and a couple of interesting lessons learned during a recent InfoTrellis engagement.

MDM Hybrid was first introduced in MDM v11.0 in June 2013 to leverage capabilities of both MDM Virtual and MDM Physical which themselves have grown considerably in capability in recent years. However, MDM Hybrid is still not yet mainstream due to a handful of reasons. One, it does represent a relative increase in complexity and requires practitioners competent in both MDM Virtual and MDM Physical. Two, it can be a difficult migration from an existing MDM Physical or MDM Virtual implementation (although the transition from virtual to hybrid is the easier of the two). Hopefully this article can help alleviate some of those concerns! We at InfoTrellis believe that MDM Hybrid is a strong offering that gives us the capability to have both Virtual MDM and Physical MDM in the same box – the best of both worlds. Additionally, MDM Hybrid is excellent for new MDM implementations, and can be implemented relatively quickly in a basic manner. IBM has also provided a detailed implementation path in its Knowledge Center (see link below).

When describing MDM Hybrid to clients, I have been couching it in terms of a “Virtual Side” and a “Physical Side”, as the product is still mostly segregated.   Between the two “sides” is a fence traversed by a physical MDM service. This MDM service, persistEntity, is one of the workhorses of any MDM Virtual implementation and will be the focus of much of the customization.

Member records (source data) are contained in the MDM Virtual side, processed through the powerful probabilistic matching process that MDM Virtual provides, and assembled into a “golden record” composite view that is then mapped into the MDM Physical schema and “thrown over the fence” to the MDM Physical side using the persistEntity service. The “golden record” is persisted on the physical side. Physical MDM services such as addParty and updateParty are disabled, and modifications to attributes mastered by the MDM Virtual side are not permitted. Other attributes, however, can be modified. For example, name types not in the golden record, privacy preferences, and product or contract data can be modified using standard Physical MDM services.

Special care needs to be taken when implementing the other MDM domains such as contract or product. The persistEntity service could initiate a call to deleteParty if the golden record no longer exists in the system – this could cause issues if there are Contract Roles or Party Product Roles. And how would one establish these in the first place? InfoTrellis recently implemented MDM hybrid with both the party and contract domains at a client, and we came away with some interesting lessons in how to accomplish this.

At our client, a large insurance corporation, we were charged with implementing MDM Hybrid using version 11.3 and using the Contract domain as well as the Party domain with both Persons and Orgs. While we implemented many pieces of the contract domain, this discussion will be simplified to contain the entities and attributes below.


Figure 1. Simplified Logical Data Model.

This new MDM solution would be fed by both web services and batch loads (initial and regular delta loads). We decided early on to use the MDM Physical type of services as the entry point for MDM. This was for a couple of reasons. First, I think the MDM Physical schema presents a much simpler and more intuitive structure to consumers (primarily web services). Second, and perhaps more importantly, the Physical MDM schema already had all the contract objects defined.

For those reasons and others, we created a composite service to handle both party and contract data from an external perspective. This maintainContract service handled adding or updating a contract & contract component, and sending the party to the MDM Virtual Side (“Tossing it over the fence”) via memput. When the golden record came back via persistEntity, the contract role was handled via another custom service – maintainContractRole. This required the customization of the PartyMaintenanceActionRule (#211). Since the golden record processing is an asynchronous operation, the service only handled the contract, contract component, and call (or calls) to memput before returning.


Figure 2. Process Flow for customized PartyMaintenanceActionRule (#211).

In order to maintain contract role data, we had to create a “backpack” (and I’m sorry for the number of metaphors here – it helped us to explain this process to the client and has stuck in my mind as a method of explanation). This backpack would contain all the data needed to establish a contract role in Physical MDM and would accompany a party as it was processed by Virtual MDM and then get picked up by the persistEntity call on the round trip back into Physical MDM. On the virtual side, this data would not be used for searching or matching. On the Physical side, we had to create a transient data object (TDO) that would be mapped using the graphical data mapper (GDM) included in the workbench. This TDO is the backpack in the metaphor. Also, it needed to be added as an extension object under the TCRMOrganizationBObj & TCRMPersonBObj.

I hope this overview of the MDM Hybrid system has been informative. Unfortunately, as I wrote it, I noticed a number of components that I left out in the interest of giving a (hopefully) better overview of the case study without droning on for 20 pages. These include – handling role locations, customizing deleteParty, modifying the Virtual algorithm, constructing the composite view, and the framework we constructed to interface between Physical and Virtual MDM. We can dive deeper into those topics in a future article.

MDM Hybrid provides a number of exciting new functionalities, and with the flexibility inherent in the IBM MDM product, there remain many unexplored avenues and even ways of doing the same thing. Between MDM Virtual, MDM Physical, and now MDM Hybrid there’s no excuse to avoid creating a Master Data Management solution in your organization. If you’re considering an MDM Hybrid implementation (Or any other IBM MDM solution), give us a call!


Topics: Hybrid IBM MDM mdm MDM 11 Use Cases

Leave a Reply

Your email address will not be published. Required fields are marked *