Risk Disclosure

AMLRegister is a crypto-asset risk-screening tool. Its output helps users assess the risk of a wallet address, but it is not a regulatory determination, legal advice, or a substitute for comprehensive due diligence. This Risk Disclosure sets out the principal limitations of the Service, the assumptions underlying it, and the risks of relying on it. You should read it in full before acting on AMLRegister outputs.

Use of AMLRegister does not transfer legal or regulatory responsibility away from you. If you are a regulated entity, you retain all of your own AML, KYC, sanctions, and fraud-prevention obligations, and the Service is one input among many that you should consider.

This disclosure is provided in good faith to help you understand what the Service can and cannot do. It is not a limitation on our warranties or liabilities — those are set out in the Terms of Service.

Public blockchains record transactions immutably, but the parties to those transactions are represented by addresses, not identities. An address can be reused, clustered with other addresses, or controlled by multiple parties. Attribution of addresses to real-world identities is an inferential process that involves uncertainty.

Our attribution draws on public disclosures, sanction lists, proprietary research, and community intelligence. Attribution can change over time as new information becomes available or as addresses change hands. A past attribution may no longer be accurate; a current attribution may be revised tomorrow.

Not every relevant piece of information is publicly observable. Off-chain activity, internal exchange transfers, and unmined transactions can all affect the true risk profile of an address in ways that we cannot observe. Users should keep this in mind when interpreting results.

The risk score we produce is a numeric summary of our assessment at a given moment. It is designed to help triage wallets — distinguishing high-risk from low-risk at a glance — not to produce a compliance verdict. Two wallets with the same score can have quite different underlying profiles, and a small change in inputs may change the score noticeably.

The category breakdown provides additional context, but it too is a simplification. A zero score in a category does not mean "no exposure"; it means no exposure currently detected. A positive score does not imply intent to commit a crime or any wrongdoing by the holder.

The advisory weighting of categories reflects our view of relative severity, which is not universally applicable. Different regulators and different businesses may weight categories differently. Where your risk appetite diverges from our defaults, you should interpret scores accordingly.

False positives occur when an address is flagged despite being innocent, for example because of address reuse by an earlier owner or because of transaction proximity to a flagged cluster. False negatives occur when an address is not flagged despite genuine risk, for example because the address is new or the attribution has not yet been discovered.

Both errors are inherent in any screening tool. We work to minimise them through multi-source data, careful labelling, and ongoing review, but we cannot eliminate them. You should account for the possibility of error in your decisions, particularly for high-consequence decisions.

If you believe a specific result is incorrect, please contact us with details. We review disputed results promptly and publish corrections where appropriate. Prompt feedback helps improve the Service for all users.

AMLRegister depends on third-party data sources for on-chain balances, transaction history, and some attribution intelligence. Third-party data can be delayed, incomplete, or temporarily unavailable. Where a primary source is unavailable, we fall back to alternative sources; where no source is available, we indicate the degradation on the report and proceed on the basis of internal data.

We do not guarantee the accuracy or completeness of data provided by third parties. Where reliance on a third-party source is material to a decision, please corroborate through additional means.

Third-party integrations may change over time. We may add, remove, or substitute sources as the ecosystem evolves. Customers with specific source requirements should consult us on current arrangements.

Different blockchains have different characteristics: UTXO vs account-based models; privacy features; block times and finality; and the availability of attribution data. The depth of analysis we can provide varies by chain, and this is reflected in the category scores.

Rollups, side-chains, and bridges introduce additional complexity. Funds may cross from one chain to another, and the risk profile may not follow cleanly. We make best efforts to trace across bridges where the data allows, but this is an area of active development.

Privacy tokens (such as Monero and Zcash shielded transactions) are not supported by the Service because their design resists address-level attribution. We may flag bridges known to interact with such tokens, but we do not purport to trace transactions on privacy chains.

Sanctions regimes differ across jurisdictions. A wallet flagged as "sanctioned" by one authority may not be flagged by another. We aim to show consolidated exposure, but you remain responsible for compliance with the specific sanctions regimes applicable to you.

Sanctions lists are updated frequently. We ingest updates as quickly as the sources allow, but there may be a delay between a designation and its appearance in the Service. For time-critical decisions, cross-check against the official regulator's publication.

Interacting with a sanctioned address, even inadvertently, can have serious legal consequences. If you suspect a potential sanctions match, consult your compliance team and, where appropriate, external counsel promptly. Do not rely on AMLRegister as the sole basis for refusing or freezing a transaction with legal consequences.

Regulated entities using AMLRegister as part of their AML, CTF, or sanctions programmes must document how the Service is used, validate its suitability for the intended purpose, and maintain human review of results where the decision in question has a material effect on a customer or counterparty.

We support customer review processes by providing evidence of the underlying data, including sources where legally disclosable, the timestamp of the attribution, and the methodology used. Reports include a verification hash that can be used to confirm the integrity of the record.

