Link and Network Analysis

Link and Network Analysis
Purpose	Reveal relationships among people, companies, accounts and events
Core steps	Collect, standardize, resolve entities, link, visualize, measure, verify
Typical outputs	Link chart, relationship (association) matrix, graph metrics, match report
Common tools	Spreadsheet/SQL joins, Python (networkx, rapidfuzz), Neo4j, Gephi, Maltego, i2 Analyst’s Notebook
Frequent use	Vendor-employee conflicts, shell vendors, bid rigging, beneficial ownership

Link and network analysis is the investigative discipline of turning scattered records into a structured map of who or what is connected to whom, and then reading the map for patterns that the individual records do not show. In fraud work it is the standard method for finding undisclosed conflicts of interest, corruption and fictitious-vendor schemes; in OSINT it connects public-record entities across registries. The method has three layers: (1) entity resolution, deciding that two records describe the same real-world person, company or account; (2) linking, recording relationships such as shared addresses, phone numbers, officers or payments; and (3) analysis, using charts, matrices and graph metrics to find clusters, bridges and anomalies. This article is a practical guide. The examples below use invented data; real investigations must confine analysis to lawful data sources (see OSINT Ethics).

1 The workflow

1. Define the question. “Does any employee have a financial interest in a vendor?” or “Which shell companies share control with this contractor?” A defined question prevents an unreadable “hairball” chart.
2. Collect structured data. Employee master, vendor master, accounts-payable history, bank account files, corporate registry extracts, procurement records, phone and email logs, public filings.
3. Standardize fields (section 2).
4. Resolve entities and create a link table with one row per relationship, including its source and the date it was observed.
5. Visualize and measure (sections 6 and 7).
6. Verify each link with an independent source, and grade confidence. A link is a lead until corroborated (the same discipline as the intelligence cycle).
7. Report with the evidence trail, not just the picture.

2 Entity resolution

Entity resolution (also called record linkage or deduplication) decides whether records refer to the same entity. The standard pipeline has five stages:^[1]

1. Standardize. Uppercase; strip punctuation; expand or contract abbreviations consistently; split names into parts; drop legal suffixes (LLC, INC, CORP, LTD) into a separate field; normalize addresses to postal standards (for example, “1200 North Market Street, Suite 400” becomes “1200 N MARKET ST STE 400”); convert phone numbers to digits only, then to a single format (E.164); remove spaces and hyphens from bank account and tax identifier fields.
2. Block. Comparing every record with every other is quadratic. Group candidate pairs by a cheap key (the first three letters of the name, postal code, last four digits of phone) so that only records in the same block are compared.
3. Compare. For each candidate pair, compute similarity per field (section 3).
4. Score and decide. Combine the field scores with weights (for example, tax ID 0.4, bank account 0.3, address 0.2, name 0.1), and classify as match, possible match or non-match using thresholds. The possible-match band goes to a human reviewer.
5. Cluster. Link matched pairs transitively (if A=B and B=C then A=B=C) into entity clusters, with care: transitive closure can chain unrelated entities together through one false match.

Strong versus weak identifiers. Treat unique identifiers (government tax ID, bank account and routing number, registered company number) as strong; names and addresses are weak. A match on a strong identifier is much more probative than a name match: a name match can be a common surname, while a shared bank account number is extremely unlikely to be a coincidence between an employee and a vendor.

3 Fuzzy-matching techniques

Technique	What it measures	Best for	Weakness
Exact match after standardization	Equality	Tax ID, account number, phone	Misses typos
Levenshtein (edit) distance	Number of single-character insertions, deletions, substitutions	Typos in names and addresses	Sensitive to word order
Jaro-Winkler	Similarity weighted toward matching prefixes (0 to 1)	Personal names	Over-scores short strings
Token set / Jaccard	Overlap of words, ignoring order	Company names, addresses	Common words dominate
Phonetic (Soundex, Metaphone)	Sound-alike codes	Spelling variants of names	English-centred; coarse
N-gram / TF-IDF cosine	Shared character sequences, weighted by rarity	Large-scale name search	Needs tuning

Worked example. Vendor master lists “ACME CONSULTING LLC” (19 characters) and the employee’s spouse’s business registry entry reads “ACME CONSULTNG LLC” (18 characters). The Levenshtein distance is 1 (one missing letter), so normalized similarity = 1 − 1/19 = 0.947. After removing the legal suffix the strings are “ACME CONSULTING” and “ACME CONSULTNG”, with distance still 1, similarity 1 − 1/15 = 0.933. A token-set Jaccard score on {ACME, CONSULTING} and {ACME, CONSULTNG} is 1/3 = 0.33 because one token mismatches, which shows why character-level and token-level measures are combined. A reasonable rule: character similarity of 0.90 or higher on a name and an exact match on a second field goes to review.

