A centralized crypto exchange (CEX) is an organization-operated platform that intermediates trading and may also provide custody or other services. In a common model, customers transfer assets and custody to the exchange before trading through its internal system. The precise operating arrangement—and any security or compliance claim about it—must be verified for the specific provider, service, jurisdiction, and date. source

What a centralized crypto exchange does

A CEX places an operator between customers and the trading process. Customers use the platform’s systems and accounts rather than arranging each exchange directly with another person. The operator may maintain an internal trading system and may provide services beyond trading, but the general model does not establish what any particular platform offers.

Centralized exchange operators may combine third-party trading, proprietary activity, margin lending, token issuance, and custody. Not every exchange performs every function. Combining roles can create operational dependencies and conflicts, so it is important to identify which functions the relevant entity performs rather than treating “exchange” as a complete description of its business. source

A centralized exchange’s role should also be distinguished from the user’s role and from any separate service provider’s role. A platform may operate a venue, manage assets, or perform other activities, but the evidence must establish which entity provides each service and under what arrangement. The general label does not settle those questions.

Cex crypto operations from order to settlement

A high-level operating flow begins when a customer accesses an account and submits a trading instruction. The platform processes the instruction within its trading system. The specific steps, records, and technology used by an individual platform cannot be established from a general description of centralized exchanges.

In a common centralized model, customers trade through an internal system after transferring assets to the exchange. This distinguishes activity recorded within that system from a direct blockchain transaction. The existence of an internal trading record does not, by itself, show that a corresponding on-chain transfer occurred; nor does it establish when or how assets move between the platform and a customer. source

The word “settlement” can refer to different parts of this flow. A platform account record may represent activity within the exchange’s system, while a blockchain record concerns a transaction on a network. Those records should not be treated as interchangeable. To describe a particular platform’s process, evidence needs to identify which record is maintained, which entity maintains it, and whether the described step involves an asset transfer to or from a blockchain.

This distinction is operational, not a conclusion about the rights attached to an account balance. The general model alone does not establish how a platform reconciles its records, when it processes withdrawals, or what customer claims apply. Those details require platform- and service-specific documentation.

Custody boundaries and security controls

Custody describes who manages access to assets or the private keys used to control them. In a common centralized-exchange arrangement, a customer transfers assets and their custody to the exchange before trading on its internal order book. source A third-party custodian, including an exchange acting in that role, manages access to private keys on customers’ behalf. The custody structure and customer rights vary by provider and jurisdiction. source

This identifies a possible control boundary, not a universal arrangement. A CEX may combine trading and custody, but a claim about a particular service requires evidence that identifies the entity responsible and the relevant assets or product. A customer-facing account balance does not, by itself, explain who manages key access or establish the customer’s legal rights.

For security review, separate the control questions. Determine who manages key access, which entity operates the trading service, and what documentation supports each claimed control. Do not treat a broad phrase such as “secure custody” as evidence of particular practices or outcomes. The general evidence here does not verify any provider’s key-management procedures, account-access safeguards, withdrawal controls, recovery processes, asset segregation, insurance, or security results. Each such claim needs current, attributable evidence for the provider and service concerned.

Security responsibilities can also differ from operational responsibilities. The exchange may operate a trading system, while another entity may manage custody; alternatively, one operator may combine functions. The general model does not tell a reader which structure applies. Evidence should therefore connect each control to the organization that performs it and the service it covers, rather than attributing all controls to a brand name.

The same boundary applies to incident handling. Without platform-specific documentation, a general explanation cannot say how a particular exchange would respond to an account incident, restore access, or return assets. Nor does evidence that an exchange performs one operational function establish the quality or effectiveness of a separate security process.

Compliance responsibilities depend on jurisdiction

The fact that an organization operates a CEX does not, on its own, establish which legal requirements apply. Statements about licensing, registration, customer checks, sanctions controls, or reporting need current authoritative support tied to the relevant jurisdiction, legal entity, service, customer location, and effective date. The available general operating claims do not specify those legal obligations, so they cannot support a universal compliance description.

Scope matters even when evidence exists for one case. A statement about one entity or service should not automatically be applied to another entity in the same corporate group, a different product, or customers in another location. A compliance statement also should not be treated as proof of security, solvency, or a particular form of customer recourse. Those are separate questions that require separate evidence.

This is why compliance review should be treated as a verification task, not inferred from a platform’s operating model. The model can help identify the entity and service to investigate; it cannot establish the entity’s status or obligations in a jurisdiction without authoritative, current evidence.

How to evaluate operational claims

Start by pinning down the scope of the claim: which legal entity, service or product, customer location, and date does it cover? Then identify the operational subject. A statement about trading does not prove who holds assets, and a custody description does not establish a particular security control or legal status.

Use these questions to keep the review bounded:

  • Trading records: Does the documentation describe the specific platform’s process, or only the general centralized model? Which system or record is being discussed?
  • Custody: Does the evidence identify who manages key access and which service it covers? Do not infer customer rights, segregation, insurance, or insolvency treatment from the word “custody.”
  • Security: Is each claimed control documented for the relevant entity and service? General descriptions do not verify provider-specific controls or outcomes.
  • Compliance: Is the source authoritative and current for the jurisdiction, entity, service, customer location, and date? Avoid extending a narrow statement to other entities or locations.
  • Other operating terms: Fees, availability, recovery processes, and customer protections require current, product- and jurisdiction-specific evidence. They are not established by the general CEX model.

A centralized exchange can combine an operator-run trading system with custody and other functions, but those functions and arrangements are not uniform. Understanding the model helps locate the questions that need evidence; it does not establish an individual platform’s security controls, compliance status, or customer protections.

Sources and references