A useful P2P evidence file lets another person test a proposition: this bank payment funded this order, this order credited this account, and these records show who controlled the relevant instructions. A folder of screenshots may show that something happened without establishing those connections.
The method below is designed for Turkish bank enquiries, platform disputes, civil claims and criminal investigations. It separates what a private user can preserve from records that may require institutional production. It also distinguishes direct observations, technical inferences and legal conclusions.
Start with the question the evidence must answer
Write a short issue statement before tracing. Examples include: “Did the seller deliver the agreed asset?”, “Was the bank payer the verified buyer?”, “Who approved release?”, “Which part of the restricted balance relates to the complaint?”, or “Was the operator trading its own assets or executing customer instructions?”
Different questions need different records. A blockchain transfer can help prove movement of a token but not the sender’s contractual authority. An IP record can help investigate control but rarely identifies a person conclusively by itself. A bank credit cannot show whether the payer was deceived in an external conversation.
Define the relevant period, accounts and assets. Preserve enough surrounding history to test the explanation, including unsuccessful orders, earlier acquisition and later returns. Do not restrict collection to the evidence that supports the preferred story.
Preserve originals before building the working file
- Acquire native exports where available. Obtain bank statements, order exports, account ledgers, chat exports and email originals. Record the account, source, export time and person acquiring them.
- Keep an untouched original copy. Store working copies separately. Preserve attachments and metadata together with the message export.
- Record integrity. A SHA-256 digest can identify whether a file later changed. It does not prove that the original content was truthful or issued by the claimed institution.
- Document transformations. Note OCR, translation, time-zone conversion, spreadsheet cleaning and any redaction. Retain the input and explain the method.
- Restrict unnecessary disclosure. Share relevant records through appropriate channels; do not publish identity documents or unrelated bank activity.
A screenshot is useful where an interface may change, but capture the order identifier, status, time and surrounding context. Pair it with a native export where possible. A cropped screenshot that omits the sender name can be actively misleading even if the visible amount is accurate.
Create a source register
| Field | Purpose | Example format |
|---|---|---|
| Evidence ID | A stable reference used in the report and annexes | BANK-001, ORDER-001, CHAT-001 |
| Source and account | Identifies who supplied the record and which account it concerns | Bank export, account ending 4321 |
| Coverage and acquisition | Separates the transaction period from the collection date | September statement, exported 4 October |
| Original filename and format | Allows the original to be found | Statement PDF or platform CSV |
| Integrity digest | Detects later file changes | SHA-256 of the acquired file |
| Transformation and limitation | Discloses what was changed or not obtained | Working copy translated; internal ledger not supplied |
Use identifiers consistently. A report that calls the same order “Trade 7”, “Payment B” and “Transaction 12” without a mapping makes independent review unnecessarily difficult. Keep personal names in a controlled identity schedule where the audience does not need them repeated in every diagram.
Join the bank, platform and blockchain records
The bank layer should include the sending and receiving accounts, amount, currency, booking and value dates where available, timestamp, reference, payment channel, return and restriction. The platform layer should include advertisement and order IDs, UIDs, verified names visible at the time, rate, quantity, messages, payment confirmation, release event and internal entries. The blockchain layer begins only where a real on-chain event exists.
For each on-chain event, record the network and chain identifier where relevant, transaction hash, block and time, sender, recipient, token contract, decimals, actual amount, fee asset and status. USDT on different networks is not one interchangeable ledger object. A familiar token symbol is insufficient to establish authenticity.
Capital Markets Law Article 35/C(5) addresses secure, accessible and traceable provider records for customer wallets and fund-transfer accounts. III-35/B.2 also distinguishes an institution’s internal ledger from distributed-ledger records. That distinction should remain visible in the report.
The transaction reconciliation row
A working table should contain, at minimum: case reference; bank transaction reference; payer and recipient identifiers; fiat amount and currency; original timestamp and zone; normalised timestamp; P2P order ID; buyer and seller UID; agreed rate and asset quantity; fees; release event; internal-ledger reference; withdrawal reference; network; token contract; transaction hash where one exists; refund or reversal; evidence IDs; and unresolved issue.
Do not force one payment into one order. A buyer may make instalments, several users may claim the same payment, or one order may be cancelled and replaced. Use a separate allocation table for one-to-many and many-to-one relationships. Preserve unmatched items rather than deleting them to make totals agree.
A transaction hash should remain blank with an explanation where the event was an internal platform credit. Writing “not applicable: off-chain release” is better than borrowing a later hot-wallet transaction and presenting it as the release itself.
Normalise time without inventing precision
Keep the original timestamp exactly as exported and record the source’s stated time zone. Add a separate normalised UTC field. A Turkish bank’s local time and an exchange’s UTC export can otherwise create a three-hour discrepancy. Check whether a screenshot uses the device’s travel time zone instead of the institution’s server time.
If a record gives only a date or minute, preserve that precision. Do not infer a second-level sequence from two minute-level entries. Separate instruction time, bank booking time, platform release time, blockchain inclusion time and later confirmation. They measure different stages.
In a hypothetical file, an order appears at 09:02 UTC and a bank credit at 12:01 Turkey time. After conversion, the credit apparently precedes the order by one minute. That warrants checking clock precision, exports and matching; it does not justify silently changing a timestamp or immediately declaring fabrication.
Reconcile units and avoid double counting
Distinguish gross order quantity, net delivered quantity, platform fees and network fees. If a fee is paid in a native network asset, keep it in a separate asset column before valuation. Do not add a deposit, internal transfer and withdrawal as three separate losses when they are successive movements of the same value.
Token decimals matter: a raw on-chain integer must be interpreted using the actual token’s decimals. A ticker or logo does not prove the contract is genuine. Failed transactions, approvals and zero-value events should not be treated as successful transfers of the quoted asset.
For a restricted bank balance, use opening balance plus documented credits minus debits and returns. For tax or trading-profit questions, do not reuse a tracing allocation convention as if it were the required accounting method. The tax-records guide explains that separate analysis.
Registration, access and control are different propositions
Platform KYC identifies the registered customer. A bank account identifies the bank’s customer. A blockchain address identifies a ledger destination. None alone proves who operated the device, negotiated the trade or approved the withdrawal at the relevant moment.
Potential corroboration includes login IPs, device identifiers, authentication events, password or SIM changes, API activity, remote-access evidence, message authorship, withdrawal-address changes and admissions supported by records. IP geolocation is approximate; shared networks, VPNs and compromised devices require caution. Explain the inference and plausible alternatives.
Never request a seed phrase or private key as routine proof of ownership. A signature-based verification, if appropriate in a specialised process, has its own risks and should use a clearly understood challenge. Ordinary legal intake normally needs public addresses and transaction records, not signing authority.
Treat wallet labels as sourced claims
For each attribution, record who supplied the label, when it was retrieved, what exactly it claims and its confidence or limitations. An exchange deposit address confirmed by that exchange is different from a crowdsourced tag. An exchange hot wallet generally does not identify which customer benefited from an internal credit.
Cross-chain bridges, routers, mixers, omnibus custody and UTXO change outputs can defeat simple “follow the next address” assumptions. Distinguish a direct transfer from exposure several hops away. Do not equate indirect exposure with ownership, criminal knowledge or contamination of an entire wallet balance.
The existing blockchain-forensics guide develops these technical issues. The P2P file still needs the off-chain order and account records that connect the graph to the disputed legal obligation.
Request the missing institutional evidence precisely
A preservation request should identify the account UID or bank account, order and transaction references, the relevant time range, the dispute or official file reference and the categories at risk of loss. Separate preservation from disclosure. A platform may preserve another user’s KYC and device records without being entitled to give them directly to you.
Useful categories include the complete order object and advertisement version; full in-platform chat and attachments; payment-confirmation and release logs; internal debit and credit entries; appeal decisions; relevant authentication and security events; withdrawal instructions and destination; and transfer information held under applicable rules.
Where CMK Article 128/A applies, the statutory text contains a ten-day response requirement for specified records requested by the prosecutor or judge. This should not be represented as a universal deadline for every private support request. Formal production and cross-border cooperation depend on the competent route.
Test competing explanations
| Observation | Possible explanation | Evidence that would discriminate |
|---|---|---|
| Payer differs from buyer | Triangle fraud, authorised third-party arrangement or display mismatch | Original instructions, verified identities, platform rules and pre-release messages |
| Immediate withdrawal | Ordinary custody preference or rapid dissipation | Historical routine, control records and destination evidence |
| High apparent margin | Market conditions, hidden fee or compensation for illicit risk | Contemporaneous prices, full fee calculation and communications |
| Repeated customer-linked receipts | Organised service or repeated proprietary trades | Ownership, mandates, contractual obligations and books |
The table does not assign probabilities without data. Its purpose is to identify the record that could change the conclusion. A report that cannot describe an alternative explanation may be overstating what the evidence supports.
Turn the file into a readable report
Open with the question, scope and material received. Follow with a participant map, chronology, reconciliation, findings, competing explanations, missing evidence and legal relevance. Use annex IDs at the point of each material factual statement. A diagram should show direction, asset, amount, time and source; avoid a large graph whose unexplained lines imply certainty.
Use clear evidence language: “the bank export records”, “the platform states”, “the address is labelled by”, “the records support the inference”, or “this cannot be determined from the material obtained”. Reserve legal conclusions for the legal analysis and make their assumptions explicit.
A private technical report and a court-appointed expert report have different procedural positions. Do not imply that a private report is an official finding or that a software risk score determines guilt. The P2P investigation guide explains how the evidence relates to knowledge and participation; the civil guide connects it to delivery and restitution.
Before submitting the file
- Can every material amount be traced to a source record?
- Are internal ledger events distinguished from on-chain transactions?
- Are names, identifiers, networks, decimals and time zones consistent?
- Are refunds, reversals and adverse facts included?
- Can another reviewer reproduce the reconciliation from the originals?
- Are missing records and uncertain attributions stated clearly?
- Have unnecessary identity data and authentication secrets been excluded from shared copies?
These checks make a file reviewable; they do not guarantee a bank, platform or court will accept its legal conclusion. For the rule governing the underlying problem, return to the Turkish P2P law collection and select the relevant account-freeze, fraud, regulatory or civil route.
