{
"slug": "nydfs-virtual-currency-guidance-meeting-cybersecurity-fraud-escalation",
"topic_id": "TOPIC-081",
"cluster": "Digital Asset Custody",
"tier": "Tier B",
"title": "What an examiner wants to see for a large transfer",
"summary": "Supervisory expectations for virtual currency businesses include non-repudiable records for significant transactions. Application logs are not that, and examiners increasingly say so.",
"lede": "An examiner asks for the authorisation record on a large withdrawal. The response is a database export showing an approval status and a user identifier, and the examination proceeds from there in a direction nobody enjoys.",
"date": "2024-07-27",
"category": "Crypto",
"author_id": "margot-reyes",
"tags": [
"NYDFS",
"supervision",
"examination",
"virtual currency",
"audit trail",
"compliance"
],
"image_title": "Examiner Large Transfer Record",
"schema": "Article",
"key_takeaways": [
"Supervisory expectations emphasise records that cannot be repudiated or altered by the entity producing them.",
"An application-generated approval record is an assertion by the supervised entity about itself.",
"A signed receipt over the rendered transfer is the same information in a form the examiner can verify independently."
],
"body": [
{
"type": "h2",
"text": "The examination question"
},
{
"type": "diagram",
"kind": "compare",
"alt": "An application-generated approval record versus a receipt the examiner can verify independently",
"caption": "The examination question moves from assessing your controls to checking a signature.",
"nodes": [],
"left": {
"title": "Application record",
"items": [
"Approval status field",
"User identifier",
"Written by your systems",
"Integrity assessed, not proved"
]
},
"right": {
"title": "Verifiable receipt",
"items": [
"Named individual and credential",
"User verification state",
"Issuer countersignature",
"Checked against a published key"
]
}
},
{
"type": "p",
"html": "Examinations sample transactions and trace controls. For a large transfer the trace is roughly: who initiated it, who approved it, what were they looking at, and how do you know."
},
{
"type": "table",
"head": [
"Question",
"Common answer",
"Examiner's follow-up"
],
"rows": [
[
"Who initiated?",
"User ID from the application log",
"How do you know that was the person?"
],
[
"Who approved?",
"Approval status and approver field",
"Who can write that field?"
],
[
"What did they see?",
"The transaction detail page",
"How do you know what it showed at the time?"
],
[
"Could the record be altered?",
"We have access controls",
"Who has database access?"
]
]
},
{
"type": "p",
"html": "The fourth row is where the conversation typically becomes uncomfortable, because the honest answer includes platform administrators, integration accounts and anyone with production database access."
},
{
"type": "h2",
"text": "Why self-generated records are weak"
},
{
"type": "p",
"html": "The record is produced by the supervised entity, stored in its systems, and attested by its staff. Every element of it is within the entity's control."
},
{
"type": "p",
"html": "This is not an accusation of misconduct. It is a structural observation about what the record can establish, and it applies equally to entities with excellent controls. The examiner's concern is what the record proves, not what the entity did."
},
{
"type": "h2",
"text": "What changes with a verifiable receipt"
},
{
"type": "code",
"text": "# What the examiner receives\n\n transfer-2026-04412.receipt\n issuer-jwks.json (as published, with rotation history)\n verify (the verification tool)\n\n# What they can establish without trusting the entity's systems:\n\n ✓ the statement was signed by a credential enrolled to a\n named individual\n ✓ user verification was performed at signing\n ✓ the statement contains the destination, asset and amount\n that executed\n ✓ the issuer countersigned at the stated time\n ✓ nothing has been altered since"
},
{
"type": "p",
"html": "The examiner is no longer assessing the entity's log integrity. They are checking a signature, which is a mechanical operation with a definite result."
},
{
"type": "h2",
"text": "The escalation dimension"
},
{
"type": "p",
"html": "Supervisory expectations commonly include escalation procedures: unusual activity is reviewed by someone with authority, and that review is documented."
},
{
"type": "p",
"html": "Escalation records have the same weakness as approval records and one additional one: they are often written after the fact, as a narrative, rather than captured at the moment of decision."
},
{
"type": "ul",
"items": [
"What triggered the escalation, in structured terms",
"What the reviewer was shown, including the alert context",
"What they decided, and on what basis",
"Whether the transaction proceeded, and who released it"
]
},
{
"type": "p",
"html": "Each of these is capturable at the moment it happens. Reconstructing them from memory and email threads during an examination is what makes examinations long."
},
{
"type": "h2",
"text": "What to prepare before an examination"
},
{
"type": "ol",
"items": [
"Identify the transaction tiers that examiners are likely to sample — typically the largest, the unusual, and any that triggered escalation.",
"For each, establish what record currently exists and who could have written it.",
"Add signed receipts at the approval and escalation points for those tiers.",
"Publish the issuer key at a stable location and document its rotation history.",
"Prepare the verification tool and instructions as part of the examination package."
]
},
{
"type": "p",
"html": "The fifth point is worth doing deliberately. An examiner handed a verification tool and asked to run it themselves is being offered something unusual, and the offer itself communicates confidence."
},
{
"type": "h2",
"text": "Scope, honestly"
},
{
"type": "p",
"html": "This addresses the authorisation and escalation records for significant transactions. It does not address transaction monitoring quality, sanctions screening, customer due diligence, or the many other areas an examination covers."
},
{
"type": "p",
"html": "It is one part of a supervisory relationship, and the part where the gap between what entities have and what examiners want is currently widest."
},
{
"type": "p",
"html": "This describes supervisory expectations at a general level and is not legal or compliance advice. Requirements are specific to licence type and jurisdiction; take them to counsel."
},
{
"type": "h2",
"text": "The trace an examiner runs"
},
{
"type": "table",
"caption": "Where the conversation usually gets uncomfortable",
"head": [
"Question",
"Common answer",
"Follow-up"
],
"rows": [
[
"Who initiated?",
"User ID from the application log",
"How do you know that was the person?"
],
[
"Who approved?",
"Approval status and approver field",
"Who can write that field?"
],
[
"What did they see?",
"The transaction detail page",
"How do you know what it showed at the time?"
],
[
"Could the record be altered?",
"We have access controls",
"Who has production database access?"
]
]
},
{
"type": "p",
"html": "The last row is where the honest answer includes platform administrators, integration accounts and anyone with production database access. That is not an accusation about conduct; it is a structural observation about what the record can establish, and it applies equally to entities with excellent controls."
},
{
"type": "h2",
"text": "Objections and honest limits"
},
{
"type": "p",
"html": "“Our logs are immutable.” Immutability protects against later alteration. It does not establish that the entry described something a human actually did, because the entry reflects what the application asserted at the time."
},
{
"type": "p",
"html": "“Escalation is documented in the case notes.” Escalation records share the weakness of approval records plus one more: they are usually written after the fact as narrative rather than captured at the moment of decision."
}
],
"faq": [
{
"q": "Why are application approval records weak for an examiner?",
"a": "They are produced, stored and attested by the supervised entity. That is a structural point about what the record proves, not an accusation about conduct."
},
{
"q": "What does a verifiable receipt let an examiner do?",
"a": "Check a signature mechanically, without assessing the entity's log integrity or database access controls."
},
{
"q": "Why do escalation records need particular attention?",
"a": "They share the weakness of approval records and are often written after the fact as narrative rather than captured at the moment of decision."
},
{
"q": "Does this cover the whole examination?",
"a": "No. It addresses authorisation and escalation records for significant transactions — one part of a supervisory relationship, and currently the widest gap."
},
{
"q": "What does a verifiable receipt change?",
"a": "The examiner checks a signature mechanically instead of assessing your log integrity and database access controls."
}
],
"sources": [
{
"t": "NYDFS 23 NYCRR Part 500 — Cybersecurity Requirements",
"u": "https://www.dfs.ny.gov/industry_guidance/cybersecurity"
},
{
"t": "Published examination manuals and supervisory expectations for money transmission."
},
{
"t": "RFC 8037 — CFRG elliptic curve signatures for JOSE",
"u": "https://www.rfc-editor.org/rfc/rfc8037"
},
{
"t": "NYDFS — virtual currency business activity",
"u": "https://www.dfs.ny.gov/virtual_currency_businesses"
}
],
"related": [
{
"slug": "fireblocks-bitgo-api-perimeter-gating-automated-custodial",
"title": "The custody API is the perimeter",
"category": "Crypto"
},
{
"slug": "automated-compliance-auditing-manav-verify-external-auditors-re",
"title": "Re-performing controls offline",
"category": "Developer"
},
{
"slug": "federal-rules-evidence-rule-902-13-14",
"title": "Self-authenticating electronic records",
"category": "Compliance"
}
],
"image": "https://cdn.twc.sh/images/igcache/Examiner%20Large%20Transfer%20Record/1200_630/blog.jpg",
"wordcount": 939,
"url": "/blog/nydfs-virtual-currency-guidance-meeting-cybersecurity-fraud-escalation.html",
"reading_time": "4 min read",
"meta_description": "Supervisory expectations for virtual currency businesses include non-repudiable records for significant transactions.",
"hub": {
"slug": "topics/digital-asset-custody",
"title": "Digital asset custody"
},
"answer": "A record they can test without trusting your systems. NYDFS supervisory expectations, alongside 23 NYCRR Part 500, emphasise non-repudiable audit trails. An application row showing an approval status and a user identifier is an assertion the supervised entity made about itself.",
"answer_q": "What does a NYDFS examiner want to see for a large virtual currency transfer?",
"entities": [
{
"name": "New York State Department of Financial Services",
"type": "GovernmentOrganization",
"url": "https://www.dfs.ny.gov/virtual_currency_businesses",
"primary": true
}
],
"glossary": [
{
"term": "Non-repudiation",
"def": "The property that the party who authorised an action cannot credibly deny it, because the evidence does not depend on records they control."
},
{
"term": "Escalation record",
"def": "Documentation that unusual activity was reviewed by someone with authority. Frequently reconstructed after the fact rather than captured at the decision."
},
{
"term": "Supervisory examination",
"def": "A regulator's periodic test of controls, typically by sampling transactions and tracing the evidence behind each."
}
],
"checklist": {
"title": "Preparing before the examination",
"id": "prepare",
"desc": "Five steps, and the fifth communicates more than the other four.",
"steps": [
{
"name": "Identify the tiers examiners will sample.",
"text": "Largest transfers, unusual ones, anything that triggered escalation."
},
{
"name": "Establish what record exists today.",
"text": "And who could have written it."
},
{
"name": "Add signed receipts at approval and escalation.",
"text": "For those tiers only."
},
{
"name": "Publish the issuer key at a stable location.",
"text": "With a documented rotation history, retained for the full period."
},
{
"name": "Hand the examiner the verification tool.",
"text": "Being asked to run it themselves is unusual, and the offer communicates confidence."
}
]
},
"cta": {
"title": "Where this fits in Manav",
"html": "Manav receipts verify against a published Ed25519 key with no call to the issuer, which means an examiner can test the full population themselves and you never grant them production access.",
"href": "../docs.html",
"label": "See offline verification"
}
}