Overview of EMS Functionality

As an Execution Management System (EMS), Moment provides automated pre-trade risk and compliance checks, connectivity and smart order routing across major fixed income venues and single dealer platforms, and post-trade processing and booking with custodians and back-office technology providers. In addition to comprehensive APIs for trading and booking, Moment provides trading & ops teams with an Admin Portal for configuring risk controls & markup schedules, monitoring real-time trading activity, and producing analytical reports for best execution and compliance reviews.

Pre-Trade Risk & Compliance Checks

To perform pre-trade risk & compliance checks, Moment has introduced the concept of a "risk group". Every Client Organization in Moment's EMS has one or more risk groups, each representing a cohort of the Client's accounts or customers. When a Client submits an order to Moment, the Client specifies the relevant risk group for the order (in addition to the end-customer's Account ID). Each risk group has its own risk controls and markup schedule:

The risk controls include pre-trade checks such as PMP price checks, maximum trade size per order (by asset class), and maximum daily notional volume (by asset class). Clients can also set criteria that determine each risk group's eligible universe, including restrictions by asset class (e.g. restricting TIPS trading) and regulatory status (e.g. restricting 144A securities), as well as explicit security allowlists and blocklists.
The markup schedule can be configured by asset class and time to maturity, as well as provide markups in price space (e.g. $0.10 marked up on the price) or yield space (e.g. 0.1% marked up on the yield). Moment automatically accounts for markups into the Top of Order Book Endpoint response and all trading-related messaging, allowing Clients to interact with Moment's APIs from the end-customer's perspective (e.g. using only "all-in" prices, inclusive of all markups).

When a Client submits an order to Moment, Moment automatically validates the order against the relevant risk checks. If the order passes the pre-trade checks, Moment will send an Order Approval message to the Client and begin attempting to execute the order.

Moment Admin Portal

Moment provides a UI to Clients, called the Moment Admin Portal, for managing their trading and operations. Using the Moment Admin Portal, Clients can:

Manage risk groups. Clients can create risk groups, set risk controls for each risk group, and set a markup schedule for each risk group. Clients can also configure Moment-side validations for risk groups, such as an Account ID regex.
Monitor trading and risk exposure in real-time. Moment provides dashboards for monitoring the stream of incoming order events and executions across all orders, as well as for digging into the individual orders and auditing the set of order lifecycle events that occurred. Moment also provides dashboards for monitoring aggregate trading volume and other risk metrics, such as the percent of the max daily notional volume that has been traded for each risk group.
Take emergency actions. In the case of unexpected behavior or a need to suddenly stop trading, Clients can use the Moment Admin Portal to institute a trading halt. A trading halt can be specific to a risk group or can apply to all of the Client's risk groups.

Connectivity and Smart Order Routing

Moment provides connectivity and automated smart order routing across the major fixed income trading venues and single dealer platforms, aggregating orders book in order to provide a consolidated limit order book for Clients to view and route orders against. When a Client submits an order, Moment automatically routes the order against the best marketable quote across all of the Client's venue connections. Moment will automatically split up orders and re-route orders as necessary to achieve best execution for the Client.

Post-Trade Processing

When a trade is executed for an order, Moment sends an order update to the Client and automatically books the trade with the Client's back-office systems. If the Client or Custodian has set markups for the order's risk group, then Moment will book multiple trade legs with the Custodian, each with the appropriate markups applied.

Order Lifecycle

The diagram below visualizes the full lifecycle of an order. Client-side systems are shaded green, Moment-side systems are shaded blue, venue systems are shaded gray, and back office systems are shaded orange. Because Moment's Clients are typically custodians, the back office systems that Moment interacts are often part of the Client's system. However, they are separated in this diagram because other arrangements are possible, either due to Moment integrating directly with a custodian's back office technology provider (e.g. Broadridge) or Moment serving Clients that custody assets at several custodians.

The Client's trading & ops team sets risk controls and markup schedules on the Moment Admin Portal. Clients can segment their users or correspondents into custom "risk groups", each with its own set of risk controls and markup schedules.
An advisor or user submits an order on the Client's platform. The Client submits the order to Moment via the Orders REST API or FIX Trading API.
Using the risk controls set by the Client, Moment's Risk Management System (RMS) performs the relevant pre-trade risk and compliance checks on the order.
Once the order is approved, Moment's Smart Order Router sends a child order to the trading venue. Because the Smart Order Router aggregates orders across many limit order books and single dealer platforms, Moment will split the parent order into several child orders and re-route child orders as necessary.
A trade is executed on one of the trading venues, and the venue sends Moment a drop copy.
Moment's Post-Trade Processing Engine books the trade with the Client's back-office systems. In the case that the Client has set a markup schedule, Moment will book several trade legs to appropriately apply the markups.

Key Concepts for Using Moment's Trading APIs

Order State Machine

Moment's APIs model orders as a state machine. Both the Real-Time Orders Websocket API and the Trading FIX API send an update to the Client when a state transition has occurred, providing both information about the event that caused the state transition (e.g. an execution) and information about the updated state of the order.

Possible States

The table below details the possible states for an order in the Websocket and FIX APIs. In the Websocket API, the order's status is provided via the status field in the Order Object. In the FIX API, the order's status is provided via the OrdStatus (39) field in the Execution Report message. The table also indicates whether the order state is considered "open" or "closed". When an order is in an open state, Clients should expect to receive additional updates for the order as the order progresses through its lifecycle. When an order is in a closed state, Clients should expect to receive no additional updates for the order. By the end of each trading session, all orders must reach a closed state.

State Description	Open vs Closed	WS `status`	FIX `OrdStatus (39)`
The order is pending acknowledgement by Moment.	`None`	`None`	`None`
The order has been acknowledged and is pending approval by Moment's Risk Management System.	`open`	`pending_approval`	`Pending New (39=A)`
The order has been rejected. No further updates are expected.	`open`	`rejected`	`Rejected (39=8)`
The order has been approved and Moment is currently attempting to execute the order.	`open`	`pending_execution`	`New (39=0)`
The order has been partially filled and Moment is currently attempting to execute the remainder of the order.	`open`	`partially_filled`	`Partially Filled (39=1)`
The order has been fully filled. No further updates are expected.	`closed`	`filled`	`Filled (39=2)`
The order has been canceled. No further updates are expected.	`closed`	`canceled`	`Canceled (39=4)`
The order has expired. No further updates are expected.	`closed`	`canceled` (`cancel_code=701`)	`Expired (39=C)`

Possible State Transitions

The table below details the possible state transitions that can occur and the corresponding messages in the Real-Time Orders Websocket API and the Trading FIX API.

The Websocket API communicates state transitions via the order_update message type, providing both the event that occurred and the updated order. The event_type specifies the event that occurred and the status specifies the updated state of the order.
The FIX API communicates state transitions via the ExecutionReport (35=8) message. The ExecType (150) specifies the event that occurred and the OrdStatus (39) specifies the updated state of the order.

Event Description	Event Name WS: `event_type` FIX: `ExecType (150)`	Possible Prev. State WS: `status` FIX: `OrdStatus (39)`	Possible New State WS: `status` FIX: `OrdStatus (39)`
Moment acknowledges the order.	WS: `request` FIX: `Acknowledgement (150=A)`	WS: `None` FIX: `None`	WS: `pending_approval` FIX: `Pending New (39=A)`
Moment rejects the order.	WS: `reject` FIX: `Reject (150=8)`	WS: `pending_approval` FIX: `Pending New (39=A)`	WS: `rejected` FIX: `Rejected (39=8)`
Moment approves the order, allowing for execution to begin.	WS: `approve` FIX: `Approve (150=0)`	WS: `pending_approval` FIX: `Pending New (39=A)`	WS: `pending_execution` FIX: `New (39=0)`
An execution occurs for the order.	WS: `execution` FIX: `Execution (150=F)`	WS: `pending_execution` `partially_filled` FIX: `New (39=0)` `Partially Filled (39=1)`	WS: `partially_filled` `filled` FIX: `Partially Filled (39=1)` `Filled (39=2)`
The order is canceled.	WS: `cancel` FIX: `Cancel (150=4)`	WS: `pending_approval` `pending_execution` `partially_filled` FIX: `Pending New (39=A)` `New (39=0)` `Partially Filled (39=1`	WS: `canceled` FIX: `Canceled (39=4)`
The order expires.	WS: `cancel` FIX: `Expire (150=C)`	WS: `pending_approval` `pending_execution` `partially_filled` FIX: `Pending New (39=A)` `New (39=0)` `Partially Filled (39=1`	WS: `canceled` FIX: `Expired (39=C)`

Cancellation

In both the Websocket/REST API and FIX API, Cancel Requests are treated as separate objects. In other words, simply submitting a cancel does not impact the state of an order. Moment will acknowledge the Cancel Request when it is submitted, attempt to cancel the order, and respond with either a Cancel Reject or an Execution Report confirming that Moment has successfully canceled the order. The table below details the events that can occur in a Cancel Request's lifecycle for both the Websocket/REST API and FIX API. Note that only orders in an "open" state can be canceled. Moment will immediately reject Cancel Requests for orders that are in a "closed" state.

Event Description	WS & REST	FIX
Client sends a Cancel Request to Moment.	`DELETE v1/trading/order/{id}/`	`OrderCancelRequest (35=F)`
Moment acknowledges the Cancel Request.	WS `event_type=cancel_request` (pertaining to the cancel)	`ExecutionReport (150=6)` (pertaining to the cancel)
Moment rejects the Cancel Request.	WS `event_type=cancel_reject` (pertaining to the cancel)	`OrderCancelReject (35=9)` (pertaining to the cancel)
Moment confirms successful cancellation of the order.	WS `event_type=cancel` (pertaining to the order)	`ExecutionReport (150=4)` (pertaining to the order)

Risk Groups

As described above, an order's risk group determines the risk checks that Moment will perform before routing the order to the trading venues, as well as the markups that Moment will apply when booking the order with the Client's back-office systems. Clients are expected to submit the relevant risk group as part of the order request, either via the Orders REST API or the Trading FIX API. This allows Clients to have complete flexibility in determining which risk group an order falls under. However, Moment also allows Clients to configure Moment-side validations to perform on the submitted risk group, such as an Account ID regex.

Eligible Trading Universe

A risk group's risk controls determines the eligible trading universe for orders from that risk group. Clients can view the eligible trading universe for the risk group on the Moment Admin Portal, as well as access it programmatically via the Risk API's Eligible Universe Endpoint. To ensure a seamless trading experience, Moment recommends that Clients only display bonds in their eligible trading universe on their platform. Moment will immediately reject orders for bonds that are not in the risk group's eligible trading universe.

Customer Perspective Orders

All front-office APIs, including the Orders REST API and Trading FIX API, consider orders from the end-customer's perspective, inclusive of all fees that the Client has specified. This means:

When the Client requests the top of order book via the Get Top of Book API, Moment applies the Client's markup to all orders in the order book and returns the top of order book net of fees. This means that the Client does not have to adjust any prices in the order book before showing the order book to end-customers.
When the Client submits an order request to Moment via the Orders REST API or Trading FIX API, the Client should specify the "all-in" limit price of the order, net of fees. In other words, the Client should specify the order's limit price from the end-customer's perspective.
When Moment receives a fill for the order, Moment applies the relevant markups to the order and sends an execution message to the Client with an "all-in" price, net of fees.

For reporting, clearing, and custody, Moment's back-office APIs book several trade legs with the Client's back-office systems, with each leg containing the relevant markups and counterparties.

Order Types

Moment only supports limit orders. A limit order is an order to buy or sell at a specified price or better. A buy limit order (a limit order to buy) is executed at the specified limit price or lower (i.e., better). Conversely, a sell limit order (a limit order to sell) is executed at the specified limit price or higher (better). Clients must specify the limit price parameter when submitting an order. While a limit order can prevent slippage, it may not be filled for a quite a bit of time, if at all. For a buy limit order, if the market price is within the specified limit price, Clients can expect the order to be filled. If the market price is equivalent to the limit price, your order may or may not be filled; if the order cannot immediately execute against resting liquidity, then it is deemed non-marketable and will only be filled once a marketable order interacts with it.

Extended Hours Trading

By default, orders are only eligible for Regular Trading Hours, which run from 9:30AM to 4:00PM ET. When submitting an order, the Client has the option to indicate that the order is eligible for Extended Trading Hours, which run from 7:30AM to 5:00PM ET. All bonds supported during Regular Trading Hours are also supported during extended hours. The table below summarizes the expected behavior for orders with and without Extended Hours Eligibility based on the time of submission. Note that when a Client submits an order before the Regular Hours Open that is not eligible for Extended Trading Hours, Moment will queue the order for execution when Regular Trading Hours begin.

Eligible for Extended Trading Hours	Pre-Extended Hours Open (before 7:30AM)	Pre-Regular Hours Open (7:30AM - 9:30AM)	Regular Hours (9:30AM - 4PM)	Post-Regular Hours Close (4PM - 5PM)	Post-Extended Hours Close (after 5PM)
Eligible	Rejected	Executed immediately	Executed immediately	Executed immediately	Rejected
Not Eligible	Rejected	Queued for execution at Regular Hours Open	Executed immediately	Rejected	Rejected

Time in Force

All orders submitted via Moment are day orders. A day order is eligible for execution only on the day it is live. By default, the order is only valid during Regular Trading Hours (9:30AM - 4:00PM ET). If unfilled by 4:00PM ET, it automatically expires. If submitted after the close, it is rejected. However, if marked as eligible for Extended Trading Hours, the order will automatically expire at 5:00PM ET.

Partial Fills

While rare, it is possible to receive a partial fill for an order. In this case, Moment will immediately notify the Client that an execution has occurred and book the partial fill with the Client's back-office systems, but will continue attempting to execute the remainder of the order for the rest of the trading session. Note the following points:

While very rare, it is possible to receive multiple partial fills for an order. In other words, it is possible for an order to transition from pending execution, to partially filled, to partially filled (again), to canceled / expired / fully filled.
Partial fills can still be canceled and will expire at the end of the day. When either of those events occur, the order's status will change from partially filled to canceled or expired.

FAQ

Can an order be rejected once it has been approved?

No, order approval is final. Once an order passes through the Risk Management System and is approved for execution, Clients will never receive a rejection message for the order. If the Client institutes a trading halt that impacts the order, then Moment will cancel the order and send a corresponding update to the Client via the Real-Time Orders API or Trading FIX API.

Can an order be approved once it has been rejected?

No, order rejection is also final. If the Client would still like to execute the order, the Client may resubmit the order after adjusting either the order or the risk controls so that the order will pass the pre-trade checks.

Can executions across multiple venues occur for a single order?

Yes, a single order can be executed on multiple venues. Moment's Smart Order Router aggregates liquidity and automatically routes orders across many trading venues and single dealer platforms. When appropriate, Moment will split up an order and execute it across multiple venues if doing so will improve the average execution price of the order. In this case, Moment will send the Client multiple execution messages, one for each fill.

Can orders that have not yet passed the pre-trade risk checks be canceled?

Yes, orders that are still pending approval can be canceled. This functionality is particularly important for Clients with a review and release process. In those cases, orders may be pending approval for several minutes or more, making it critical that Clients can cancel orders that have not yet been approved.

Can partially filled orders be canceled?

Yes, partially filled orders may be canceled using the normal cancellation workflow. In the case of a partially-filled order, the Client should have already received an Execution Report for the partial fill. In the Execution Report confirming cancellation of the order, the order status tags will properly reflect that the order is closed, but was partially filled:

OrdStatus (39) will be "4", indicating that the order has been canceled and no further updates are expected for the order.
LeavesQty (151) will be zero, indicating that there is zero remaining quantity to be filled.
CumQty (14) will be the quantity that was filled.
AvgPx (6) will be the average fill price of the filled portion of the order.

Can partially filled orders expire?

Yes, a partially filled order will expire at the end of its eligible trading day. A previous Execution Report should have already provided the relevant details of the partial fill to the Client. Just like when a partially filled order is canceled, the order status tags will properly reflect that the order is closed, but was partially filled:

OrdStatus (39) will be "C", indicating that the order has expired and no further updates are expected for the order.
LeavesQty (151) will be zero, indicating that there is zero remaining quantity to be filled.
CumQty (14) will be the quantity that was filled.
AvgPx (6) will be the average fill price of the filled portion of the order.