Frequently Asked Questions

It is a payment link you paste into the invoice you already send. Your client settles it from an account they already hold, and the act of paying is what completes their verification. The wallet that pays is the wallet we verified.

Ordinary crypto checkouts verify the business receiving the money and never check the person sending it. That is why a supervised firm cannot use one - value arrives from an address with no name attached, and there is nothing to put in front of a supervisor. Ours is the only stablecoin checkout on crypto rails that verifies the payer as well as the merchant.

It's a stablecoin that tracks whatever currency you raised the invoice in. Your client doesn't pick it at checkout and you don't set it up - it just follows the invoice.

Bitcoin, Ether and the rest we don't take. The price moves between your client hitting send and you checking your balance, and that's not a risk a practice should be carrying to get a fee paid. That's the whole reason we settle in something that holds its value.

In two stages, and they answer different questions. First, who the person is: that is verified by a provider certified under the UK Digital Verification Services Trust Framework and listed on the OfDIA register, from data held by banks about their own customers. Your client reaches it through their own online banking, with their bank's own security, and nothing is uploaded.

Second, that the same person controls the account the money comes from. WhyAML observes their authenticated relationship with a regulated institution and witnesses control of it as the payment moves. That is the part the Witness Model does, and it is a narrower claim than identifying them - the certified service has already done that.

No passport, no selfie, no app to download, and no document collected or stored at any point in either stage.

Minutes, and it is final when it lands. There is no settlement window, no overnight batch, and no waiting for a bank to open on Monday.

Card money takes one to three days to reach you, and can still be pulled back weeks after the work is done while somebody argues about it. This arrives and it is yours.

No. Once a same-chain stablecoin payment settles, it settles. There is no representment process, no chargeback exposure, and no reserve to hold against a dispute.

That is a materially cleaner settlement position than card acceptance, where the money in your account is provisional for months. It also means you should be as careful about who you invoice as you always were - finality cuts both ways, and a payment taken in error has to be refunded deliberately rather than clawed back automatically.

Yes. A client can settle part now and the balance later, on the same link, without losing the compliance evidence attached to it. Each payment is its own verification event, so the evidence in your file is from the day the money moved rather than from onboarding.

A bank transfer moves the whole amount or none of it, which is why most practices never ask for anything up front. Being able to ask for a deposit commits the client before the work starts.

The payment arrives in the invoice currency, already matched to the invoice and the client. The link was generated against a specific invoice, and the settlement record carries that reference with it, so the match is made as the money lands rather than reconstructed afterwards.

In Xero, QuickBooks or FreeAgent the line appears against the right client with the invoice marked settled. Nothing to search for and nothing to key in. Keep your own records as you always have - this puts the entry in your ledger, it does not replace the file behind it.

Pay.UK research puts manual reconciliation at 3.6 hours a week for a small business - roughly 166 hours a year that nobody bills for. Opening the bank, finding the payment, finding the invoice, ticking it off. That is the work this removes, because the payment and the record were never separate to begin with.

One Single Portal Credit. That one flat credit covers every cost of accepting the payment in full - network fees, certified identity verification, sanctions and PEP screening, and the compliance certificate. No transaction fee is charged, and no card-processing fee of 1.5 up to 3.5 percent applies.

Credits are bought in packs and stay valid for 24 months. There is no subscription, no minimum, and no contract, so a quiet quarter costs you nothing.

Yes. Sanctions and Politically Exposed Person screening runs as part of onboarding a client, and the result is recorded on the compliance certificate next to the verification itself. Both carry the same timestamp, so the screening and the identity evidence sit in one document rather than two.

Screening runs against the verified identity returned by the certified verification service, not against the details you typed into the form. That distinction matters: screening a name as entered tests only what was entered, whereas screening a verified attribute set tests the identity that was actually established.

The cost is inside the Single Portal Credit. It is not metered and it is not billed separately from the payment.

