Operational
Model

TRADEPRESS operates as a pure middleware layer — positioned between the source of capital (the User) and the licensed destination institution. The platform's sole function is to digitise, clean, consolidate, and route data. It does not execute trades, hold deposits, clear transactions, or manage client positions.

The platform serves three routing channels — Private Wealth Placement, Broker-Dealer Liquidity Routing, and Institutional Affiliate & IB Network — all powered by the same four-stage pipeline and the same Canonical Contact Record protocol.

Every institutional referral processed by the TRADEPRESS middleware engine passes through a deterministic four-stage pipeline:

• Stage 1 — Digitise: The platform ingests unstructured client data from disparate international liquidity feeds — identity verification, source-of-funds documentation, risk appetite assessments, jurisdictional information, and trading preferences. This data is normalised into a structured digital format suitable for machine processing.
• Stage 2 — Clean: Sanitisation pipelines strip duplicates, validate data integrity, cross-check jurisdictional compliance tags, and attach regulatory metadata required by the destination institution. This stage ensures that every record arriving at a licensed institution is pre-validated and ready for immediate onboarding.
• Stage 3 — Route: The cleaned Canonical Contact Record is matched to the optimal licensed destination based on instrument type, jurisdiction, execution quality metrics, and the institution's current onboarding capacity. The record is transmitted via secure API to the destination institution.
• Stage 4 — Settle: The destination institution confirms receipt, onboards the client under its own regulatory licence, and assumes full custody of any subsequent capital flows. TRADEPRESS's role concludes at confirmation of receipt. All subsequent capital movements occur directly between the client and the institution.

The Canonical Contact Record (CCR) is the standardised data envelope that powers every routing decision in the TRADEPRESS ecosystem. It is the output of Stage 2 (Clean) and the input to Stage 3 (Route).

Each CCR contains the following data fields:

• Identity block — Client name, entity type, jurisdiction of residence, KYC status, and verification timestamp.
• Risk profile — Risk appetite score, investment horizon, leverage tolerance, and declared experience level.
• Capital source — Declared source of funds, AML/CTF screening status, and sanctions clearance flag.
• Instrument preferences — Asset classes, preferred instruments, typical trade size, and execution style.
• Jurisdictional tags — Regulatory jurisdiction, permitted instrument classes, and restrictions applicable to the client's region.
• Routing metadata — Record ID, timestamp, source channel, and destination institution identifier.

Once created, a CCR is immutable — it cannot be modified after the Clean stage. Any changes require a new CCR to be generated, ensuring a complete and tamper-evident audit trail.

The routing algorithm in Stage 3 transmits only the Canonical Contact Record — a data payload containing no capital, no payment instructions, and no value tokens. The routing decision is based on:

• Instrument match — The client's preferred instruments are matched against the destination institution's product catalogue.
• Jurisdictional compatibility — The client's jurisdictional tags are verified against the institution's regulatory permissions.
• Execution quality — Historical execution metrics (spread, slippage, fill rate) for the matched instrument at the destination.
• Onboarding capacity — The destination institution's current onboarding throughput and any capacity constraints.

The routing is performed by deterministic algorithms — not by human discretion. This ensures consistency, auditability, and eliminates the risk of inappropriate routing decisions.

The non-custodial nature of TRADEPRESS is not a policy — it is an architectural constraint enforced by the absence of specific infrastructure components:

• No payment gateway — The platform contains no code for processing payments, card transactions, or bank transfers.
• No custodial accounts — TRADEPRESS does not operate any bank account designated for client funds. No segregated, client-money, or trust accounts exist.
• No settlement engine — The platform cannot execute, settle, or clear financial transactions. All settlement is performed by the destination institution.
• No digital asset custody — The platform does not generate, store, or manage private keys, wallet seeds, or any cryptographic material capable of controlling digital assets.
• No balance sheet exposure — At no point in the pipeline does any client capital enter, transit through, or rest within any system controlled by TRADEPRESS.

This design can be independently verified through architectural audit. See our Non-Custodial Declaration for the formal declaration.

TRADEPRESS provides three integration methods for institutional partners, introducing brokers, and affiliates:

• REST API — A stateless JSON-over-HTTPS API for submitting client data, retrieving routing decisions, and tracking Canonical Contact Record status. Authentication is via API key with per-endpoint scope control.
• Embeddable widgets — Iframe-based and JavaScript SDK widgets for embedding TRADEPRESS calculators (margin, position sizing, stop-out, and others) on third-party websites. Widgets are themeable via CSS variables and require no server-side integration.
• White-label deployment — Partners can deploy the TRADEPRESS middleware engine under their own brand, with custom theming, domain mapping, and institutional destination preferences. White-label deployments inherit the same non-custodial architecture.

All integration methods transmit data only — no capital flows through any integration endpoint.

The platform implements layered security controls appropriate to a non-custodial data intermediary:

• Encryption in transit — All API traffic uses TLS 1.2+ with perfect forward secrecy. Widget embeds are served over HTTPS.
• Encryption at rest — Canonical Contact Records stored for audit purposes are encrypted using AES-256.
• Access control — Role-based access control (RBAC) with least-privilege principle. API keys are scoped per endpoint and rate-limited.
• Immutable audit trail — Every CCR is timestamped, hash-chained, and retained for the regulatory retention period. Records cannot be modified or deleted after creation.
• Incident response — Automated monitoring detects anomalous access patterns, API abuse, and potential data breaches. Incidents are escalated and, where required, notified under the Notifiable Data Breaches scheme.

Compliance is embedded in the pipeline at Stage 2 (Clean), not bolted on as an afterthought:

• Jurisdictional tagging — Each CCR is tagged with the client's regulatory jurisdiction, determining which institutions are eligible recipients.
• AML/CTF screening — Client data is screened against sanctions lists and politically exposed person (PEP) databases during the Clean stage.
• Restriction enforcement — Jurisdictional restrictions (e.g., instrument bans, leverage caps, short-selling prohibitions) are enforced at the routing stage, ensuring no CCR is routed to an institution that cannot legally accept it.
• Regulatory metadata — Each CCR carries the regulatory metadata required by the destination institution's compliance team, reducing manual onboarding friction.

See our Regulatory Disclaimer for the allocation of compliance responsibility between TRADEPRESS, Users, and third-party institutions.

The TRADEPRESS middleware engine is designed for institutional throughput:

• Edge deployment — The platform is deployed on a global edge network (Cloudflare Workers) with 300+ data centres, ensuring sub-50ms response times for API calls from most jurisdictions.
• Stateless processing — Each pipeline stage is stateless, enabling horizontal scaling without session affinity.
• Asynchronous routing — CCR routing to destination institutions is performed asynchronously, preventing any single institution's latency from blocking the pipeline.
• Cached instrument data — Instrument metadata, institution capabilities, and execution quality metrics are cached at the edge, reducing database round-trips.

The platform is built on a serverless edge-first architecture:

• Compute — Cloudflare Workers (V8 isolates) for API processing, pipeline execution, and widget rendering.
• Key-value storage — Cloudflare Workers KV for cached instrument data, institution metadata, and session state.
• Relational database — Cloudflare D1 (SQLite at the edge) for Canonical Contact Record storage and audit trail.
• Object storage — Cloudflare R2 for document attachments, KYC files, and compliance records.
• Static assets — Served directly from the edge with aggressive caching headers.
• DNS & security — Cloudflare DNS, WAF, DDoS protection, and Bot Management.

This stack ensures that the platform has no single point of failure, no traditional server to compromise, and no custodial infrastructure to attack. The non-custodial architecture is reinforced by the serverless infrastructure choice.