Anti-Money Laundering ("AML") obligations apply to every regulated financial institution that handles customer funds, not only to crypto exchanges. The framework predates crypto by decades. The U.S. Bank Secrecy Act of 1970 was the first federal statute to require U.S. financial institutions to identify customers, keep records, and report suspicious activity. The Financial Action Task Force ("FATF"), established in Paris in 1989 by the G7, sets the international AML and counter-terrorist-financing standard now adopted by most major jurisdictions.

FATF extended these obligations to virtual asset service providers ("VASPs") through its 2019 Interpretive Note to Recommendation 15, which applies the Travel Rule (Recommendation 16) to crypto firms. The European Union has brought crypto firms inside its AML perimeter through successive directives. The United Kingdom, Singapore, Hong Kong, Japan, and other jurisdictions operate comparable regimes. The core requirements are consistent across them: Know Your Customer ("KYC"), transaction monitoring, and suspicious activity reporting to regulators.

The factual statement that follows is direct. A crypto exchange that operates openly under the regulators of its jurisdictions inherits the same KYC and AML duties. Those duties have applied to banks for decades. Identity verification, transaction monitoring, and reporting are not service choices made by the platform. They are legal obligations. Bitbase operates as part of this regulated financial infrastructure. Its controls reflect that institutional position rather than a posture toward any individual user.

KYC failures have several structural causes. The list below describes categories, not a checklist of fixes — the operative rules vary by jurisdiction, and cross-border platforms must apply the strictest standard each user touches.

Document inconsistency. Submitted fields — full legal name, date of birth, address — must reconcile with the supporting identity document. Conflicts between fields, or between submitted data and the machine-readable zone of the document, trigger automated review.

Risk-rating mismatch. Every regulated institution assigns each user a risk rating based on the totality of submitted information: jurisdiction of residence, source of funds, declared use, and other factors. When that profile does not match the platform's risk tolerance, the application may be declined without further explanation.

Sanctions and watchlist matches. Regulated institutions must screen users against international sanctions lists — OFAC, the EU consolidated list, UN lists, UK HM Treasury — and against Politically Exposed Persons (PEP) databases. Even a false positive on a common name typically requires manual review and may result in rejection.

Jurisdictional restriction. Some countries and territories cannot be served. The cause may be a sanctions regime, the absence of a local license the platform has not yet obtained, or a strategic decision to exit a market. From the user's perspective the outcome is the same: the application cannot proceed.

Bitbase does not disclose its internal scoring parameters. Disclosure would defeat the function of the control. What can be stated is that KYC is designed to identify identity-related risk, not to test the user. The entry point and status tracking for Bitbase KYC are available at the Bitbase KYC HelpPage.

Holds on active accounts arise from ongoing monitoring obligations, not from a single judgment made at onboarding. The triggers fall into four broad categories.

Transactional pattern monitoring. Every regulated institution runs automated systems that flag unusual deposits, withdrawals, and trading patterns. Flags can mark behavior that deviates from a user's established baseline, or that matches typologies tied to money laundering, market manipulation, or fraud. A flag does not imply wrongdoing; it triggers a review obligation.

On-chain address screening. Deposit and withdrawal addresses are screened against blockchain analytics flags: known mixer addresses, addresses tied to sanctioned entities, addresses linked to exploits or theft. An incoming deposit from a flagged address can place the receiving account under review independent of the user's own conduct.

Third-party reports. Law enforcement requests, bank notifications, and information shared by partner institutions can each trigger a hold. A valid law-enforcement request leaves the platform with no discretion to refuse.

User-side protective triggers. Patterns suggesting account compromise — login from an unfamiliar location, repeated failed authentication, withdrawal address changes followed by large transfers — can trigger automated holds intended to protect the account holder. These are typically reversible through identity re-verification.

In all four cases, the hold is a procedural action, not a verdict on the user.

This is where the gap between user expectation and platform obligation becomes visible.

Across most major AML jurisdictions, once a regulated institution files a suspicious activity report ("SAR" in U.S. terminology, "STR" in the FATF framework), the law applies a hard restriction. The institution cannot inform the subject of that report that the filing has occurred. The prohibition is known as the tip-off offence. Section 333A of the United Kingdom's Proceeds of Crime Act 2002 is among the frequently cited examples. Most jurisdictions aligned with the FATF framework operate similar rules.

The practical consequence is that customer-service teams at every regulated institution — banks and exchanges alike — operate under hard limits on what they can disclose to a user whose account is under review. The silence is not an attitude. It is the perimeter of what the representative is permitted to say.

The standard path is one option, not several. Contact official Bitbase customer support through the channels listed on the Bitbasewebsite and respond to any verification requests with accurate, complete information. There is no faster route. Any third party offering one should be treated as suspicious. Imitation customer-service accounts on social media, Telegram, and direct-messaging platforms are a common fraud vector targeting users precisely when their account is on hold.

Requests that involve transferring funds, paying a "release fee," or sharing private keys or login credentials do not originate from Bitbase. Bitbase customer service does not ask for any of those. The full scope of legitimate customer-service communication is set out in the BitbaseTerms of Use and PrivacyPolicy.