In Python:

from rapidfuzz import fuzz
fuzz.ratio("ACME CONSULTING", "ACME CONSULTNG")         # ~96.6
fuzz.token_set_ratio("ACME CONSULTING", "CONSULTING ACME")  # 100

Remember that a high name similarity is common among legitimate businesses (“Smith & Sons Plumbing” appears across the country). Set the threshold from a labelled sample, not from a guess.

4 Vendor-employee matching

The classic internal-fraud application. The Association of Certified Fraud Examiners reports that billing schemes through shell or conflicted vendors are among the most common asset-misappropriation and corruption forms (see ACFE Report to the Nations). The test is a series of joins between the employee master and the vendor master (and the remit-to files):

Match field	Join rule	Strength
Bank account number	Vendor account = employee payroll direct-deposit account	Very strong
Tax ID / SSN / EIN	Vendor TIN = employee SSN or an employee-controlled EIN	Very strong
Street address (normalized)	Vendor address = employee home address; including unit-less variants	Strong
Phone number	Vendor phone = employee home or mobile, or the same number shared among several vendors	Strong
Email	Same email, or same domain registered to a personal address	Medium
Surname / name	Fuzzy name match to vendor owner or officer	Weak (relatives are named differently)
PO Box / mail drop	Vendor address = known mail-drop or registered-agent address	Weak; use in combination

-- Vendors whose address matches an employee address (after both are standardized)
SELECT v.vendor_id, v.vendor_name, e.employee_id
FROM vendor_master v
JOIN employee_master e ON v.addr_std = e.addr_std;

-- Vendors sharing a bank account with any other vendor or employee
SELECT acct_no, COUNT(DISTINCT payee_id) AS n_payees
FROM (SELECT acct_no, vendor_id AS payee_id FROM vendor_bank
      UNION SELECT acct_no, employee_id FROM payroll_bank) t
GROUP BY acct_no HAVING COUNT(DISTINCT payee_id) > 1;

Dates matter. A vendor created three days after an employee changed address, or paid only while the employee held an approval role, is a stronger indicator than a standing match. Also compare the vendor-creation user with the approver of the first payment. Matches should be tested against employee relationship-disclosure forms, since a disclosed and approved interest is a control success, not a fraud. Relatives often have different surnames, so extend to emergency-contact and beneficiary data only where lawful and permitted by the employer’s policy and local privacy law.

5 Shell vendor detection

A shell (fictitious) vendor is an entity created to receive payments for goods or services never delivered. The detection approach combines master-data attributes with payment behaviour:^[2]

• Master-data signals: PO box or residential address; no phone, or a phone that goes to a mobile or voice-over-IP number; missing tax ID or a TIN that fails validation; generic names with initials or sequential names (“ABC Services,” “ABD Services”); address shared with several vendors or with a registered-agent address; recently incorporated; no website or a template website; vendor name resembling a legitimate supplier with a minor change.
• Payment signals: invoice numbers that are sequential with no gaps (a real vendor with other customers skips numbers); invoices just below the approval limit; round-dollar invoices; a single customer; vague service descriptions (“consulting,” “professional services”); invoices on weekends; payments approved by the same person, or sequenced right after vendor creation; no purchase order or receiving report.
• Behaviour signals: payments drawn out quickly with the vendor account later closed; payments to a bank account in a different state or country from the vendor address; vendors with payments and no contact history.

Test procedure. (1) Run the master-data screens; (2) run Benford and duplicate screens on the vendor’s invoices (see Journal Entry and Ledger Testing); (3) check the vendor against corporate registry, tax authority status and sanctions lists; (4) site-visit or confirm the vendor’s existence by independent contact details (not those on the invoice); (5) trace payments to the receiving account and to the ultimate beneficiary (see Asset Tracing). Bid rigging yields analogous patterns: bidders sharing addresses, phone numbers, typos, or document metadata (see Anti-Corruption OSINT).

6 Relationship matrices and link charts

