Entity resolution and financial networks

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.

Inside the mechanism. Resolve entities before inferring a network. Separate a source record from the real-world entity it may describe, and keep confidence and conflicting evidence visible. A false merge can create an apparently dense suspicious network from unrelated people. A false split can hide repeated activity. Stable internal identifiers, source references, and reversible resolution decisions allow later corrections without losing the original evidence.

A concrete example. Two records may share a name or address without describing the same subject. A mistaken merge can spread labels and create an artificial suspicious network. The matcher returns 210 candidates from 18,500 records. It identifies 63 of 68 known fictional identity matches and misses 5. After scoped suppressions and stale-evidence returns, review demand is 169. The example keeps identity resolution, control availability, and the final legal disposition separate.

When the assumption fails. A common address causes unrelated businesses to become one entity. Preserve source records and review high-impact merges with reliable attributes. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Two records may share a name or address without describing the same subject. A mistaken merge can spread labels and create an artificial suspicious network.

Entity resolution before linking: reference condition figure preview

01Reference conditionEntity resolution before linking

Entity resolution before linking: failure and stress figure preview

02Failure and stressEntity resolution before linking

Entity resolution before linking: controlled response figure preview

03Controlled responseEntity resolution before linking

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.

Inside the mechanism. Edges need types, direction, time, and provenance. Ownership, shared device use, transfer, address similarity, and management control are not equivalent relationships. A path through several weak similarity edges should not become a statement that one person owns another’s account. Keep observed edges separate from inferred ones and preserve the evidence for each. Graph queries should state which edge types and time windows they include.

A concrete example. A payment, director role, device link, and ownership interest are different edges. Their meaning depends on direction, time, and evidence. The daily source population is 12,400 items, but 248 are outside the completed monitoring run. The included population creates 316 hits and 259 unique cases. With 35 cases already open and capacity for 270, the queue closes at 24. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

When the assumption fails. Every edge is rendered as an identical association. Keep relationship types and temporal validity visible to the investigator. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A payment, director role, device link, and ownership interest are different edges. Their meaning depends on direction, time, and evidence.

Typed network relationships: reference condition figure preview

01Reference conditionTyped network relationships

Typed network relationships: failure and stress figure preview

02Failure and stressTyped network relationships

Typed network relationships: controlled response figure preview

03Controlled responseTyped network relationships

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.

Inside the mechanism. Compare the observed network with the stated business model. A payroll provider can legitimately send to many people; a small retailer may have a different expected pattern. Look at sequence, concentration, turnover, and supporting commercial activity rather than shape alone. A hub-and-spoke picture is an organizing view, not a legal conclusion. Alternative explanations belong in the investigation record.

A concrete example. A dense cluster can describe payroll, marketplace settlement, a household, or an activity needing further investigation. The business story determines the useful comparison. The daily source population is 10,600 items, but 212 are outside the completed monitoring run. The included population creates 436 hits and 358 unique cases. With 64 cases already open and capacity for 310, the queue closes at 112. Coverage, duplicate work, and staffing are separate causes; reducing one number does not prove that the overall control improved.

When the assumption fails. High connectivity alone becomes the reason for an adverse conclusion. Compare transaction roles and timing with the declared business and plausible alternatives. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A dense cluster can describe payroll, marketplace settlement, a household, or an activity needing further investigation. The business story determines the useful comparison.

Network and business explanation: reference condition figure preview

01Reference conditionNetwork and business explanation

Network and business explanation: failure and stress figure preview

02Failure and stressNetwork and business explanation

Network and business explanation: controlled response figure preview

03Controlled responseNetwork and business explanation

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.

Inside the mechanism. Graph measures are sensitive to the chosen population and missing edges. A central node may reflect a common service provider rather than coordination. A short path can combine unrelated relationship types. State the graph boundary, resolution method, observation period, and known omissions. Use network evidence to direct review and test a hypothesis; do not promote a visualization into proof of intent.

A concrete example. The graph is a view over source data and entity-resolution choices. A visually striking path can still depend on a weak or stale edge. The case identifies 1,418 eligible records from a source population of 1,750. The required workflow completes for 1,375, but 21 completed records miss the illustrative internal target. Another 43 remain incomplete. Communication evidence covers 1,361 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A low-confidence relationship is presented as a confirmed ownership or criminal link. Retain confidence, source, dates, competing explanations, and the scope of any conclusion. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The graph is a view over source data and entity-resolution choices. A visually striking path can still depend on a weak or stale edge.

Limits of graph evidence: reference condition figure preview

01Reference conditionLimits of graph evidence

Limits of graph evidence: failure and stress figure preview

02Failure and stressLimits of graph evidence

Limits of graph evidence: controlled response figure preview

03Controlled responseLimits of graph evidence

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.

Inside the mechanism. Network access can expose relationships about many people beyond the initial case subject. Scope access to the task and log sensitive queries and exports. Version the source and resolution logic so a past graph can be reconstructed. Corrections should invalidate affected conclusions where appropriate. A downloaded image with no record of its source graph is difficult to audit and easy to overinterpret.

A concrete example. Connected records can reveal sensitive relationships beyond what one investigator needs. Corrections must also propagate when a merge or edge is found to be wrong. The case identifies 1,716 eligible records from a source population of 2,600. The required workflow completes for 1,665, but 25 completed records miss the illustrative internal target. Another 51 remain incomplete. Communication evidence covers 1,648 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A corrected identity merge remains embedded in exported case material. Use scoped access, versioned graph changes, and an affected-record correction path. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Connected records can reveal sensitive relationships beyond what one investigator needs. Corrections must also propagate when a merge or edge is found to be wrong.