Payments & Banking Foundation Explainer

What can a payment record actually show?¶

A payment record is a service provider’s record of an attempted or completed movement of money or value. It may establish the accounts, amount, time, status and route involved - but the name on an account does not automatically identify the person who pressed the button or benefited.

In one sentence

A payment record follows money between financial identifiers; personal attribution follows the people controlling the relevant accounts, devices and decisions.

Instruction

Authorisation

Processing

Receiving account

Settlement

Onward movement

One payment can create several records¶

The customer’s application, sending institution, payment network, receiving institution, merchant or wallet provider may each observe a different stage. Their times and terminology can differ without one record necessarily being wrong. Payment authorisation and payment processing are related stages, not interchangeable labels.

InstructionThe customer or system creates a request to move funds.

AuthorisationThe provider checks and approves or rejects the request.

ProcessingPayment messages pass through the relevant scheme or service.

Credit or settlementThe receiving side records the value and its final status.

A statement may show posting or settlement rather than the moment the user acted. Pending and completed transactions should therefore be read using the provider’s definitions, as should reversed or refunded events.

The complete event is stronger than the amount¶

Example payment record

Transaction IDTX-884219

Authorised17 Aug 2026 · 14:07:31.284 UTC

Amount£1,850.00

Receiving accountEnding 4219

ReferenceBIKE27

StatusCompleted

Together these fields identify a particular provider-recorded event. “£1,850 paid to Sam” is easier to say but discards most of what makes the record usable. A [transaction reference](../pay-005/) helps locate and compare the event, although [a customer-entered reference does not by itself prove the purpose of the transfer](../pay-041/).

Depending on the provider and payment type, supporting records may also include:

account opening and verification material;
login and authentication events;
device, application or browser identifiers;
beneficiary creation and changes;
risk alerts and payment challenges;
notification and confirmation events;
reversals, refunds, cash withdrawals and onward transfers.

The account holder is not necessarily the user¶

EstablishedAccount ••4219 is held by Sam DyerThe provider associates Sam with the customer relationship.

Still openWhether Sam knowingly authorised the onward transferAccess sessions, device possession, authentication, communications and conduct address control and knowledge.

The payer, account holder, user and beneficiary can be different. That is not a reason to treat the payment as weak evidence. It identifies the propositions that the next records must test.

A compromised account, coerced payer, shared business account, scheduled transaction or mule arrangement may explain why the holder and user differ. Each explanation leaves different evidence in the access, device, communications and onward-money records.

The payment may corroborate another event¶

Financial eventThe victim authorised transaction TX-884219 using reference BIKE27.

Wider caseThe same reference and account details appear in seller message MSG-90318 six minutes earlier.

Matching identifiers and precise times can link a payment to an advert, message, purchase, login or physical event. That comparison should retain the provenance of each source: the bank records the transaction; the messaging service records the instruction. Together they explain more than either does alone. This is strong corroboration: independent systems agree on the distinctive reference, account details, amount and sequence while recording different parts of the event. Following the complete payment chain then tests control and benefit without confusing movement of money with personal attribution.

Operational takeaway

State precisely what the payment system recorded, then follow control and benefit. Use complete transaction fields to trace the route and use account-access, device, communication and real-world evidence to establish who made the money move and why.

Investigator walkthroughFollow a marketplace payment to suspects →Separate offender exampleSee Dodgy Dave divert an invoice through a mule account →

Explore the linked payment questions