Step 6 - Placing Trades / Orders

API Reference

Minimum Required Endpoints

• Account Summary

• GET Instruments Details

• GET NBBO Quotes

• POST Create an Order

• PUT / Cancel an Order

• GET Order Status via API

  • This should be be substituted with the Amazon SQS order events for regular status updates

• Error List

SQS Reference

• Instrument Events
• Order Events

Task OR1 - Incorporate Daily Active Instrument Update (if applicable)

• Before Placing Trades Understand the Daily Active Instrument Update

• Once a day make a single request to GET /instruments to retrieve a list of ALL currently ACTIVE instruments on the platform and cache that information including the id (instrumentID) this is your daily update of the available securities on the platform; DW is constantly adding to this. Please do not call this endpoint more than twice a day!

• Once you have a mapping of instrumentID’s to their associated symbol you can request security details: fundamental details and other related information to build out a “stock card” (see Stock Card Example)

  • There is no requirement to display additional information about the security, but this generally improves customer transparency
  • Test the retrieval and incorporation of instrument data into your test plan before going to Production

Filtering Instrument Group Lists

• Standardly, you will have access to approximately 6,000 instruments (this excludes OTC symbols, " Alternate Assets" and "Mutual Funds")
• You will need to design and incorporate an instrument filtering process that ensures that your end users can ONLY VIEW the instruments that your firm wants to provide them access to

Placing Orders Overview

• This section covers the basic mechanics of placing an orders through your platform and the associated API request/responses.
  Critical Items
  - Is customer buying power sufficient to place orders?
  - Are orders executing correctly - ticker symbols, type of orders, mechanics?
  - Are you incorporating both or one type of orders?
  - Notional (Dollar Amount) based
  - Share quantity based
  - Was the order successful, if not why did it fail?

- TRADING LIMITS - To reduce the risk imposed by accidental or nefarious orders being created DriveWealth maintains internal monitors that flag down larger orders for review prior to execution. As of 8/10/2021, the notional limit is $1.5mm, and share quantity 20,000 shares or greater.

Available Order Types:

• Market
• Limits (GTC & GTD)
• Stops (GTC & GTD)
• Market if Touched (GTC & GTD)

Market Order

• Market orders are submitted immediately to execution venues (assuming the security is actively trading) and carry the highest priority. Provided there is sufficient liquidity to fill the order, customers can expect very fast execution, but without any guarantee of price.

• The bid or ask the customer sees when placing the trade is an indicative price only, and due to the fast-moving nature of the market, the actual executed price may differ.

Limits

• Unlike market orders, limit orders have a guarantee of price if filled. To achieve this, an order for a quantity and specified price is sent to an exchange or market maker to be later paired with a buyer or seller also willing to transact at that price. There is no guarantee that the order will be executed—for example: if a customer wants to purchase stock at $100/share, they may not ever receive a fill if the security continues to trade around $120/share.

• Buy orders are created with a price below the current ask, and sell orders are created with a price above the current bid. It is possible for the customer to receive a price better than requested. Limit orders can also be set to expire up to 90 days from the date of creation.

• Because limit orders need to rest in an order book at a market maker, limit orders accept whole-share quantities only.

Stop & Market if Touched

• Stop orders and market-if-touched orders have very similar functions: they both create market orders when a condition has been reached.

• Like limit orders, these order types require both a quantity (or dollar amount) and a price. Unlike limit orders, this price is not a guarantee. Instead, it is a triggering price which, upon the security trading at, dispatches a market order to buy or sell the requested amount.

The trigger prices should be set according to the following:

• Buy stop: If lastTrade >= trigger price

• Buy market-if-touched: If ask <= trigger price

• Sell stop: If lastTrade <= trigger price

• Sell market-if-touched: If bid >= trigger price

• Market-if-touched orders share the same side of the current price as limit orders. Because of this, they may be considered an alternative to limit orders when fractional orders are desired (keeping in mind the lack of guaranteed price).

• To provide a simplified approach to choosing an appropriate order type, consider a workflow that guides the customer similar to the below:

• Buy now — (market order)

• Buy if price goes down, sell if price goes up (for Quantity based orders use - Limit Orders)

• Buy if price goes down, sell if price goes up (for Notional or Dollar entered orders use Market-If-Touched (MIT) orders)
  The DriveWealth platform offers the ability to trade and invest in over 6,000 U.S. securities. Our Partners can offer the full breadth or a limited subset of our investment products to customers.