As with everything else here, this supports your own customer due diligence. It does not discharge your obligation, and the decision on whether to act for a client remains yours.

What we can tell you is the mechanism, which is narrower than the question. Settlement happens in the currency your invoice was raised in, so there is no movement between two different currencies sitting between the payment and the invoice, and no separate conversion figure attached to it. The amount received tracks the invoice currency; it is not guaranteed to match it to the penny.

That describes the position of the business receiving the coin in settlement of an invoice. It does not describe someone who acquired the coin with their own money and later disposed of it, which is a different set of facts and a different computation. If you are asking on behalf of a client, it is that second position you are asking about, not this one.

We are not stating what follows from any of this for tax, and nothing here should be read as saying anything is or is not due. What the mechanism means for your return, or your client's, is a question for your own tax adviser on your own facts.

If a check fails on our side, you keep the credit. You are not charged for our problem.

If the check completes and returns a result you are not comfortable with, that is a different thing. The evidence goes in your file and the decision on whether to act for that client remains yours - as it always was. We supply evidence that supports your verification and your documented procedure. It does not discharge your obligation, and no product can.

You need a wallet for the stablecoin to arrive into, and that is the extent of it. The payment is wallet to wallet. We never hold your money and we never hold your client's money, so there is no client money to account for and no capital to hold against it.

There is nothing to install, nothing to migrate, and no IT project. Bank transfer still works, cards still work if you take them, and this sits alongside for the clients and the invoices where it fits.

Around six million UK adults hold crypto, and some of them are already your clients or would like to be. They hold value they cannot easily spend with you, and they struggle to find an adviser who understands disposals, staking and the rest of it. Accepting stablecoin is the loudest available signal that you do.

The rest is operational. Money that arrives in minutes and cannot be reversed, deposits you can actually ask for, and a Friday afternoon you get back.

WhyAML is a document-free identity-verification platform built for businesses with anti-money-laundering obligations. It lets you verify that your clients are who they say they are - in line with UK AML rules - without ever handling a single identity document.

The platform is operated by Go 2 Glory Ltd. The consumer-facing verification product carries the brand name WhyAML, because AML is the experience your client has.

As an estate agent, tax accountant, solicitor, lender, or other regulated business, you are classified as an 'obliged entity' under the UK Money Laundering Regulations 2017. Parliament has given you a specific responsibility to check who your clients are before working with them. It is not optional, and it applies to every business in your sector regardless of size.

The rules apply identically to you and to a major bank. The difference is that the bank has a dedicated compliance team and infrastructure built over decades, and you do not. WhyAML closes that gap by giving you access to the same standard of verification the large institutions use, at a price that fits a smaller business.

Identity checks are a standard obligation for every firm in your sector - HMRC supervises estate agents and accountants, the SRA supervises solicitors, the FCA supervises others. What good standing looks like in practice is a consistent, documented process applied to every client, every time. That is exactly what WhyAML gives you: the same check, the same record, on every file - so when your supervisor looks, the work is already there and organised.

Those are the three sectors WhyAML is launching for first, because they share a particularly clear version of the same problem: a full AML obligation, without the compliance infrastructure of a large institution. The method itself is general - it applies to any obliged entity under MLR 2017 that isn't a Tier 1 bank with its own verification stack. If your firm is supervised for AML and you're not a major institution, it's built for you.

Two parties, doing two different jobs. Identity is verified by a provider certified under the UK Digital Verification Services Trust Framework and listed on the register maintained by the Office for Digital Identities and Attributes. That is the stage that establishes who your client is, and it is done by a certified service rather than argued from first principles.

WhyAML does the second stage: binding that verified person to the account and the wallet the money comes from. This is attribution rather than identification, and it is a deliberately narrower claim.

The two stages rest on different evidence and are recorded separately on your compliance certificate, so your file shows which question was answered by which method.

