Link Analysis in Financial Investigations

What Link Analysis Shows in a Financial Investigation

Link analysis shows how separate transactions form a payment network, including intermediaries and loops that are difficult to recognise across individual statements. Start with the records you hold, then use the network to direct document requests and enquiries.

Consider this fictional example. Alder Services and Beacon Trading look like separate suppliers, but account P-01 pays both. All amounts below are Australian dollars. The page numbers are illustrative numbered PDF pages.

Transaction	Timing	Payment	Amount	Fictional source
T01	First payment	P-01 pays Alder Services	$6,000	payer-statement.pdf, page 2
T02	Two days later	P-01 pays Beacon Trading	$4,000	payer-statement.pdf, page 2
T03	One week after T01	P-01 pays Alder Services	$6,000	payer-statement.pdf, page 3
T04	One day after T03	P-01 pays Beacon Trading	$5,000	payer-statement.pdf, page 3

The chart has two outgoing payment links from P-01. The Alder link totals $12,000 across T01 and T03. The Beacon link totals $9,000 across T02 and T04. Together, the links account for all $21,000 in the four transactions.

The shared payer gives you a relationship to test. Supplier records might reveal genuine separate businesses, common control or shell suppliers used to receive money. A chart alone cannot choose between those explanations.

In a fraud investigation, add verified ownership information to test whether payees collude or share a controller. Follow onward transfers to examine a chain of suspected mule accounts. For suspected kickbacks, compare payments to suppliers with later receipts by someone who influences purchasing decisions. The chart guides that enquiry after extraction and reconciliation, before conclusions about the scheme.

Turning Bank Statements Into Nodes and Links

Build the network by giving each distinct account, account holder and counterparty a stable identity, then connecting them with the recorded payments. A counterparty is the person or entity on the other side of a transaction.

Keep account nodes separate from person or company nodes. One person can hold several accounts. An ownership link connects that person to each account, while a payment link connects the accounts involved in a transfer. Record the source establishing ownership separately from the statement establishing payment.

A payment link can carry one transaction or an aggregate for a defined period. Its weight might be total value or transaction count. State which measure you use, retain the individual rows and keep payments in opposite directions separate. Summing both directions into one figure can hide a round trip.

Resolve names before drawing the chart. “Alder Services”, “ALDER SVC” and “Alder Services Pty Ltd” can create three false nodes for one payee. Keep the original statement wording alongside a normalised name. Merge records using supporting identifiers, such as the destination account, instead of a similar name alone.

FinTrace saves investigators and forensic accountants hours of statement conversion and review by consolidating supplied PDFs into a searchable ledger and a clear findings report. Findings cite their source PDF filename and page, putting the supporting evidence beside the analysis. That source-backed ledger supports your own network preparation and further investigation.

Network Patterns Worth Testing

Network patterns identify relationships that deserve further enquiry, with transaction timing and supporting records deciding what each pattern means. A busy account or a shared contact detail is a lead, not a finding of fraud.

Pattern	What the chart shows	What to test
Circular flow	Money travels through accounts and returns to its starting account	Compare amounts, fees and timing, then examine the reason for each leg
Hub account	One account pays or receives from many others	Identify its holder and compare the activity with its business or administrative role
Pass-through account	Receipts are followed by similar outgoing amounts, leaving little retained	Match the movements and examine the account’s role in the onward payments
Shared contact details	Separate payees have the same address or phone number	Check the original records and whether a shared office or agent explains the overlap

Use distinct link types for payment, ownership and shared contact information. An address match must not look like a bank transfer. Its source might be a supplier form or company record, rather than a statement.

A nominee arrangement can appear as an intermediary between an employer and an employee’s relative. For example, the employer pays a supplier account, which then pays the relative. Test the supplier’s ownership and invoices, along with the reason for the onward payment. The relative’s position in the chart gives you a question to investigate, while those records help answer it.

Use a flow-of-funds chart when the immediate task is showing the direction and sequence of money movements. A wider link chart adds the people and entity relationships around those movements.

Charts That Stand Up in Court

A financial link chart prepared for service must let the reader trace every payment link to its transactions and source statement pages. Give each link an identifier tied to an accompanying transaction schedule. For an aggregate, the schedule must list every contributing transaction and reproduce the displayed total.

Keep the original statement set and the chart’s underlying ledger together. Record how you merged names, selected the period and aggregated payments. Show verified relationships separately from hypotheses so the picture does not turn an investigative inference into an apparent fact.

The method you use to draw the chart changes the effort of updating it and checking its totals.

Method	Practical use	Work to manage
Hand-drawn chart	A small network or an early discussion of possible relationships	Each change needs manual redrawing and checking against the schedule
Spreadsheet pivots	Grouping payments by payer and payee, with reproducible totals	A separate chart still needs clear identities, direction and source references
Dedicated analyst software	Exploring larger networks and changing views as the enquiry develops	Import rules and identity mappings need to match the underlying records