Our standard listing criteria for US listed securities is $300 million market cap, average traded notional value of $1 million and 100,000 shares traded per day.

Fractional Trading

• When orders are received, DriveWealth manages whole and fractional components of the trade separately:
• Whole share trades are routed to the Market - by DW in an agency capacity
• Fractional components of a trade are routed to DW’s Fracker^Ⓡ - and executed by DW on a principal basis
  • The share price of a mixed capacity trade will reflect the market price of the whole share executed in the market, i.e. the fractional share price for the fractional component of the trade will always be the same as the whole share execution price
• Order executions can go out to 8 decimal places
• Orders will never be executed for more than the submitted share quantity or notional amount
  • Example: when a customer submits a $100 order to buy AMZN the Fracker^Ⓡ calculates the number of shares required to fill the $100 order. If the security price moves during the time between the share calculation and the order execution, the Fracker^Ⓡ will shave off 0.00000001 shares until the total order quantity is equal to or less than the requested $100.
• Dollar-based orders are supported through 2 order types
  • Market orders
  • Market-if-touched orders (See Order Types)

Below are 2 examples of dollar-based orders through the Fracker:
Example 1:
Price of Apple = $325
Order Amount to buy = $100
Order Quantity executed by The Fracker = 0.30769231 shares
Example 2:
Price of Apple = $325
Order Amount to buy = $500
Order Quantity executed away from the Fracker = 1.0 whole share at $325
Order Quantity executed by The Fracker = 0. 53846154 shares ($500 - $325)
Total Order Quantity executed = 1.53846154 shares

Task OR2 - Retrieve Customer Cash Balance

• Build Front End Logic to Reject buy and sell orders that will place the account in a debit; this will be achieved by retrieving the Customer Cash balance prior to accepting the order submission

• Use the "GET Account Summary" API call to determine a customer’s buying power and current share position when creating SELL orders

• Make your GET request when the customer selects the security they want to buy and or sell and are attempting to determine the total notional or share quantity for the order

• Buy Order - cash.cashAvailableForTrade is the equivalent of buying power (how much money the customer can spend on any given market order). If a buy order is greater than this value; it is rejected immediately

  • This will always be $0.00 for the Trade Settlement Workflow

• Sell Order - equity.equityPositions.availableForTradingQty is the total number of shares that a customer can sell for the given security. If a sell order is greater than this value; it is rejected immediately

Task OR3 - Retrieve Quotes via API from Partner designated Market Data sources

• Complete Review Market Data Section

• Complete Review Data Caching, Storage and Retrieval

• When a customer places an order they must be provided an accurate price; this request is a requirement by DriveWealth, and must be shown to abide by Regulation NMS

  • A customer MUST have a DriveWealth user in order to be provided market data
  • DriveWealth does not offer streaming market data services (at the moment). Recommendation: a request call every 5 seconds while the customer is on the screen displaying quotes

• 2 Types of quotes

  • REQUIRED (IF USA BASED)- The ability to display the NBBO Quotethis provides the NBBO (National Bid Best Offer) price feed and other attributes; this must be displayed to the customer after they have submitted a trade, but prior to confirmation
  • NON-REQUIRED Quotes from NYSE BQT - The sample below shows additional information compared with the non-required quotes, however this endpoint is charged on a per-request basis. Recommendation - do not call more than needed

Retrieving Security QUOTES:

• Market data must be requested with the calling userID in the header
• lastTrade can be used on a “stock card” page (see sample below) this is the mid-point price (between the bid/ask) of the last trade. This price will generally be displayed to the customer when they are looking at a stock screen alongside a chart (charting to follow)
  • This data will always be displayed to the user PRIOR to submitting a trade
  • Sample Screen Flow - DW will only describe best practices for displaying Regulation NMS requirements, and general flows. There are an infinite number of ways to design and display this information, since this is a revenue driving portion of the application - Partners dictate their own design.

Task OR4 - Submit a Trade via API and collect Important Trade (Order) Data Points

• Use the POST Create an Order API endpoint to place trades

• (Advisors using the Allocations API endpoint) Order status Check - prior to submitting the allocation list order are in an immutable/terminal status: CANCELLED, REJECTED, FILLED

