Common warning signs include an audit that covers testnet code instead of production, missing remediation evidence, custody documentation without key management procedures, AML policies with no functioning monitoring tool, and a penetration test that excludes smart contracts or APIs. If the regulator asks for a live demonstration and the team cannot produce one, the package is not ready.
What a VASP package must prove before a regulator will trust it
A review-ready package has to show that the controls work in the real operating environment, not just on paper. If the evidence is drawn from test environments, omits remediation proof, or describes custody and AML controls without proving they are implemented, the reviewer cannot rely on it. The question is whether the package demonstrates executable governance, not whether it reads like a policy set.
The strongest packages make the operating model legible: who owns custody decisions, how key management is controlled, how sanctions or AML monitoring is actually performed, and what evidence shows those controls are active. That is why a regulator will treat a polished narrative with missing artifacts as weaker than a narrower package that proves the critical controls end to end.
For custody and operational control gaps, teams should make sure the package describes the live systems and not an aspirational future state. A custody summary that lacks key handling procedures, approval paths, or recovery steps leaves a reviewer unable to test whether the control design matches the risk. Where APIs, smart contracts, or other transaction paths are part of the business model, their security evidence needs to be included because they are part of the reviewable control surface. See also the Vendor Security Assessment Template for the evidence-heavy style regulators and risk teams expect, and the Security Questionnaires Guide for structuring answers around proof rather than assertions.
Where VASP review packages usually fail
The common failure pattern is a mismatch between the claims in the submission and the scope that a reviewer actually needs to test. Testnet-only audit evidence, a penetration test that excludes smart contracts or APIs, and policies that mention monitoring without a functioning tool all signal that the package is incomplete. A regulator is looking for evidence that the controls cover the production risk path, not just a representative environment.
Another recurring weakness is fragmented evidence. A team may provide AML policy documents, custody diagrams, and an audit report, but if the remediation trail is missing, the reviewer cannot tell whether the findings were closed, accepted, or deferred. That is especially damaging where the package depends on third-party tooling, external custody providers, or platform-level controls, because the reviewer needs to see how responsibility is allocated and verified. The Vendor Security Assessment Template is useful here because it forces clear evidence requests, ownership, and approval logic rather than a document dump.
Reviewers also look for scope discipline. If the package covers only one side of the business, such as custody, while omitting transaction monitoring, incident handling, or production access control, it creates the impression that the team has not reconciled the full operational risk. The result is usually not an outright rejection on the first pass, but a request for more evidence that delays licensing and can expose deeper control gaps.
What to fix before you submit again
The practical fix is to turn the package into a controlled evidence set. Use a production-scoped control narrative, attach artifacts that demonstrate actual operation, and make it easy for the reviewer to trace each major claim to a record, a log, a report, or a live demo. If the reviewer cannot follow the control from policy to operation to evidence, the package is not yet reviewable.
Where remediation has been raised, include closure evidence, not just a statement that the issue was addressed. That means screenshots, change tickets, test results, sign-off records, or other durable proof that the corrective action landed in production. If the package depends on crypto custody or privileged access, the evidence should also show how keys, approvals, and emergency access are handled in practice, because those are the controls most likely to be challenged under review. The Security Policy Framework Guide helps teams separate policy, standard, procedure, and exception handling so the package does not blur intent with execution.
The final readiness test is simple: if the regulator asks for a live demonstration, the team should be able to show the workflow without improvising. A package that cannot survive a demonstration request usually still has documentation, but it does not yet have operational proof.
Risk and Threat Considerations
A weak VASP licensing package is not just a documentation problem, it is an exposure problem. Gaps in production evidence, custody controls, or monitoring can hide real operational weaknesses, while incomplete penetration testing can leave exploitable paths unexamined. In a regulated crypto environment, that creates both supervisory risk and a larger chance that a control failure goes undetected until after launch.
Failure mechanism: The package describes controls that are not actually operating in production, so reviewers miss gaps in custody, monitoring, remediation, or application security before approval.
Impact: The organisation can be delayed, refused, or required to resubmit, and it may also carry forward unresolved security weaknesses that increase the chance of loss, abuse, or regulatory scrutiny after go-live.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Production scope and evidence depend on knowing the live control surface. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Regulators need proof that monitoring and review are actually operating. | |
| IA-5 — Authenticator Management | Custody and privileged access packages depend on key and secret lifecycle control. | |
| Recommendation — Inventory the production systems, custody tools, APIs, and monitoring components in scope. Review audit evidence and monitoring output for the controls claimed in the package. Manage credentials, keys, and authenticator lifecycle with documented rotation and revocation. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | A live review depends on logs, traceability, and demonstrable security monitoring. |
| V4 — API and Web Service | API security evidence matters when the VASP relies on transaction or service interfaces. | |
| Recommendation — Verify that logging and error handling produce evidence suitable for review. Test and document API security controls before submitting the package. | ||
Practitioner Guidance
What to verify: Confirm that every major claim in the package has production evidence behind it, especially custody, monitoring, remediation closure, and any API or smart-contract testing that would affect real-world risk.
Decision rule: If a control cannot be demonstrated live, treat it as incomplete even when the written policy looks strong. A reviewer will usually trust execution evidence more than narrative polish.
Practitioner takeaway: The fastest path to review readiness is to prove the operating control, not to describe the intended control; if the evidence trail cannot survive a live demo, the package is still draft-quality.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org