Crypto exchange software is usually procured as a single product, but what is delivered and operated is a set of distinct modules with different failure modes, different regulatory exposure and different ownership implications. Treating the platform as one indivisible purchase tends to conceal the questions that later determine cost, control and authorisation readiness.
This article sets out the modules a trading venue requires in practice, the questions each module raises for executive, engineering and compliance stakeholders, and the criteria that separate a coherent architecture from an assembly of components. The perspective is procurement and planning rather than implementation: what must exist, why it matters, and how completeness is assessed before a provider is selected.
Why Exchange Software Is Best Assessed as Modules
A trading venue is a regulated business supported by software, not an interface with prices on it. When a platform is evaluated as a whole, demonstrations tend to concentrate on the parts that are visible, while the components that determine operational and regulatory outcomes remain unexamined. Module-level assessment reverses that emphasis and asks which parts exist, which are supplied by third parties, and which the operator can modify without vendor involvement.
The distinction matters to each decision-maker for a different reason. For the chief executive, module boundaries determine where recurring costs accumulate and which supplier relationships become expensive to exit. For the technology lead, they determine what can be changed, by whom and at what risk. For the compliance function, they determine where records originate and whether evidence can be produced when it is requested rather than reconstructed afterwards.
The Trading Core
The trading core consists of the matching engine, the order-management layer and the market-data distribution that supports both. The matching engine applies the venue's priority rules and produces the execution record from which everything downstream is derived. Its throughput and its behaviour under load set the ceiling for the venue's product ambitions, particularly where derivatives, high order-to-trade ratios or professional participants are contemplated.
Engineering baseline: A matching engine tested at up to 700,000 orders per second. Benchmark figures describe a defined test configuration and are not a service commitment; the question that matters for any venue is the order profile it actually expects to carry.
Order management holds the state of every instruction between submission and settlement, applies the venue's limits and rejects what must be rejected. Market-data distribution carries the resulting book and trade stream to interfaces and API clients. These three parts are frequently discussed as one, yet they scale differently and fail differently, and the boundary between them is where most performance disputes are eventually settled.
Ledger and Balance Records
The ledger is the authoritative record of what the venue owes each customer and what it holds. It is distinct from the balance shown in the interface, which is a projection of ledger state, and distinct again from on-chain holdings, which must be reconciled against it. Where these three are conflated, discrepancies are discovered late, usually during reconciliation or an examination rather than in normal operation.
A double-entry structure with immutable postings is the conventional expectation, because it allows every balance to be explained by the entries that produced it. The useful procurement question is not which database technology is used, but whether the ledger can be reconstructed, reconciled and evidenced independently of the application that writes to it.
Wallet and Custody Infrastructure
Wallet infrastructure covers deposit address generation, transaction construction and broadcast, confirmation tracking, and the separation of hot and cold holdings. Withdrawal approval belongs here as well, and it is an operational control before it is a technical feature: who authorises, against which conditions, and how that authorisation is recorded. Multisignature arrangements and hardware-backed key custody are the common structures, whether operated internally or through an external custodian.
The choice between internal wallet operation and custodian integration changes the venue's risk profile, its insurance position and its regulatory conversation, and it is difficult to reverse once customer assets are held. It is therefore an architecture decision taken before selection, not a configuration choice deferred to delivery.
Fiat Rails and Payment Connectivity
Fiat deposit and withdrawal connect the venue to banking and payment providers, and this is the module where launch timelines most often slip. The software requirement is comparatively contained: payment-provider integration, deposit attribution, withdrawal instruction and the reconciliation between payment records and ledger entries. The commercial and regulatory requirement is larger, because banking relationships are granted against the venue's own control environment rather than its technology.
Where a venue holds customer money rather than passing it directly to a payment partner, payment-services and e-money regulation becomes relevant to the architecture and not only to the licence application; the structural questions are set out in more detail on the e-money platform software page. Grumpio does not safeguard funds and does not issue payment instruments. The platform is structured so that the operator's own obligations can be evidenced.
Compliance Modules
Identity verification, AML and wallet screening, Travel Rule messaging and transaction monitoring are separate modules with separate data flows, and they are the modules most often assumed rather than specified. Verification decides who is admitted. AML and sanctions screening decides who is admitted and on what terms, and repeats that decision periodically. Travel Rule handling governs what accompanies a transfer between providers. Monitoring observes behaviour after admission, which is where most reportable activity is found.
The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. In the United Kingdom, MLR registration is not FSMA authorisation: the FCA published its final rules for the incoming cryptoasset regime on 30 June 2026, the application window runs from 30 September 2026 to 28 February 2027, and the regime is expected to take effect on 25 October 2027. The UK Travel Rule has applied since 1 September 2023. Both directions of travel place compliance modules inside the technical scope of the platform rather than beside it.
Legichain, Grumpio's screening and verification product, covers person and company screening, PEP and sanctions data, adverse media, multi-chain wallet risk screening, risk scoring, PDF evidence reports and periodic rescreening, through an API and a web panel, with dedicated storage where that is required. Identity capabilities, including KYC verification software with NFC document reading, liveness and face matching, are delivered through the same credit pool. Product detail and pricing are published at legichain.com.
We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations.
Back Office, Roles and Audit Records
The back office is where the venue is actually operated: customer administration, deposit and withdrawal handling, fee and limit configuration, and the investigation of exceptions. Its quality determines headcount, and headcount determines operating cost more reliably than licence fees do. Role and permission design belongs to this module, together with the audit record showing which operator did what, when, and under whose approval.
Audit logging is frequently treated as a technical afterthought and then requested urgently during an examination. Where the log is designed as evidence — complete, tamper-evident, exportable and readable by someone who is not an engineer — an examination becomes a retrieval exercise rather than a reconstruction project.
Module Map and Ownership Questions
The map below summarises the modules described above alongside the single question that most usefully tests each one during provider evaluation. The questions concern ownership and evidence rather than features, because feature lists rarely differ much between providers while ownership terms almost always do.
| Module | Primary risk if absent or weak | Question that tests it |
|---|---|---|
| Matching and order management | Throughput ceilings and unpredictable behaviour under load | Has the engine been benchmarked against the venue's own order profile? |
| Ledger | Unexplained balances and failed reconciliation | Can balances be reconstructed independently of the application? |
| Wallet and custody | Loss of assets and unauthorised withdrawal | Who approves withdrawals, and how is the approval evidenced? |
| Fiat rails | Delayed launch and banking friction | Do payment records reconcile to ledger entries without manual work? |
| KYC, AML and Travel Rule | Admission of prohibited customers and undocumented decisions | Are screening results retained as evidence with the decision attached? |
| Back office and audit records | Operating cost and examination findings | Can a complete operator action history be exported without engineering support? |
| Deployment and resilience | Downtime and resilience findings | Have recovery objectives been exercised rather than documented? |
Deployment and Resilience Modules
Deployment is a module in its own right, because where the platform runs determines who can reach it, who can change it and what happens when a component fails. Dedicated or on-premises deployment, primary and secondary data centres, release governance and recovery objectives are architecture decisions with regulatory consequences, particularly under the operational-resilience expectations now applying across the United Kingdom and the European Union.
DORA has applied since 17 January 2025 and treats resilience as a tested capability rather than a documented intention. The practical distinction is straightforward: a recovery objective that has been exercised is a control, while a recovery objective that exists only in a policy is a finding waiting to be raised. The engineering implications are examined further under regulatory readiness.
Summary and Next Steps
An exchange platform is complete when each module has a defined boundary, a named owner and an evidence trail: trading core, ledger, wallets, fiat rails, compliance, back office and the deployment around them. Gaps in that map do not appear during a demonstration. They appear in reconciliation, in the first incident and in the first examination, when the cost of closing them is highest.
The practical next step is to map the modules against the intended market, licence position and operating model before providers are compared, because the comparison only becomes meaningful once the required scope is known.
Do not buy software alone. Buy the process that makes it work. Grumpio delivers exchange, e-money and compliance technology together with the architecture, evidence and operating model that support it.