One Customer, Many Legal Entities: Building a Single Customer View Across Business Units and Jurisdictions
TL;DR: A group-wide customer view should provide one identity reference without pretending the group is one legal entity. Resolve the records that policy allows, keep source ownership and original values, and enforce which subsidiary may see which attributes. Where data cannot be pooled, place the same resolution engine inside each approved perimeter and exchange only governed entity references or permitted results.
Design one view without flattening your controls. Review the deployment and governance boundary with our team or test the matching behaviour locally. Book a Demo or Try Tilores Studio (Free).
On this page
- Why does a group create several customer views?
- Can the view work without centralising data?
- Where does the resolved view sit?
- How do you handle two jurisdictions?
- What about consent and retention?
- Which deployment model fits?
- Frequently asked questions
A customer can be one person to the group and five separate records to the companies inside it. The retail subsidiary knows an email. The lending business knows a legal name and address. The support centre knows a telephone number. A newly acquired business still runs its own CRM. Each record may be correct, yet no system can answer the group question without crossing an organisational boundary.
That boundary is not merely technical. Legal entities have their own contracts, purposes, retention schedules, consent records and regulators. A single customer view succeeds when it resolves identity while preserving those controls. It fails when “single” is interpreted as permission to pool every attribute into one unrestricted profile.
Why does a group with several business units end up with several customers?
Each business unit builds a customer record for the process it owns. CRM identifies a sales relationship. Billing identifies the contracted party. Support identifies the caller. Marketing identifies a reachable audience member. A regulated subsidiary may identify the person or legal entity subject to screening. These are not duplicates created by carelessness. They are local views created for different responsibilities.
Identifiers also change at the edges of the group. One subsidiary stores a national telephone format and another includes the country code. A person uses a personal email for one product and a work email for another. A parent company contracts in one jurisdiction while a subsidiary pays in another. Corporate registrations, trading names and addresses vary between markets.
Acquisitions multiply the problem. The acquired company brings its own customer keys, match rules and retention history. A migration may eventually consolidate systems, but the business needs to recognise shared customers before that programme completes.
Traditional master data management can govern a golden record, and a customer data platform can resolve identity for activation. Either may be the right owner within its domain. The cross-entity gap appears when the resolved identity must also serve operational applications, several data stacks and several legal perimeters without turning one platform into the owner of every source.
A useful group entity therefore has two levels. The first is a durable identity reference that says which permitted records relate to the same subject. The second is an authorised view assembled for the requesting business unit. The reference may be shared more widely than the underlying attributes.
Can you build a single customer view when data cannot be centralised?
Yes. Centralised identity does not require centralised raw data.
The default design for a group whose policies allow pooling is one Managed Cloud on AWS deployment serving the approved group sources. The engine ingests the identity fields needed for matching, retains source lineage and exposes the current entity through GraphQL. Applications receive only the attributes they are authorised to use.
When a jurisdiction or subsidiary cannot move those fields into the group deployment, place the resolution engine within that perimeter. Tilores supports Your AWS Account, Another Cloud and On-Premise after the managed AWS option. The same GraphQL contract and matching behaviour can operate across the models.
Each deployment needs only a key-value store, a queue and file storage. On AWS those primitives are DynamoDB, SQS and S3. That limited requirement lets a group use the same resolution function near each approved data estate instead of adopting a different identity product in every region.
The deployments can exchange a governed reference, a match assertion or an approved subset rather than raw source records. The exact exchange is a policy decision. Some groups may share a pseudonymous group entity ID. Others may permit a yes or no answer to “is this an existing group customer?” without revealing which subsidiary holds the record. A regulated use case may require a human review before any cross-entity link becomes visible.
The architecture should never imply that deployment alone creates a lawful basis for sharing. It changes where the function runs and what data must move. The controller and relevant group entities still decide purpose, access, retention and disclosure.
Where does the resolved view sit when subsidiaries have separate systems?
The resolved view sits as a shared identity service beside the systems, not as a replacement for them. Source CRMs, billing systems and warehouses continue to own their records and workflows. They attach or retrieve a group entity reference when the policy allows it.
There are three common patterns.
One group deployment with controlled views. All approved sources feed one resolution engine. GraphQL queries apply caller and source permissions so a subsidiary sees its authorised view of the entity. This is the simplest operating model when data may be processed in one perimeter.
Per-jurisdiction deployments with a group reference. Each perimeter resolves its local records. A controlled service maps permitted local entity IDs to a group reference. Raw identity attributes remain local. This model adds coordination but reduces cross-border movement.
Per-entity resolution with brokered queries. No central map is persisted. An authorised workflow asks local deployments a narrow question and combines permitted responses. This suits highly constrained cases, though it increases latency and makes group-wide analytics harder.
The governance decision table below makes the trade-offs explicit.
| Decision | One group deployment | Per-jurisdiction deployments | Brokered local queries |
|---|---|---|---|
| Raw identity data location | Approved central perimeter | Remains in each jurisdiction | Remains in each legal entity |
| Group entity reference | Native in one engine | Mapped from local entity IDs | May be transient only |
| Operational simplicity | Highest | Moderate | Lowest |
| Local control | Enforced through access policy | Enforced by separate deployments | Maximum local decision control |
| Cross-group analytics | Direct when authorised | Requires approved entity-ID exchange | Limited to permitted aggregates or responses |
| Best fit | Group may pool identity fields | Some regions cannot pool | Sharing is exceptional and question specific |
Whichever pattern is chosen, store the source system and source record ID with every record. Keep original values alongside normalised values. A group identifier without lineage is a new silo that nobody can safely correct.
Downstream teams should not use the entity ID as universal permission. A marketing system may be allowed to know that a person is already a customer and not allowed to see the lending subsidiary’s balance or support transcript. Resolve identity once, authorise data use separately.
How do you handle a customer who exists in two jurisdictions?
Treat cross-jurisdiction identity as an assertion with evidence and policy, not as an automatic merge.
Begin with deterministic evidence where it is valid. A shared group account ID or verified registration number can be strong. Fuzzy matching handles spelling and formatting variation. Probabilistic matching weighs several partial signals. Keep the three methods distinct and make the match reason reviewable.
The same value can carry different risk across borders. Names may be transliterated into different scripts. Address formats may omit or reorder components. Telephone numbers may be recycled. National identifiers may be prohibited from leaving the source jurisdiction or from being used for a new purpose.
Configure matching by source and jurisdiction rather than applying one global threshold. A value verified by one regulated subsidiary may carry more weight than a self-entered marketing form. A common family name should carry less weight than a rare combination. Where evidence is insufficient, preserve two local entities and send the cross-group assertion to review.
Corporate customers add hierarchy. The contracting party, paying entity, parent company and operating location may all be different legal entities. Do not collapse a corporate group merely because records share a domain or address. Model the resolved legal entity separately from relationships such as subsidiary of, pays for or trades as.
For financial services, identity resolution may prepare a more complete subject for sanctions, politically exposed person and adverse media screening. It does not replace those checks or decide the outcome. The group should also record which legal entity performed the screening and which entities are permitted to rely on it.
If a cross-border link changes, preserve the event. A correction may split one group entity into two local entities. Downstream applications need a mapping and effective time so historical reports can be reproduced.
What does this mean for consent and retention across entities?
Consent and retention remain attached to the purpose and legal entity that collected the data. Resolving two records does not merge their permissions.
This is consistent with the European Data Protection Board’s data-protection-by-design summary, which keeps purpose limitation, data minimisation, accuracy, storage limitation and security as separate principles. Resolution improves accuracy and findability; it does not cancel the others. The ICO data sharing agreement guidance likewise requires organisations to document purpose, roles, data handling and standards before personal data is shared.
The legal anchor is Article 5 of the GDPR, which treats purpose limitation, data minimisation, accuracy and storage limitation as simultaneous obligations. A group identity design therefore needs to show both why records belong to one subject and why a particular consumer may use a particular attribute.
Represent consent, suppression, retention and lawful-basis metadata with source and entity context. A customer may consent to product updates from one subsidiary and not another. A group-wide suppression may be valid for a specific channel while a statutory service message remains permitted. The resolution layer helps recognise the same person across identifiers; the policy system decides what action follows.
Use the resolved entity to make approved outcomes complete. If a person exercises a valid erasure right, identity resolution can help locate the records covered by the request. Each legal entity still applies its obligations and exceptions. One subsidiary may need to erase a marketing profile while another retains transaction records under law.
Tilores can set retention rules per data source. When a record expires or is deleted, the entity is reorganised and the action can be audited. A per-source rule is essential in a group because a single global retention period is usually false.
The governance model should answer:
- which entity captures and verifies a request;
- which other entities are notified;
- which identifiers may be used to locate related records;
- what evidence of completion is returned;
- which exemptions apply and who approves them;
- whether the cross-group entity reference itself must be retained, replaced or deleted.
Audit queries as well as changes. A shared identity service can reveal relationships even when it withholds attributes. Unusual cross-entity lookups deserve monitoring.
Which deployment model fits a multi-entity group?
Use the least fragmented model that satisfies the real perimeter.
Managed Cloud on AWS is the starting point when the group can process approved identity fields in one managed boundary. It gives the organisation one engine, one configuration and one operational view while access controls preserve subsidiary permissions.
Your AWS Account fits a group that wants the same AWS reference architecture inside its own controlled account. It is useful when account ownership, networking or residency rules prevent the managed model.
Another Cloud fits a group or jurisdiction whose approved cloud perimeter is elsewhere. Avoid duplicating matching logic in a separate product merely because the surrounding platform differs.
On-Premise fits an isolated local environment. It is a supported option for a specific control requirement, not the headline design and not evidence that every other model is unsafe.
| Group condition | Recommended starting point | Control to add |
|---|---|---|
| One approved identity-processing perimeter | Managed Cloud on AWS | Source and attribute permissions by legal entity |
| Group requires infrastructure in its AWS account | Your AWS Account | Account-level operations, network and recovery ownership |
| A jurisdiction requires its approved cloud | Another Cloud | Local deployment plus governed entity-ID exchange |
| A perimeter cannot use cloud infrastructure | On-Premise | Local operations plus a narrowly approved federation path |
| Sharing is allowed only for specific questions | Separate deployments | Brokered GraphQL query with purpose and audit controls |
Read the current deployment options as part of the data-protection assessment. The architectural goal is not centralisation for its own sake. It is one reliable identity function placed where each group’s policies allow it to run.
The phrase “single customer view” can hide a dangerous assumption: that one view should contain everything for everyone. A better design is one resolved identity with several lawful, purpose-bound views. The group recognises the customer. Each legal entity still knows what it is allowed to do.
Frequently Asked Questions
Can a group build one customer view without pooling all personal data?
A group can build one customer view without pooling every attribute by resolving inside approved perimeters and exchanging governed entity references or permitted results. The design depends on the group’s legal basis and data-sharing rules.
Does entity resolution create permission to share customer data between subsidiaries?
Entity resolution does not create permission to share data. It identifies related records; each legal entity still needs a valid purpose, lawful basis, access rule and retention policy for the attributes it uses.
How should consent be represented in a group customer view?
Consent should stay attached to the legal entity, purpose, channel and collection context that created it. A group entity can expose the applicable consent state without turning several local permissions into one universal permission.
What happens when the same customer appears in two jurisdictions?
When the same customer appears in two jurisdictions, preserve both source records and local controls, then map them to a governed group reference only where policy permits. Do not silently copy the full profile across borders.
Which Tilores deployment fits a multi-entity group?
Managed Cloud on AWS is the default when the group may use one approved perimeter. Use the customer’s AWS account, another approved cloud, on-premise, or separate deployments when residency and operating controls require them.
See what resolved entity data does for your business — and your AI.