API overview
1 Core System exchanges data with other systems in three ways: a message API for systems that need to act in real time, files where a counterparty works in files, and outbound calls that CDD Core makes to services such as identity proofing.
What is available
Section titled “What is available”| Interface | Direction | Status | Reference |
|---|---|---|---|
| Trading link (DA Dealer): customer state, restriction commands, limits, execution reports, transaction feed | Both ways, JSON over HTTPS | Live | Conventions · Messages CDD Core receives · Messages CDD Core sends |
| FundConnext files: customers, accounts, monthly statements | In | Live | Files |
| AERS XML for AMLO forms 1-02 and 1-03 (DA Dealer) | Out, as a file the officer files | Live | Files |
| Identity proofing (NDID · DOPA), liveness (Didit), e-mail and SMS | CDD Core calls them | Live, per installation | Integrations |
Design principles
Section titled “Design principles”- One message, one HTTPS POST, one JSON object. No shared database, no direct table access across systems.
- A key per direction. Each side holds only the SHA-256 hash of the key it accepts. Keys are handed over out of band and never appear in code, documents or messages.
- Receipt first, result later. The HTTP answer only confirms receipt. Work that takes time is reported as its own message.
- Safe to repeat. The same
message_idis processed once and answered the same way every time, so senders can retry freely. - Store first, send second. An officer’s decision is stored before it is sent, so a network failure never loses a command, and the screen never waits on the other system.
- Last state holds. If the other side cannot be reached, the last state it received stays in force. A restricted leg stays restricted.
- Minimum data. The trading system receives what it needs to serve and to refuse. Identity documents, addresses, dates of birth and screening results never cross the link.
Environments
Section titled “Environments”Each institution has its own installation. Staging and production differ by base URL and key, never by a field in the message. Base URLs and keys are issued during onboarding of the link.
Versioning
Section titled “Versioning”Message types and their fields grow by agreement. A field is never repurposed. A sender that adds a new code before the receiver knows it gets UNKNOWN_CODE, so neither side guesses.