Entities
Entities Exist Before the Bank
The bank does not create the entity. It creates a record of something that already exists.
Companies, funds, branches, governments, partnerships and people exist independently of the bank. They have their own legal, organisational or recognised existence before the bank decides to establish a relationship with them.
The bank's task is to determine what that participant is, which specific entity it is, and how it should be represented consistently across the organisation.
This distinction matters because banks frequently create multiple records for the same real-world participant: a KYC record, a counterparty record, an issuer record, a credit record, an account party or a trading identifier.
Those records may serve different purposes, but they do not necessarily represent different entities.
An entity can perform many roles, participate in many relationships, enter different business arrangements, sign contracts and use multiple products. None of those activities changes the underlying entity.
The starting point is therefore not the bank's record.
It is the real-world entity the record is intended to represent.
What Is an Entity?
Beyond legal personality
A legal entity is one type of entity. It is not the definition of an entity.
For client lifecycle purposes, an entity is a distinct real-world participant that the bank needs to recognise, identify and manage independently.
The participant exists independently of the bank. The bank recognises that participant as an entity so that it can be represented consistently in its information, processes and technology.
This is particularly important in IT systems.
A bank cannot manage a company, branch, fund or person directly. It must create a persistent representation of that participant, an entity that can be identified, referenced and linked to everything the bank knows or does in relation to it.
Some entities have their own legal personality. A company, for example, may be incorporated under law and able to own assets, enter contracts, incur liabilities and sue or be sued in its own name.
But banks also need to recognise participants that do not have separate legal personality.
A branch may form part of the same legal person as its head office, yet operate under a separate licence, in another jurisdiction, from a different address and subject to different regulatory requirements.
A fund may need to be recognised independently even where its legal structure means that another entity acts on its behalf.
A natural person is also an entity, but plainly not a legal entity in the corporate sense.
The relevant question is therefore not “is this a legal entity?”, but is “does the bank need to recognise and manage this participant as a distinct entity?”
Once recognised, that entity should provide a persistent anchor across the bank. Different systems may hold different information about it, but they should still be referring to the same underlying participant.
The law determines what legally exists and where rights and obligations ultimately sit. The bank must preserve that legal reality, while also recognising the participants it needs to identify, risk-manage, permission, transact with and aggregate across its activities.
An entity is therefore the bank's recognised representation of a real-world participant — the anchor to which identity, roles, relationships, arrangements, obligations, risks and lifecycle events can be connected.
Entity Is Not Role
What it is, not what it does
An entity is what the participant is. A role describes what that entity is doing in a particular context.
The same entity may act as a borrower in one arrangement, an issuer in another, a guarantor somewhere else and a counterparty in a trading relationship.
Those roles can change without the entity itself changing.
This matters because banking systems often create records around particular activities. A participant may therefore appear separately as an issuer, borrower, customer, account holder or trading counterparty even though each record refers to the same underlying entity.
If role and entity are confused, the bank can easily create multiple versions of the same participant and then treat them as unrelated.
The better model is to recognise the entity once and associate the relevant roles with it.
This also means that a role should not define the identity of the entity.
ABC Holdings Ltd does not become a different entity because it becomes a guarantor. It is the same entity performing another role.
Separating entity from role allows the bank to understand the participant consistently across different products, arrangements and risk processes, while still recognising the specific responsibilities and permissions attached to each role.
The entity provides continuity. The role provides context.
Entity Is Not Relationship
Participants and connections
An entity is the participant. A relationship is the connection between that participant and another party.
The distinction matters because an entity can exist without any relationship with the bank at all.
A company may be incorporated, a fund established or a person born long before the bank has any reason to recognise them. The relationship begins only when some form of connection is established or contemplated.
That connection may be directly with the bank, or it may arise between the entity and another participant in a wider business arrangement.
An entity can therefore participate in many relationships at the same time.
The same company might be a borrower of one bank entity, a trading counterparty of another, the guarantor of a subsidiary, the issuer of securities held by the bank and the parent of several other entities.
Those relationships are different. The underlying entity is not.
Relationships also have their own lifecycle. They can be proposed, established, changed, suspended and terminated while the entity continues to exist.
This is why the bank should not create a new entity simply because a new relationship begins.
The entity is the persistent participant. The relationship records how that participant is connected to someone else.
Keeping those concepts separate allows the bank to understand one entity across many relationships, while managing each relationship according to its own purpose, obligations, risks and lifecycle.
One Entity, Many Contexts
Different views, same participant
The same entity can appear many times across the bank without becoming a different entity.
A company may be recognised in credit, KYC, payments, markets, lending, securities and regulatory reporting.
It may participate in several business arrangements, perform different roles, enter multiple contracts and use different products.
It may also be viewed differently for different purposes.
Credit may assess its ability to meet financial obligations. Financial crime may assess its ownership, control and activity. Markets may need to understand its trading capacity. Operations may need settlement instructions. Regulatory reporting may require yet another classification.
These are different views of the same participant.
The problem arises when each context creates its own independent version of the entity.
The bank can then lose sight of the fact that a borrower, issuer, account holder and trading counterparty are all the same real-world participant. Exposure can become fragmented, information duplicated and changes applied inconsistently.
A stronger model keeps the entity persistent while allowing different contexts to be associated with it.
One entity can therefore support many roles, relationships, arrangements, contracts, products and risk views without losing its identity.
The entity becomes the common point through which the bank can connect those different perspectives and understand the participant as a whole.
The Bank Needs One Recognised Entity
One entity, multiple records
Recognising the same participant consistently across the bank is different from forcing every system to hold the same record.
Large banks commonly have multiple platforms, business lines and data stores, each of which may need to hold information about the same entity for a different purpose.
The problem is not that multiple records exist.
The problem is when the bank cannot reliably determine that those records refer to the same underlying participant.
A company might therefore have one identifier in KYC, another in credit, another in trading, another in payments and several more in downstream systems.
Without a common entity anchor, the bank can fragment its understanding of that participant.
Changes to the entity may not propagate consistently. Risk may be assessed against incomplete information. Exposure may be split across identifiers. Relationships may appear unrelated. Different parts of the bank may even reach different conclusions about who the participant is.
The objective should therefore be one recognised entity instance, even where multiple systems continue to maintain their own records and identifiers.
That recognised entity can be given a persistent enterprise identifier and mapped to the identifiers used elsewhere across the bank.
This allows systems to continue serving their own operational purposes while preserving the connection back to the same real-world participant.
One recognised entity does not mean one database record.
It means that wherever the participant appears, the bank can determine that it is dealing with the same entity.
That capability is fundamental to understanding relationships, aggregating risk, controlling permissions and managing the participant consistently through its lifecycle.
When Is Something a Separate Entity?
Recognising meaningful distinctions
Not every organisational unit needs to be recognised as a separate entity. But some do, even when they are not separate legal persons.
This is one of the harder questions in entity design.
Legal personality is an important consideration, but it is not always sufficient on its own.
A branch, for example, may be part of the same legal person as its head office. Yet the bank may still need to recognise that branch separately because it operates under a particular licence, in a particular jurisdiction, from a specific address or within a distinct regulatory context.
Funds can create similar challenges. A fund, sub-fund or compartment may need to be recognised independently because assets, obligations, investment activity or regulatory treatment are attributable specifically to it, even where another legal person acts on its behalf.
The question is therefore not simply whether something has been separately incorporated.
The bank should ask whether the participant needs to be distinguished independently for a meaningful business, legal, regulatory, risk or operational purpose.
That may include whether the bank needs to:
establish its identity separately;
attribute activity, exposure or obligations to it;
recognise a separate licence or jurisdiction;
distinguish the relationships or arrangements in which it participates; or
maintain continuity of that participant across systems and processes.
The decision should not be made differently by every system or business line.
If one part of the bank treats something as a distinct entity while another treats it only as an attribute of something else, the resulting architecture becomes difficult to reconcile.
Entity recognition therefore requires a consistent rule for deciding when a participant must exist independently within the bank's information model.
That rule should reflect the real-world structure the bank is trying to represent — not simply the limitations of a particular system.
Entities Change
Identity through change
An entity can change significantly without becoming a different entity.
A company may change its name, registered address, ownership, directors, legal form, industry, tax status or country of operation.
A fund may change its manager, strategy or regulatory classification.
A branch may move location, change its licence status or alter the activities it is permitted to conduct.
These changes matter, but they do not automatically mean that a new entity has come into existence.
The bank therefore needs to distinguish between a change to an entity and a change that means the original entity has ceased and another has replaced it.
That distinction is essential for continuity.
If a simple name change creates a new entity record, the bank can lose the history of the participant. Relationships, contracts, exposures, risk decisions and prior activity can become disconnected.
Equally, if a genuinely new legal or recognised participant is treated as though it were merely an update to the old one, the bank may incorrectly carry forward rights, obligations, risk assessments or permissions.
Entity management therefore requires the bank to preserve identity through change while recognising genuine discontinuity when it occurs.
The question is not only “What has changed?” but also “Is this still the same entity?”
That determination allows the bank to maintain a continuous history of the participant while ensuring that material structural or legal changes trigger the appropriate reassessment of relationships, risk, contracts and permissions.
Entity as the Anchor
Connecting the wider picture
The entity is the persistent participant around which the bank can organise everything else it needs to know and manage.
Once the bank has recognised the entity, it can connect the other components of the business relationship to that common anchor.
The entity has an identity.
It performs roles.
It participates in relationships.
It enters business arrangements.
It may become party to contracts.
It may be eligible for products and activities.
And it may be granted, restricted or lose permission to undertake those activities over time.
Each of those things can change independently.
A role can end while the entity remains.
A relationship can terminate while other relationships continue.
A contract can expire without the entity ceasing to exist.
A product can be disabled while the wider client relationship remains active.
This is why the bank needs to keep the entity distinct from the contexts in which it participates.
The entity provides continuity while everything around it changes.
That continuity makes it possible to connect identity, risk, obligations, activity and permissions across the bank and to manage them coherently through the lifecycle.
Without a persistent entity anchor, the bank is left managing disconnected records.
With one, it can begin to represent the real business relationship.
Entity Is Not Identity
Participant versus identification
The entity is the participant. Identity is how the bank establishes which participant it is.
The distinction is important because the two concepts are closely connected but serve different purposes.
A company, fund, branch or person exists independently of the information the bank holds about it.
The bank then uses identity information to determine that the participant it is dealing with is the specific entity it believes it to be.
That may include legal name, registration details, date of incorporation, registered address, identifiers, constitutional documents or other evidence appropriate to the type of participant.
Identity therefore supports recognition.
It does not replace the entity itself.
The same entity may accumulate new identifiers, updated documentation or additional evidence over time without becoming a different entity.
Equally, two records that look similar may turn out to represent different entities once their identity is properly established.
This is why identity data should be attached to a persistent entity rather than treated as the entity itself.
The entity is the thing being recognised. Identity is the basis on which the bank knows that recognition is correct.
Keeping those concepts separate allows the bank to preserve continuity of the participant while updating the evidence used to identify it.