Unit 04 · Chapter 3 · 10 min read

Entity resolution and financial networks

Connect records without turning association into guilt.

Three businesses share an address. It could be a criminal network. It could also be a popular accountant’s office. A graph makes relationships visible; it does not explain them on its own.

Resolve records before drawing edges

Entity resolution determines whether records refer to the same real-world person or organization. Exact identifiers can help, but names, addresses, and dates may be incomplete or inconsistent. Keep the original record and the proposed match with a confidence and reason.

A false merge can attach another person’s transactions to a customer. A false split can hide a relevant pattern across accounts. Evaluate both errors. Use manual review for consequential uncertain matches and preserve the ability to undo a merge. A graph built on unreliable identities can look precise while being wrong at its foundation.

Entity resolution is the task of deciding which records refer to the same real-world subject. Exact agreement can still mislead: unrelated people can share a name, and businesses can share an address with many other tenants. Disagreement can also mislead when a legitimate name has multiple spellings or an address changes. Treat the resolution result as an evidence-supported relationship with a confidence and history where appropriate.

A mistaken merge has consequences beyond one screen. It can combine unrelated payment histories, spread a negative label, and create a network that appears suspicious only because the data was joined incorrectly. Review high-impact merges and make correction possible. Preserve the original records so a reviewer can reconstruct how the system produced the combined view.

Resolve records before drawing edges Resolve records before drawing edges — the flow Follow the sequence. Version the accepted relationship. Record Preserve source identity fields Match Evaluate evidence for shared identity Resolve Version the accepted relationship — Follow the sequence. Version the accepted relationship. Chapter sources · Open image

Resolve records before drawing edges Resolve records before drawing edges — the distinction These concepts answer different questions. Read each definition in the context of the section. False merge Different entities combined False split One entity represented as several — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Resolve records before drawing edges Entity-match review Fictional teaching record. Avoid unsupported merge. Entity-match review Illustrative data; not a real customer record or a prescribed policy. Name similar spelling Weak match alone Identifier conflicting Strong reason for caution Action keep separate pending review Avoid unsupported merge Identity links can be wrong — Fictional teaching record. Avoid unsupported merge. Chapter sources · Open image

Resolve records before drawing edges — control and failure modes

Control design

Track match evidence and reversible resolution. Identity links can be wrong.

Failure mode 1avoid: Merge from name alone. Common names create false associations.
Failure mode 2avoid: Assume exact text means exact identity. Different people can share fields.
Failure mode 3avoid: Make merges irreversible. Later evidence may require correction.

Identity links can be wrong. The branches show why alternative designs fail. Chapter sources · Open image

Type the relationships

Ownership, control, shared device, shared address, payment, and employment are different edges. Their direction and time matter. A person who once worked for a business does not necessarily control it now. A payment edge does not imply an ownership relationship.

Define an edge schema with type, source, observed time, effective period, and confidence. Keep inferred relationships visibly distinct from confirmed ones. This supports queries that answer a specific investigative question. A diagram that draws every connection with the same line encourages readers to assign meaning the data does not contain.

Type the relationships Type the relationships — the flow Follow the sequence. Preserve how it was established. Type Name the relationship Date Record when it applies Source Preserve how it was established — Follow the sequence. Preserve how it was established. Chapter sources · Open image

Type the relationships Type the relationships — the distinction These concepts answer different questions. Read each definition in the context of the section. Payment edge Value moved between parties Ownership edge One party holds an economic stake — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Type the relationships Graph edge specimen Fictional teaching record. Does not establish ownership. Graph edge specimen Illustrative data; not a real customer record or a prescribed policy. From business A Sender entity To business B Receiver entity Type payment Does not establish ownership The meaning of a connection must remain explicit — Fictional teaching record. Does not establish ownership. Chapter sources · Open image

Type the relationships Type the relationships — control and failure modes The meaning of a connection must remain explicit. The branches show why alternative designs fail. Control design Use typed directed time-aware edges. The meaning of a connection must remain explicit. Failure mode 1 Treat every edge as control. Payments and addresses do not prove control. avoid Failure mode 2 Ignore former relationships. Time changes the interpretation. avoid Failure mode 3 Hide inferred status. Analysts may overstate the evidence. avoid — The meaning of a connection must remain explicit. The branches show why alternative designs fail. Chapter sources · Open image

Compare the network with the business story

A wholesaler may receive many payments and pay a few suppliers. A payroll service may receive one large funding transfer and send many smaller payments. Similar graph shapes can be normal in different businesses.

Compare the network with the customer profile, product, and transaction timing. Document the inconsistency being investigated. Do not publish exact operational detection thresholds in general customer messages. The teaching point is to identify an unexplained mismatch and obtain evidence, not to supply a checklist for staying just below a rule.

Edges need meaning. A shared director, a common device, a payment, and an ownership interest are different relationships with different implications. Drawing every edge as an identical line makes the network visually impressive but analytically weak. Add the relationship type, direction, time, and source. A cluster that existed years ago may not describe current control. A payment in one direction is not proof of ownership. The best network view helps the investigator test a business explanation rather than rewarding the largest or most colorful cluster.

