Technological Due Diligence
This page summarises WhyAML's Technological Due Diligence - the document your firm places in its Practice-Wide Risk Assessment folder when adopting WhyAML.
Under Regulation 19(4)(c) of the Money Laundering Regulations, your firm must assess the risks of adopting new verification technology. WhyAML provides the complete TDD pack for its two-stage method: certified identity verification from bank-held data, then attribution through the Witness Model. This summary covers the key elements.
The full TDD document (v5.0) is available in your client portal after onboarding. It includes the complete risk assessment, the particulars of the certified verification service relied upon (Schedule 1 Part A), regulatory mapping references, G-RADE engine specification, and audit trail field descriptions.
The G-RADE™ confidence engine
G-RADE is WhyAML's proprietary confidence accumulation engine. It does not make binary pass/fail decisions - it measures the cumulative weight of evidence across all proof elements and determines when the institutional connection confidence threshold has been reached.
How G-RADE works
Every proof element adds to the confidence score. No single element is load-bearing. A low G-RADE score requires more proof elements - it never rejects the individual. A high score allows a faster path. The threshold is fixed, documented, and auditable.
Your firm sets its own minimum threshold through the security slider. This is recorded as part of your audit trail and PWRA documentation.
See how the verification process works in our FAQThree proof levels
These are the attribution-stage proof elements. Identity is established first by the certified verification service; the levels below then bind that verified person to control of the regulated account and the paying wallet. Each level provides independent evidence, and together they form a composite proof significantly stronger than any single document-based check.
Self-Screener (Knowledge-Based)
Dynamic knowledge-based authentication using OSINT identity triangulation, geographic cross-referencing, and 4-9 dynamically generated questions from the individual's own observable financial history. Questions are unique to the genuine account holder - they cannot be pre-set or guessed.
MCP-TLS Institutional Connection
Live institutional account connection proof via MCP-TLS inside AWS Nitro Enclave - a hardware-isolated trusted execution environment. Demonstrates in real time that the individual controls access to their institutional account.
Transaction-Based Proof
A natural transfer from the connected account as real-time proof of control, with the customer's own signature over the specific recipient and amount verified before value moves. This binds the identity established at Stage 1 to the specific wallet from which the payment is made.
Risk assessment summary
The TDD assesses each risk associated with adopting WhyAML, as required by Regulation 19(4)(c).
Reliance on a certified Digital Verification Service (DVS)
Identity is verified by a provider certified under the UK Digital Verification Services Trust Framework and listed on the OfDIA register - the route the 26 February 2026 HMT/DSIT guidance expressly recognises as a reliable and independent source for Regulation 28. The minimum profile accepted is GPG45 M1C, and the profile achieved is recorded on every Certificate. The provider's name, register entry and certified role are set out in Schedule 1 Part A of the firm's own TDD, so the register entry can be checked from the firm's file. WhyAML itself is not the DVS: it adds attribution through the Witness Model. Adoption is recorded under Reg 19(4)(c) with full Technological Due Diligence documentation, and the company-level Regulatory Defence cover funds defence of the methodology if it is formally challenged.
False positive (impersonation)
Requires simultaneous compromise of the individual's own online banking at the certified identity stage, dynamic knowledge questions, live MCP-TLS access, and a signed financial transaction. Composite resistance exceeds 97%. Structurally stronger than document inspection against AI deepfakes.
Provider ceases trading
Compliance Token is on-chain and self-contained. Does not depend on platform access for evidentiary value. Blockchain record permanently accessible.
Document-based is superior
WhyAML is immune to deepfake documents, verifies identity from bank-held data through a certified service rather than from a document, re-verifies in full at each movement of value, creates an immutable blockchain audit trail, and detects fraud patterns document methods cannot identify.
Data architecture
WhyAML's architecture is designed to minimise data exposure. Your firm stores no PII through the WhyAML process.
| Data held | Held by |
|---|---|
| Name, date of birth, address, country of residence, email address, wallet address | Go 2 Glory Ltd (data controller) |
| Broker Compliance Certificate (no PII) | Your firm |
| Compliance Token (no PII, on-chain) | Your client |
In the event of a data breach, the data at risk is limited to the verified attribute set - name, date of birth, address, country of residence and email address - and the wallet address. No identity document is held, and no personal data is transmitted to the verification service; the individual authenticates with their own bank directly.
Full TDD document available in your portal
The complete Technological Due Diligence pack - including the full risk assessment, G-RADE specification, audit trail field descriptions, and regulatory mapping cross-references - is available to clients in the WhyAML portal.
This document is the risk assessment required by Regulation 19(4)(c). See it mapped provision by provision.