A deposit from an address that turns out to be sanctioned
The money is on your books. The client is a real customer who passed KYC months ago, and nothing about the deposit looked unusual until the address was checked. The question now is what you will be able to show later about the moment you found out and what you did next.
Here a risk score helps least. Nobody disputes that an exact match on an official list is bad. A supervisor's questions are narrower and harder. Which list, held at what moment, was the address compared against? Under which written policy, and who decided? Can you produce all of that again in eighteen months?
What happens
- The screening returns a decision
One POST to /api/v1/screenings. The address is compared against the sanctions snapshot the deployment currently holds, the stablecoin issuers' own contracts are read live, and the baseline policy is applied. The response is BLOCK_PENDING_MLRO. The funds are held for the Money Laundering Reporting Officer and are neither returned automatically nor credited.
- A case opens with the evidence already attached
Everything that is not ALLOW opens a case. The signals, the coverage matrix and the fired rule are on it from the start, so nobody has to assemble the file from memory afterwards. A file assembled from memory is what fails an examination.
- A signed receipt is written at decision time
The receipt is an Ed25519 signature over the decision, its inputs, the policy version and the content hashes of the list snapshots it was compared against. Anyone holding the public key can verify it, including someone who does not trust you.
- Closing it needs two people
A release on a blocked case is four-eyes: proposed by one person, approved by another, and both recorded. The evidence pack shows that it happened without naming your staff to the recipient.
- A SAR draft is built, with the 'why' left blank
The draft is assembled from the stored rows: reporting entity, subject, addresses, amounts, timeline, coverage, snapshot hashes and the signed receipt. The reasons for suspicion are left blank. That judgement belongs to the MLRO, and KYTGate will not write it for them.
A real response
REAL OUTPUT · A real response, 26 September 2026, from a sandbox tenant screening the address the sandbox's own first-call example uses. Identifiers shortened; nothing else changed. You can produce your own in about a minute. The sandbox screen gives you this exact command with your key already in it.
{
"assessment": "ADVERSE_SIGNAL",
"decision": "BLOCK_PENDING_MLRO",
"assuranceTier": "PUBLIC_BASELINE",
"policyVersion": "baseline-v0.4",
"firedRuleIds": ["sanctions-direct"],
"coverage": {
"sanctions": "COMPLETE",
"issuerFreeze": "COMPLETE",
"transactionIntegrity": "NOT_AVAILABLE",
"walletOwnership": "NOT_AVAILABLE",
"processorEvidence": "MISSING",
"travelRule": "MISSING",
"actorAttribution": "NOT_AVAILABLE",
"sourceOfFundsExposure": "NOT_AVAILABLE",
"customerBehaviour": "NOT_AVAILABLE"
},
"signals": [
{ "provider": "sanctions-cache", "category": "sanctions", "severity": 100, "directness": "direct",
"summary": "Exact match: this address appears on the EU consolidated list. The list publishes this address under the designation of \"Garantex\"; that name is the publisher's, not KYTGate's. Read from the sanctions snapshot KYTGate held at 2026-09-26T06:00:45.081Z." },
{ "provider": "issuer:tether", "category": "issuer_blacklist", "severity": 100, "directness": "direct",
"summary": "USDT on ethereum: address is blacklisted by tether" },
{ "provider": "issuer:circle", "category": "issuer_blacklist", "severity": 100, "directness": "direct",
"summary": "USDC on ethereum: address is blacklisted by circle" },
{ "provider": "chainalysis-oracle", "category": "sanctions", "severity": 100, "directness": "direct",
"summary": "Chainalysis Sanctions Oracle: match" }
],
"risk": { "score": 100, "band": "LISTED", "scoreBasis": "listing", "confidence": 50,
"flags": ["coverage.incomplete", "issuer.frozen", "listing.exact"] },
"receiptId": "32a54584-…", "caseId": "fb399c6c-…", "buildVersion": "57a7f7c…"
}decision is BLOCK_PENDING_MLRO and firedRuleIds names the single rule that produced it. The decision came from a versioned policy, not from the number beside it.
risk.score is 100 with scoreBasis: "listing". An exact match sets the score directly instead of it being summed from contributions. confidence is 50 because only four of the nine checks applied here answered.
coverage says which checks did NOT run. Two are MISSING and five NOT_AVAILABLE, and the pack states in words what each absence leaves open.
The sanctions signal quotes the publisher's own designation and says so: the name "Garantex" comes from the EU. It also gives the time of the snapshot it was read from.
What this does not do
This says the address is on a list. It does not say who controls the wallet. KYTGate holds no proprietary attribution data and will not infer an owner.
A screening of an address is not a screening of a transaction. `transactionIntegrity` reads NOT_AVAILABLE above because there was no transfer to verify.
Nothing here files anything. The SAR draft is a draft, goAML schemas differ per FIU, and submission is yours.
Next
Questions
No. It decides and records. BLOCK_PENDING_MLRO means your system should hold the credit pending review; moving money is your platform's job and your MLRO's call.
Because a machine should not close a sanctions case. The decision holds the funds and routes the question to the person who is accountable for it, and the release, if there is one, is recorded as an MLRO override on the receipt.
The receipt records which snapshot was compared against, by content hash. If a designation is later withdrawn, the original decision can still be shown to be correct on the data held at the time.
One e-mail link gives you an isolated tenant and an API key. The screen that shows the key also shows a first call with a real listed address already in it. The sandbox includes fifty screenings a month on real data and is deleted after seven days.