Because the bank already did it, properly, and is supervised on whether it did. The certified verification service reads data the bank holds about its own customer, reached through your client's own online banking with the bank's own security. What comes back is a verified set of attributes - name, date of birth, address, country of residence - not a photograph of a document.

That also proves your client was genuinely present at the moment of the check, because they authenticated to their bank to allow it. A document proves a document exists. This proves a person is there.

You enter the client's name, address and email - the particulars you already hold. The certified service returns the verified attributes independently, and WhyAML matches one against the other, recording the result on the certificate separately from what you entered.

This is what makes the address in your file verified rather than assumed. An address a firm typed in and never checked against an independent source would not satisfy the identification obligation, and a certificate implying otherwise would be misleading.

Where there is a discrepancy, the verification does not proceed to a positive determination on your entered details. You are told what did not match, and you decide how to proceed under your own procedures.

For identity, the source is bank-held data, reached through a certified verification service. Those are regulated institutions that verified their customers under their own statutory obligations and are supervised on it.

For attribution, the source is the regulated institution your client transacts through - at present FCA-registered crypto-asset firms, registered with the FCA for anti-money-laundering purposes under the MLRs. The reliable, independent source in both stages is a regulated institution, not a document about your client.

They authenticate with their own bank in the way they already do - the certified service handles that directly, and WhyAML has no visibility of it. Then they confirm a connection to the account the payment will come from, and supply a recent email from that institution which the platform cryptographically verifies.

They never upload an identity document, take a selfie, or install an app. What they are doing is proving control of things already theirs - not assembling a new file about themselves for you to hold.

Identity verification does not need either. That stage runs from bank-held data through your client's own online banking, so almost any client with a bank account can be verified.

An exchange account and a wallet are needed only to pay in stablecoin. Where a client has neither, WhyAML walks them through setting both up - it is a one-time step, and their verification carries across to every payment afterwards.

Some clients will not want to, and that is a reasonable answer. Bank transfer still works, and your existing arrangements are unaffected.

Real exchange emails carry an invisible cryptographic signature called DKIM, which proves the email genuinely came from the institution's domain and was not altered in transit. By verifying that signature, WhyAML confirms your client's institutional relationship is real - without ever contacting the institution or needing its cooperation.

The email is read inside a sealed, hardware-isolated environment. No member of WhyAML staff ever sees its contents, and the file itself is never retained - only the result of the check is recorded.

Identity verification is the same for everyone, to the same minimum confidence level. What varies is the attribution stage: G-RADE™ (confidence scoring) reads each client's institutional history and asks for exactly as much proof as their profile warrants.

A strong, recent regulated relationship clears on fewer signals; a more complex profile is asked for more, until the same confidence is reached. Nobody is rejected by the scoring - a lower-confidence profile is routed through additional proof rather than declined. This is the risk-based approach the Regulations describe, turned into evidence.

Where your client transacts, the verification runs again in full at each payment. Screening is re-run, control is re-established, and a determination is produced for that payment alone. Nothing is cached and no confidence is carried forward, so the evidence in your file is from the day the money moved rather than from onboarding.

Where you verify a client and no payment follows, the verification is point-in-time and is not repeated. Your ongoing monitoring obligation under Regulation 28(11) in that case remains yours, undertaken by you, and we do not represent it as discharged. Any reporting obligation under the Proceeds of Crime Act 2002 remains yours in every case.

Sometimes the last step depends on something that has not happened yet - a payment signed and awaiting confirmation, for instance. Until it lands, the verification is in progress: no determination has been produced and no certificate has been issued.

A verification in progress is not a partial pass. There are two outcomes and this is neither of them. You are free to carry on with the commercial side of the relationship in the meantime, but customer due diligence is not complete, and you should not treat it as complete or establish the business relationship until the certificate issues.

None of them. Identity is verified from bank-held data your client reaches through their own online banking, so there is no selfie, no liveness scan, no biometric captured by WhyAML, and nothing to install. Where a bank uses its own biometric to unlock its app, that is the bank's own security on the client's own device - nothing of the kind is captured or held here.