You must not adopt AMLRegister in a way that creates reliance contrary to regulator expectations of human oversight. Model risk management frameworks (for example, the FCA's principle of human-in-the-loop for AML tooling) should be followed.

Nothing in AMLRegister constitutes investment advice, a recommendation to buy or sell any asset, or an opinion on the value of any asset. Risk-screening output does not correlate with price, liquidity, market sentiment, or investment quality.

Crypto-assets are volatile and can lose value rapidly. The Service does not purport to assess price risk. If you are making an investment decision, consult a qualified financial adviser; do not treat a green score as an investment endorsement, or a red score as a sell signal.

We may change or discontinue features of the Service at any time, subject to applicable contractual commitments. Changes in methodology may cause a given wallet's score to change even if no new information has been added. We publish material methodology changes in our Insights section and notify enterprise customers in advance.

Where we remove or sunset a feature that you rely on, we will endeavour to give reasonable notice and migration guidance. However, legal or security requirements may compel us to act with less notice, in which case we will provide as much information as circumstances permit.

You are responsible for deciding whether AMLRegister is suitable for your use-case, for interpreting its outputs correctly, for applying appropriate human review, and for complying with the laws applicable to you. You must not treat AMLRegister output as determinative.

You should maintain backup procedures for times when the Service is unavailable or produces results that you cannot reconcile with other intelligence. A well-designed compliance programme never depends on a single point of failure.

If you become aware of a material error in a result, please inform us promptly so we can investigate and, where appropriate, publish a correction. Your feedback contributes to the integrity of the Service for the wider community.

The same risk score can carry different implications in different jurisdictions. A 40-point score that is borderline in one jurisdiction may be decisively over the threshold in another, depending on the regulator's enforcement posture and the firm's risk appetite. We do not produce jurisdiction-specific scores; we produce a single score that firms must interpret against their own regulatory framework.

Where customers operate across multiple jurisdictions, we recommend documenting a "translation table" that maps our scores and categories to local regulatory expectations. This translation table should be approved by the firm's MLRO and reviewed annually. We can assist with the initial drafting on an advisory basis; the decision remains the firm's.

Certain blockchains, tokens, and transaction types are outside the current coverage of the Service and should be expected to produce lower-quality results. Privacy coins (Monero, Zcash shielded, Dash PrivateSend) are not supported; transactions through them are opaque by design. Layer-2 activity on channels (Lightning Network, Hyperliquid) is not directly observable; only the on-chain settlement is visible.

Cross-chain bridges vary in our coverage: well-established bridges are traced with high confidence, but emerging bridges may have incomplete mapping. Wrapped assets and synthetic representations can mask the true origin of value. Off-chain transfers between exchange customers (internal book transfers) produce no on-chain evidence at all.

Our documentation enumerates known coverage gaps and is updated as the product evolves. Enterprise customers can request a bespoke coverage statement for their specific use-cases; we provide frank assessments rather than marketing pitches.

Regulators increasingly expect firms using automated or data-driven tools to implement model risk management (MRM). Under frameworks such as the UK Prudential Regulation Authority's SS1/23 and the ECB's Targeted Review of Internal Models (TRIM), firms must validate, monitor, and govern the models they deploy. These expectations apply to AML screening tools even when the tool is an external vendor product.

For firms incorporating AMLRegister into a regulated programme, we recommend the following minimum practices: (a) documented model inventory including AMLRegister as an input; (b) validation at onboarding and at defined intervals thereafter; (c) human-review requirements for any decision with material legal or customer impact; (d) monitoring of false-positive and false-negative rates; and (e) escalation procedures where the tool produces unexpected results.

We support these practices with technical documentation of our methodology, calibration summaries published to enterprise customers, and support for customer-initiated validation exercises. We do not, however, replace the customer's own MRM obligations. The governance of how AMLRegister is used rests with the using firm.

No single crypto AML tool covers all scenarios equally well. Firms with demanding requirements often use multiple tools and reconcile their outputs. We support this: our API is designed to interoperate with existing case-management and screening systems, and our reports explicitly document the methodology so that differences with other tools can be reasoned about, not merely observed.

Customers occasionally ask how AMLRegister compares with competitors. We do not offer direct benchmarks — any published benchmark is a snapshot at a moment in time, in one use-case, and such comparisons are often misleading. We recommend customers run a proof-of-value against their own historical cases to form an independent view.

Where you observe a material discrepancy between AMLRegister and another provider, please report it to our research team. Reconciliation work helps both products improve, and we take our share of the responsibility for explaining differences clearly.

Questions about this disclosure can be directed to compliance@amlregister.com. For specific concerns about a result, please use the dispute link at the bottom of any report, or email us with the report ID and the reason for your query.

By using the Service, you confirm that you have read and understood this Risk Disclosure and that you accept the limitations described here. If you do not accept the limitations, please do not use the Service. The obligations of Okanewatch LTD are set out in our contractual documents; this Disclosure is informational and does not create additional rights or waivers beyond what is stated in the binding agreements.