How does LUSID support the order process?

The order lifecycle within LUSID is represented via a domain model of related entities and functions, which allows the client the freedom to model any bespoke relationship required. At a very high level, the model allows use cases such as the following:

• Fund managers give verbal instructions to brokers to execute transactions.
• Electronic RFQs are generated via eTrading platforms.
• A large futures order is placed directly on an exchange, resulting in hundreds of small fills
• An allocation process examines the participation and apportions the fills across multiple accounts
• Transactions are matched back to the original orders and the remainder held over to be re-submitted at the next session

Different organisations use processes of varying complexity over different instruments, and typically interchange terms from a mostly common set to describe the entities involved. To support such a range of related systems, LUSID uses an extensible model that can be mapped onto any particular client use case.

In the diagram below, we show an example order workflow and how it interacts with the LUSID domain model. This is by no means representative of all use cases, and our intention is to ensure clients can consume as much or little of the model as needed.

Once an order in LUSID has been blocked and placed with executing brokers or intermediaries in accordance with its participation, the allocation process distributes returned executions to allocations in line with its ruleset and the originating order's participation. Transactions are then created and booked from the allocations.

An orders and allocations book of record

Support exists via API endpoint (see orders and allocations) and examples of the implementation in code can be found in the SDK and in Jupyter Notebooks.

Orders and allocations in LUSID support a small core of common properties, to which a client can add bespoke properties as appropriate. Both can be filtered on retrieval by any of the properties, the LusidInstrumentId (LUID), Quantity, OrderId or Portfolio.

Support also exists via API endpoint for related entities such as order books, blocks, executions, participations and placements. We are also working on a blended position view which includes pending orders across portfolios.

Mapping FIX messages

The most direct points of integration with the market would be via receipt of FIX New Order Single messages (which map to the LUSID placement entity) and FIX Execution Report messages (which map to the LUSID execution entity), both via FIX drop copy, although LUSID also supports the bulk upload of order, allocation or other entity data directly to appropriate endpoints.

Currently, LUSID has some facility for processing FIX. In the full domain model, a FIX Execution Report message, for example, would get mapped to a LUSID execution. However, as an example, it's possible to demonstrate its mapping to a LUSID allocation, mimicking the direct-allocation process a smaller investment concern might want to use.

Say the market produces an Execution Report for sale of 25 gold futures contracts:

This would get mapped onto an allocation with: