How marketplaces can prepare verification evidence for an audit, bank or partner query: what to keep, how to package it and how to show it is unchanged.
Sooner or later someone asks how you checked a seller. A payment partner wants to know why an account was approved. A bank's due diligence team asks for evidence on your top sellers. An auditor samples a set of onboarding decisions. Sometimes it is a seller asking why they were rejected.
If the answer involves screenshots, exported spreadsheets and a search through Slack, it will take days and look weak. This post covers what good verification evidence looks like and how to package it so it stands up.
This is general information, not legal advice. What you must keep, and for how long, depends on your obligations. See GOV.UK and ICO guidance, and take advice.
The people asking usually want the same four things:
They also want confidence that the record has not been changed since.
Complete. Every check that contributed to the decision is included. If a check could not run, that is recorded too, rather than silently missing.
Readable by a person. A reviewer at a bank should be able to open a document and understand it without access to your systems.
Readable by a machine. Your own team, or the other party's, may need structured data to sample or analyse many cases.
Verifiable. There should be a way to show the files have not been altered since they were produced.
Proportionate. Include what is needed to answer the question, not every piece of personal data you hold. Sending more than necessary creates its own data protection risk.
If you build this in-house, a sensible structure for each seller:
Agree the format once, so every pack looks the same. Consistency makes packs faster to produce and easier for the receiver to trust.
TrustVerify produces PDF reports for individual checks: RPT-001 for KYC, RPT-002 for KYB and RPT-003 for AML. See the reports guide.
For an audit or a bank query, a regulatory evidence bundle (RPT-016) packages these together. You request one for an existing check with POST /api/v1/reports/rpt-016 (see the API reference), optionally adding your own reference, such as an audit or case number. Once it is ready, you download a ZIP containing:
A few design choices are worth knowing:
No empty promises. You can only ask for report types that can actually be produced for that check. Asking for one that cannot be is rejected up front, so a bundle never claims to contain a document it does not.
Gaps are listed. If a requested report was not produced, both the manifest and evidence.json list it with a reason.
Hashes, not signatures. Bundles are not signed. Re-hashing each file against the manifest shows whether anything has changed since you downloaded it. It does not prove who produced the archive. Be accurate about this when you describe the evidence to others.
A bundle is only as good as the records behind it. In TrustVerify, audit events are append-only, and reviewer decisions on KYC submissions are recorded as approved or rejected with optional notes. In your own systems, aim for the same: decisions recorded once, with who and when, and changes added as new events rather than edits.
Our post on designing a fraud review queue covers writing review notes someone else can understand six months later. [Planned URL, live on publication.]
Evidence is only available if you kept it, and you should only keep it as long as you have a reason to. These pull in opposite directions, so settle them in one policy. TrustVerify keeps customer due diligence check records for five years and then deletes them. Your own records need their own periods. [Planned URL, live on publication.]
By default, TrustVerify deletes due diligence check records after five years.
Not every query comes from a bank or auditor. A seller may ask why they were rejected, or ask for the personal data you hold about them under data protection law. These are different requests. A subject access request has its own rules and time limits, which the ICO explains in its guidance. Evidence bundles built for audits may contain internal notes or third-party information that needs careful handling before anything is shared with the seller. Agree in advance who handles each type of request, and take advice where you need it.
Run a dry run once a quarter. Pick five sellers at random and produce evidence for each as if a bank had asked. Time it, and note anything missing. The gaps you find on a quiet afternoon are much easier to fix than the ones a partner finds for you.
If you only remember a few points from this post, make them these:
None of these points requires a large team or a long project. Most can be put in place in a few weeks, and each one makes the next decision easier to explain.
Every check run through our KYC software for UK businesses has a recorded decision; our guide to choosing KYC software in the UK explains what to ask vendors about audit records.
See which reports TrustVerify produces for each check. Read the reports guide.
KYC, KYB, AML screening and fraud prevention in one place, with published pricing.
Compliance
Ongoing Monitoring: Why a One-Off Seller Check Goes Stale
Why sanctions and PEP checks at onboarding go stale, how ongoing monitoring works for marketplace sellers and what to do when an alert arrives.
Developer
Pulling Verification Reports via API
How to fetch KYC, KYB and AML screening reports by API, check they exist, download the PDF and assemble an evidence bundle for audit.
Developer
Using the TrustVerify Sandbox: Test Keys and Your First Check
A developer guide to the TrustVerify sandbox: test and live keys, deterministic synthetic results, magic test values and what the sandbox does not cover.
