Skip to content
InfrastructureSolutionsLocationsCompanyLegal & trust
Discuss your project
← Legal & trust

Policy / 1.2

Downstream Customer Verification Standard

Risk-based verification that continues through resellers, providers and customer-controlled services.

Effective 2026-09-23

In this document

1. The required outcome2. Establish the account before granting access3. Recognise when stronger checks are required4. Select a proportionate method5. Reach and record a human-reviewable decision6. Use providers and biometrics responsibly7. Share evidence only where justified8. Set retention by record and purpose9. Extend the standard through further resale10. Escalation and review
Ask a question

1. The required outcome

Where the Reseller & Hosting Provider Policy applies, you must know who your direct customer is, be able to reach an accountable contact and connect that relationship to the resources supplied. Where that customer resells again, require an equivalent process and an effective escalation route at the next level.
Apply the same substantive verification requirements that govern your 3NT service. The method may differ, but the chain must not weaken a required check. This standard supplements the Customer Verification Policy; it does not turn every hosting service into a regulated financial activity or require documentary KYC for every person who visits a hosted application.

2. Establish the account before granting access

Obtain accurate account and contact information, verify control of the contact channel by an appropriate method and record the service being requested. For an organisation, establish the business identity and the representative’s authority to order or manage the service to the extent relevant to the risk.
Assess material inconsistencies between the account, payment and service request. Record the account identifier, applicable terms accepted and allocation of resources. The checks must be sufficient to create an accountable relationship; an unverified email alias alone may be insufficient where the surrounding risk requires more assurance.
Do not ask for information merely because it is available. A document copy, a selfie or a payment record must serve an identified purpose. Public company registers, account-control checks and other less intrusive evidence may be sufficient in an appropriate case.

3. Recognise when stronger checks are required

Assess relevant signals together and keep a short record of the reason for escalation. A trigger requires assessment; it is not automatic proof of wrongdoing.

  • Credible signs of unauthorised payment, account takeover or misuse of another person’s identity.
  • Material inconsistencies in the customer’s identity, payment entitlement, authority or explanation of the proposed service.
  • A request to enable a restricted function, including SMTP where the service makes verification a condition of access.
  • Repeated substantiated abuse, attempts to bypass an earlier restriction or a resale pattern that conceals the party controlling the affected resource.
  • A potential applicable sanctions match or a specific legal obligation requiring identification or additional information.
  • A refund, ownership change or access-recovery request where there is a genuine need to establish the recipient’s entitlement or authority.
  • A specific, reasoned and lawful 3NT request tied to the affected customer, resource or activity.

Nationality, a country inferred from an IP address, use of a privacy service, an automated risk score or a name match alone is not a conclusive basis for an adverse decision. Consider the evidence, the service and a reasonable explanation, and review possible false positives.

4. Select a proportionate method

Tell the customer the purpose of the check, what evidence is required, how to submit it safely and the possible effect on the service. Use the least intrusive method that provides sufficient assurance in the circumstances.
A check may establish account control, payment entitlement, a representative’s authority or identity. Corporate ownership or source-of-funds information should be requested only where necessary for the particular risk or applicable obligation. Government identity documents are not the default answer to every technical or billing question.
Do not request passwords, authentication codes, full card credentials, CVV values, private keys or seed phrases. Do not use the public sales form or an ordinary abuse mailbox to collect identity documents. Agree a protected submission method with access limited to the people who need the information.

5. Reach and record a human-reviewable decision

Record the purpose, method, date, outcome, decision-maker and any restriction or follow-up date. Retain the evidence necessary to support that decision under a documented schedule; a result or reference may be sufficient without retaining a full document image.
Where verification is a required condition, do not activate the affected service or function until the requirement is satisfied or a lawful, documented alternative is agreed. During an existing service, restrict the affected functionality proportionately to the substantiated risk. An unsuccessful automated check or missed deadline alone must not trigger automatic deletion of customer data.
Provide a reasonable opportunity to correct information or explain a discrepancy, unless an urgent threat or legal restriction prevents it. Offer human consideration of contested results and a practical route for technical failures or accessibility needs. Apply refund rights under the contract and law; verification is not a reason to retain money without a proper basis.

