Three completed anonymised engagements
EXCOIN completed three engagements across trading platforms, payments and crypto lending. The owner confirmed completion, but contracts prevent disclosure of client identity and implementation details. We therefore omit names, dates, source code, production networks, contract addresses and commercial outcomes. The technical discussion combines confirmed project themes with broadly applicable architecture; it does not claim that every pattern shown was deployed exactly as described.
That makes the study useful rather than fictional. It shows decisions that a real engagement cannot skip: which system owns the state of a trading account, what happens after an order request times out, how an order differs from a deal or position, and how to identify whether a client, employee or automated process changed a state. Regional outages and recovery authority are part of the same design.
What confidentiality permits us to share
An anonymised reference can explain the type of brief, system boundaries, difficult states and verification method. It cannot publish actual volumes, provider names, availability measurements or internal security controls without client approval. We therefore show engineering decisions and acceptance questions, not numbers we cannot substantiate. If the client later approves wider disclosure, a specific outcome and its evidence can be added.
A prospective client can prepare a brief with available interfaces, permissions, roles, permitted operations, representative data, contractual and regulatory limits and operational requirements. MT4 and MT5 require licensed server access; payments add processors and settlement; Ethereum lending adds collateral and economic rules. Without those inputs, no one can credibly promise a complete scope or fixed price.
How to judge the proposed architecture
A useful case study goes beyond a block diagram. It identifies ownership boundaries, sources of truth, failure states, audit events, deployment model and verification method. Every integration needs an owner, a versioned contract and a response when one side is late or unavailable. The result should be readable by engineering, operations and product owners without pretending to know what has not been established in a contract or test environment.
The MetaTrader study covers interfaces, trading states and global operation. The payment study traces card and crypto branches through ledger entries and refunds. The lending study covers collateral, oracles, liquidation and contract security. All three separate generally applicable design choices from confidential implementation parameters.
For a new engagement, a useful review brings together the product owner, architect, operations team and risk owner. Each validates a different part of that new brief: customer journeys, vendor API constraints, incident response or data handling. A delivery plan and budget follow from those verified inputs rather than from assumptions about the confidential completed projects.