That is not a convenience feature bolted on. A check built on verified banking data and an observed relationship has no need for a photo of a face, which is also why it cannot be defeated by a synthetic one.

The verified attribute set the certified service returns - name, date of birth, address and country of residence - together with the email address you supplied and the wallet used for the payment. That is the whole of it.

WhyAML transmits no personal data to the verification service. Your client is routed to it and authenticates directly with their own bank; WhyAML has no visibility of that authentication and receives only the verified attributes and the confidence level reached.

No passport copies. No bank statements. No utility bills. No selfies or biometric templates. The sensitive documents that traditionally sit in filing cabinets and shared drives - the ones that make small businesses targets for identity theft - are never collected in the first place. The institutional email used in the attribution stage is read inside a sealed, hardware-isolated environment and never stored.

Operational data is held in encrypted, secure cloud infrastructure based in the EU, subject to UK data protection law. An independent technology audit covers how data is handled at every stage. The architecture is designed so that the personal information held about your client is genuinely minimal - data minimisation in fact, not just in policy.

When verification is complete, your client receives an encoded record on the blockchain called a Compliance Token. It contains no personal information - no name, no address, nothing readable. It is an anti-fraud signal of verification, written as a native part of how the system works.

Your client holds it in their own wallet. Under the Data (Use and Access) Act 2025 and UK GDPR Article 20, the verified-status record is theirs to hold and to port - they can use it in a future verification or keep it private, and the protection works either way.

You receive a Broker Compliance Certificate - a clean, downloadable record confirming the verification was completed, the confidence level reached, the result of matching the verified attributes against the details you entered, the screening result, the timestamped flow of each step, and the regulations satisfied. The Technological Due Diligence assessment and the Certificate Terms of Use are appended in full.

The determination is binary: a verification either reached a positive determination or it did not. There is no score, no band and no gradation reported to you, because the threshold was either crossed or it was not. The confidence level achieved is recorded separately, as a stated fact rather than an outcome, so you can assess it against your own risk assessment rather than infer it.

This is your evidence of compliance. You store it, and if a regulator examines your process, this is what you show them. The underlying personal data never enters your systems.

UK law requires AML verification records to be kept for five years, and WhyAML meets this automatically. Your Broker Compliance Certificates are stored in your portal. Your client's on-chain record is permanent and independently verifiable - it cannot be lost, altered, or deleted.

Most of the cyber risk a smaller firm carries on AML comes from one place: holding identity documents it doesn't have institutional infrastructure to protect. The regime asks you to perform an institutional security function on a non-institutional budget. WhyAML's answer isn't tighter security around the documents - it's not collecting them. There is no filing cabinet, no shared drive, no inbox folder of passports. What can't be lost is what was never gathered.

A passport is a piece of paper. The bank behind your client has already verified their identity to a far higher standard than any single document could provide, and continues to monitor the relationship under statutory obligations. Checking the passport gives you a copy of a document; verifying against bank-held data gives you the supervised verification the bank maintains.

In a world where AI-generated passports are increasingly difficult to detect - a 311% increase in synthetic identity documents between Q1 2024 and Q1 2025 - the document-centric model has a structural weakness. This method does not, because there is no document in it to forge.

Under the document-centric model, your client's identity documents end up in every database they applied to - including every deal that never completed. Most people have no idea how many copies of their passport and bank statements sit in the systems of firms they never did business with.

Under the WhyAML model this doesn't happen. The verification is recorded once, and your client controls who has access. If a deal doesn't complete, no identity documents were ever collected - the honeypot doesn't exist because the documents were never gathered.

No, and that is more true than it used to be. Identity verification runs from bank-held data through your client's own online banking. It needs no interest in crypto, no technical knowledge, and no exchange account - only a bank account and the ability to log into it.

The attribution stage does involve a regulated crypto institution, because that is where the payment comes from. Where a client has no such account, we walk them through setting one up; where they would rather not, bank transfer still works and nothing about your existing arrangements changes.