Total order amount

• Total order amount is the net funds required to pay for the order or the net funds received from the order. The actual amount of cash paid or received depends on the final execution amount. There are two times the total order amount should be shown:

1. Prior to submitting a trade, the estimated total order amount will be displayed to the customer. This is calculated by the partner, usually on the front end.
2. After submitting a trade, the final total order amount is provided through the order status API and in other places.

These two values may differ, such as when creating a share-based order, or when an order cannot be fully filled.

Order status and Cumulative Quantity

• DriveWealth utilizes a cumulativeQuantity property within all order response's that indicates how many shares have been filled as part of an order. Along with using the status property, cumulativeQuantity can provide further insight into where an order is in its lifecycle.

When displaying orders to customers, or issuing a notification based on the events system, it's going to be important to take into account the cumulativeQuantity value, as well as the lastShares. Both properties allow for the accurate depiction of an order as its being executed.

• Customers should always be able to view the current status of the order they have placed. Partners can opt to integrate with either the Amazon SQS Order Events or use the "Order Status API" to retrieve execution information and status

• Since SQS is setup as a standard queue events are not sent in sequential order, meaning cumulativeQuantity and lastShares become important to validate order sequence. Please reference Amazon SQS Integration for additional detail on how to maintain accurate order reporting using a stand queue format.

• DW recommends utilizing the SQS events, so polling individual order statuses is not needed

Order Error Messages

• In the event a customer’s order is rejected an error code, status, and description of the rejection will be returned to the customer. You can find all common order error messages in the API Reference. Ensure that the details of a rejection is given to the customer to limit confusion

• Events API: to receive an SQS-based notification when an order is created, updated, and completed

• Order Status API: to poll for current and updated status

Task OR5 - Store orderID and orderNO

• After a successful order creation you will be provided both in the response payload:
  • orderID
  • orderNo

Task OR6 - Order Cancellation workflow is complete and includes cancelled order events with SQS

The PUT Cancel Orders Endpoint will be used:

• When the market is open orders will execute immediately
• When an order is submitted after hours it will be in a NEW status until market open
  • While the order is in a NEW status you can CANCEL it
  • By using the "PUT Cancel Orders" Endpoint you will receive a successful response which means the order has been cancelled

Non-Market Hours Orders and Cancelling Orders

• DriveWealth will accept market orders that are placed after 4:00 pm ET, and will hold them overnight to release on market open the following business day.

• For partners that don't want their customer orders to be queued for market open we provide the preventQueuing parameter when creating the order. By sending the order request with this parameter set to true the order will be rejected if submitted or received after 4:00pm ET.

• To help determine whether a NEW order will be executed immediately or queued for the next market session there is an orderExpires attribute in the order status response. For example, an order submitted after hours will have an orderExpires set to 4:00pm ET the following market session.

• Market orders that are submitted overnight are sent to DriveWealth's executing brokers at 9:05am ET and will generally be part of the opening auction. Orders cannot be cancelled after these times for the following exchanges:

• The Exchanges listed below will not allow the cancellation of orders past the following times:

  • NASDAQ Names - 9:28am ET
  • NYSE ARCA Names - 9:29am ET
  • NYSE American Names - 9:29am ET
  • BATS Names - 9:28am ET
  • IEX Names - 9:28am ET
  • NYSE Names - Open Time

• Orders that are submitted after 9:28am ET will not be part of the opening auction and are sent directly to the street for execution.

Task OR7 - Order Testing and Trading Violation Incorporation

Order Type Testing

• Data Validation - request/responses are returning expected values
  All Order Types - test failed orders
• All Order Types - test rejected orders
• All Order Types - test partial fills
• Account for and Implement "Liquidate All" for Notional based sell orders (Dollar Amount Orders) - if over a given percentage, example: if > 95% of position, then the option to 'liquidate all' should be presented to the front-end user, but when submitting the order to ensure no fractional amounts are left over; the order needs to be submitted on the back-end as a 'Quantity' order going out 8 decimal places

Order Testing

• $0 notional purchase, buy order
• Attempting to buy 0.00000001 share (100 millionth of a share)
• Submit an order that will be in a "Pending" Status (ex: buy order that is submitted during non-market hours) - Validate this order can be cancelled, and when cancelled it's immediately cleared

Incorporate Trading Violations