6. Use providers and biometrics responsibly

If you use a verification provider, assess its suitability, relevant data flows, security, retention and contractual role. Give the customer the applicable privacy information before the process begins. Maintain oversight of the result and a route to correct errors; a supplier’s decision does not remove your responsibility for the decision you take.
Biometric recognition is not authorised by this policy. Any use requires an appropriate lawful basis, any additional condition needed for special-category data, clear information and the applicable safeguards. Where consent is relied on, it must be valid and capable of withdrawal. Consider a proportionate alternative where required or appropriate; refusal of biometrics is not, by itself, proof of fraud.

7. Share evidence only where justified

When 3NT makes a specific verification enquiry, start with the relevant customer reference, resource, method, outcome and date, and a brief account of the issue. We may accept an attestation or redacted record where it provides sufficient assurance. Additional evidence must be requested and assessed against the identified need.
Establish the lawful basis for any disclosure and any required international-transfer safeguards. Use the agreed secure route, minimise the material shared and record the recipient and purpose. Do not routinely upload all downstream customers’ passports, biometrics or payment records to 3NT. If disclosure is prohibited or the evidence is not held, explain that promptly and work with us on a lawful alternative or the required legal process.
A request to preserve evidence is separate from permission to disclose it. Authority requests must follow the Law Enforcement Guidelines, including authentication, scope and any valid confidentiality restriction.

8. Set retention by record and purpose

Use a documented schedule that distinguishes account and allocation records, verification results, raw identity evidence, biometric information and accounting records. Review the continuing need and securely delete or anonymise information when the purpose expires, subject to applicable legal requirements and a valid, scoped hold.
Do not apply a blanket seven-year period to every identity document because financial-sector rules use a retention period in a different context. Keep access and deletion controls proportionate to the information. A record of the fact and outcome of a check may have a different retention need from the source document.

9. Extend the standard through further resale

Require each permitted intermediary to bind its own downstream customers to materially equivalent obligations, maintain attribution and contact records, and carry out a required check when the relevant trigger arises. Confirm that the intermediary can obtain a response from the party controlling the affected resource.
You may delegate the practical check to a suitable party, but must be able to demonstrate that the required process took place and respond through the agreed chain. Repeated referrals with no accountable decision or unexplained claims that “the next reseller handles KYC” do not satisfy this standard. Where the chain cannot resolve a necessary check, keep the affected restriction in place and escalate for a documented decision.

10. Escalation and review

For a policy question, a disputed requirement or a conflict with local law, contact legal@3nt.com and identify the service, issue and proposed alternative without attaching unnecessary sensitive data. For a live security incident, use security@3nt.com or the agreed operational escalation. Do not route verification evidence through abuse@3nt.com, which automatically forwards reports and sender details to the customer.
Review the process after a material incident, change of provider or change in the service model. The standard is an ongoing operating obligation where incorporated into the contract, not a one-off document collection exercise.

End of document · Version 1.2
3NT Solutions LLP · OC363382

Compute. Connect. Continue.

A foundation for what comes next.

sales@3nt.com

Infrastructure

Bare MetalVirtual MachinesColocationDDoS protectionBackups & recovery

Who we work with

Hosting providersIT & managed service providersSaaS platformsCDN & edge networksTelecom & internet service providersFinTech teamsVPN providers

3NT

LocationsCompanyContactLegal & trustReport abuseLaw enforcementReseller policyCustomer verification
Our missionOur valuesCareers

© 2026 3NT Solutions LLP
Registered in England & Wales · OC363382

TermsPrivacyCookiesKYCAML
Back to top ↑