Entity resolution and financial networks
Connect records without turning association into guilt.
A connection needs a meaning
Enlarge to read every label and explore the connections
A network becomes useful when each edge has a type, source, time, and confidence. Association alone does not establish wrongdoing.
Identify the real entity behind each node.
Use the legend to distinguish each relationship.
Inspect the source and date before making an inference.
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
- RecordPreserve source identity fields
- MatchEvaluate evidence for shared identity
- ResolveVersion the accepted relationship
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.
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.
- False merge
- Different entities combined
- False split
- One entity represented as several
Entity-match review
Illustrative data; not a real customer record or a prescribed policy.
- Namesimilar spelling
Weak match alone
- Identifierconflicting
Strong reason for caution
- Actionkeep separate pending review
Avoid unsupported merge
Identity links can be wrong
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.
Type the relationships
- TypeName the relationship
- DateRecord when it applies
- SourcePreserve how it was established
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.
A payment, director role, device link, and ownership interest are different edges. Their meaning depends on direction, time, and evidence.
- Payment edge
- Value moved between parties
- Ownership edge
- One party holds an economic stake
Graph edge specimen
Illustrative data; not a real customer record or a prescribed policy.
- Frombusiness A
Sender entity
- Tobusiness B
Receiver entity
- Typepayment
Does not establish ownership
The meaning of a connection must remain explicit
Use typed directed time-aware edges. The meaning of a connection must remain explicit.
- Failure mode 1avoid
- Treat every edge as control. Payments and addresses do not prove control.
- Failure mode 2avoid
- Ignore former relationships. Time changes the interpretation.
- Failure mode 3avoid
- Hide inferred status. Analysts may overstate the evidence.
Compare the network with the business story
- ProfileState expected relationships
- PatternObserve actual flow structure
- ExplanationTest material inconsistencies
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.
A dense cluster can describe payroll, marketplace settlement, a household, or an activity needing further investigation. The business story determines the useful comparison.
- Fan-out pattern
- One source reaches many recipients
- Suspicious use
- Context and evidence make the pattern concerning
Payroll pattern
Illustrative data; not a real customer record or a prescribed policy.
- Inflowemployer funding
Expected source
- Outflowsemployee payments
Expected recipients
- Review focusunexplained deviations
Shape alone is not enough
The same shape can have legitimate uses
Interpret graph patterns through the customer purpose. The same shape can have legitimate uses.
- Failure mode 1avoid
- Treat all fan-out as laundering. Payroll is one counterexample.
- Failure mode 2avoid
- Ignore timing and amounts. They help explain the pattern.
- Failure mode 3avoid
- Reveal exact alert boundaries. Customers do not need control internals.
Use graph evidence carefully
- PathIdentify the specific chain
- ValidateCheck each edge and date
- ConcludeLimit the claim to supported facts
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.
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.
- Connected by a path
- Records show a chain of relationships
- Common intent
- Requires evidence beyond mere connection
Path evidence
Illustrative data; not a real customer record or a prescribed policy.
- A to Bconfirmed payment
Supported edge
- B to Cinferred shared device
Uncertain edge
- Conclusionreview lead
Not proof of common control
The path is only as strong as its evidence
Expose edge provenance and uncertainty. The path is only as strong as its evidence.
- Failure mode 1avoid
- Call every connected node complicit. Association does not establish intent.
- Failure mode 2avoid
- Hide weak links in the graph. That overstates certainty.
- Failure mode 3avoid
- Use a picture without source records. The finding cannot be checked.
Control graph access and change
- AccessLimit queries to a valid purpose
- ChangeVersion matching and edge rules
- ImpactReview downstream alert changes
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.
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.
- Graph feature
- Approved summary for a decision
- Raw network export
- Detailed relationships with broader exposure
Matching release
Illustrative data; not a real customer record or a prescribed policy.
- Old linked accounts1200
Prior graph
- New linked accounts9000
Large change
- Actionreview merge impact
Do not release blindly
Resolution changes can alter many decisions
Test graph changes and restrict access. Resolution changes can alter many decisions.
- Failure mode 1avoid
- Treat the graph as harmless metadata. Relationships can be sensitive.
- Failure mode 2avoid
- Export every neighbor by default. The task may require less data.
- Failure mode 3avoid
- Release a merge change without impact review. False links can spread through controls.
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.