An association (relationship) matrix is a grid with entities on both axes; a cell records whether a link exists, or its type or strength. It is the oldest link-analysis tool and still the best for dense data because it shows every pair, including the absences. A link chart draws entities as nodes and relationships as lines; it communicates better but becomes unreadable above a few dozen nodes.

	Vendor V1	Vendor V2	Vendor V3	Employee E1
Vendor V1	—	Same phone	—	Same address
Vendor V2	Same phone	—	Same bank acct	—
Vendor V3	—	Same bank acct	—	—
Employee E1	Same address	—	—	—

Read the matrix: V1 is tied to employee E1 by address, and to V2 by phone, while V2 is tied to V3 by bank account, so all three vendors are a single connected cluster reaching an employee, although no direct E1 to V3 link exists. That transitive chain is the finding a flat vendor-versus-employee join misses. Best practice for charts: use different edge types or colours for different link types, show confidence (solid for verified, dashed for inferred), keep a source reference on every edge, and filter to the cluster of interest.

7 Graph analysis

Once relationships are stored as a graph (a node table and an edge table), standard network measures give investigators a prioritized view:

• Connected components. Groups of nodes reachable from one another. Each component with a mixture of employees and vendors is a lead.
• Degree. The number of links of a node. A bank account used by 14 “different” vendors has degree 14.
• Betweenness centrality. The share of shortest paths between other nodes that pass through a node; high values identify brokers, controllers or intermediaries.
• Community detection (for example, the Louvain algorithm). Splits a large graph into densely connected groups, helpful in large data sets such as money-flow networks.
• Shortest path. The minimum chain of links between two named entities, answering “how is X connected to Y?”
• Bipartite projection. From a vendor-to-address graph, derive a vendor-to-vendor graph in which vendors sharing an address are linked.

import networkx as nx
G = nx.Graph()
G.add_edge("V1","E1", kind="address"); G.add_edge("V1","V2", kind="phone")
G.add_edge("V2","V3", kind="bank")
for comp in nx.connected_components(G):
    if any(n.startswith("E") for n in comp) and any(n.startswith("V") for n in comp):
        print("mixed cluster:", sorted(comp))
nx.betweenness_centrality(G)   # V1 and V2 score highest

Graph databases such as Neo4j make the same queries (for example, a path of up to four hops between an employee node and a vendor node) declarative, and are useful when the graph runs to millions of edges, as in money-laundering transaction analysis and cryptocurrency tracing. Machine-learning link prediction extends the approach; see AI Fraud Detection Platforms, but explainability requirements in court (see ML Forensics Explainability) mean the underlying links must always be shown.

8 Open-source data for links

External data lets an examiner extend links beyond internal records: corporate registries and their open aggregations (for example, OpenCorporates), securities filings on SEC EDGAR for officers and directors, court dockets, property and UCC filings, domain registration and archive data, and leaked-data collections such as the ICIJ Offshore Leaks Database, which links entities, officers, intermediaries and addresses from published investigations.^[3] Treat leak-derived records as leads: appearing in a database does not itself show wrongdoing, and the ICIJ itself states this on the database. Methods and tool inventories are covered in OSINT Tools, OSINT Disciplines and Asset Tracing.

9 Pitfalls and verification

• False positives from common values. Shared addresses at apartment buildings, shared registered-agent addresses, shared call-centre phone numbers and common surnames produce spurious links. Exclude high-frequency values (an address shared by hundreds of entities) or down-weight them.
• Transitive chaining. One wrong merge can fuse two unrelated clusters. Review cluster merges and keep the pairwise evidence.
• Stale data. Links must be dated; an address that matched in 2019 may not be current.
• Confirmation bias and over-reading. A tidy chart feels like proof. Record confidence ratings and look actively for disconfirming links.
• Privacy and legal limits. Restrict to lawful, authorized data; handle personal data of private individuals with care; follow employment and data-protection law (see OSINT Ethics).
• Presentation. Courts and boards need the underlying records. Attach each edge to its source document (see Evidence and Testimony and Report Writing).

See also: Occupational Fraud, Red Flags, Bank Statement and Cash Analysis, Fraud Detection Analytics, Anti-Corruption OSINT.

References

1. Christen, P. Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection (Springer), 2012; Fellegi, I. & Sunter, A. “A Theory for Record Linkage,” Journal of the American Statistical Association 64 (1969).
2. Association of Certified Fraud Examiners. Occupational Fraud 2024: A Report to the Nations (billing and corruption schemes). acfe.com
3. International Consortium of Investigative Journalists. Offshore Leaks Database. offshoreleaks.icij.org