Compare the network with the business story — the flow

ProfileState expected relationships
PatternObserve actual flow structure
ExplanationTest material inconsistencies

Follow the sequence. Test material inconsistencies. Chapter sources · Open image

Compare the network with the business story Compare the network with the business story — the distinction These concepts answer different questions. Read each definition in the context of the section. Fan-out pattern One source reaches many recipients Suspicious use Context and evidence make the pattern concerning — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Compare the network with the business story Payroll pattern Fictional teaching record. Shape alone is not enough. Payroll pattern Illustrative data; not a real customer record or a prescribed policy. Inflow employer funding Expected source Outflows employee payments Expected recipients Review focus unexplained deviations Shape alone is not enough The same shape can have legitimate uses — Fictional teaching record. Shape alone is not enough. Chapter sources · Open image

Compare the network with the business story Compare the network with the business story — control and failure modes The same shape can have legitimate uses. The branches show why alternative designs fail. Control design Interpret graph patterns through the customer purpose. The same shape can have legitimate uses. Failure mode 1 Treat all fan-out as laundering. Payroll is one counterexample. avoid Failure mode 2 Ignore timing and amounts. They help explain the pattern. avoid Failure mode 3 Reveal exact alert boundaries. Customers do not need control internals. avoid — The same shape can have legitimate uses. The branches show why alternative designs fail. Chapter sources · Open image

Use graph evidence carefully

A path through several entities can suggest a relationship worth investigating. It does not automatically prove common ownership, intent, or knowledge. Each step needs a valid edge and an interpretation. The farther the path, the more assumptions may accumulate.

Show the actual path used to support an alert, including dates and sources. Limit claims to what the evidence supports. If one edge is uncertain, the conclusion should reflect that uncertainty. Analysts need a way to inspect the underlying records rather than rely on a dramatic network picture with no provenance.

Use graph evidence carefully Use graph evidence carefully — the flow Follow the sequence. Limit the claim to supported facts. Path Identify the specific chain Validate Check each edge and date Conclude Limit the claim to supported facts — Follow the sequence. Limit the claim to supported facts. Chapter sources · Open image

Use graph evidence carefully Use graph evidence carefully — the distinction These concepts answer different questions. Read each definition in the context of the section. Connected by a path Records show a chain of relationships Common intent Requires evidence beyond mere connection — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use graph evidence carefully Path evidence Fictional teaching record. Not proof of common control. Path evidence Illustrative data; not a real customer record or a prescribed policy. A to B confirmed payment Supported edge B to C inferred shared device Uncertain edge Conclusion review lead Not proof of common control The path is only as strong as its evidence — Fictional teaching record. Not proof of common control. Chapter sources · Open image

Use graph evidence carefully Use graph evidence carefully — control and failure modes The path is only as strong as its evidence. The branches show why alternative designs fail. Control design Expose edge provenance and uncertainty. The path is only as strong as its evidence. Failure mode 1 Call every connected node complicit. Association does not establish intent. avoid Failure mode 2 Hide weak links in the graph. That overstates certainty. avoid Failure mode 3 Use a picture without source records. The finding cannot be checked. avoid — The path is only as strong as its evidence. The branches show why alternative designs fail. Chapter sources · Open image

Control graph access and change

Financial networks reveal relationships about customers and third parties. Apply purpose-based access, query logging, and export controls. An investigator may need a limited neighborhood, while a model pipeline needs approved aggregate features. Neither necessarily needs unrestricted raw network access.

Version entity-resolution logic and test changes before rebuilding the graph. A new matching rule can suddenly connect thousands of accounts and trigger a wave of alerts. Compare the changed edges, affected customers, and downstream decisions. The graph is a production dependency, not a passive illustration.

Control graph access and change Control graph access and change — the flow Follow the sequence. Review downstream alert changes. Access Limit queries to a valid purpose Change Version matching and edge rules Impact Review downstream alert changes — Follow the sequence. Review downstream alert changes. Chapter sources · Open image

Control graph access and change Control graph access and change — the distinction These concepts answer different questions. Read each definition in the context of the section. Graph feature Approved summary for a decision Raw network export Detailed relationships with broader exposure — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Control graph access and change Matching release Fictional teaching record. Do not release blindly. Matching release Illustrative data; not a real customer record or a prescribed policy. Old linked accounts 1200 Prior graph New linked accounts 9000 Large change Action review merge impact Do not release blindly Resolution changes can alter many decisions — Fictional teaching record. Do not release blindly. Chapter sources · Open image

Control graph access and change Control graph access and change — control and failure modes Resolution changes can alter many decisions. The branches show why alternative designs fail. Control design Test graph changes and restrict access. Resolution changes can alter many decisions. Failure mode 1 Treat the graph as harmless metadata. Relationships can be sensitive. avoid Failure mode 2 Export every neighbor by default. The task may require less data. avoid Failure mode 3 Release a merge change without impact review. False links can spread through controls. avoid — Resolution changes can alter many decisions. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Customer due diligence and beneficial ownership. Continue with Transaction monitoring and alert quality to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17