Digital Experience to Master Data Management , Data Quality, Human Capital Contingent Labor
Background:
Customer is a major Commercial Lending and Leasing company and has recently become a SIFI company (Systemically Important Financial Institution) thru M&A. This makes the Customer to go through rigorous Audit process by the Feds and has to evaluate all its Commercial customers for Risk Exposure and submit Feds the CCAR report (Comprehensive Capital Analysis and Review).
MDM process:
Legal Entity Identification (LEI) is one of the key process to be compliant with Banking regulations such as BASEL II by the BCBS. Dun and Bradstreet (DnB) is an authoritative source on providing Legal entities across the Globe identified by a Unique number called D-U-N-S. Customer consolidates their commercial customers from all of its Receivable systems using Informatica MDM and enrich them with the DUNS information. The MDM datamodel captures the below information
- Counter Party
- Party Location
- Party DNB
- Party hierarchy
- Party Phone
At the detail level, they have 25+ Receivable systems which are pulled into MDM consolidation process on a Monthly basis. The Consolidated Receivable customers are then enriched with D&B data like DUNS number and the hierarchy data. The DUNS hierarchy has 3 relationship types viz Global Ultimate, Domestic Ultimate and HQ/Parent. Using these relationships the tree hierarchy of the Legal entities are created in MDM. The DUNS records can be purchased using the DnB APIs namely “Find Company Cleanse Match” and “Get Company Details”. The MDM process enriches the Customer data with DUNS information every time a new receivable record is added to MDM. There could be updates to the DUNS information like Name, Address and also to the Hierarchy which should be refreshed using the Bi-annual DnB refresh contract. This is a flat-file extract from DnB website.
DnB purchase and refresh process:
DnB API calls are encapsulated into a Composite Webservices that also uses the SIF framework to read-write MDM data. DNB is the most trusted system in MDM implementation and hence survives over the other Receivable records. DUNS records that have a confident score of 8+ is merged into Receivable records thru Automerge rules and the ones with Confidence scores 6 & 7 are sent to Datasteward queue for Manual merge. And at any given ROWID_OBJECT there should be only 1 DUN record in its XREF table. That way each Legal entity is uniquely maintained.
DUNS refresh is a bi-annual contract thru which the DUNS name, address and the Hierarchy information should be updated. A separate set of Staging tables and mappings are designed to capture this refresh records into MDM. For every Unique DUNS the data are updated. And the DUNS number that are obsoleted would be soft-deleted and maybe replaced with new DUNS number.
Managed Hierarchy:
DataStewards know their Customer better than the DNB and hence they would be amending few records correcting the DNB hierarchy or supply new hierarchy where DNB doesn’t have it. This has 2 relationship types viz, Bank Ownership and Bank Operational hierarchy. Combo of both the DNB and Customer’s hierarchy serves to complete its Legal tree structure.
Data consumers:
As mentioned initially, the uniquely identified “Legal Entity Identifiers (LEI)” are then fed into RiskOriginsTM and CCAR. RiskOrigins software (from Moody’s Analytics) is a credit decisioning and credit monitoring solution that allows banks to simplify the underwriting process across their operations. The Golden record and the Hierarchy data are consumed by RiskOrigins and CCAR. Each receivable record is identified with an Ultimate parent from top of its hierarchy tree and sent to these systems.