When placing trades in a brokerage account there are ultimately 2 types of violations a customer can commit, dependent on their account type. Each of these violations carry different penalties and are caused by different trading activity.

• Good Faith Violation (GFV)
  • Only applicable to cash accounts
• Pattern Day Trading Violations (PDT)
  • Only applicable to margin and limited purpose margin accounts

How Partner Operations Manage Trading Violations

• Partners will receive SQS Notifications of violations in Customer accounts

• Also Daily outbound emails are sent to Partners with a list of impacted customers

• Pattern Day Trader (PDT) violation in an account. The account will be restricted for 90 calendar days upon being flagged as a PDT, during which no new positions can be traded.

• Customers have the following options if an account is flagged:

  • Deposit additional funds to bring the account’s equity up to DriveWealth’s required minimum of $25,000.
  • Wait for the restriction to expire in 90 days.
  • Request a one-time PDT account reset* using the "Pattern Day Trader Rest" Form in the Credentials tab of the Partner's Project Plan

FINRA (Financial Industry Regulatory Authority) has provided brokerage firms the ability to remove the PDT flag from a customer’s account within 180 days. If you did not intend to day trade with your account, DriveWealth can grant a one-time PDT reset

• Good Faith Violations - Accounts with three good faith violations in a 12-month period will be restricted to purchasing securities with only settled cash for a period of 90 days. Further, any trades executed that exceed either 3 violations or $1,000 may be cancelled.

Please be aware that if a customer were to conduct three (3) good faith violations over a 12-month period or free-ride as defined by Regulation T, DriveWealth must take mandated action and freeze the customer’s account. The account freeze is a 90-day restriction whereby a customer may still make purchases in their account; however, it must be with settled funds only.

These rules are non-negotiable. In order for funds to be considered acceptable to resolve a Good Faith Violation before settlement date, the funds must be within the broker-dealer For Benefit of Account (FBO), which is considered a good control location for the broker-dealer.

Summary ("GFV")

If a customer purchases a security in their cash account AND they sell it prior to being paid for (via settled funds in the account), a good faith violation has occurred.

• The reason it is referred to as a good faith violation is that trade activity is giving the ‘appearance’ that sales proceeds are being used to cover ‘Buy’ orders when there is insufficient settled cash to cover these purchases.
• Basically, trade activity indicates that your customer made a good faith effort to deposit additional cash into the account; however it will not happen in time.
• For DriveWealth Partners that are taking advantage of 24/7 ACH it is important to take note of the following. If an account is placed on a restricted status, any new ACH deposit that has been made will not be immediately available to use towards a purchase and must wait until the funds have settled with our bank. The reason behind this is that funds are not considered settled, or in a good control location for the broker-dealer until they have arrived and settled at the bank.

The regulations

Under Regulation T, which governs an investor’s use of a cash account, a customer can purchase securities if:

• There are sufficient (“settled”) funds in the account; or
• The broker-dealer accepts, in good faith, the investor’s agreement that they will
• promptly make a full cash payment for the security before selling it and
• it does not contemplate selling the security prior to making such a payment.

Good Faith Violations are based on intention and purpose. It is your customers’ responsibility to ensure that they have fully settled funds in their account before they submit another ‘Buy’ order. To confirm, customers cannot ‘Buy’ securities with unsettled funds.

Helpful links

1. https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_cashaccounts
2. https://www.investor.gov/introduction-investing/investing-basics/glossary/freeriding
3. https://www.investor.gov/introduction-investing/investing-basics/glossary/freeze-brokerage-account

Examples

Good faith violation example 1:
Cash available to trade = $0.00

• On Monday morning, a customer sells Y stock netting $5,000 in cash account proceeds.
• On Monday afternoon, the customer buys X stock for $5,000.
• If the X stock is sold prior to Wednesday (settlement date of the Y sale), a good faith violation would be charged as the X stock is not considered fully paid for prior to sale.

Good faith violation example 2:
Settled cash = $5,000

• On Monday morning, a purchase is made for $5,000 of X stock.
• On Monday mid-day, the customer sells the X stock for $5,500.
• Near market close, the customer purchases $5,500 of Y stock.
• At this point no good faith violation has occurred because the customer had sufficient funds for the purchase of X.
• If Y is sold prior to being paid for (settlement) then a good faith violation will have occurred.

Good faith violation example 3:

• Cash available to trade = $10,000 minus cash credit from unsettled activity = $5,000 (proceeds from a sale of stock the prior Friday – trade settles on Tuesday)
• On Monday morning, the customer purchases $15,000 of Y stock.
• A good faith violation occurs if this customer sells the Y stock on Monday.
• The purchase is not considered fully paid for because the $5,000 proceeds are not considered sufficient funds until they are settled on Tuesday.

PATTERN DAY TRADING (PDT) VIOLATIONS

What is Pattern Day Trading? (“PDT”)

As defined within Regulation T and Rule 4210, a pattern day trader is an account that does four or more “day trades” within any rolling 5-day period. A day trade is when a buy order and sell order of the same symbol are executed in the customer account in one trading day.

Current FINRA Guidance: - https://www.finra.org/rules-guidance/notices/21-13

PDF Version - https://www.finra.org/sites/default/files/2021-03/Regulatory-Notice-21-13.pdf

Equity Requirements

• If a customer is tagged as a pattern day trader, they must maintain a minimum account equity balance of $25,000 USD.
• For customers with less than $25,000 in a single margin account at DriveWealth, A PDT trading equity restriction/requirement will result for customers that execute four or more day trades over 5 rolling business days.
• For customers who typically hold more than $25,000, if their balance falls below $25,000 USD, they must be restricted from day trading again in the account until they bring the balance back above $25,000.

How does PDT affect me (the end client)?

Users who maintain an equity requirement of $25,000 in their account are able to engage in Pattern Day Trading. PDT allows users to trade up to 4x their NYSE excess value. For example, an account with $30,000 in NYSE excess would have $120,000 available in day trading buying power

What are the NYSE Requirements and NYSE Excess?

The NYSE requirement can be calculated by taking the market value of all marginable positions and multiplying by 25% or 0.25.

Example: An account with $50,000 in market value would have an NYSE requirement of $12,500.

The NYSE excess can be calculated by deducting the NYSE requirement from the total equity of the account (market value + cash)

Example: An account with $50,000 in market value and $25,000 in cash would have a NYSE requirement of $12,500.

Equity = Market Value + Cash Balance
Equity: $50,000 + $25,000 = $75,000

NYSE Requirement: $12,500
Excess = Equity - NYSE Requirement = $62,500

Day Trading Buying Power would be up to 4x the excess as long as there are no pending calls on the account. Day Trade Buying Power is based on the previous day and does not change intraday.

Day Trade Calls

A day trade call is generated if a user exceeds their Day Trading Buying Power. The user has 5 business days to satisfy a day trade call. The first time a user exceeds the day trade buying power, their buying power is reduced to 2x the NYSE excess. If a day trade call is not met after 5 days, the user’s buying power is reduced to their NYSE Excess.

If funds are not received by the due date, the account will be restricted to only their NYSE excess. If another day trade call is created or the account falls below $25,000 minimum equity, the account will be restricted from day trading for 90 days, or until funds are received.

Users are able to liquidate positions to partially satisfy a call, however, they will only get the 25% release of the sale towards the call.

Counterparty Controls

For a variety of reasons, the most impactful being the end user experience, counterparties are required to implement system controls to ensure that customers do not trade into a PDT situation, unless the customer makes an attestation that they intend on becoming a PDT. The controls are as follows:

• Counterparty must implement notifications to customers for each Day Trade that the customer executes.
• Counterparty must implement a trading control, which prevents a customer from trading into a PDT situation. The controls is, as follows:
  • Count Day Trades – Buy and Sell, same symbol, same day
  • Apply rolling 5-day (trading day) calendar over the Day Trade counter
  • If customer Day Trade count equals 3 within the rolling 5 day, restricts customer from purchasing, until the day, where one of the 3 day trades rolls out of the 5-day window.
  • If you would like the customer to be able to buy the 4th potential day trade (if they were to sell the same day), please note that if the customer was to sell it would cause them to be tagged as a PDT. This is NOT the recommended approach as the customer is subject to market risk, if the sell side is blocked.

Task OR8 - Validate all HL symbol test cases (if applicable)

🚧

Ignore Market Hours Flag

Accounts using the ignoreMarketHoursForTest flag as true will NOT be able to perform the below tests.

• Testing Orders with the "HL" symbol in the Sandbox Environment. Only the "HL" symbol will produce these results in the Sandbox Env

