Transmission of orders – implications for buy-side - Typical Sample Solution Scenario

Transmission of orders – implications for buy-side : Basic trading scenarios (D1 to D7 -T 1 to T3) scenarios will be explained in next blog article, Note these example are simple capital market product buyer side scenarios and nothing SHOULD be linked to any organisation or company . These examples are purely my own production form training and study and research ongoing on this topic.

1.       Front Office <Removed - to be updated later >

2.     Middle office for DMS settlements

3.     Data Mart / Reporting 

4.     Reporting engine communication/ Real time ASP, Key stroke synchronism correspond to operational AREA status and Conf of Business partner/ references data

5.    Exception Pre- Reporting. -traded obligation between staging data mart before transmission to avoid failure, major validation area  

6. Pre-sumission validation results (Key validation here for each and every transaction rules probably might be aligned to ARM before MIFR ARAM

6a Actual submission in destination format accepted in the ARM solution

Above diagram do not goes into Pre traded validations which are unique to individual organisation trading infra.

Reference Data standards

In the buyer and seller fields, Buyers and sellers can either be reported as legal entities  (i.e. investment firms or legal persons), or natural persons. As above, where the buyer or seller is a legal entity, they need to be identified using an LEI, which needs to be reconciled against the global LEI database before engaging in any reportable transactions. This is particularly important when an investment firm is trading on behalf of its clients, as the firm will need to collect and verify the LEIs provided by its clients in advance of any trading. Where the buyer or seller is a natural person, their first name, surname and date of birth are required in the report. Firms will need to gather and normalise this information from HR databases, before compiling transaction reports. To ensure best practice, they should also reconcile any responses from the reporting venues to make sure the data is accurate. Additionally, under MiFIR, firms will need to identify the person or entity that made the decision to buy or sell the instrument in the first place. This will require considerable work to record the relevant data in front-end systems, and then robust data controls to ensure it remains accurate throughout the lifecycle of the trade. Whether an individual or a group of people make the decision to trade, the firm must report the one person considered to have primary responsibility for the transaction. This person needs to be identified by their ID number, passport number, tax or national insurance number depending on their nationality. Or, in the absence of these, by a concatenated code consisting ++

The main executor of the transaction must also be identified – using the same system. Where the decision to trade, or the execution of a transaction, is carried out by an algorithm, that algorithm must be identified using a unique, consistent and persistent code. This enables regulators to track all transactions carried out under a particular strategy, and also ties in with other areas of MiFID II which stipulate that firms must have controls in place to ensure the auditability and resilience of their algorithms. These extra identifiers will require new data to be captured at the point of execution, and then passed to middle and back office Systems to ensure consistency of reporting