Defining Entities for Better Risk Assessment

Revealing Hidden Risk
When providing financial products and services, banks need to understand who they are dealing with for risk assessment purposes. While this may seem obvious, it’s not as easy to achieve as it may appear. The Legal Entity Identifier (LEI) system put forth by SIFMA is a way to identify unique parties to financial transactions and is designed to be a building block for improvements in the quality of financial data around the globe.

The critical importance of identifying entities can be easily demonstrated when banks attempt to quickly aggregate risks associated with different counterparties across their portfolios. Inability to establish risk ownership may lead these banks to incur huge losses.

During the financial crisis, the lack of information about which corporate group each entity belonged to and the complex ownership structures made it almost impossible for the banks to establish direct ownership of their exposures. They were thus unable to provide oversight of these exposures and ascertain where they were carrying extra risk, as well as the nature and magnitude of that risk. And of course, we all know how that story ended.

Within every banking institution many different internal systems are required to facilitate the customer relationship and fulfill its myriad activities. While each of these systems typically has its own unique identifier for the entities defined therein, linking the entities from disparate systems continues to challenge banks. Uniquely identifying each entity is thus proving to be a critical step in organizations’ pursuit of a complete understanding of their relationship with each entity to more accurately know where their risks lay. This need has become even more critical in the current regulatory environment, as evidenced by many of the recent compliance measures related to identifying a specific counterparty.

In this paper we will see how origination software could fit into the organization’s overall entity identification strategy and enhance the credit decisioning and monitoring process. We will also explore the operational and regulatory drivers of the need to uniquely identify entities at banks, and will look at some best practices to accomplish this end.

Defining an Entity
As a starting point, banks may want to make sure that no two entities can be set up in a system with the same name. A name-based identification approach may work for banks of small size and less complexity. Banks also typically associate each unique entity with some reference data in their origination systems, such as tax identification number or company registration number. However, with these methods duplicate entities are still likely to occur for larger banks and banks involved in acquisitions.

In large banks and those with complex hierarchical structures of entities, associating each entity with a unique LEI in the origination software creates a solid foundation for all risk-related activities. Additionally, equipping the origination system to store unique identifiers from the bank’s other source systems makes it possible to have a full understanding of risk associated with each entity. For maximum benefit these bank source system identifiers (e.g., AFS Id, Algo Id, etc.) should be stored with the entity and populated automatically to avoid a user mistyping the value.

Once the entities are identified, another challenge for banks is to structure entity relationships in a way that reflects the complex web of interrelationships these entities have in the real world. Many banks increasingly consider linking of counterparties with economic dependency relationships, e.g. buyer/supplier relationships, as essential to their risk assessments. Capability in the origination system to build credit, legal, and other entity hierarchies is essential to understanding the specific influences these interrelationships have on overall credit risk assessment.

A credit origination system that links the deal structuring process to an entity structure defined with these guidelines, supplemented with an effective user access management (UAM) process, protects data integrity and controls access for regulatory scrutiny.

Benefits of Uniquely Defined Entities
A uniquely defined entity aids in risk management by helping banks definitively know who is carrying risk for them and allows organizations to capture operational efficiencies. In a sense, banks build their entire organizations around entities. For instance, a retail and commercial bank will have separate business divisions that look after different entity groups. Once these entities are known and structured within their hierarchies and groups, banking organizations apply risk calculations along these hierarchies to get an accurate and complete view of the risk contribution of an entity. The wide terrain of beneficial applications of entity management in a banking organization includes seven key elements:

1. Improved Operational Efficiency:

Being able to construct a full view of the entity rather than seeing it from the perspective of a single account could deliver substantial cost reductions by helping banks and other financial institutions avoid large scale duplication in the recording and maintaining of customer data. Creating a new client record requires establishing and validating a range of information in a largely manual process. This initial on-boarding of information then has to be updated, creating more work. Inaccuracies and inconsistencies in client identification could also potentially dampen effective client relationship management due to, for example, redundant contact with the same client.

2. Accurate Risk Aggregation:

When aggregating limits for risk appetite calculations, banks need to make sure that the appropriate entities’ data is included in the calculations to avoid misrepresentation, undercounting, or even double-counting. Entity to entity and facility to entity risk aggregation calculations used to allocate risk to the correct owner depend on this unique entity definition for accuracy.

3. Credit and Counterparty Risk Management:

To a bank, collateral and guarantees are risk mitigants that help reduce the credit risk of a particular borrowing transaction with an entity. This is achieved primarily by offering the bank an alternative or secondary source of repayment should the borrowing entity be unable to pay back a loan by itself. Looking at the entire deal structuring process, identifying who owns the collateral and who is providing the guarantee becomes critical for effective risk mitigation. Banks can seize assets of the borrowing entity in the event of a default only if the bank is clearly able to establish ownership of the collateral. Specifically, an asset can be associated with several collateral pledges across multiple loans, giving all the associated banks varying priority of claims.

4. Entity Risk Grade Accuracy:

Typically, company financial statements are important inputs to the calculation of an entity risk grade, which in turn is used to calculate capital allocation against loans made to entities. Hence, it’s important to ensure that the correct financials for the entity are being used. In larger organizations, entities are linked together in a complex hierarchical relationship with intertwined risk. These structures could become even more complex with cross-default clauses, consolidated covenants that apply to all group entities, or a high level of management influence or ownership control. These situations may mean that the entire group shares common risk, resulting in the risk grade of one entity being distributed to other entities across the hierarchy. Rating distribution is also seen in instances where a strong supplier exerts a significant influence over the borrower.

At times, entities within the same hierarchy often cross-guarantee the others’ loans. It is then critical from the risk mitigation perspective to clearly identify the entities within the hierarchy and their relation to each other.

5. Adherence to Data Privacy and Protection Rules:

From a regulatory perspective, banks have to demonstrate the integrity of their data, showing that no unauthorized person has access to the data or an opportunity to change it. In cases of restricted deals, banks have to ensure that the access of any employee outside the deal team is prohibited. In other words, banks need a system where they can manage user access to entities along with the actions those users can take on those entities. Appropriate employee access using authentication and authorization is often achieved through a user access management (UAM) system that controls user’s access to entities as well as features in the system.

6. Demonstrating Regulatory Compliance:

Know Your Customer (KYC) regulations are in effect in all advanced economies and require that banks identify every single customer to satisfy Anti-Money Laundering (AML) rules, sanctions, fraud and other financial crime measures. The Basel Committee on Banking Supervision (BCBS) regulations also drive demand for identification. Leverage, liquidity, and many other ratios calculated under different Basel regimes assume that the banks have properly identified entities. More recent guidelines to monitor large exposures and the analytical credit dataset regulation, which include entity and loan identity as two of many required data points, reinforce the need to have a unique entity identity.

7. Reporting on Transactions:

Banks are required to prove that their records are accurate even when the actual borrower may be buried under a complex web of entity relationships and hierarchies. The principles for effective risk data aggregation and risk reporting, more commonly known as BCBS 239, include principles of Governance, Data Architecture and IT Infrastructure, Accuracy and Integrity, Completeness, Timeliness, Adaptability, Accuracy, Comprehensiveness, Clarity and Usefulness, Frequency, and Distribution. A common theme among all these principles is accurate, true, and clean data broken down along several dimensions including counterparty, instrument, jurisdiction, and so forth. A unique entity identifier stored within the database makes it possible to query and report at the required level of granularity. 

Achieving Entity Identification
A comprehensive view of the total exposure to an entity depends on the accuracy of the linkages between source systems’ exposure data and the associated entity it belongs to in the bank’s loan origination system. Getting these right starts early in the process – when entities are created.

Ideally, one system, a Customer Information System (CIS) or a Customer Relationship Management (CRM) system, should serve as the location where the bankwide unique identifier is initially generated and where all other systems’ unique identifiers for that same entity are also stored. A bank’s loan origination system could then be integrated to the CIS/CRM to ensure that any entities created are properly linked to the centralized system. There are two common ways – pull or push – that a CIS/CRM can integrate with a loan origination system for entity creation:

Scenario 1: Pull from CRM

In this scenario, when users initiate the creation of a new entity in the loan origination system the communication is sent to an interface exposed by the CIS/CRM. The user’s search criteria, captured in the origination system, is sent and a matching list of entities is returned and displayed to the user. The user then reviews the list and determines if the desired entity was returned from the CIS. If so, the user selects the item and a new entity is created in the origination system with data obtained from the CIS such as name, address, CIS-unique ID, and other system IDs. Ideally, the origination system then returns its own unique identifier back to the CIS for association with the same entity in the CIS.

Depending on the bank’s policies, if no entity from the CIS is located, a user may be allowed to manually create the entity in the origination system. In this case, the origination system should still communicate to the CIS to obtain a CIS-unique ID and return back its own origination system unique ID to maintain association of the entities between the two systems. Regardless of the approach, once linked, identifiers should not be editable by end users.

If the bank does not have a CIS/CRM, the bank should at a minimum enforce minimal duplication checking when a user tries to create a new entity in its loan origination system. This will help ensure there is a oneto-one mapping between entities stored in various core banking systems. Flexible and optimized origination systems offer users the option to have a soft warning or a hard-stop message based on their own internal policies and the data infrastructure. The validation criterion for these warnings could be configured to support both “AND” and “OR” logic operators, such as “Entity Name” AND “Country of Risk” OR “CIF Code,” resulting in a failed validation if any of these attributes match between two entities in the system.

 Scenario 2: Push from the CRM

In this scenario, the CIS/CRM is leveraged to push an entity to the loan origination system programmatically when some event occurs indicating that a new entity is needed by the origination system. In this case, a bank’s internal process is modified and users are instructed that the CIS is the starting point for any new customers or prospects. The ability to create a new entity in the origination software is disabled. When origination users require a new entity, they create it manually in the CIS or request that it be created by operational personnel.

The CIS must include the functionality to send the new entity to the loan origination system when needed. To facilitate this, the origination system exposes an interface that can be called from the CIS with the information required to create the entity. Once the entity is created in the origination system, the interface returns the entity’s unique identifier to the CIS. If ongoing synchronization between the systems is required, the CIS uses this unique identifier to communicate with the origination system on a scheduled basis.

Effectively Managing Risk
Armed with expanded oversight authority, regulators are demanding that financial institutions demonstrate a more sophisticated approach to entity identification that genuinely improves the ability to identify, manage, and mitigate risks. By building processes to uniquely identify an entity across their numerous internal systems, banks can raise the bar for firmwide risk management by establishing the level of risk ownership information necessary to effectively measure and monitor risk. Starting at the point of origination and integrating and automating the flow of entity information throughout their systems can confer competitive advantages to these banks. Without accurate identification of an entity, it will be very hard to attain business and regulatory compliance goals.