AML exists to enable financial investigation. Under the document-centric model, if fraud is discovered after the verification, the trail ends at the document accepted at onboarding - and if that document was synthetic, there is nothing for an investigator to follow.

Here, the trail leads upstream into regulated institutions' own records, their ongoing monitoring, and their supervisory oversight. An investigator reaches the bank that performed the underlying identity work and the institution the payment came from - not a piece of paper that may or may not be real.

G-SSO is the platform's wallet connectivity engine - the part your client actually touches at the payment stage. It is how they connect an account they already hold, prove they control it, and have that proof written on-chain, without handing anything over to you.

It sits alongside G-RADE™ (confidence scoring): G-SSO establishes the connection, G-RADE weighs what the connection shows. Both are Go 2 Glory engines, and both are covered by the same patent filings. Nothing about G-SSO changes what you hold - the connection is read inside a sealed, hardware-isolated environment, only the result is recorded, and no identity document is collected at any stage.

Regulation 28(2)(a) of the Money Laundering Regulations 2017 requires identity to be verified on the basis of documents, data or information obtained from a reliable source which is independent of the person being verified.

Identity here is verified by a provider certified under the UK Digital Verification Services Trust Framework and listed on the OfDIA register. The joint HM Treasury and DSIT guidance of 26 February 2026 - approved guidance for anti-money-laundering purposes - recognises a certified and registered digital verification service as a reliable and independent source able to fulfil Regulation 28. That is the footing this stands on, and no further argument is advanced.

You meet your Regulation 28 obligation using that evidence; WhyAML does not meet it for you. Adoption of the platform is recorded under Regulation 19(4)(c) as a documented risk-based approach, supported by the Technological Due Diligence assessment appended to every Broker Compliance Certificate.

Yes. Identity verification is performed by a provider certified under the UK Digital Verification Services Trust Framework and listed on the register maintained by the Office for Digital Identities and Attributes.

This is the route the HM Treasury and DSIT guidance of 26 February 2026 expressly recognises as satisfying Regulation 28. It means the identification stage of your client due diligence rests on a certified service rather than on an argument about whether an alternative method is good enough.

What certification covers is the identity verification itself. The attribution stage, the screening, and the assembly of your compliance record are performed by WhyAML and are not separately certified - there is no certification scheme for them. We state that plainly rather than letting the certification imply more than it covers.

Yes. The provider's name, its OfDIA register entry and the certified role relied upon are set out in Schedule 1 of the Technological Due Diligence document supplied to your firm, so you can look the entry up on the register and put the reference in your own file.

We do not publish those particulars on the public site. They belong in your compliance file rather than in our marketing, and a firm that needs to evidence the certification has it in the document it already holds.

Every verification is performed to at least a Medium confidence identity profile under the government's identity-proofing standard, GPG45. A Low confidence profile is not accepted for anti-money-laundering verification.

The level actually achieved is recorded on the certificate for every client, so you can assess it against your own risk assessment rather than infer it. Where your risk assessment calls for enhanced measures under Regulation 33, verification escalates to a higher profile and that escalation is recorded too - so the application of an enhanced measure is evidenced rather than asserted.

Yes - that obligation sits with you as the regulated business. WhyAML provides the documentation to support it, including a Technological Due Diligence assessment that sets out the verification method stage by stage, identifies the risks of adoption and the mitigation for each, and records the particulars of the certified verification service relied upon. Your MLRO signs it off before first use, and it becomes part of your Practice-Wide Risk Assessment file.

You show them your Broker Compliance Certificates and the appended Technological Due Diligence assessment. That document names the certified verification provider and its register entry, so the certification can be checked independently. WhyAML's deeper documentation - the provision-by-provision Regulatory Compliance Mapping that defends each requirement in detail - is available to your counsel on request. Every verification leaves a clear, auditable, timestamped record.

