848%3C-7111%3B848%3DCOSTARET%3B5001%3DSORvalue='848<-7111;848=COSTARET;5001=SOR'
encoded=$(python3 -c 'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe="=-"))' "$value")
curl -X POST -d '' "https://myurl.corp/service/$encoded"curl -X POST -d '' "https://myurl.corp/service/$(python3 -c 'import urllib.parse; print(urllib.parse.quote("848<-7111;848=COSTARET;5001=SOR", safe="=-"))')"
Why DCM is different
1. Contracts become self-contained executable action structures
DCM does not stop at static terms and conditions. It models:
- who acts;
- on which asset or information object;
- at which location or account;
- under which authority;
- in which causal order;
- with which temporal triggers and deadlines;
- with what confirmation and communication requirements.
2. Reconciliation is first-class, not bolted on
Custody, account servicing, and post-trade processing depend on multiple parties maintaining related but independently operated records.
DCM represents this explicitly via a special mirroring construct.
A mirrored relationship is not simply an alias or shared database row. It is a formal correspondence between independently maintained representations of the same underlying financial content.
This naturally models:
- custody books;
- nostro/vostro relationships;
- client and custodian positions;
- omnibus-to-segregated account views;
- CSD participant accounts;
- reconciliation obligations.
A break is not just “data mismatch.” It is a violation of a defined correspondence.
3. Authority is part of the model
Financial operations are not governed only by physical or technical capability. They are governed by mandates, permissions, delegation, and institutional authority.
DCM represents this through dominion: a formal relation determining who may authorise a change in a given operational space.
For example:
- a custodian may locally operate an account;
- the client may retain authority to instruct operations affecting that account;
- an instruction must therefore be represented as a formal information event before the custodian can act.
This creates a native bridge between:
- operational action;
- communication;
- authority;
- evidence;
- auditability.
5. Every action can retain its causal lineage
A local action such as:
debit cash from a custodian’s nostro account
usually loses its business context once it enters a low-level workflow, API call, queue, or ledger process.
DCM introduces an activation context that can accompany operational activity across parties and contracts. This preserves a route from any immediate action—including purely technical actions—back to the contracts it is intended to implement, or to the ultimate cause that initiated it.
This creates a native form of distributed traceability:
Trade
→ custody obligation
→ pooled account action
→ nostro instruction
→ CSD settlement action
Rather than correlating logs after the fact to reconstruct the Humpty-Dumpty piece by piece, the causal relationship is part of DCM’s core operational model. Humpty-Dumpty is therefore never broken in the first place.
Traditional systems commonly implement aggregation and netting as product-specific ad-hoc SQL, batch jobs, or bespoke accounting logic.
In DCM, aggregation can emerge automatically from a shift in vantage, without writing any specific code.
For example, the same securities may be represented:
- individually by client custody account;
- collectively in an omnibus account;
- collectively again at a CSD participant account.
The correspondence between these views is explicitly modelled.
Netting and aggregation can therefore be derived from the relationship between more detailed and more aggregate operational vantages, rather than rebuilt separately for every product and infrastructure.