1.6

Settlement

Last update, October 14
Services Description
Transaction Capture • Refers to the capture of a trade (or block-trade) internally by each counterparty of the trade, or by a dedicated third-party, for the purpose of trade validation, allocation, matching and confirmation/affirmation;
• Allows downstream processing, notably by corporate departments (e.g. finance, risk and accounting departments).
• Responsibility of front-office teams. Results in the trade details being sent to the middle and back-office teams.
Trade Allocation • Refers to the allocation of the Security Tokens across various accounts.
• The instructing party communicates the allocation instructions to the executing party.
Transaction Confirmation & Affirmation • Refers to the confirmation and affirmation of trade details and settlement terms and conditions between the executing party (broker/dealer) and its instructing party;
• Occurs on both the buy-side and the sell-side.
Settlement instructions notification • Refers to the sending of settlement instructions to relevant parties, including the Registrar.
• Responsibility of back-office teams.
Position management • Refers to the process of managing and reporting positions and related transactions;
• A position includes the transaction details and may also include valuation information.
Pricing & valuation • Refers to the determination of securities prices in order to valuate positions and feed downstream systems;
• Responsibility of middle-office teams.
Risk management • Refers to the process of monitoring and controlling the financial exposure created by a collection of financial obligations with respect to fluctuating risk factors (e.g. market price, creditworthiness, etc.)
Repository management • Refers to the data management systems required to process any trade involving Security Tokens;
• Contains reference data to be adapted (e.g. DLT option for “place of settlement”) and distributed across downstream systems.
Accounting management • Refers to the corporate departments used to record any transaction;
• Accounting systems need to be adapted to take into account the upstream processing of transactions involving Security Tokens.
Treasury management • Refers to the departments in charge of anticipating and executing funds transfers;
• Responsibility of the back-office teams.

In order to be successfully settled, a transaction (a subscription or a trade) must be accurately recorded and processed in the transaction counterparties’ current systems (post-trade chain).

Front-office, middle-office and back-office teams must validate and operate every stage of the transaction life cycle, to comply with internal duties.

The “matching” process can be defined as the comparison of settlement details by two counterparts to a transaction, following the execution of a trade, to ensure that they meet the terms of the intended transaction.

Executing parties may execute transactions not only on their own account but also on behalf of instructing parties. In this case, the direct market participant may be required to notify its instructing party (or its agent) of the details of the transaction and allow it to positively affirm the details, a process referred to as transaction confirmation or affirmation.

Two party model:

Transaction Processing Two Party Model

Three party model:

Transaction Processing Three Party Model

The fundamental challenge for trade processing services is to adapt current systems so they can process transactions involving Security Tokens:

  • Reference data may contain information on DLTs and be able to store new objects such as crypto accounts or crypto SSI;
  • Downstream services, such as position management or accounting management, should be able to interact with new sources of data (e.g. positions available on the DLT), and define new processing policies (e.g. accounting rules for Digital Assets).
  • Treasury management should develop new operational and technical capabilities to handle transfers if the payment leg of a transaction requires Digital Asset transfers instead of traditional cash transfers.
  • Etc. To address these challenges, the CAST Framework comes with a set of open-source technical components, the Oracles, intended to facilitate adaptation of the post-trade chain legacy systems.