i2 Analyst’s Notebook is i2 Group’s visual analysis software, owned by N. Harris Computer Corporation. It supports network and temporal views, letting analysts examine relationships and the sequence of events. Choose a drawing method for the size and changing needs of the enquiry, without making the software name a substitute for the evidence schedule.

Make payment arrows point from payer to recipient. Scale line thickness to value only when the chart explains the scale, and label amounts in their currency. Use consistent node shapes for people, accounts and companies. A timeline view can show whether a receipt preceded an onward payment, which a static network view can obscure.

For a dense network, prepare a small overview and separate detail views. Keep identifiers consistent between them. Include the selected period and what the chart omits so readers can understand the limits of the picture.

Limits of a Link Chart

A payment link establishes the recorded movement of money, while its purpose needs other evidence. A transfer to a relative might be a loan, reimbursement or gift. An invoice, agreement or witness account can explain the transaction in a way the statement cannot.

A missing link can reflect missing statements or an unrecorded destination account. It does not establish that the payment never occurred. Label an unknown destination as unknown instead of joining it to a person because the reference looks familiar.

Bank descriptions can truncate names, and several people can share a name. A shared account or repeated value also needs context before you infer common control. Keep confirmed identifiers distinct from uncertain matches.

Aggregation can hide sequence. Two accounts might exchange the same total across a period, while the order of those transfers changes the explanation. Return to the individual transactions when testing a circular flow or pass-through pattern.

Preparing Bank Data for an i2 Import

Prepare an i2 Analyst’s Notebook import by resolving entity identities and mapping each transaction row to its accounts and payment properties. The Analyst’s Notebook import documentation describes spreadsheet and text imports through an import specification. That specification determines how the columns become entities and links.

Data extraction comes before link analysis. Convert bank PDFs or other unstructured source records into rows, then normalise dates and identifiers while retaining the original values. Reconcile transaction counts and debit and credit totals against the source records. Analysis of imported links then tests relationships within that reconciled dataset.

Treat each transaction row as a record with its own identifier. Map account identifiers to entities and payment direction to the relationship between them. Keep amount, currency and date as payment properties. The source reference must identify the original document and page, not merely the spreadsheet used for import.

For bank data, prepare the following fields. They are a practical transaction model for your import, not a universal fixed column order.

Field	What it supplies
Date	The recorded transaction date, with a consistent date interpretation
Amount	The payment value, with currency retained in a separate field
Direction	The debit or credit direction relative to the source statement account
Source account	A stable identifier for the paying account
Destination account	A stable identifier for the receiving account, or an explicit unknown
Counterparty name	The normalised person or entity name alongside the original description
Reference	The payment reference retained as recorded
Source statement page	The PDF filename and page behind the transaction

Add a unique transaction identifier so an import or refresh does not duplicate payments. When both account statements show the same transfer, reconcile the two observations into one payment. Retain both source references behind it.

Before import, merge spelling variants of one counterparty and link accounts to the same holder where the records establish that identity. Keep a mapping of original values to the chosen identifiers. The import specification guidance explains how identity rules decide whether incoming entities or links are the same.

Import a small known subset first. Confirm that payer and recipient are separate nodes, arrows run in the correct direction and amounts match the source rows. For the fictional example above, the import must produce $12,000 from P-01 to Alder and $9,000 from P-01 to Beacon. Confirm that each link still leads to its transaction identifiers and source pages before importing the wider ledger.

For external enrichment, i2 documents Data Connectors for Analyst’s Notebook Subscription and other i2 deployments. These can bring external-source results into the analysis, including open-source intelligence (OSINT). A connector changes the input trail: retain the provider, query and retrieval time alongside each returned record. Keep the originating record or permitted copy and the connector’s record identifier.

Record an OSINT relationship’s original URL or document reference and the passage supporting it. Distinguish a verified company-registration fact from an inferred association based on a shared address. An imported association needs its own relationship type and confidence note, separate from a bank-proven payment. A connector result does not establish common control merely because two names match.

The Analyst’s Notebook publishing guidance describes PDF exports and snapshots for sharing a chart. Retain the native chart alongside the exported view and its underlying transaction schedule. Supply the entity-identity mapping, import specification and source-reference index with the data needed to reproduce each relationship. Record filters and the period shown so omitted records remain identifiable.

Open the exported view and check that relationship identifiers remain readable. Use those identifiers to recover each contributing bank transaction or OSINT record, including its source page or URL. Reconcile aggregate links to their schedule totals after export. This preserves a checkable evidence trail through extraction, import and presentation.