This example demonstrates how a trade settlement process can be implemented by specifying only a minimal amount of meaningful domain information. With only a few pages of DCM code — or equivalent diagrams — an entire settlement process involving multiple parties can be orchestrated in a distributed manner without writing a single line of traditional PLcode.
None of the traditional artefacts of software development — such as services, message repositories, database tables, or APIs — need to figure in the solution; they are essentially at the wrong level of description when dealing with the automation of the business process itself.
Note that it does not matter whether these technical artefacts are produced manually by developers or generated by AI. The important point is that, in the traditional approach, these are the primary way the target business process is rendered into software.
DCM, in contrast, tries to formalize the business domain directly by means of its conceptual descriptions, capturing the semantics of what is going on within the business domain. There is no need to degrade the description into the purely technical domain, which might have no structural similarity to the business domain except for the superficial similarity that is artificially imposed through conventions.
The main elements of the DCM solution doing all the work are topology, mereology, and interactional force dynamics.
None of these are present in the traditional approach, even though they are intrinsic to the nature of the business domain.
What is probably even more important, though less visible, is that LLMs and current AI systems lack these structures at the foundational level as well. Such structures may be indirectly induced within an ANN's abstract weight space during training, but they do not play the same foundational role. There is no guarantee that the inferences produced by an LLM actually follow principles of topology, mereology, or space-time reasoning, because the underlying objective remains token prediction.
This is a crucial point of divergence between AI-driven automation and the natural flow of human thought when working on a problem.
The example shown here is intentionally simplified to highlight the core capabilities of DCM. Real-world trade settlement systems involve additional complexity, such as CCPs, T2S, and other operational layers, which will be presented in a separate case. The key point is that the approach scales naturally to real-world complexity without requiring it to go beyond its expressive powers.
DCM use case :
Implementing
settlement of a trade
Frames
DCM itself is based on framed vantage theory, a broader subject grounded in cognitive science, neuroscience, perception, and linguistics — unlike traditional methodologies for writing programming-language code such as OOP, FP, or DDD. For the purposes of this example, theoretical concepts are introduced as necessary — only when they appear in the code fragments.
A frame is a fundamental building block of DCM. A fundamental building block within DCM describes either a process (frame) or a static configuration (schema). A frame usually construes an interaction between several agents (which can represent parties in a financial contract) — the TRANSFER, TRADE, or OPTION frames fall into this category. But a frame can also describe some change that is local to a single agent (called an ego-frame in this case) — e.g. the LOCAL_MOVEMENT frame.
Every frame splits the content it is framing (or construing) into a figure and a background — and each frame can split it in its own way. A frame consists of static elements — agents, figures, and places — as well as dynamic elements: agents interacting and acting upon figures.
Note that a frame involving multiple agents effectively defines a contract between them: each agent is obliged to enact its part of the frame.
Each agent also creates a perspective — a local view of how the world appears from that agent’s vantage point.
All the elements within a frame have labels called roles attached to them. The frame acts as a small world model where all elements are co-dependent, meaning an element is defined via all the other elements that appear in the same frame. There cannot be a BUYER without a SELLER, there cannot be a GIVER without a TAKER, etc.
Elements of the frame are not like variables or class members in traditional programming languages. In traditional programming languages, a developer can attach an arbitrary label to a technical element, which need not have any correspondence to the role this element actually plays in implementing some business process. A variable can be called "BUYER" but be treated as a memory address for a sequence of characters, with no "cash" going from it and no "securities" coming its way. The actual meaning (or definition) of a technical element is attached externally to it.
Even with perfectly controlled naming conventions, due to the multi-levelled nature of any software implementation of a business domain, there will always be multiple alternative choices for how to name some element of the implementation.
This problem is resolved by DCM's collage model of composition, where a single element can simultaneously play many roles in many frames — e.g. a person can be a parent, an employee, a customer, and a client — playing a different role in each frame the person is engaged in.
With frames, each element gets its name from the role it plays within the frame as a whole; thus, element names are the names of the roles these elements play within the frame, and the latter are specified intrinsically by the frame and are not subject to external interpretation.
The outline
To build an executable model of a stock trade settlement, a set of 11 frames will be introduced:
TRANSFER — framing a transfer of an object (figure) from one agent to another
TRADE — framing a stock trade between two counterparties
CUSTODY — framing one party as relying on another to hold its stock
BANK — framing one party as relying on another to hold its cash
CSD — framing the CSD within the context of a TRADE immobilizing securities
POOL_ACCOUNT — framing the pooling of assets within a single account
NOSTRO_ACCOUNT — framing assets held within an internal account as being held by an external party
COM — framing a minimal communication between two parties
REQUEST_REPLY — framing a more complex communication, such as one party instructing another
LOCAL_MOVEMENT_LINKED — framing a local movement of an object (figure) from one location to another
DVP — framing a delivery versus payment
Out of all these frames, the TRADE frame plays a privileged role because it represents the actual contract to be enacted (the final cause in Atertotelian terms).
All the other frames are combined via cross-referencing to provide a contextual elaboration of the TRADE frame, introducing enough detail to make it executable in a distributed manner.
Each frame will be introduced in a separate section, followed by its application in elaborating the TRADE frame and progressively making the latter more detailed.
The end goal — the ability to orchestrate a distributed settlement of a trade — will be presented at the end of this article as a set of action plans for each party (agent) involved in the settlement process, including:
the counterparties (buyer and seller);
their clearing banks;
the CSD.
Construing TRANSFER
frame TRANSFER @ GIVER, TAKER {
TRANSFERRED is figure;
perspective GIVING @ GIVER where GIVEN => TRANSFERRED {
release GIVEN;
}
perspective TAKING @ TAKER where TAKEN => TRANSFERRED {
capture TAKEN;
}
dynamics {
GIVING:IN @ GIVER -> TAKING:IN @ TAKER;
TAKING:OUT @ TAKER -> GIVING:OUT @ GIVER;
}
}
The concept of trade is not an irreducible one, but something that can be analyzed into more fundamental components. To define a trade, we therefore begin with a more primitive notion: a transfer, formalized through the TRANSFER frame.
This frame construes the movement of a figure between two agents: the GIVER and the TAKER. Because every action must have an actor and remain local to that actor (the “no action at a distance” principle), actions involving a single agent can always be construed from within that agent’s perspective.
Thus, the GIVING perspective construes the action from the point of view of the GIVER. The action itself is simply the release of a figure. The figure is labelled with a GIVEN role from within this perspective, but appears under the TRANSFERRED role at the detached level.
DCM defines a small set of prime (irreducible) changes to which all target (business) domain changes can be semantically decomposed into. In this example, only two are needed: release and capture.
In the trading domain, these map directly to familiar operations:
Releasing a CASH figure such as 50 USD from a CASH_ACCOUNT corresponds to debiting that account by 50 USD.
Capturing the same figure corresponds to crediting the account by 50 USD.
Symmetrically, the TAKING perspective construes the dual operation: capture of a TRANSFERRED figure, which is labelled as TAKEN from within the perspective (or POV) of the TAKER.
A frame with multiple agents must also define the interaction between them. Otherwise, there is no justification for including two agents in a single frame — it is only a frame when these agents interact with each other; otherwise, this would be two independent frames, the sum of two frames.
This interaction is construed from a detached, third-person perspective. Since interaction inherently involves multiple agents, no single agent’s perspective is sufficient to enact it.
There can also be a frame construing an action internal to a single agent — the ego frame — which we will encounter later.
The important point is that every frame defines force dynamics — a causal graph of actions and interactions — be these between agents (two subjects) or between an agent and a figure (subject and an object).
In the TRANSFER frame, the interactional dynamics consist of two causal relations:
the start of the GIVER’s action triggers the start of the TAKER’s action;
the completion of the TAKER’s action triggers the completion of the GIVER’s action.
This interactional structure binds the otherwise independent primitive changes — release and capture — into a complete transfer of a figure from one agent to another. In this way, the frame as a whole describes a complex change or a complex event.
frame TRADE_TC @ BUYER, SELLER {
PRODUCT is STOCK;
CASH is CASH;
components { TRANSFER as PRODUCT_TRANSFER; TRANSFER as CASH_TRANSFER }
tc { SETTLEMENT_DATE_SOD -> SETTLEMENT_DATE_EOD }
perspective BUYING @ BUYER where BOUGHT => PRODUCT, PAID => CASH,
TAKING_PRODUCT => PRODUCT_TRANSFER/TAKING,
GIVING_CASH => CASH_TRANSFER/GIVING {
component GIVING_CASH where GIVEN => PAID;
component TAKING_PRODUCT where TAKEN => BOUGHT;
dynamics {
SETTLEMENT_DATE_SOD >> GIVING_CASH:IN ;
SETTLEMENT_DATE_SOD >> TAKING_PRODUCT:IN ;
GIVING_CASH:OUT -| SETTLEMENT_DATE_EOD;
TAKING_PRODUCT:OUT -| SETTLEMENT_DATE_EOD;
}
}
perspective SELLING @ SELLER where SOLD => PRODUCT,
GIVING_PRODUCT => PRODUCT_TRANSFER/GIVING,
TAKING_CASH => CASH_TRANSFER/TAKING {
component GIVING_PRODUCT where GIVEN => SOLD;
component TAKING_CASH where TAKEN => CASH;
dynamics {
SETTLEMENT_DATE_SOD >> GIVING_PRODUCT:IN ;
SETTLEMENT_DATE_SOD >> TAKING_CASH:IN ;
GIVING_PRODUCT:OUT -| SETTLEMENT_DATE_EOD;
TAKING_CASH:OUT -| SETTLEMENT_DATE_EOD;
}
}
}
Construing TRADE
In this version of a trade, we assume that we want the transfer of cash and securities to happen on a settlement date — anywhere between its start (SETTLEMENT_DATE_SOD) and end (SETTLEMENT_DATE_EOD). These are temporal constraints on the actions we have construed within the perspectives of the BUYER and SELLER; hence, we have two blocks of dynamics under each perspective adding these constraints.
Note that time, unlike action/force, is a global notion — each agent has its own access to time because all the agents are co-temporal or embedded within the very same temporal dimension.
Still, there can be an additional structure expressed within the temporal dimension — like the fact that SETTLEMENT_DATE_EOD follows SETTLEMENT_DATE_SOD on the temporal dimension.
We can also construe a TRADE where the release of PRODUCT requires that the capture of CASH has started, as is displayed in the diagram. Here, we would need to add an additional dynamical coupling between two components of the SELLING perspective (CASH_TRANSFER/TAKING and PRODUCT_TRANSFER/GIVING).
Note that the force-dynamical edges connecting two agents are highlighted in gray to indicate that they are not directly enactable by either of the two agents alone, since they represent an interaction rather than a local action such as capturing PRODUCT or releasing CASH.
This topic will be elaborated upon later and will lead to the introduction of a communication framework to make those edges executable.
Now we are ready to construe a trade. A trade can be construed in many different variations — all having their own grounds or use cases. In this example, we will pick just one out of many.
The essential part here is the presence of two agents and two figures — one being CASH and the other being STOCK. The dynamics are those of one figure being exchanged for another.
This semantics can be composed out of simpler components — out of two TRANSFERs. Hence, we have a TRADE as a composite frame that has two component frames — both are instances of TRANSFER, but each one binds to the TRADE in its own way.
DCM is based on a collage model of composition (imitating that of cognition, which is also composition path-agnostic) that is fundamentally different from the Lego-block model that sits behind all programming languages. The essence of the collage model is that elements can overlap and complement or elaborate each other — there will be content that has more than one single “structure” or interpretation.
Because there are two agents in the TRADE frame, we have two perspectives here within which we can construe action. And since we have two TRANSFER components, we automatically “inherit” all the content from each component frame — including the actions and perspectives themselves.
We only need to put those in correspondence with the current frame — to map elements of each TRANSFER component frame into their corresponding elements in the TRADE composite frame. This is a binding (or wiring) operation, and it sits at the core of the collage model of building large structures from small ones that DCM is built on.
Because the resulting composite construction includes all the content of its components, we can also say that the structure of each component frame is embedded into the composite frame.
Here we are doing that through a reference to the component frame's perspective: what the BUYER does is composed out of the TRANSFER frame’s GIVING perspective for the CASH component and the TRANSFER frame’s TAKING perspective for the PRODUCT component. I.e. the buyer is giving the cash and taking the product.
The perspectives of the component frame are thus embedded into the perspectives of the composite frame in the same way as all other content of the component construction is embedded into the composite construction.
In general, each frame is a small model of reality, and the embedding between frames is an embedding of one reality into another. In the binding operation, the more abstract model (a component) is bound to the more concrete one (a composite), and thus the former is embedded into the latter.
schema CUSTODY @ CLIENT, CUSTODIAN {
CUSTODIAN <~ CLIENT, CUSTODIED;
CLIENT -> CUSTODIAN;
CUSTODIED is STOCK;
CUSTODIED @ CLIENT.CUSTODIAN.SECURITIES_ACCOUNT
~> CUSTODIAN.CLIENT.SECURITIES_ACCOUNT;
}
Construing CUSTODY and BANK
schema BANK @ CLIENT, BANK {
BANK <~ CLIENT, HELD;
CLIENT -> BANK;
HELD is CASH;
HELD @ CLIENT.BANK.CASH_ACCOUNT
~> BANK.CLIENT.CASH_ACCOUNT;
}
The TRADE frame can itself become a component within more complex contracts such as FUTURE or OPTION.
In this example, however, we focus on executing the trade we have just construed — enacting the frame itself. Because a frame is essentially the brain's mechanism to affordaction and interaction within the world, its purpose is realized through enactment.
In financial systems, this execution process of a trade is called settlement or clearing. Since the TRADE frame represents a contract, the actions construed within it must eventually be enacted by the participating agents — for example, the securities being delivered by the seller and received by the buyer.
In practice, however, the seller does not usually hold securities directly, as in a simple physical exchange of goods. Instead, securities and cash are typically held by third-party institutions providing custody and banking services.
This situation is modeled through:
a CUSTODY schema for STOCK;
a BANK schema for CASH.
Note that the content construed here is static — what is construed is the stable relation (the relation in the phase of stasis). That is the difference between a frame (which construes a change in relations) and a schema (where relations are stable).
This difference between a frame and a schema creates a difference in how frames and schemas auto-complete when instantiated (as overlays), which will be illustrated later.
The CUSTODY schema involves two agents with an asymmetrical relation between them specified as "CLIENT->CUSTODIAN": it is the CLIENT agent who is ontologically prior, while the CUSTODIAN agent is the one playing some functional role for the former (and thus is dependent on the former for its existence).
Here we also have an individuation condition specified with "CUSTODIAN <~ CLIENT, CUSTODIED": the identity of the CUSTODIAN agent is fixed by, or linked to, that of the CLIENT and the figure that is held in custody — called here CUSTODIED.
A key part of the schema is the mirroring relation denoted by ~>.
It states that the localization of a CUSTODIED figure at:
CLIENT.CUSTODIAN.SECURITIES_ACCOUNT
implies the existence of another, grounding figure at:
CUSTODIAN.CLIENT.SECURITIES_ACCOUNT
This construction expresses an irreducible semantic relation deeply rooted in human cognition: whatever appears at a certain location must be backed up by something else, which is ontologically prior, at another location.
An everyday example of this would be a reflection in a mirror: the reflection exists only because an underlying object exists first. Another example is a shadow cast onto a wall: the shadow cannot exist without an object and a light source falling onto it.
Using the shadow analogy:
the role of the object casting the shadow is the figure;
the role of the light falling onto the object is one place/location;
the shadow is another figure;
the wall onto which the shadow is cast is another place/location.
This mirroring relation can also be understood as a representation relation or a model-to-realization relation:
a STOCK figure appearing in the client account acts as a representation;
the corresponding figure in the custodian account acts as its grounding realization.
More generally, this is a special case of representation itself: one agent internally representing some aspect of another agent’s state.
For example:
R = cash represented in a nostro account;
X = the corresponding cash in a vostro account.
Finally, because schemas construe stable configurations rather than actions, they contain no dynamics — only structural relations between elements.
Similarly, we can construe a BANK schema for indirectly holding CASH.
Note that both schemas (CUSTODY and BANK) are also contracts.
Instantiating CUSTODY and BANK within TRADE
We now need to apply the two schemas to the previously defined TRADE frame — combining multiple constructions into a single coherent structure — in a way that does not contradict anything we have already construed within the TRADE frame.
We want to add an additional detail that is complementary to what we have built so far. We want to take the TRADE construal we have built as a baseline and specify an elaboration of it via the CUSTODY and BANK schemas.
The way an elaboration is created from a baseline is topology-preserving: what the baseline specifies — the STOCK figure being within the dominion of the BUYER — remains true in the elaboration. The STOCK is still within the dominion of a BUYER — only the structure of the dominion itself is elaborated.
The ability to create topology-preserving elaborations enables “structural multiplication” — a concept analogous to a semi-direct product in abstract algebra — allowing us to describe independent aspects of reality separately (thus preserving human-scale descriptions), while still being able to compose these aspects into a single and coherent reality (along dimensions where they minimally overlap, i.e., respecting how one component of a product is linked to another).
Two constituents of this operation — in this case the CUSTODY schema and the TRADE frame — are linked closely enough to achieve a closure that results in a new construction that includes all the specifications of the constituent constructions.
We are taking one construction — the one that has a more concrete/specific level of reality — as having priority over the other.
Here the CUSTODY frame has a lifespan that embeds the lifespan of TRADE, which results in CUSTODY instances being the background against which the TRADE frame is instantiated. Note that this relation between frame lifespans applies directly to contracts (since a frame represents a contract).
Hence, the TRADE frame represents the more concrete level of reality, and that is where the more abstract level of reality — the CUSTODY (or BANK) schema — will be brought to.
To lift the CUSTODY schema to the level of reality of the TRADE frame, we need to wire (or bind) elements of the CUSTODY schema to those of the TRADE frame.
instantiate CUSTODY where CLIENT => A, CUSTODIED @ CLIENT.CUSTODIAN.SECURITIES_ACCOUNT => L from #1 figure F : STOCK ; #1 -> #2 localisation L : F @ agent A
The instantiation statement defines a pattern that is matched against the content of the TRADE frame — the target level of reality — in order to bind the minimal generating kernel of the instantiated CUSTODY schema.
In this example, the pattern consists of two conditions:
a figure of type STOCK;
localized under some agent.
When matched against the TRADE frame, this pattern produces two captures:
one where PRODUCT is localized under BUYER;
another where PRODUCT is localized under SELLER.
Following the rules of individuation, this results in two instantiated CUSTODY schemas:
one representing the BUYER holding the stock indirectly through a BUYER custodian;
another representing the SELLER holding the stock indirectly through a SELLER custodian.
At this stage, there is nothing that tells us anything specific about these two CUSTODIANs, only the general fact that there must be two. In practice, both custodians could even turn out to be the same real-world institution.
That level of instantiation is called generic (it is part of the frame vantage theory on which DCM is based): when we take the CUSTODY schema and lift its level of reality to that of the TRADE frame, all the coordinates of the CUSTODY construction are either:
fixed or wired onto the corresponding coordinates of the TRADE construction, or
fixed generically (if there is no pre-existing element to fix them to).
This operation is just one specific example of a coordinate-fixing operation in frame vantage theory that underlies the formal core of DCM (which is itself more abstract than DCM and deals only with construal of points of view in abstract/cognitive space).
We can now further extend the TRADE substrate by instantiating the BANK schema in a similar way.
This time, however, we want to model a trade-settlement scenario involving a clearing bank.
A clearing bank combines both custody and banking functions for one side of the trade (BUYER or SELLER).
The goal is therefore to instantiate the BANK schema so that the BANK and CUSTODIAN roles are played by the same agent (the clearing bank).
The matching pattern is:
find a figure of type CASH;
find a CUSTODY fiber;
find a localization of the CASH figure under an agent playing the role of CLIENT within that CUSTODY fiber.
Again, note that these two (frame and schema) construe complementary content — i.e., there is some content construed only in TRADE and not in CUSTODY, as well as content that is only construed in CUSTODY but is absent in TRADE.
Importantly, the frame and schema construe complementary content:
some content exists in TRADE but not in CUSTODY;
some content exists in CUSTODY but not in TRADE.
To instantiate the CUSTODY schema, we need to put its elements into correspondence with the elements of the TRADE frame — to bind or wire elements of the instantiated construction to something that already exists.
This results in an alternative framing of the same content — several frames will bind onto the same content, overlapping in their interpretations (construals) of this content.
In this example, both constructions share:
the STOCK figure;
the agent holding the stock.
However, there will be some content in the instantiated construction that cannot be wired onto anything — simply because it is missing in the other construction and there is nothing to put it in correspondence with.
In this example, the CUSTODY schema also introduces additional elements absent from the TRADE frame, including:
the CUSTODIAN agent;
the accounts on both sides of the mirroring relation.
This is where the concept of a core set of elements, called a minimal generating kernel, that can be pattern-completed within a larger context, comes into play.
This means that we can infer the values for all the free (unbound/unwired) coordinates of the CUSTODY schema to the level of reality of the TRADE frame, given that we have instantiated (wired) enough content of the CUSTODY schema to auto-complete itself within the TRADE context.
Notably, only one side of the mirroring relation is explicitly wired in this CUSTODY instantiation. Due to the semantics of the mirroring relation, the other location is inferred and individuated automatically — if there is a shadow cast on a wall, there must be an object and a light source from which this shadow comes.
Thus, the other location defined in the CUSTODY frame (CUSTODIAN.CLIENT.SECURITIES_ACCOUNT) is also auto-completed or generically fixed.
At this point we arrive at an extended construal of the trade. The resulting structure no longer consists solely of the original TRADE frame but contains the result of the interaction between multiple constructions — here, TRADE and CUSTODY. This combined structure is called a substrate.
A substrate always has a single surface level of reality defined by the surface frame (the top-level frame from which we have started construction) — the frame that bootstraps the substrate. Other frames and schemas can then be lifted into this surface level.
In this example:
the TRADE frame acts as the surface frame of the substrate;
the two instantiated CUSTODY schemas are embedded within that same substrate.
Because a substrate is composed of many different frames and schemas, or even many different instances of the same frame, all of these are called fibres.
The name fibre is borrowed from fibre bundle theory, due to it being the mathematical model of how we are construing a complex object (substrate) by “bundling together” multiple instances of frames and schemas (fibres).
In this example, the resulting substrate contains:
one TRADE fibre defining the surface reality;
two CUSTODY fibres.
instantiate BANK where BANK => CT:CUSTODIAN, CLIENT => CT:CLIENT, HELD @ CLIENT.BANK.CASH_ACCOUNT => L from #1 figure F : CASH ; #1 -> #2 fibre CT : CUSTODY; #2 -> #3 localisation L : F @ agent CT:CLIENT;
Unlike the earlier instantiation of the CUSTODY schema, here we explicitly wire the BANK role.
Specifically, the agent playing the role of BANK must be the same agent already playing the role of CUSTODIAN in the matched CUSTODY fiber.
In other words, the same institution simultaneously acts as:
custodian for securities;
bank for cash.
After executing this instantiation, the TRADE substrate is extended once again — now containing two additional BANK fibers alongside the previously instantiated CUSTODY fibers.
Construing CSD and instantiating it within TRADE
schema CSD @ CSD {
CSD <~ STOCK;
STOCK is STOCK;
CASH is CASH;
}
We can now extend the scope of the TRADE construal by instantiating the CSD schema within the TRADE substrate.
At this stage, we only construe the aspects of the CSD required from the POV of the TRADE substrate. We are not attempting to model the CSD objectively from a detached point of view, we are only looking at it only from within the TRADE’s POV.
Every STOCK figure within the substrate now has a corresponding grounding figure under the CSD schema. The same applies to CASH.
Because the substrate contains only one type of STOCK figure, and because the CSD is individuated by that figure type, only a single CSD instance is created — one CSD fiber.
We can now construe the CSD itself as simultaneously acting as:
CUSTODIAN;
BANK;
for the two clearing banks participating in the trade.
This is achieved by instantiating additional CUSTODY and BANK schemas on top of the existing substrate, which we can do by instantiating CUSTODY frame where CSD plays the role of CUSTODIAN.
Here we are going to significantly simplify the EU stock-settlement process by assuming that the CSD itself orchestrates settlement, rather than involving yet more parties such as T2S.
A more realistic model — including T2S, delivery-versus-payment (DvP), receive-against-payment (RaP), and other settlement instructions — will be presented separately.
The purpose of this example is to demonstrate how DCM works, not to reproduce every operational detail of a real settlement infrastructure.
Notice how the indirect holding hierarchy for STOCK is unfolded layer by layer:
the surface level represented in the TRADE frame, where the STOCK is within the dominions of BUEYR or SELLER;
the custody level represented by CUSTODY schema, where the STOCK within the dominion of CUSTODIAN;
the terminal grounding level represented by the CSD schema, where the STOCK within the dominion of CSD represents the immobilisation of a security.
We start with the “mode of presentation” of STOCK - the STOCK being at the BUYER or SELLER - that exists at the surface level frame (TRADE).
The surface frame represents the primary activity motivating the entire substrate.
In Aristotelian terms, it acts as the final cause for everything else that happens within the substrate (hence the substrate gets it’s name after it's surface frame).
Then we go deeper by revealing layers where the figure we have construed (STOCK) actually comes from - going from a “mode of presentation” of something to that something, going from re-presentation of an entity to that entity.
From the perspective of enacting the TRADE contract — i.e. settlement — we can model the CSD minimally through a CSD schema.
The key idea is that the CSD acts as the terminal holder of securities and cash.
(In practice, this resembles the role played by DTC in the US market.)
Within the TRADE context, the CSD is individuated by the type of figure it grounds — here, STOCK.
instantiate CSD where STOCK <~ F, CASH <~ C from #1 figure F : STOCK ; #1 -> #2 figure C : CASH;
This time, however, we bind more coordinates explicitly.
In particular, we wire the realization side of the mirroring relation — the grounding figure — directly onto the STOCK figure already present at the CSD level.
This captures the core semantics of:
indirect holding;
immobilization of securities.
A single grounded security at the CSD level is mirrored upward across multiple layers of custody and bookkeeping systems.
No matter how many agents represent this STOCK as a figure within their own frames, there will always be a single STOCK figure at the CSD level that represents the actual figure and grounds all the others.
Conceptually, this resembles a single object casting multiple shadows or a single sound source generating multiple echoes: multiple representations grounded in one underlying reality.
Note that at this point, the TRADE substrate contains 4 CUSTODY fibres:
two where BUYER and SELLER act as clients;
two where the buyer’s and seller’s custodians act as clients;
instantiate CUSTODY as CSD_CUSTODY where CLIENT => C:CUSTODIAN, CUSTODIAN => D:CSD, CUSTODIED @ CLIENT.CUSTODIAN.SECURITIES_ACCOUNT => C:CUSTODIED @ CUSTODIAN.CLIENT.SECURITIES_ACCOUNT, CUSTODIED* => D:STOCK from #1 fibre D : CSD; #1 -> #2 fibre C : CUSTODY;
The next step is to make CSD a BANK for both clearing banks via instantiating BANK schema in the TRADE substrate.
After this instantiation we will also have 4 fibres of the BANK frame within the TRADE substrate.
instantiate BANK as CSD_BANK where CLIENT => B:BANK, BANK => D:CSD, HELD @ CLIENT.BANK.CASH_ACCOUNT => B:HELD @ BANK.CLIENT.CASH_ACCOUNT, HELD* => D:CASH from #1 fibre D : CSD; #1 -> #2 fibre B : BANK;
Note that this frame captures the essence of what it means to be a “nostro account”.
Unlike labels containing the word “nostro” in traditional PLs, where the link between the name and the meaning is purely accidental and, at best, the subject of a naming convention, in DCM the two are inseparable.
The roles of NOSTRO_SEC_ACCOUNT can be given abstract, uninterpretable names, like A for US and B for THEY, but what the frame construes would not change — the meaning would be preserved (and can even be pattern-detected while ignoring the labels altogether).
This is a fundamental property of frames — the role receives its name from what it does or how it is construed within that frame, i.e. relative to all other elements of the frame, regardless of what else it might be outside the frame.
A dual notion of the vostro account can also be represented as a frame.
In this minimal example, this frame is not needed because we are only construing the pool account within the clearing bank (which corresponds to the nostro side of the CUSTODY fibre making the CSD play the role of CUSTODIAN for the clearing bank).
If there were a pool account at the CSD, this would require instantiating VOSTRO_ACCOUNT fibres in the same way to bridge two different topologies: the vostro-account side of the CUSTODY schema and the pool account within the CSD.
schema POOL_ACCOUNT {
POOLED is FIN_FIGURE ;
POOLED @ POOLED_ACCOUNT ~> POOL_ACCOUNT;
}
The clearing bank itself is a participant within the CSD, where the CSD acts as a CUSTODIAN for the stock that the clearing bank holds.
To ground the stock held in the pool account of a clearing bank, a CUSTODY fibre can be instantiated that turns the clearing bank into a CUSTODY.CLIENT, where the CUSTODIAN role is played by the CSD.
The next step in descending the indirect holding hierarchy is to link the stock held in the pool account to that held under the CSD.
The CUSTODY frame links the nostro and vostro sides between the clearing bank as CLIENT and the CSD as CUSTODIAN.
So the missing link now is the one between the pool account (POOL_ACCOUNT location of POOL_ACCOUNT frame) and the nostro account of the CUSTODY frame: CLIENT.CUSTODIAN.SECURITIES_ACCOUNT.
The former cannot be wired directly onto the latter (which would mean that the pool account is identified with the nostro account), because this would violate the mereotopology upon which DCM is based.
The structure of CLIENT.CUSTODIAN.SECURITIES_ACCOUNT, where CLIENT is wired into the clearing bank while CUSTODIAN is wired onto the CSD, implies that the SECURITIES_ACCOUNT is under the gateway representing the CSD agent within the clearing bank agent.
However, the structure of POOL_ACCOUNT is just a single container local to the clearing bank (the agent of the POOL_ACCOUNT ego frame).
These two have different topologies — one cannot be transformed into the other without changing the topology.
Hence, we need an additional construction to bridge this gap — we need to represent the fact that the pool account acts as a nostro account and not just a local one, without stating that the two are one and the same thing.
schema NOSTRO_ACCOUNT @ US, THEY {
US -> THEY;
ASSET is FIN_FIGURE;
ASSET @ US.LOCAL_ACCOUNT ~> US.THEY.NOSTRO_ACCOUNT;
}
Vostro Account frame
schema VOSTRO_ACCOUNT @ US, THEY {
THEY -> US;
ASSET is FIN_FIGURE;
ASSET @ US.THEY.VOSTRO_ACCOUNT ~> US.LOCAL_ACCOUNT ;
}
A clearing bank has many clients whose assets it holds in custody.
At the lower level of the indirect holding hierarchy, the assets of many clients can be pooled into the same account that the clearing bank itself holds within the CSD, where it is a participant.
In order to model this aspect, we need to introduce the POOL_ACCOUNT frame.
Note that this is an ego frame with a mirroring relation where the more fine-grained location (the client gateway) is backed up by a more coarse-grained one (the pool account), thus representing aggregation.
The same structure is applicable to both STOCK and CASH, and thus instead of defining two separate frames to model the pooling of cash and the pooling of stock, only one frame can play both roles.
Note that having one frame does not imply having one fibre, and as will be shown later, the instantiation statement for the POOL_ACCOUNT frame can individuate two separate pool accounts — one for stock and one for cash.
Nostro Account frame
This can be expressed via the NOSTRO_SEC_ACCOUNT frame.
It construes a local account (local to the agent US) as mirroring an external account that is located under a different agent (THEY).
The way the former agent (US) thinks about this external account, which is held by the latter agent (THEY), is as “our account” or “nostro”.
Construing pool account and nostro account
instantiate POOL_ACCOUNT as CUSTODIAN_SEC_POOL_ACCOUNT where EGO => C:CUSTODIAN, EGO.POOLED_ACCOUNT => C:CUSTODIAN.CLIENT.SECURITIES_ACCOUNT, POOLED @ EGO.POOLED_ACCOUNT => C:CUSTODIED @ CUSTODIAN.CLIENT.SECURITIES_ACCOUNT, POOLED => C:CUSTODIED* from #1 fibre C : CUSTODY; instantiate POOL_ACCOUNT as BANK_CASH_POOL_ACCOUNT where EGO => B:BANK, EGO.POOLED_ACCOUNT => B:BANK.CLIENT.CASH_ACCOUNT, POOLED @ EGO.POOLED_ACCOUNT => B:HELD @ BANK.CLIENT.CASH_ACCOUNT, POOLED => B:HELD* from #1 fibre B : BANK;
instantiate NOSTRO_ACCOUNT as POOL_INTO_NOSTRO where US => P:EGO, THEY => D:CSD, ASSET @ US.LOCAL_ACCOUNT => P:POOLED @ EGO.POOL_ACCOUNT from #1 fibre D : CSD; #1 -> #2 fibre P : POOL_ACCOUNT;
The POOL_ACCOUNT frame can be instantiated to represent the pooling of STOCK within a CUSTODIAN, as well as the pooling of CASH within a BANK.
Note that, at this moment, there are two CUSTODY fibres within the TRADE substrate, as well as two BANK fibres.
To instantiate a POOL_ACCOUNT frame representing STOCK, a CUSTODY fibre can be used as its base, while to instantiate a POOL_ACCOUNT frame representing CASH, a BANK fibre plays this role.
After this instantiation statement is processed, there will be four additional POOL_ACCOUNT fibres in the TRADE substrate:
pooling of STOCK within the BUYER’s clearing bank (instantiating a securities pool account within the latter);
pooling of STOCK within the SELLER’s clearing bank (instantiating another securities pool account);
pooling of CASH within the BUYER’s clearing bank (instantiating a cash pool account within the latter);
pooling of CASH within the SELLER’s clearing bank (instantiating another cash pool account).
The next step is to connect these pool accounts to the next level in the indirect holding hierarchy, which is the nostro account at the CSD.
As mentioned above, this link is represented via the NOSTRO_ACCOUNT frame, and by instantiating this frame within the TRADE substrate, the link is actualized as well.
Note that whether this link connects a CASH or STOCK pool account as LOCAL_ACCOUNT does not matter, since the same structure is instantiated in each case.
Hence, there is only one instantiation statement here, which has two fibres in its baseline matching condition — the POOL_ACCOUNT and a CSD (representing the remote agent of the nostro account and the next level in the indirect holding hierarchy).
Once executed against the TRADE substrate, it produces four fibres, since it is individuated by the product of the CSD and POOL_ACCOUNT fibres, which is 1 × 4 = 4.
At this point, the lowest level in the indirect holding hierarchy for STOCK and CASH is still within a clearing bank, but it points toward an external party (a remote agent) — the CSD.
Instantiating and linking pool account and nostro account
Construing CSD and instantiating it within TRADE
schema CSD @ CSD {
CSD <~ STOCK;
STOCK is STOCK;
CASH is CASH;
}
We can now extend the scope of the TRADE construal by instantiating the CSD schema within the TRADE substrate.
At this stage, we only construe the aspects of the CSD required from the POV of the TRADE substrate. We are not attempting to model the CSD objectively from a detached point of view, we are only looking at it only from within the TRADE’s POV.
Every STOCK figure within the substrate now has a corresponding grounding figure under the CSD schema. The same applies to CASH.
Because the substrate contains only one type of STOCK figure, and because the CSD is individuated by that figure type, only a single CSD instance is created — one CSD fiber.
We can now construe the CSD itself as simultaneously acting as:
CUSTODIAN;
BANK;
for the two clearing banks participating in the trade.
This is achieved by instantiating additional CUSTODY and BANK schemas on top of the existing substrate, which we can do by instantiating CUSTODY frame where CSD plays the role of CUSTODIAN.
Here we are going to significantly simplify the EU stock-settlement process by assuming that the CSD itself orchestrates settlement, rather than involving yet more parties such as T2S.
A more realistic model — including T2S, delivery-versus-payment (DvP), receive-against-payment (RaP), and other settlement instructions — will be presented separately.
The purpose of this example is to demonstrate how DCM works, not to reproduce every operational detail of a real settlement infrastructure.
Notice how the indirect holding hierarchy for STOCK is unfolded layer by layer:
the surface level represented in the TRADE frame, where the STOCK is within the dominions of BUEYR or SELLER;
the custody level represented by CUSTODY schema, where the STOCK within the dominion of CUSTODIAN;
the terminal grounding level represented by the CSD schema, where the STOCK within the dominion of CSD represents the immobilisation of a security.
We start with the “mode of presentation” of STOCK - the STOCK being at the BUYER or SELLER - that exists at the surface level frame (TRADE).
The surface frame represents the primary activity motivating the entire substrate.
In Aristotelian terms, it acts as the final cause for everything else that happens within the substrate (hence the substrate gets it’s name after it's surface frame).
Then we go deeper by revealing layers where the figure we have construed (STOCK) actually comes from - going from a “mode of presentation” of something to that something, going from re-presentation of an entity to that entity.
From the perspective of enacting the TRADE contract — i.e. settlement — we can model the CSD minimally through a CSD schema.
The key idea is that the CSD acts as the terminal holder of securities and cash.
(In practice, this resembles the role played by DTC in the US market.)
Within the TRADE context, the CSD is individuated by the type of figure it grounds — here, STOCK.
instantiate CSD where STOCK <~ F, CASH <~ C from #1 figure F : STOCK ; #1 -> #2 figure C : CASH;
This time, however, we bind more coordinates explicitly.
In particular, we wire the realization side of the mirroring relation — the grounding figure — directly onto the STOCK figure already present at the CSD level.
This captures the core semantics of:
indirect holding;
immobilization of securities.
A single grounded security at the CSD level is mirrored upward across multiple layers of custody and bookkeeping systems.
No matter how many agents represent this STOCK as a figure within their own frames, there will always be a single STOCK figure at the CSD level that represents the actual figure and grounds all the others.
Conceptually, this resembles a single object casting multiple shadows or a single sound source generating multiple echoes: multiple representations grounded in one underlying reality.
Note that at this point, the TRADE substrate contains 4 CUSTODY fibres:
two where BUYER and SELLER act as clients;
two where the buyer’s and seller’s custodians act as clients;
instantiate CUSTODY as CSD_CUSTODY
where
CLIENT => N:US,
CUSTODIAN => N:THEY,
CUSTODIED @ CLIENT.CUSTODIAN.SECURITIES_ACCOUNT =>
N:ASSET @ US.THEY.NOSTRO_ACCOUNT,
CUSTODIED* => D:STOCK
from
#1 fibre D : CSD;
#1 -> #2 fibre N : NOSTRO_ACCOUNT where ASSET is STOCK;
The same logic can be applied to grounding the indirect holding of CASH.
Again, there are 4 NOSTRO_ACCOUNT fibres, out of which the fibre selector picks only two — the ones that deal with pooling of a figure having the construal of CASH.
These two NOSTRO_ACCOUNT fibres then individuate 2 new BANK fibres:
one representing the CSD as BANK of the buyer's clearing bank;
another representing the same CSD as BANK of the seller's clearing bank.
This completes an incremental elaboration of the indirect holding hierarchy for both CASH and STOCK, all the way from the virtual level where these are construed as being held (within the dominion of) the counterparties to a trade, down to the terminal level where the assets become immobilized.
Note that, at this point, there are 4 CUSTODY fibres and 4 BANK fibres within the TRADE substrate:
two representing the clearing banks of each counterparty as CUSTODIAN;
two representing the CSD as CUSTODIAN of the clearing banks.
instantiate BANK as CSD_BANK
where
CLIENT => N:US,
BANK => N:THEY,
HELD @ CLIENT.BANK.CASH_ACCOUNT =>
N:ASSET @ US.THEY.NOSTRO_ACCOUNT,
HELD* => D:CASH
from
#1 fibre D : CSD;
#1 -> #2 fibre N : NOSTRO_ACCOUNT where ASSET is CASH;
Note how the lowest level of the indirect holding hierarchy we have instantiated so far, represented by NOSTRO_ACCOUNT fibres, plays the role of a baseline to be matched within the instantiation statement. At this moment, there are 4 NOSTRO_ACCOUNT fibres present.
However, because the CUSTODY frame operates over STOCK (and not CASH), there is an additional where condition that selects only those NOSTRO_ACCOUNT fibres where the construal of the ASSET figure matches that of STOCK.
Out of the 4 NOSTRO_ACCOUNT fibres, only two match this condition. Thus, execution of this instantiation statement produces 2 CUSTODY fibres:
one representing the CSD as CUSTODIAN of the buyer's clearing bank;
another representing the same CSD as CUSTODIAN of the seller's clearing bank.
Adding elements into info plane to bridge gaps in the actual plane
At this point, we have introduced all the essential parties (as agents) involved in a simplified TRADE settlement scenario.
However, the substrate we have built so far is not "executable" because it is incomplete in its specifications — it has many dynamical elements which cannot be enacted directly, specifying what to do but not how to do it.
Each mirroring relation involves two agents:
a superordinate agent (BUYER or SELLER) acting on its local representation of a figure;
a subordinate agent (CUSTODIAN or BANK) responsible for mirroring that action on the underlying realization figure.
All changes within the TRADE frame ultimately reduce to two primitive operations:
release;
capture.
For mirrored figures, once one side of the relation is fixed, the corresponding change on the other side can be inferred automatically. For example:
releasing a figure from CLIENT.CUSTODIAN.SECURITIES_ACCOUNT
implies
releasing the corresponding figure from CUSTODIAN.CLIENT.SECURITIES_ACCOUNT.
However, this mirrored change occurs under a different agent. We are therefore dealing with a causal link involving two agents: one agent, in order to execute its local action, is causing or triggering the action local to another (remote) agent.
This link between two changes — the force-dynamic edge — is not directly enactable, because only local actions (actions falling under a single agent) are directly enactable.
For these non-local causal interactions between two agents to be enactable, we need to deploy some kind of interaction framework that involves communication between agents. At minimum, this framework must support:
imperative semantics — one agent requesting another to act;
indicative semantics — one agent reporting the result of an action.
At this point we need to introduce another important concept of DCM: planes.
So far we have been construing only business-level elements, and these fall under the so-called actual plane — a plane that represents the target domain directly. Elements within this plane represent objects of the business domain — e.g. CASH, BUYER, or CUSTODIAN.
Now we need to frame a domain of interaction between several agents, where the interaction itself could be about any subject matter, including things happening within the TRADE frame. This communication domain can also be framed in the same way we frame the business domain.
Here we will need to introduce another plane where we can construe content — the info (informational) plane. Elements in this plane are about other elements, not about the business domain.
In other words, the info plane is a meta-plane or second-order plane with respect to the actual plane, which is a first-order plane:
Info plane → Actual plane → Target domain
Note that whether something is in the info plane is relative, as will be shown later, so we will need yet another term to cover a plane where all DCM constructions themselves fall into — the content plane.
Thus, the actual plane and info plane both fall under the content plane in the sense that the former two are expressed via DCM constructions, while the target domain can only be expressed via the actual plane:
Content plane = Info plane + Actual plane
This distinction between planes was originally introduced by Langacker and was made between an actual plane (representing reality) and a virtual plane (representing conceptualizations of reality or a POV).
Now, a figure can represent an element of the target domain like CASH or STOCK. This figure belongs to the actual plane.
But a figure can also represent a message that is being sent from one agent to another, which itself can be a command to execute some action (such as delivering securities). This message is still a figure — it can be released by one agent and captured by another, as will be shown below — and thus belongs to the content plane.
However, the content of such a figure, instead of referring to an element of the target domain (e.g. CASH), refers to some other element of the content plane (e.g. a start of release of a CASH figure, which is itself an edge in the force dynamics of the TRADE frame). This is what makes such a figure fall under the info plane — its reference to another element of the content plane instead of the target domain.
The info figure has a double presence in DCM: it is itself a figure and thus present in the content plane (meaning it can be released and captured as a message), and at the same time it also has content that refers to (or points to) another element of the content plane (which can be an element of the actual plane, such as release of CASH or capture of STOCK).
Note that splitting all content into planes also implies splitting the dynamics, since there will be causal links between the two planes.
The causal links in the force-dynamics graph shown in this diagram will reappear using the same colors in the final section of this example, where the action plans for each agent (party involved in the settlement) are presented.
Construing communication - adding dynamics to info plane
frame COM @ SENDER, RECEIVER {
COMMUNICATED is MESSAGE;
perspective SENDING @ SENDER where SENT => COMMUNICATED {
release SENT;
}
perspective RECEIVING @ RECEIVER where RECEIVED => COMMUNICATED {
capture RECEIVED;
}
dynamics {
SENDING :OUT @ SENDER-> RECEIVING :IN @ RECEIVER ;
}
}
However, the COM frame alone is not enough to solve the problem of enacting a remote change (where a change of one agent can only be enacted indirectly through enacting the change at another agent), such as the mirror change.
Because agents can act only locally, any interaction between two agents requires something above these local forces — we need to reach through the gap from one locality into another.
The BUYER has to be able to command its CUSTODIAN to release STOCK and to command its BANK to receive CASH. In each case, the superordinate agent has to cause or force the subordinate agent to execute the change local to the latter — to release STOCK from CLIENT.SECURITIES_ACCOUNT and to capture CASH into CLIENT.CASH_ACCOUNT.
A change is durational not only in the literal sense — for example, crediting cash takes time — but also in a deeper conceptual sense. Every change has an internal structure consisting of:
a causal force initiating the change;
the completed change itself becoming a new causal force capable of triggering further changes.
Any change thus comes with an aspect — the shape of its dynamics — which can be independent from its content because it is subject to construal. This is similar to the distinction between grammar and lexicon in language, or more generally between the closed class (aspectual types) and the open class (all possible changes construed as having certain aspectual types).
An aspect of any change can be elaborated into a more detailed one, just as any other element of a frame can be elaborated into a more specific version of it (the most obvious being sub-typing — like elaborating a figure of type "STOCK" into a concrete stock identified by a specific ISIN).
frame REQUEST_REPLY @ REQUESTER, REPLIER {
REQUEST is MESSAGE;
transient REPLY is MESSAGE;
components { COM as COM_REQUEST; COM as COM_REPLY }
perspective REQUESTING @ REQUESTER {
component COM_REQUEST/SENDING where SENT => REQUEST;
component COM_REPLY/RECEIVING where RECEIVED => REPLY;
}
perspective REPLYING @ REPLIER {
REPLY_IN : create REPLY;
component COM_REQUEST/RECEIVING where RECEIVED => REQUEST;
component COM_REPLY/SENDING where SENT => REPLY;
dynamics COM_REQUEST:OUT -> :REPLY_IN;
dynamics :REPLY_IN -> COM_REPLY:IN
}
}
We start with the simplest frame in the communication domain — the COM frame — which construes one agent communicating with another.
Sending a message is represented as the release of an info figure, while receiving a message is represented as its capture.
Each of these changes belongs to the corresponding agent’s perspective. In addition, the frame defines an interaction between the two agents in its global (non-perspectival) dynamics:
the receiving of the message is caused by the sending of the message.
Because the figure being acted upon is an info figure, this interaction takes place entirely within the info plane.
The reason we diverged into the communication domain and info plane was to bridge the gap we had between a superordinate agent (BUYER) that needs to execute a remote change (e.g. STOCK release from Vostro account) and a subordinate agent (CUSTODIAN) to whom that change is local (and thus executable).
Furthermore, an aspect can be construed as actual (directly enactable) or as virtual (not directly enactable, requiring its actual part to be performed through mirroring).
For example:
the TRADE frame may construe the release of CASH by the BUYER as an actual change;
the CUSTODY frame may construe that same change as virtual — where a CASH at the BUYER is a model figure grounded in another CASH figure residing under the CUSTODIAN agent.
This is just a reflection of the general fact that whether something is an abstraction of something else depends on the POV, as abstraction is a relation between two forms and not an absolute, intrinsic property of a form.
The same principle applies to many other distinctions in DCM, including:
info plane vs. actual plane;
type (baseline) vs. subtype (elaboration);
model vs. realization.
Thus we need a way to implement remote change that includes this more sophisticated dynamical aspect — not just a single communication between two agents, but two: requesting and replying. This is exactly what the REQUEST_REPLY frame is for.
The REQUEST_REPLY frame is composed of two COM frame instances (two COM fibres), wired together in sequence:
a request to execute a change is sent by an agent to whom the change is remote;
the requested agent receives the request and enacts the change locally;
a reply is sent back informing the requesting agent that the change has been executed.
The REPLYING perspective adds an additional dynamic constraint beyond the interactions defined within the individual COM fibres:
the creation of the REPLY info figure can begin only after the REPLIER has completed the actions associated with the COM_REQUEST component.
In this way, REQUEST_REPLY allows us to implement not just communication, but remote enactment — allowing one agent to trigger and observe the completion of actions performed by another.
Instantiating communication frames within TRADE
We can now bridge the inter-agent gaps in the TRADE substrate by adding a communicational tissue composed of REQUEST_REPLY fibres.
The goal is to span the gaps between agents involved in each CUSTODY and BANK fibre, as well as across figures of STOCK and CASH.
At this stage, the substrate contains:
4 CUSTODY fibres;
4 BANK fibres;
which together give rise to 8 additional REQUEST_REPLY fibres.
The instantiation of the REQUEST_REPLY frame takes as its baseline those elements of the substrate that match the following pattern:
a figure of type financial figure (with STOCK and CASH as subtypes);
a change involving that figure that is mirrored between agent A and agent B.
Whenever this pattern is detected, a new REQUEST_REPLY fibre is wired into the substrate.
In this wiring:
the superordinate agent becomes the REQUESTOR;
the subordinate agent (where the mirrored change originates) becomes the REPLIER.
At this point, there is no direct communication between the BUYER and the SELLER.
What we have now in the substrate is communication between each party and its respective CUSTODIAN or BANK, as well as between those intermediaries and the CSD.
However, we might want a party to notify its counterparty whenever there is STOCK or CASH coming its way (being released). We can add a causal dependency between the start of releasing CASH by the BUYER and the capture of CASH by the SELLER.
The SELLER may need to know when to instruct its BANK to anticipate an incoming cash credit on a future date — a form of pre-advice.
To enable this, we introduce a causal dependency between:
the start of CASH release by the BUYER;
the start of CASH capture by the SELLER.
This is an interaction between two different agents, represented by an edge in a force-dynamics graph, which is not directly enactable by either agent alone.
Two info figures are also introduced:
the REQUEST info figure, carrying an imperative meaning: “execute this change”;
the REPLY info figure, carrying an indicative meaning: “this change has been executed”.
In effect:
the REQUEST triggers the execution of a remote change;
the REPLY confirms its completion.
Thus, each inter-agent gap matching the pattern is covered by a corresponding REQUEST_REPLY fibre.
In this example, this results in 8 REQUEST_REPLY fibres being added to the TRADE substrate.
Importantly, this mechanism is highly generic. It applies not only within TRADE, but across frames such as CUSTODY and BANK, and across all types of changes (release, capture) and financial figures (CASH, STOCK are subtypes of the FIN_FIGURE).
This makes the REQUEST_REPLY frame applicable across different types of contracts — including OPTION and FUTURE — wherever the same kind of inter-agent causal gap needs to be bridged.
The diagram above shows how the subgraph of the TRADE substrate (representing activity in the actual plane) plays the role of the model which is given an implementation — another graph, which is a force-dynamics graph of the REQUEST_REPLY frame.
Note how the latter is wired onto the former so as to make the former commute.
The upper square represents a capture of the substrate (made by the pattern specified in the instantiation statement), which consists of two changes linked via a mirroring relation.
The remote change on the left causes the local change on the right, but since both belong to different agents, these edges are not directly executable in the actual plane — therefore they are marked with dashed lines.
The lower square represents the structure coming from the REQUEST_REPLY frame that can make those edges executable by providing an implementation for each of these edges (a graph connecting the same nodes) which is itself executable (enactable).
The edges in orange wire the REQUEST_REPLY dynamics so as to provide an implementation for the first inter-agent force-dynamical edge (the start of the remote change should trigger/cause the start of the local change).
The edges in turquoise do the same for the other virtual edge: they provide an alternative route connecting completion of the local change to completion of the remote change.
A simple analogy is a water-piping system: if a direct pipe from A to B is shut, the water can take a detour passing through other branches — from A to C, from C to D, and from D to B.
instantiate REQUEST_REPLY
where
REQUESTER => A,
REPLIER => B,
REQUEST => imperative of C/S:IN,
REPLY => indicative of C/S:OUT,
from
#1 figure F : FIN_FIGURE ;
#1 -> #2 schange C : F @ agent A. location X
~>
G @ agent B.location Y;
To enact such a remote (from the POV of each involved agent) edge, we can instantiate a COM fibre.
The pattern to match for instantiation to occur requires:
a financial figure;
released by agent A;
and captured by agent B;
where the capture is causally triggered by the start of the release.
In other words, the start of release at one agent causes the start of capture at another, establishing a coupling across two peer agents.
More specifically, the start of capture of figure F by agent B is caused by the start of its release by agent A.
instantiate COM as PREADVICE where SENDER => A, RECEIVER => B, COMMUNICATED => indicative of R:IN from #1 figure F : FIN_FIGURE ; #1 -> #2 dynamics : R release F @ agent A :IN -> C capture F @ agent B :IN
Construing a movement trajectory
frame LOCAL_MOVEMENT_LINKED {
MOVED is figure;
FROM is place;
TO is place;
perspective {
release MOVED @ FROM;
capture MOVED @ TO;
dynamics release:IN -> capture:IN;
dynamics capture:IN -> release:OUT;
}
}
frame DVP {
STOCK is STOCK;
CASH is CASH;
FROM_SEC_ACCOUNT is place;
TO_SEC_ACCOUNT is place;
FROM_CASH_ACCOUNT is place;
TO_CASH_ACCOUNT is place;
components {
LOCAL_MOVEMENT_LINKED as STOCK_MOVEMENT where
.FROM => .FROM_SEC_ACCOUNT,
.TO => .TO_SEC_ACCOUNT,
MOVED => STOCK;
LOCAL_MOVEMENT_LINKED as CASH_MOVEMENT where
.FROM =>
.FROM_CASH_ACCOUNT,
.TO => .TO_CASH_ACCOUNT,
MOVED => CASH;
}
dynamics {
CASH_MOVEMENT.release:IN -> STOCK_MOVEMENT.release:IN ;
CASH_MOVEMENT.capture:OUT -> STOCK_MOVEMENT.capture:OUT ;
STOCK_MOVEMENT.release:IN -> CASH_MOVEMENT.release:OUT ;
}
}
At this stage, we have construed the prime changes — release and capture — for both CASH and STOCK throughout the entire indirect holding hierarchy, from the surface level of the TRADE frame down to the terminal level of the CSD, where the figures originate (where they become actual).
Release and capture are irreducible primitives, but they do not constitute a complete trajectory of movement in themselves.
Each of these changes represents just a part of a trajectory — a figure released at one place has to be captured at another.
For the actual STOCK figure at the CSD level, these partial changes must combine into a continuous trajectory, analogous to the movement of a physical object through space.
To achieve this, the dynamics of release and capture must be coupled together.
This coupling can be construed as a frame describing movement local to an agent — a movement of a figure from one place to another place under the same agent (and thus construed from a single perspective).
Operationally, this requires adding causal links between the two changes:
the start of release causes the start of capture;
the completion of capture is required for the completion of release.
This produces a complete movement trajectory rather than two disconnected partial changes.
There is one additional concept of the target domain required to implement the settlement semantics: Delivery versus Payment (DvP).
Again, this example intentionally simplifies real-world settlement, where the DvP would be orchestrated by T2S.
Not only must the CASH and STOCK figures each form complete trajectories, but those trajectories must also be interlocked. In other words, we need to couple the dynamics of movement of STOCK with the dynamics of movement of CASH.
Within the CSD context:
(internally to the CSD agent) the start of CASH release is required for starting STOCK release: STOCK delivery starts only after CASH delivery has started;
(internally to the CSD agent) completion of CASH capture is required for completion of STOCK capture: STOCK receipt can complete (is committed) only after CASH receipt has been completed.
Semantically, this ensures that securities and cash move together as a whole — the two movement events are linked into a single complex event.
This behavior is modeled through the composite DVP frame.
Note that this frame involves only one agent, which makes it an ego-frame (in contrast to an interactional frame), and thus it comes with a default perspective.
The DVP frame contains two LOCAL_MOVEMENT components:
one for CASH;
one for STOCK.
Each component independently construes a local movement trajectory. The composite DVP frame then adds additional dynamical couplings between those component trajectories, interlocking them into a single complex change.
This is another example of a key framing principle: the composite construction is more than the sum of its components because it introduces new causal structure linking the otherwise independent dynamics of each component fibre together.
Linking trajectories together to implement DVP
instantiate DVP as CSD_DVP
where
EGO => D:CSD,
STOCK => D:STOCK,
CASH => D:CASH,
EGO.FROM_SEC_ACCOUNT => X,
EGO.TO_SEC_ACCOUNT => Y,
EGO.FROM_CASH_ACCOUNT => Z,
EGO.TO_CASH_ACCOUNT => I,
STOCK_MOVEMENT.release -> SR,
STOCK_MOVEMENT.capture -> SC,
CASH_MOVEMENT.release -> CR,
CASH_MOVEMENT.capture -> CC
from
#1 fibre D : CSD;
#1 -> #2 change SR : release D:STOCK @ agent D:CSD.location X;
#2 -> #3 change SC : capture D:STOCK @ agent D:CSD.location Y;
#3 -> #4 change CR : release D:CASH @ agent D:CSD.location Z;
#4 -> #5 change CC : capture D:CASH @ agent D:CSD.location I;
Now that we have a frame capturing the DvP semantics, the remaining step is to apply it to the TRADE substrate by instantiating the DVP frame within that substrate.
We begin by capturing the CSD fibre, which provides access to all elements required to wire the DVP dynamics into the TRADE substrate we have built so far.
Specifically, we capture four changes occurring under the CSD agent:
release of STOCK;
capture of STOCK;
release of CASH;
capture of CASH.
We then overlay the dynamical couplings defined by the DVP frame onto these captured changes, turning four disconnected (decoupled) changes — two releases and two captures — of two figures into a single interconnected whole, thus implementing (overlaying) the DvP semantics over the TRADE substrate.
Importantly, the instantiation specification itself contains no direct reference to the TRADE frame.
As a result, the same DVP construction can be reused across different contracts and substrates wherever equivalent settlement semantics are required.
Note that the bindings here involve not only static content — such as agents, figures, and locations — but also dynamic content.
Nodes within the force-dynamics graph of the instantiated DVP frame are wired onto already existing nodes in the force-dynamics graph of the TRADE substrate via the CSD fibre acting as a baseline (which gets elaborated by the DVP frame).
Instantiating DVP by adding couplings onto already existing dynamics
At this point, we have elaborated the initial construal of TRADE (substrate) by adding sufficient context (extending the field of view to cover CUSTODY, etc) to be able to orchestrate a settlement — to execute the TRADE contract.
In other words, the TRADE substrate now contains sufficient detail to be enacted.
Because the substrate involves multiple agents, its enactment is inherently distributed: each agent must enact its own part of the overall framing. This means that every agent can infer its own action plan from the shared contracts — from the TRADE substrate.
Such a plan allows an agent to know:
which actions it must execute;
when those actions should occur;
how it should interact with other agents;
what behavior it should expect from them and when.
Having such a plan is essentially having a model of the future (self and others), which turns each agent into anticipatory rather than just reactive (which is what most traditional systems do).
The DCM compiler automatically derives these action plans from the substrate by adopting a POV of each agent (present in the TRADE substrate).
Only minimal instance-specific information is then required to begin execution for each agent, since the operational behavior is inferred automatically from the definition of the contract — from the substrate structure itself.
Importantly, in DCM the definition of a contract is inseparable from its execution. Once a contract is represented semantically, making the representation deep, the software already contains the structure required to enact it.
No additional procedural layer is needed to “animate” the model externally (because then it ceases to be a model of the target process in the first place).
This contrasts with traditional software development approaches, where representations are often largely syntactic and semantically shallow, requiring extensive procedural code to re-animate (operationalize) the concepts they are supposed to represent.
This difference relates to the dispositional semantics of conventional programming languages, discussed separately in another piece.
More broadly, the notion of multiple agents coordinating behavior through shared contractual structure connects DCM to broader research areas it is built upon, including shared agency, intersubjectivity and joint intentionality.
Note how the “data model” is omnipresent in traditional IT, but the “process model” is not.
This has to do with the fact that traditional software development does not model the target domain (which it is supposed to automate) but instead tries to model static artefacts that are by-products of the target business processes (the dynamics of the target domain).
Database and message schemas are a prime example of this. These are disconnected snapshots of some target domain dynamics that are, in formal terms, out of scope for capture.
Focusing on still snapshots rather than the movie is much easier at the start, but it does not scale with the complexity of the movie.
This is encouraged by the dispositional semantics of traditional programming languages, as examined in another piece.
Enacting TRADE settlment : generating action plans for each agent
0 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_SOD Triggering RELEASE of CASH:IN
1 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_SOD Triggering CAPTURE of PRODUCT:IN
2 : Start executing change : RELEASE of CASH
3 : Causal (#6) : RELEASE of CASH:IN -> RELEASE of CASH @ BUYER.BANK/CUSTODIAN.CASH_ACCOUNT:IN // implementing : RELEASE of CASH by BUYER
4 : Start executing change : RELEASE of CASH @ BUYER.BANK/CUSTODIAN.CASH_ACCOUNT // implementing : RELEASE of CASH by BUYER
5 : Causal (#22) : RELEASE of CASH @ BUYER.BANK/CUSTODIAN.CASH_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:IN // implementing : RELEASE of CASH by BUYER
6 : Start executing change : RELEASE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
7 : Finish executing change : RELEASE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >
8 : Causal (#29) : RELEASE of CASH:IN -> RELEASE of COMMUNICATED < EXECUTED RELEASE of CASH >:IN // implementing : Causal (#1) : RELEASE of CASH:IN by BUYER -> CAPTURE of CASH:IN by SELLER
9 : Trigger from SELLER coming into CAPTURE of COMMUNICATED < EXECUTED RELEASE of PRODUCT >:IN
10 : Start executing change : CAPTURE of COMMUNICATED < EXECUTED RELEASE of PRODUCT > // implementing : Causal (#1) : RELEASE of PRODUCT:IN by SELLER -> CAPTURE of PRODUCT:IN by BUYER
11 : Start executing change : RELEASE of COMMUNICATED < EXECUTED RELEASE of CASH > // implementing : Causal (#1) : RELEASE of CASH:IN by BUYER -> CAPTURE of CASH:IN by SELLER
12 : Finish executing change : RELEASE of COMMUNICATED < EXECUTED RELEASE of CASH >
13 : Trigger from BUYER's CUSTODIAN/BANK coming into CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:IN
14 : Start executing change : CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
15 : Finish executing change : CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >
16 : Causal (#22) : CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:OUT -> RELEASE of CASH @ BUYER.BANK/CUSTODIAN.CASH_ACCOUNT:OUT // implementing : RELEASE of CASH by BUYER
17 : Finish executing change : RELEASE of CASH @ BUYER.BANK/CUSTODIAN.CASH_ACCOUNT
18 : Causal (#6) : RELEASE of CASH @ BUYER.BANK/CUSTODIAN.CASH_ACCOUNT:OUT -> RELEASE of CASH:OUT // implementing : RELEASE of CASH by BUYER
19 : Finish executing change : CAPTURE of COMMUNICATED < EXECUTED RELEASE of PRODUCT >
20 : Causal (#30) : CAPTURE of COMMUNICATED < EXECUTED RELEASE of PRODUCT >:OUT -> CAPTURE of PRODUCT:IN // implementing : Causal (#1) : RELEASE of PRODUCT:IN by SELLER -> CAPTURE of PRODUCT:IN by BUYER
21 : Start executing change : CAPTURE of PRODUCT
22 : Causal (#5) : CAPTURE of PRODUCT:IN -> CAPTURE of PRODUCT @ BUYER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:IN // implementing : CAPTURE of PRODUCT by BUYER
23 : Start executing change : CAPTURE of PRODUCT @ BUYER.BANK/CUSTODIAN.SECURITIES_ACCOUNT // implementing : CAPTURE of PRODUCT by BUYER
24 : Causal (#23) : CAPTURE of PRODUCT @ BUYER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:IN // implementing : CAPTURE of PRODUCT by BUYER
25 : Start executing change : RELEASE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
26 : Finish executing change : RELEASE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >
27 : Trigger from BUYER's CUSTODIAN/BANK coming into CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:IN
28 : Start executing change : CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
29 : Finish executing change : CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >
30 : Causal (#23) : CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:OUT -> CAPTURE of PRODUCT @ BUYER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:OUT // implementing : CAPTURE of PRODUCT by BUYER
31 : Finish executing change : CAPTURE of PRODUCT @ BUYER.BANK/CUSTODIAN.SECURITIES_ACCOUNT
32 : Causal (#5) : CAPTURE of PRODUCT @ BUYER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:OUT -> CAPTURE of PRODUCT:OUT // implementing : CAPTURE of PRODUCT by BUYER
33 : Finish executing change : CAPTURE of PRODUCT
34 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_EOD Constraining CAPTURE of PRODUCT:OUT
35 : Causal (#31) : CAPTURE of PRODUCT:OUT -> RELEASE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT >:IN // implementing : Causal (#1) : CAPTURE of PRODUCT:OUT by BUYER -> RELEASE of PRODUCT:OUT by SELLER
36 : Start executing change : RELEASE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT > // implementing : Causal (#1) : CAPTURE of PRODUCT:OUT by BUYER -> RELEASE of PRODUCT:OUT by SELLER
37 : Trigger from SELLER coming into CAPTURE of COMMUNICATED < EXECUTED CAPTURE of CASH >:IN
38 : Start executing change : CAPTURE of COMMUNICATED < EXECUTED CAPTURE of CASH > // implementing : Causal (#1) : CAPTURE of CASH:OUT by SELLER -> RELEASE of CASH:OUT by BUYER
39 : Finish executing change : CAPTURE of COMMUNICATED < EXECUTED CAPTURE of CASH >
40 : Causal (#32) : CAPTURE of COMMUNICATED < EXECUTED CAPTURE of CASH >:OUT -> RELEASE of CASH:OUT // implementing : Causal (#1) : CAPTURE of CASH:OUT by SELLER -> RELEASE of CASH:OUT by BUYER
41 :Finish executing change : RELEASE of CASH
42 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_EOD Constraining RELEASE of CASH:OUT
43 : Finish executing change : RELEASE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT > having remote effects to 1 agents
44 : Effect to SELLER coming from CAPTURE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT >:IN
Note that in this example we have another simplification resulting from limiting the scope or number of contracts (frames) we need to introduce.
In this example, the BUYER or SELLER has to explicitly request (instruct) its CUSTODIAN/BANK to release/capture its PRODUCT/CASH.
However, in reality this is redundant due to the existence of another contract between the BUYER/SELLER and its CUSTODIAN/BANK, turning the latter into a clearing bank.
Part of the clearing agreement between the clearing bank and its client (e.g. a broker) already pre-authorizes the former to act on the cash and securities of the latter. This would be part of the CLEARING_BANK contract, the formalization of which is out of scope for the current example.
Having this authorization in place means that the causal chain from the BUYER to its clearing bank (playing the roles of CUSTODIAN and BANK in the TRADE substrate) is pre-enacted for all potential TRADE contracts.
Thus, for any given trade, the clearing bank does not need to be triggered by its client to release/capture its PRODUCT/CASH.
Instead, it will be triggered by the existence of the contract and the settlement date listed in the contract.
This means that the force dynamics we have built into the TRADE substrate still hold in the presence of the clearing bank contract.
What changes is the elaboration of that dynamics in the info plane: instead of having additional REQUEST_REPLY fibres, the very same mirrored changes (vostro-to-nostro links) are enacted directly, thus leaving the clearing bank in sole control of initiating these changes.
Conceptually, there is still a causal link between the BUYER delivering the CASH and its clearing bank doing the same with the CASH under the BUYER's vostro CASH_ACCOUNT. It is just that this link becomes pre-activated in the presence of the CLEARING_BANK contract.
The action plan of the BUYER agent within the TRADE substrate is printed below as a serialized sequence of steps. An actual representation of this action plan within DCM is a force-dynamics graph.
There are two triggers that initiate the actions of the BUYER to start playing out its role in the TRADE contract. Both are temporal and highlighted in light blue: there is a temporal point, the actualization of which triggers a causal chain within the BUYER.
Note that there is a temporal dimension to the TRADE frame which comes with its own order, though this is not represented in the action plan (as it is not something enacted by each agent).
Additionally, there are triggers, highlighted in orange, that come from other agents : where the BUYER interacts with the other agents of the TRADE substrate.
The trigger in line 9 is the capture of an info figure (COMMUNICATED) which refers, in the indicative mood, to the node in the force-dynamics graph of the TRADE substrate representing the completion of a release of PRODUCT by the SELLER.
In simpler words, the trigger is the SELLER telling the BUYER that it has started the delivery of PRODUCT.
The following trigger in line 13 is the BUYER's clearing bank telling the BUYER that its CASH (from the vostro cash account) has been debited.
The next trigger in line 27 is the same clearing bank telling the BUYER that its PRODUCT (from the vostro securities account) has been received.
The last trigger in line 37 is the SELLER confirming to the BUYER that it has received the CASH.
The actual changes — the changes in the actual plane — such as the release of CASH or capture of PRODUCT, are highlighted in green.
Note that the same change can be construed at different levels of abstraction. For example, in line 2 the BUYER agent is starting the action of releasing CASH, while in line 4 the BUYER is starting a more concrete version of this action — the release of CASH held in its nostro account.
The step in line 3, highlighted in dark blue and representing a causal link rather than an action, is an elaboration or refinement of a conceptual structure.
The TRADE frame construes CASH as something held directly under the BUYER, abstracting away any accounting structure that might be employed, thus representing the fact that the CASH is within the dominion of the BUYER agent without saying anything about the structure of this dominion.
However, when the TRADE frame was elaborated by the CUSTODY schemas, this link between the BUYER and its CASH — the dominion itself — was elaborated by providing a more detailed version of it. This elaboration is a topology-preserving transformation of one structure into another.
Because it is an elaboration, anything that the baseline structure (the one coming from the TRADE frame) says is still correct in the elaborated structure. However, the latter adds more detail to the former.
This is exactly what the causal edge in line 3 represents: releasing CASH from the BUYER is implemented as (or has a more concrete version in) the release of CASH from a place under the BUYER, which is under the gateway subspace "BANK/CUSTODIAN" representing another agent, within a place playing the role of CASH_ACCOUNT.
In other words, this causal link is a specific example of the relation between an intention (the what, the model) and its realization (the how).
There are many other ways this very generic relation is rendered explicitly within DCM.
Another example is the relation between a remote change (usually an edge in the force-dynamics graph) and its implementation (a subgraph of that force-dynamics graph) — like the one between a STOCK release by the SELLER starting a causal chain to its CUSTODIAN and back.
Another example is the relation between any action node within the action graph of any agent and the change frames at the surface level (included in the text following '//' as in line 14). These are especially useful when this link is indirect, involving layers of implementation or mediation detail, as we shall illustrate in the CSD action plan.
The step in line 18 represents a similar causal link, but this time going from implementation to intention — the completion of debiting CASH from the nostro account at the BUYER's clearing bank causally completes the (higher-level or more abstract) activity of the BUYER sending its CASH.
Steps highlighted in purple represent causal links (rather than actions) that connect actions across planes — from the info plane to the actual plane, or the other way around.
For example, in line 5, the start (denoted by the :IN point of the change's aspectual contour) of the CASH release enacted by the BUYER from its nostro account (an actual-plane activity) causes the start of release of an info figure (an info-plane activity) towards the BUYER's clearing bank. This info figure refers, in the imperative mood, to the node in the TRADE substrate force-dynamics graph representing a release of CASH from the BUYER's vostro account at the clearing bank.
In simpler words, the BUYER is telling its BANK to debit its CASH.
Note the mirroring relation between the cash-account place under the BUYER and the corresponding cash-account place under its BANK.
The first corresponds to a nostro account, while the second corresponds to the vostro account, thus illustrating how apparently domain-specific concepts arise naturally from a very general construal structure (a relation between two agents).
Note how the request made by the BUYER flips from the nostro side to the vostro side within this causal link.
The causal step in line 16 represents the second part of the CASH release realization.
Here, the capture of an info figure stating that the BUYER's clearing bank has completed debiting its vostro cash account causes the BUYER to conclude that its nostro account has been debited.
This is the causal link going from an activity in the info plane to one in the actual plane.
Actions of the BUYER agent
0 : Trigger from BUYER coming into CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:IN
1 : Start executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
2 : Trigger from BUYER coming into CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:IN
3 : Start executing change : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
4 : Finish executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >
5 : Causal (#47) : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:OUT -> CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT:IN // implementing : CAPTURE of PRODUCT by BUYER
6 : Start executing change : CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT // implementing : CAPTURE of PRODUCT by BUYER
7 : Causal (#9) : CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT:IN -> CAPTURE of PRODUCT as POOLED* @ POOL_ACCOUNT:IN // implementing : CAPTURE of PRODUCT by BUYER
8 : Start executing change : CAPTURE of PRODUCT as POOLED* @ POOL_ACCOUNT // implementing : CAPTURE of PRODUCT by BUYER
9 : Causal (#38) : CAPTURE of PRODUCT as POOLED* @ POOL_ACCOUNT:IN -> CAPTURE of PRODUCT as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:IN // implementing : CAPTURE of PRODUCT by BUYER
10 : Start executing change : CAPTURE of PRODUCT as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT // implementing : CAPTURE of PRODUCT by BUYER
11 : Finish executing change : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >
12 : Causal (#45) : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:INSTANT
13 : Causal (#49) : CAPTURE of PRODUCT as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN // implementing : CAPTURE of PRODUCT by BUYER
14 : Start executing change : RELEASE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
15 : Finish executing change : RELEASE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
16 : Causal (#45) : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:OUT -> RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT:IN // implementing : RELEASE of CASH by BUYER
17 : Start executing change : RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT // implementing : RELEASE of CASH by BUYER
18 : Causal (#10) : RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT:IN -> RELEASE of CASH as POOLED* @ POOL_ACCOUNT:IN // implementing : RELEASE of CASH by BUYER
19 : Start executing change : RELEASE of CASH as POOLED* @ POOL_ACCOUNT // implementing : RELEASE of CASH by BUYER
20 : Causal (#37) : RELEASE of CASH as POOLED* @ POOL_ACCOUNT:IN -> RELEASE of CASH as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:IN // implementing : RELEASE of CASH by BUYER
21 : Start executing change : RELEASE of CASH as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT // implementing : RELEASE of CASH by BUYER
22 : Causal (#47) : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:INSTANT
23 : Causal (#50) : RELEASE of CASH as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN // implementing : RELEASE of CASH by BUYER
24 : Start executing change : RELEASE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
25 : Finish executing change : RELEASE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >
26 : Trigger from CSD coming into CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN
27 : Start executing change : CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
28 : Trigger from CSD coming into CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN
29 : Start executing change : CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
30 : Finish executing change : CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >
31 : Causal (#50) : CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:OUT -> RELEASE of CASH as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:OUT // implementing : RELEASE of CASH by BUYER
32 : Finish executing change : RELEASE of CASH as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT
33 : Causal (#37) : RELEASE of CASH as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:OUT -> RELEASE of CASH as POOLED* @ POOL_ACCOUNT:OUT // implementing : RELEASE of CASH by BUYER
34 : Finish executing change : RELEASE of CASH as POOLED* @ POOL_ACCOUNT
35 : Causal (#10) : RELEASE of CASH as POOLED* @ POOL_ACCOUNT:OUT -> RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT:OUT // implementing : RELEASE of CASH by BUYER
36 : Finish executing change : CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
37 : Causal (#49) : CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:OUT -> CAPTURE of PRODUCT as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:OUT // implementing : CAPTURE of PRODUCT by BUYER
38 : Finish executing change : CAPTURE of PRODUCT as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT
39 : Causal (#38) : CAPTURE of PRODUCT as ASSET* @ BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT:OUT -> CAPTURE of PRODUCT as POOLED* @ POOL_ACCOUNT:OUT // implementing : CAPTURE of PRODUCT by BUYER
40 : Finish executing change : CAPTURE of PRODUCT as POOLED* @ POOL_ACCOUNT
41 : Causal (#9) : CAPTURE of PRODUCT as POOLED* @ POOL_ACCOUNT:OUT -> CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT:OUT // implementing : CAPTURE of PRODUCT by BUYER
42 : Finish executing change : RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT
43 : Causal (#45) : RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT:OUT -> CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:INSTANT // implementing : RELEASE of CASH by BUYER
44 : Finish executing change : CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT
45 : Causal (#47) : CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT:OUT -> CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:INSTANT // implementing : CAPTURE of PRODUCT by BUYER
46 : Executing instantaneous change (#45) : CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >
47 : Causal (#45) : CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:IN // implementing : RELEASE of CASH by BUYER
48 : Executing instantaneous change (#47) : CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >
49 : Causal (#47) : CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:IN // implementing : CAPTURE of PRODUCT by BUYER
50 : Start executing change : RELEASE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
51 : Start executing change : RELEASE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
52 : Finish executing change : RELEASE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT > having remote effects to 1 agents
53 : Effect to BUYER coming from CAPTURE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT >:IN
54 : Finish executing change : RELEASE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT > having remote effects to 1 agents
55 : Effect to BUYER coming from CAPTURE of REPLY < EXECUTED RELEASE of CASH as HELD* @ BUYER's CUSTODIAN/BANK.BUYER.CASH_ACCOUNT >:IN
The action plan of the buyer's clearing bank, which acts both as CUSTODIAN for PRODUCT and BANK for CASH, is listed below.
The interesting part here is how the clearing bank mediates between its client (the BUYER) and the CSD via intermediate levels, where netting can take place (subject of a separate article).
The actual changes that are local to the clearing bank, and thus are the ones the clearing bank can execute directly, are highlighted in green.
The steps highlighted in purple represent causal links connecting actions in the actual plane to theinfo plane and vice versa, while steps highlighted in blue represent causal links where both activities are within actual plane.
The extremities of the TRADE aspect from the POV of the buyer’s clearing bank (a frame is a complex change/event, thus an agent’s POV on it is also a complex change/event with a composite aspect) — i.e. the requests from the buyer triggering its clearing bank execution plan, as well as the final responses to those requests (effects) — are highlighted in yellow.
There are no temporal triggers here, meaning the engagement of the clearing bank into the contract is initiated by it’s client.
Triggers in lines 0 and 2 represent the BUYER instructing the clearing bank directly to deliver cash and receive securities.
Note that in real settlement the client does not send instructions to the clearing bank to move cash or securities, as discussed above.
In that case, the clearing bank is triggered temporally by the existence of the contract and the concrete settlement date stated in it.
Line 5 represents a causal link from activity in the info plane to activity in the actual plane: the interpretation of a message as a command.
Here, receiving a request to initiate the receipt (CAPTURE) of securities (PRODUCT) into the buyer’s vostro account at the buyer’s clearing bank initiates that receipt of securities.
Line 6 represents the start of receiving securities (capturing the PRODUCT) into the client’s vostro account (BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT).
This action takes place within the setting of the CUSTODY fibre, where the captured (actual-plane) figure is playing the role of CUSTODIED.
Line 7 shows a causal link between two activities within the actual plane: the start of the receipt of securities (capture of PRODUCT) at the vostro account that the buyer has with its clearing bank (BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT) implies the start of the receipt of securities at the pool account of the clearing bank (under the same party playing the CUSTODIAN role — under the buyer’s custodian).
Line 8 shows the start of the latter action — the receipt of securities into the pool account of the clearing bank.
Line 9 shows another causal dependency within the actual plane: the start of receipt of securities into the pool account (POOL_ACCOUNT) itself implies the start of receipt of securities at the nostro account that the clearing bank has with the CSD (BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT).
Line 10 represents the start of the latter action — receipt of securities at the nostro account held with the CSD.
Line 13 represents a causal link from activity in the actual plane to activity in the info plane: the start of receipt of securities at the nostro account held with the CSD (BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT) implies that the clearing bank should send an instruction (release an info figure in the imperative mood) to the CSD to receive securities (to EXECUTE capture of PRODUCT) at the vostro account of the clearing bank (CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT).
Note how the nostro account (BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT) flips into the vostro account (CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT) across this causal link — this is a side effect of switching perspective from the CLIENT agent’s POV to the CUSTODIAN agent’s POV that is part of the CUSTODY frame.
In lines 16 to 23, the same “starting” story happens with the CASH delivery.
After these two requests (to receive securities into the clearing bank’s vostro account at the CSD and to deliver cash) have been sent to the CSD, the clearing bank agent must wait for the CSD to reply before resuming execution of the action plan.
These two requests, once received, engage the CSD in executing the movement of both securities and cash at the terminal level of the holding hierarchy and in responding once it has completed these movements in a DvP manner.
These actions are part of the CSD’s execution plan, as will be shown in the next section.
The replies arriving from the CSD are shown in lines 26 and 28 as triggers of activity within the clearing bank, thus allowing the clearing bank agent to resume execution of its action plan.
Note the order of these changes — they are effectively interlocked, so that one does not finish before the other.
This is an indirect consequence of the DvP semantics (enforced by the DVP fibre) at the bottom level of the indirect holding hierarchy within the CSD.
Line36 represents receiving a response from the CSD informing the clearing bank that the receipt of securities at the vostro account within the CSD (CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT) has been completed.
This is effectively part of a settlement confirmation from the CSD to the clearing bank (which is playing the role of the CSD’s CLIENT).
Line 37 represents a causal link from activity in the info plane to activity in the actual plane: the receipt of confirmation that securities have been received by the CSD into the corresponding vostro account implies the completion of receipt of securities at the nostro account (BUYER's CUSTODIAN/BANK.CSD.NOSTRO_ACCOUNT).
Line 38 represents the completion of the action of receiving securities at the nostro account of the clearing bank within the CSD.
Line 39 shows a causal link between two activities within the actual plane: the completion of receipt of securities at the nostro account implies the completion of receipt of securities at the pool account (POOL_ACCOUNT).
Line 40 represents the completion of this action (receipt of securities at the pool account).
Line 41 shows another causal link between two activities within the actual plane: the completion of receipt of securities at the pool account implies the completion of receipt of securities at the buyer’s vostro account at the clearing bank (BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT).
Line 42 represents the completion of this action (receipt of securities at the buyer’s vostro account).
Line 45 represents a causal link from activity in the actual plane to activity in the info plane: the completion of receipt of securities at the buyer’s vostro account (BUYER's CUSTODIAN/BANK.BUYER.SECURITIES_ACCOUNT) triggers the sending of a message (CREATE REPLY) to the buyer informing it about the completion of this activity.
The same “completion” story happens for the CASH, with the reply from the CSD coming back to the clearing bank in line26 and the resulting confirmation of the cash delivery in line43.
Note that because, in this example, we do not bundle cash and product changes into a single settlement instruction, two confirmations are sent to the BUYER in lines 53 and 55: the confirmation of the receipt of securities and the confirmation of the delivery of cash.
This effectively completes the part of the TRADE frame that has to be played out by the BUYER’s clearing bank.
This can be seen in lines 53 and 55, which indicate that the clearing bank is triggering activity within the BUYER agent.
Actions of the BUYER’s clearing bank agent
In the execution plan (serialized into a sequence of steps in order to print it out) of the CSD, there are four triggers coming from the two agents the CSD interacts with — the BUYER’s clearing bank and the SELLER’s clearing bank.
In the actual settlement, where the trade would undergo novation, these would be replaced by the CCP.
These are:
The first trigger is the capture of an info figure by the CSD that refers, in the imperative mood, to the starting point of a release of cash from the account of the buyer's clearing bank.
Translated into settlement terms, this means that the CSD gets instructed by the buyer's clearing bank to debit its cash account.
The second trigger for the CSD is the instruction by the buyer's clearing bank to receive stock into its client's account.
Note that in the actual settlement process, which is the subject of a separate article, these two will be combined (bundled) into a single settlement instruction.
The other two triggers are instructions coming from the seller's clearing bank to deliver securities and receive cash.
The actual movements of immobilized securities, as well as cash movements, are all internal to the CSD and are highlighted in green.
Note how the order of cash and stock movement is interlocked — neither side is completed before the other.
The lines highlighted in blue represent the DvP aspect of these movements: these are additional couplings between individual changes (movements of STOCK and CASH) that were imposed onto the TRADE substrate by the DVP frame, whose fibre gets the sequence number #33.
The :IN and :OUT represent the start and completion points of each change — these are the extremities of an aspectual contour connected by a causal link (the edge in the force dynamics of the TRADE substrate).
The first one (line 21) reads as: "the (start of) release of STOCK from the SELLER's clearing bank's account requires (as a cause) the start of release of CASH from the BUYER's clearing bank's account."
Note the presence of the last section following "//", which links whatever the current line of activity is to the top-level change (aka the final cause).
For example, in line 31, a message is sent from the CSD to the SELLER's clearing bank informing the latter that the CSD has debited securities from its account — i.e. executed its instruction to deliver securities on a trade. This step, like any other step in any of the other agents' plans, will always be linked (via several levels if required) to the top-level change it implements, where the latter acts as a final cause justifying what the current step is doing.
This means that whatever is being done by the software, you can always ask why (on many levels, actually) and get a meaningful answer. This is crucial for troubleshooting, recovering from errors, or simply understanding what the system is doing without needing to know how it is doing it.
The lines highlighted in purple represent causal connections between things happening in the info plane and the actual plane.
An action/change in one plane can cause (or be caused by) an action/change in the other.
The first one (line 18) runs in the direction from the info plane to the actual plane: the CSD completing capture of the REQUEST info figure, referring in the imperative mood to the start of a release of the (actual-plane) figure PRODUCT from the SELLER's clearing bank's account at the CSD, causes the CSD to start executing the very same thing it refers to — namely, to start the release of PRODUCT from the SELLER's clearing bank's account at the CSD.
Another example is line 26, where the direction is the opposite — when an activity in the actual plane within one agent has to shift itself onto a higher plane — the info plane — in order to bridge the intersubjective gap between two interacting agents.
The completion of release of PRODUCT (an actual figure) from the SELLER's clearing bank's securities account causes the creation of a REPLY info figure that reports the very same completion.
In other words, the CSD completing delivery of securities from the SELLER's clearing bank's account causes the CSD to report to the SELLER's clearing bank that it has done what was instructed.
Note that the lines in black represent activities happening in the info plane, which are themselves foreign to the target domain and represent artefacts of the digitalization (or automation) of this domain.
Nevertheless, each of these activities is still directly traceable to the target-domain action whose implementation it contributes to. This also makes it easy to distinguish which actions executed by each agent's system pertain to which domain.
0 : Trigger from BUYER's CUSTODIAN/BANK coming into CAPTURE of REQUEST < EXECUTERELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN
1 : Start executing change : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
2 : Trigger from BUYER's CUSTODIAN/BANK coming into CAPTURE of REQUEST < EXECUTECAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN
3 : Start executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
4 : Finish executing change : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >
5 : Causal (#27) : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:INSTANT
6 : Finish executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
7 : Causal (#25) : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:INSTANT
8 : Causal (#25) : CAPTURE of REQUEST < EXECUTE CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:OUT -> CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN // implementing : CAPTURE of PRODUCT by BUYER
9 : Causal (#27) : CAPTURE of REQUEST < EXECUTE RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:OUT -> RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT:IN // implementing : RELEASE of CASH by BUYER
10 : Start executing change : RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT // implementing : RELEASE of CASH by BUYER
11 : Trigger from SELLER's CUSTODIAN/BANK coming into CAPTURE of REQUEST < EXECUTECAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN
12 : Start executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
13 : Trigger from SELLER's CUSTODIAN/BANK coming into CAPTURE of REQUEST < EXECUTERELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN
14 : Start executing change : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
15 : Finish executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >
16 : Causal (#28) : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:INSTANT
17 : Finish executing change : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
18 : Causal (#26) : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:OUT -> RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN // implementing : RELEASE of PRODUCT by SELLER
19 : Causal (#26) : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:INSTANT
20 : Causal (#28) : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:OUT -> CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT:IN // implementing : CAPTURE of CASH by SELLER
21 : Causal (#33) : RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT:IN -> RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN
22 : Start executing change : RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT // implementing : RELEASE of PRODUCT by SELLER
23 : Causal (#33) : RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN -> RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT:OUT
24 : Causal (#33) : RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN -> CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN
25 : Start executing change : CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT // implementing : CAPTURE of PRODUCT by BUYER
26 : Causal (#33) : CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:IN -> RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:OUT
27 : Finish executing change : RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT
28 : Causal (#26) : RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:OUT -> CREATE of REPLY < EXECUTEDRELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:INSTANT // implementing : RELEASE of PRODUCT by SELLER
29 : Executing instantaneous change (#26) : CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
30 : Causal (#26) : CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN // implementing : RELEASE of PRODUCT by SELLER
31 : Start executing change : RELEASE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
32 : Causal (#33) : RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT:IN -> CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT:IN
33 : Start executing change : CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT // implementing : CAPTURE of CASH by SELLER
34 : Causal (#33) : CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT:IN -> RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT:OUT
35 : Finish executing change : RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT
36 : Causal (#27) : RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT:OUT -> CREATE of REPLY < EXECUTEDRELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:INSTANT // implementing : RELEASE of CASH by BUYER
37 : Executing instantaneous change (#27) : CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >
38 : Causal (#27) : CREATE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN // implementing : RELEASE of CASH by BUYER
39 : Start executing change : RELEASE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : RELEASE of CASH by BUYER
40 : Finish executing change : CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT
41 : Causal (#28) : CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT:OUT -> CREATE of REPLY < EXECUTEDCAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:INSTANT // implementing : CAPTURE of CASH by SELLER
42 : Executing instantaneous change (#28) : CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >
43 : Causal (#28) : CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN // implementing : CAPTURE of CASH by SELLER
44 : Start executing change : RELEASE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
45 : Causal (#33) : CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT:OUT -> CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:OUT
46 : Finish executing change : CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT
47 : Causal (#25) : CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT:OUT -> CREATE of REPLY < EXECUTEDCAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:INSTANT // implementing : CAPTURE of PRODUCT by BUYER
48 : Executing instantaneous change (#25) : CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
49 : Causal (#25) : CREATE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN // implementing : CAPTURE of PRODUCT by BUYER
50 : Start executing change : RELEASE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : CAPTURE of PRODUCT by BUYER
51 : Finish executing change : RELEASE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > having remote effects to 1 agents
52 : Effect to SELLER's CUSTODIAN/BANK coming from CAPTURE of REPLY < EXECUTEDRELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN
53 : Finish executing change : RELEASE of REPLY < EXECUTED CAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > having remote effects to 1 agents
54 : Effect to BUYER's CUSTODIAN/BANK coming from CAPTURE of REPLY < EXECUTEDCAPTURE of PRODUCT as CUSTODIED* @ CSD.BUYER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN
55 : Finish executing change : RELEASE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT > having remote effects to 1 agents
56 : Effect to SELLER's CUSTODIAN/BANK coming from CAPTURE of REPLY < EXECUTEDCAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN
57 : Finish executing change : RELEASE of REPLY < EXECUTED RELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT > having remote effects to 1 agents
58 : Effect to BUYER's CUSTODIAN/BANK coming from CAPTURE of REPLY < EXECUTEDRELEASE of CASH as HELD* @ CSD.BUYER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN
Actions of the CSD agent
0 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_SOD Triggering RELEASE of PRODUCT:IN
1 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_SOD Triggering CAPTURE of CASH:IN
2 : Start executing change : RELEASE of PRODUCT
3 : Causal (#4) : RELEASE of PRODUCT:IN -> RELEASE of PRODUCT @ SELLER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:IN // implementing : RELEASE of PRODUCT by SELLER
4 : Start executing change : RELEASE of PRODUCT @ SELLER.BANK/CUSTODIAN.SECURITIES_ACCOUNT // implementing : RELEASE of PRODUCT by SELLER
5 : Causal (#24) : RELEASE of PRODUCT @ SELLER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:IN // implementing : RELEASE of PRODUCT by SELLER
6 : Start executing change : RELEASE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
7 : Finish executing change : RELEASE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >
8 : Trigger from BUYER coming into CAPTURE of COMMUNICATED < EXECUTED RELEASE of CASH >:IN
9 : Start executing change : CAPTURE of COMMUNICATED < EXECUTED RELEASE of CASH > // implementing : Causal (#1) : RELEASE of CASH:IN by BUYER -> CAPTURE of CASH:IN by SELLER
10 : Causal (#30) : RELEASE of PRODUCT:IN -> RELEASE of COMMUNICATED < EXECUTED RELEASE of PRODUCT >:IN // implementing : Causal (#1) : RELEASE of PRODUCT:IN by SELLER -> CAPTURE of PRODUCT:IN by BUYER
11 : Finish executing change : CAPTURE of COMMUNICATED < EXECUTED RELEASE of CASH >
12 : Causal (#29) : CAPTURE of COMMUNICATED < EXECUTED RELEASE of CASH >:OUT -> CAPTURE of CASH:IN // implementing : Causal (#1) : RELEASE of CASH:IN by BUYER -> CAPTURE of CASH:IN by SELLER
13 : Start executing change : CAPTURE of CASH
14 : Causal (#7) : CAPTURE of CASH:IN -> CAPTURE of CASH @ SELLER.BANK/CUSTODIAN.CASH_ACCOUNT:IN // implementing : CAPTURE of CASH by SELLER
15 : Start executing change : CAPTURE of CASH @ SELLER.BANK/CUSTODIAN.CASH_ACCOUNT // implementing : CAPTURE of CASH by SELLER
16 : Causal (#21) : CAPTURE of CASH @ SELLER.BANK/CUSTODIAN.CASH_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:IN // implementing : CAPTURE of CASH by SELLER
17 : Start executing change : RELEASE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
18 : Finish executing change : RELEASE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >
19 : Trigger from SELLER's CUSTODIAN/BANK coming into CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:IN
20 : Start executing change : CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
21 : Finish executing change : CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >
22 : Causal (#21) : CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:OUT -> CAPTURE of CASH @ SELLER.BANK/CUSTODIAN.CASH_ACCOUNT:OUT // implementing : CAPTURE of CASH by SELLER
23 : Finish executing change : CAPTURE of CASH @ SELLER.BANK/CUSTODIAN.CASH_ACCOUNT
24 : Causal (#7) : CAPTURE of CASH @ SELLER.BANK/CUSTODIAN.CASH_ACCOUNT:OUT -> CAPTURE of CASH:OUT // implementing : CAPTURE of CASH by SELLER
25 : Finish executing change : CAPTURE of CASH
26 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_EOD Constraining CAPTURE of CASH:OUT
27 : Start executing change : RELEASE of COMMUNICATED < EXECUTED RELEASE of PRODUCT > // implementing : Causal (#1) : RELEASE of PRODUCT:IN by SELLER -> CAPTURE of PRODUCT:IN by BUYER
28 : Finish executing change : RELEASE of COMMUNICATED < EXECUTED RELEASE of PRODUCT >
29 : Trigger from SELLER's CUSTODIAN/BANK coming into CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:IN
30 : Start executing change : CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
31 : Finish executing change : CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >
32 : Causal (#24) : CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:OUT -> RELEASE of PRODUCT @ SELLER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:OUT // implementing : RELEASE of PRODUCT by SELLER
33 : Finish executing change : RELEASE of PRODUCT @ SELLER.BANK/CUSTODIAN.SECURITIES_ACCOUNT
34 : Causal (#4) : RELEASE of PRODUCT @ SELLER.BANK/CUSTODIAN.SECURITIES_ACCOUNT:OUT -> RELEASE of PRODUCT:OUT // implementing : RELEASE of PRODUCT by SELLER
35 : Trigger from BUYER coming into CAPTURE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT >:IN
36 : Start executing change : CAPTURE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT > // implementing : Causal (#1) : CAPTURE of PRODUCT:OUT by BUYER -> RELEASE of PRODUCT:OUT by SELLER
37 : Finish executing change : CAPTURE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT >
38 : Causal (#31) : CAPTURE of COMMUNICATED < EXECUTED CAPTURE of PRODUCT >:OUT -> RELEASE of PRODUCT:OUT // implementing : Causal (#1) : CAPTURE of PRODUCT:OUT by BUYER -> RELEASE of PRODUCT:OUT by SELLER
39 : Finish executing change : RELEASE of PRODUCT
40 : fibre #1 : TRADE_TC ~top level TRADE_TC~SETTLEMENT_DATE_EOD Constraining RELEASE of PRODUCT:OUT
41 : Causal (#32) : CAPTURE of CASH:OUT -> RELEASE of COMMUNICATED < EXECUTED CAPTURE of CASH >:IN // implementing : Causal (#1) : CAPTURE of CASH:OUT by SELLER -> RELEASE of CASH:OUT by BUYER
42 : Start executing change : RELEASE of COMMUNICATED < EXECUTED CAPTURE of CASH > // implementing : Causal (#1) : CAPTURE of CASH:OUT by SELLER -> RELEASE of CASH:OUT by BUYER
43 : Finish executing change : RELEASE of COMMUNICATED < EXECUTED CAPTURE of CASH > having remote effects to 1 agents
44 : Effect to BUYER coming from CAPTURE of COMMUNICATED < EXECUTED CAPTURE of CASH >:INActions of the SELLER agent
0 : Trigger from SELLER coming into CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:IN
1 : Start executing change : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
2 : Trigger from SELLER coming into CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:IN
3 : Start executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
4 : Finish executing change : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >
5 : Causal (#32) : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:OUT -> RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT:IN // implementing : RELEASE of PRODUCT by SELLER
6 : Start executing change : RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT // implementing : RELEASE of PRODUCT by SELLER
7 : Causal (#17) : RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT:IN -> RELEASE of PRODUCT as POOLED* @ POOL_ACCOUNT:IN // implementing : RELEASE of PRODUCT by SELLER
8 : Start executing change : RELEASE of PRODUCT as POOLED* @ POOL_ACCOUNT // implementing : RELEASE of PRODUCT by SELLER
9 : Causal (#20) : RELEASE of PRODUCT as POOLED* @ POOL_ACCOUNT:IN -> RELEASE of PRODUCT as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:IN // implementing : RELEASE of PRODUCT by SELLER
10 : Start executing change : RELEASE of PRODUCT as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT // implementing : RELEASE of PRODUCT by SELLER
11 : Finish executing change : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >
12 : Causal (#29) : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:OUT -> CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT:IN // implementing : CAPTURE of CASH by SELLER
13 : Start executing change : CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT // implementing : CAPTURE of CASH by SELLER
14 : Causal (#24) : CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT:IN -> CAPTURE of CASH as POOLED* @ POOL_ACCOUNT:IN // implementing : CAPTURE of CASH by SELLER
15 : Start executing change : CAPTURE of CASH as POOLED* @ POOL_ACCOUNT // implementing : CAPTURE of CASH by SELLER
16 : Causal (#25) : CAPTURE of CASH as POOLED* @ POOL_ACCOUNT:IN -> CAPTURE of CASH as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:IN // implementing : CAPTURE of CASH by SELLER
17 : Start executing change : CAPTURE of CASH as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT // implementing : CAPTURE of CASH by SELLER
18 : Causal (#36) : CAPTURE of CASH as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN // implementing : CAPTURE of CASH by SELLER
19 : Causal (#29) : CAPTURE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:INSTANT
20 : Start executing change : RELEASE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
21 : Finish executing change : RELEASE of REQUEST < EXECUTE CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >
22 : Causal (#32) : CAPTURE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:OUT -> CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:INSTANT
23 : Causal (#33) : RELEASE of PRODUCT as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:IN -> RELEASE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN // implementing : RELEASE of PRODUCT by SELLER
24 : Trigger from CSD coming into CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:IN
25 : Start executing change : CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
26 : Start executing change : RELEASE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
27 : Finish executing change : RELEASE of REQUEST < EXECUTE RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
28 : Finish executing change : CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >
29 : Causal (#36) : CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ CSD.SELLER's CUSTODIAN/BANK.CASH_ACCOUNT >:OUT -> CAPTURE of CASH as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:OUT // implementing : CAPTURE of CASH by SELLER
30 : Finish executing change : CAPTURE of CASH as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT
31 : Causal (#25) : CAPTURE of CASH as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:OUT -> CAPTURE of CASH as POOLED* @ POOL_ACCOUNT:OUT // implementing : CAPTURE of CASH by SELLER
32 : Finish executing change : CAPTURE of CASH as POOLED* @ POOL_ACCOUNT
33 : Causal (#24) : CAPTURE of CASH as POOLED* @ POOL_ACCOUNT:OUT -> CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT:OUT // implementing : CAPTURE of CASH by SELLER
34 : Finish executing change : CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT
35 : Causal (#29) : CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT:OUT -> CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:INSTANT // implementing : CAPTURE of CASH by SELLER
36 : Trigger from CSD coming into CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:IN
37 : Start executing change : CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
38 : Executing instantaneous change (#29) : CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >
39 : Causal (#29) : CREATE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:IN // implementing : CAPTURE of CASH by SELLER
40 : Finish executing change : CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >
41 : Causal (#33) : CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ CSD.SELLER's CUSTODIAN/BANK.SECURITIES_ACCOUNT >:OUT -> RELEASE of PRODUCT as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:OUT // implementing : RELEASE of PRODUCT by SELLER
42 : Finish executing change : RELEASE of PRODUCT as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT
43 : Causal (#20) : RELEASE of PRODUCT as ASSET* @ SELLER's CUSTODIAN/BANK.CSD.VOSTRO_ACCOUNT:OUT -> RELEASE of PRODUCT as POOLED* @ POOL_ACCOUNT:OUT // implementing : RELEASE of PRODUCT by SELLER
44 : Finish executing change : RELEASE of PRODUCT as POOLED* @ POOL_ACCOUNT
45 : Causal (#17) : RELEASE of PRODUCT as POOLED* @ POOL_ACCOUNT:OUT -> RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT:OUT // implementing : RELEASE of PRODUCT by SELLER
46 : Start executing change : RELEASE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT > // implementing : CAPTURE of CASH by SELLER
47 : Finish executing change : RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT
48 : Causal (#32) : RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT:OUT -> CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:INSTANT // implementing : RELEASE of PRODUCT by SELLER
49 : Executing instantaneous change (#32) : CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >
50 : Causal (#32) : CREATE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:INSTANT -> RELEASE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:IN // implementing : RELEASE of PRODUCT by SELLER
51 : Start executing change : RELEASE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT > // implementing : RELEASE of PRODUCT by SELLER
52 : Finish executing change : RELEASE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT > having remote effects to 1 agents
53 : Effect to SELLER coming from CAPTURE of REPLY < EXECUTED CAPTURE of CASH as HELD* @ SELLER's CUSTODIAN/BANK.SELLER.CASH_ACCOUNT >:IN
54 : Finish executing change : RELEASE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT > having remote effects to 1 agents
55 : Effect to SELLER coming from CAPTURE of REPLY < EXECUTED RELEASE of PRODUCT as CUSTODIED* @ SELLER's CUSTODIAN/BANK.SELLER.SECURITIES_ACCOUNT >:INActions of the SELLER’s clearing bank
Once each agent has a model of its own engagement in a contract, it can execute its part of the contract without requiring any additional manual development of technical artefacts.
These action plans generated by the DCM compiler allow execution of a distributed settlement of a trade without writing a single line of programming-language code. There are no variables being read from or written to, no function or subroutine calls, no database tables or queries, no data-flow diagrams, no coding of sending or receiving messages, no message repositories, etc.
This is exactly the point of this example: to show that problems in contract-management domains such as post-trade processing can be addressed purely on the conceptual level, without having to deal with them via “low-level” technical artefacts.
Thus, it does not matter whether the latter (technical code) is developed manually, generated by an LLM, or encapsulated in so-called “low-code” platforms. From the point of view of modelling, it is “the wrong end of the stick”, and starting with it effectively “puts the cart before the horse”.
Note that the communication frames used in this example can be easily mapped onto technical implementations such as SWIFT or FIX (yielding yet another level of implementation within the info plane, while still remaining cleanly separated from the higher levels).
This mapping is generic and therefore does not require any manual code to be written to handle these messages, apart from setting up the technical infrastructure (such as establishing connections between endpoints, managing sessions, etc.).
Notice how DCM, despite knowing nothing specific about the trading domain, generates logic that maps one-to-one onto the trading domain — for example, how
“an agent (CLIENT) releasing an info figure referring, in the imperative mood, to the start of release of another figure with the nominal construal of CASH from a location under another agent (BANK)”
translates into“sending a cash-debit instruction”.
The encoding we obtain in the form of DCM source code is therefore almost one-to-one and stands in a modelling relation to the target domain (trade processing).
In terms of domain overlap, our goal is to preserve the semantics of the target domain in the implementation (the content of the actual plane), while adding minimal noise to the latter (i.e. avoiding technical idiosyncrasies and irrelevant semantics, which in DCM is also enhaced by confining all implementation details to the info plane and its derivatives).
Many relevant topics from the trade-processing domain have been excluded or simplified in this example because the main focus was to demonstrate how DCM works rather than to model real-world trade processing in its full scale.
Each of these topics will be addressed in a separate article, as they require substantially more space to explore in depth.
Some are listed below.
Runtime instantiation
Note that the execution plan was generated without even instantiating any of the frames involved in the construction of the TRADE.
This is a generic simulation that does not need to know any concrete values, which are known only at runtime.
However, in production, the TRADE construal will be instantiated to the runtime level of reality, much like a variable can be assigned a value.
This is the subject of a separate article, but the important thing to mention here is that there is no single point where the whole substrate has to be instantiated all at once (as is the case with instantiating classes in programming languages).
Instead, the instantiation — the lifting of the substrate to the runtime level of reality — happens incrementally.
Runtime information needs to be resolved only at the moment of its usage, and because frames represent processes unfolding in time, their instantiation also unfolds over time: concretes are fixed on demand, not all at once.
CCP, T2S, settlement instructions
The settlement model presented here is only a simplification of what an actual settlement involves.
A more realistic model of settlement requires modelling novation through a CCP, orchestration by T2S, the building of settlement instructions, central banks, and other aspects.
Treating all of these requires substantially more space and a few additional concepts not introduced in this example for the sake of brevity.
Netting
Another aspect that needs to be addressed is netting.
Trades are not settled individually, but only after they have been netted.
Furthermore, this can happen at multiple levels of the indirect holding hierarchy.
Conceptually, netting is just another example of a core operation of the frame vantage theory upon which DCM is based, allowing netting to be implemented without requiring any programming code to be written, in the same way as in the current example.
Position Administration
Position administration can also be handled in a purely conceptual manner within DCM.
Like settlement instructions or vostro/nostro accounts in this example, the notion of position maps directly onto an existing operation within DCM.