Your existing verification records remain valid for the period they were conducted. WhyAML is for new verifications and for periodic re-verification where your obligations require it.

CARF - the Crypto-Asset Reporting Framework - adds requirements to identify and report clients with crypto-asset positions. Its due-diligence obligations are already live, in force since January 2026, with the first report to HMRC due in May 2027. If any of your clients hold or trade digital assets, it already shapes how you must identify and document them.

The verification returns a verified country of residence, which is a stronger starting point than a declared address. Alongside it, WhyAML supplies economic-residency evidence drawn from real, authenticated activity to support the tax-residency determination you have to make - which remains yours.

You end up in the same place on your file - a verified client - but you get there without ever taking custody of their documents. A passport copy in your inbox is a liability you are then responsible for protecting, indefinitely, and it is your problem if it leaks. WhyAML verifies the same identity without that document ever existing in your systems. Nothing collected is nothing to lose.

On the identity check itself, it is not different in kind - that stage is performed by a certified service, which is the same standard any good provider should be held to. What differs is everything around it.

Most digital services stop at identity and hand you a result. WhyAML then binds that verified person to the account and wallet the money actually comes from, and delivers the payment in the same act. You get a verified client and a settled invoice from one process, not a verification in one system and a payment in another.

The other difference is what it costs you to hold. Document-based services - selfies, scans, liveness checks - still inspect a document, and that document then exists somewhere. Nothing here does.

The bank knows your client is authorising an identity check, because your client authenticates to it directly and consents - that is how the certified service works, and it is right that they should.

The institution behind the payment is different: WhyAML does not contact it, request anything from it, or require its participation. That part of the verification is based entirely on evidence your client generates through their own activity, observed rather than requested.

WhyAML's attribution engine - including the G-RADE™ (confidence scoring) system and the multi-level proof architecture that binds a verified person to the account and wallet a payment comes from - is Patent Protected. The identity verification stage is performed by a certified service and is not what the patents cover; what is protected is the method by which a verified identity is bound to an authenticated relationship and to the movement of value.

Most are, and many prefer it. Sending a passport copy to a firm over email is something clients have quietly learned to be uneasy about, even when they go through with it. Logging into their own banking app, which they already do, asks them to do less rather than more, and leaves no document in your systems for them to worry about afterwards. It is a different experience on their side - not just a different mechanism on yours.

Complete the WhyAML onboarding process: accept the Client Terms of Service, review and sign off the Technological Due Diligence assessment (which becomes part of your Practice-Wide Risk Assessment file), and integrate the platform into your client onboarding workflow.

The identity stage takes about as long as logging into online banking, because that is what it is. The attribution stage depends on the client's institutional history, because the process asks for proportionate proof - a straightforward profile clears on fewer steps than a complex one.

For some clients the final confirmation completes when they make the payment they were going to make anyway. You and your client always see exactly where they are in the process, so there is never a black box.

Identity verification needs online banking, and almost every UK bank account has it. Where a client genuinely has none, document-based verification remains available for those cases and your existing method still applies.

An exchange account and a wallet are only needed to pay in stablecoin, and where a client has neither, WhyAML walks them through setting both up. It is a one-time step and the verification carries across to every payment afterwards. A client who would rather not can still pay you by bank transfer.

WhyAML provides onboarding support, a knowledge base, and direct access to our team for queries about the platform and its use. For questions about your specific legal obligations, we recommend speaking with your professional body or a specialist adviser - our job is to give you the best possible tool, not to replace professional advice.

The Regulations don't require a UK address or a utility bill - they require a reliable, independent source. Identity is verified from bank-held data, and the address in your file is matched against a verified address rather than accepted as entered. The client who is hardest to verify on documents is often the most straightforward to verify this way.

Yes. Pricing is per check, with no monthly minimum and no contract - you pay for the checks you do and nothing else. Making institutional-grade verification reach a single-partner firm is the whole point, not an afterthought.