• To help simulate less common order types hard-coded different status and execution permutations based on quantity submitted when [creating an order] via API; these permutations are only available for BUY side orders

• In order to successfully trigger these different events, an exact quantity has to be included when requesting a new order in the Sandbox Environment:

Expected Results:

• 176 - Execute only half of the quantity, and exchange cancel the remainder
• 177 - Execute in two fills, at two different prices
• 178 - Execute in 10 share increments, for a total of 18 fills
• 179 - Execute in 20 share increments and send a new fill every 1 second
• 1019 - Execute fully, no different from typical execution
• 1039 - Execute 1 share at a time
• 1049 - Execute 100 shares at a time
• 1059 - Returns NOS NAK or failure
• 1069 - Execute a partial amount, exchange cancel remainder
• 1079 - Execute nothing, exchange cancel everything
• 1089 - Execute nothing, leave open and awaiting cancel
• 5089 - Execute nothing, leave open and await cancel request

Task OR9 - Validate Amazon SQS Integration with Order Workflow

• Test Retrieval of Order Status and verify all Amazon SQS order events are being populated and received

• Point of Emphasis -

• For order status DriveWealth uses Amazon SQS to push status, this solution is more effective versus web hooks

• The orderID provided in the response payload in can be queried via API call, but this is designed to supplement the SQS events

• Order Statuses - 5 different values: NEW, CANCELLED, REJECTED, FILLED, PARTIAL_FILL

  • When an order is submitted it will return a status of: NEW

  • It will then change to one of the following:

    • CANCELLED - immutable, does not change
    • REJECTED - immutable, does not change
    • FILLED - immutable, does not change

  • PARTIAL_FILL - will ONLY transition to FILLED or CANCELLED / If a PARTIAL_FILL order changes to CANCELLED you may determine the executed amount prior to cancelling using cumulativeQuantity in the Response payload. cumulativeQuantity is the total amount that has been filled, where the quantity of an order is the amount that was requested.

  • Fractional Orders less than 1 share will change from NEW to FILLED NOT PARTIAL_FILLED

  • Fractional Orders with a (whole share + fractional competent) example - 5.12564 shares of AMZN will receive: PARTIAL_FILL until both, the whole share and fractional component are filled; then it will change to FILLED

Task OR10 - UX/UI - Finalize Landing Page, Market Data Presentation, Orders Submission Screens (including Order Cancellation)

Build and Test Order Entry INCLUDING NMS REQUIREMENTS

1. Stock charts accurately reflect price

SAMPLE - SECTOR LANDING PAGE
*Grouping securities into their individual sectors can potentially make investment selection easier

SAMPLE - UI "STOCK CARD" INCLUDING SECURITY DETAILS

• FOR FRACTIONAL ORDERS - When selling out of an entire position that contains a fractional component, you MUST enter the order in quantity (8 decimal places). If entering as a notional based order it's highly likely the entire position will not be liquidated causing a small position to be left in the account

• Submit orders with the POST/Orders Request

• Creating an order requires:

  • Customers account number
  • Type of order (market, limit, MIT)
  • Symbol, side, and
  • Either the amount of cash they want to spend (Notional Order), OR the number of shares they want to purchase (Quantity Order)

SAMPLE - ORDER ENTRY

• After selecting the buy option it is customary to give the customer the ability to enter either a dollar amount (notional) or a share quantity

SAMPLE - DISPLAYING REGULATION NMS REQUIREMENT

Display the additional NMS details behind a user initiated click (see rightward arrow on AMOUNT section below)

After clicking that arrow you will want to make the request to GET NBBO QUOTES, and display the following response attributes

bid (Price)
ask (Price)
bidSize
askSize
bestBidExchange
bestAskExchange
timeOffset (converted to current time)
volume
lastTrade (Price)
lastTradeSize
lastTradeExchange

• From this point the Partner can utilize the Events API to receive Amazon SQS notifications when the status of the order changes

SAMPLE - POST TRADE EXECUTION DETAILS
After the order has been sent display the current status of the order and the execution details to the customer

SAMPLE - POST TRADE EXECUTION DETAILS
After the order has been sent display the current status of the order and the execution details to the customer

SAMPLE - POST TRADE EXECUTION DETAILS
After the order has been sent display the current status of the order and the execution details to the customer