### **API Reference**

  • ο»Ώ[GET List All Cashless Reconciliations](πŸ”—ο»Ώ)ο»Ώ

  • ο»Ώ[GET Cashless Reconciliation Details](πŸ”—ο»Ώ)ο»Ώ

**SQS Reference:**

  • Coming Soon

## **Task F1** - Review Deposit Workflow

  • **This model supports a "Digital Wallet"**

  • **Partner is responsible for calculating the Customer's Buying Power (Partners maintain all risk and responsibility of end customer funding and calculation of `buyingPower`**

    • The Partner must be able to support potentially large daily payments for all Customer "Buy" transactions

    • Since DriveWealth is receiving a single payment from the Partner there are no seasoning periods

  • **The Partner has real-time visibility into funded account balances and is able to ring-fence assets because they can hold/custody assets or are in partnership with a 3rd party banking service that can; this prevents the customer from spending funds that have been allocated for brokerage**

  • **"Instant Trading Experience"** - Customer is given an automatic increase in requested buying-power based on their API requested deposit

    • **Only Limited Purpose Margin Accounts (LPMA) are used - Can Incur Pattern Day Trade (PDT) Violation**

    • **API Call for Reconciliation Amount - Wire - (push and/or pull) - 2 separate payments (Buys - Partner to DW / Sells - DW to Partner) **

  • **Cash to Settle "Buy" Trades needs to be delivered on Trade Settlement Date**

    • **Cash is NOT held in DW Customer Account unless there are off-setting trades in-between settlement**

    • **Funds for Aggregate Buy Trades will be held in Partner FBO Account not at DriveWealth **

    • **"Daily Travel Rule File" (.csv) must be sent by the Partner to DW Operations (spreadsheet of deposits for the day - AML requirement **

    • _This is not traditional brokerage financial leverage, both the Partner and DriveWealth will not need to calculate traditional margin leveraged account levels_

## **Task 2** - Partner Buying Power Check is complete

  • **Partner must account for calculating and maintaining buying power on their side **

  • **Journals for wallet funding are appearing correctly through Drive Hub**

  • ignoreBuyingPower should be true so deposits should automatically be approved

### Determining when to Debit / Credit Client Wallet

**Debiting (buy orders)**

EventDescriptionAction
orders.createdThe `payload.amountCash` indicates the maximum value the order could be executed forPartner should set this value to pending in clients wallet and not allow them to spend it
orders.completedThe `payload.amountCash` indicates the final value of the executed tradePartner should debit this value from the clients wallet, and make available the difference between the `amountCash` in the order.created and orders.completed events.
  • **Partners must ensure clients does not overspend the total amount available in their wallet**

**Rules of Engagement**

  • Partners should utilize notional based order types, or other types that allow for the calculation of final amount owed prior to execution

  • Prior to submitting buy orders the Partner should perform a real-time check of available balance in the customer wallet, this becomes their **buying power**.

    • Upon placing an order the Partner should not allow a customer to submit an order where **buying power** \< **amountCash** "Create Order" API Call.

    • If buying power is less than the amountCash the Partner should immediately reject the order and not send to DriveWealth

  • Throughout the trading day, and overnight if allowing for pending orders, Partners should be using the [events](πŸ”—ο»Ώ) API to debit a customer wallet in real-time the moment an order is accepted.

    • By consuming [order events](πŸ”—ο»Ώ), upon the successful acceptance of an order the following event is sent to the queue:

ο»Ώ
  • Please take note of the `payload.amountCash` property as this will determine the total amount of money that has to be debited or set aside from the customers wallet.

  • **It's possible for the final amount after execution to be less than the `amountCash` value, but will never be more**

  • Due to the above call out, in addition to the `orders.created` event DriveWealth recommends listening to `orders.completed` events

    • The `orders.completed` event contains the final `payload.amountCash` that has to be held aside for settlement. Please take note of other [order workflow and edge cases](πŸ”—ο»Ώ) to act accordingly to the status received.

**Crediting (sell orders)**

EventDescriptionAction
orders.createdUpon receiving this event type the Partner can verify the order was accepted but has not yet been executedDo nothing, since the final execution value is not known it's not possible to calculate value that will be returned to client
orders.completedThis event type indicates the final amount a customer is to receive based upon the executionPartner now knows what amount is to be credited back to the customer using the `totalOrderAmount` property
  • Partners have the option to immediately credit back funds to the customer after a sell order has been successfully `FILLED`. Although generally speaking the amount is to always be returned on settlement date there could be a rare event whereby the money does not settle and is not included in settlement date figures. This then introduces risk to the Partner, however minuscule that may be.

  • Alternatively, Partners can wait until settlement date to return the funds back to the customers wallet that were a result of a sell. This reduces risk even further and does not require the Partner to "front" any cash to the customers wallet.

  • Throughout the trading day, and overnight if allowing for pending orders, Partners should be using the [events](πŸ”—ο»Ώ) API to determine the final amount that will be credited back to the customers wallet. By consuming [order events](πŸ”—ο»Ώ), upon the successful acceptance of an order the following event is sent to the queue:

ο»Ώ

Please take note that for sell side orders Partners want to use the `payload.totalOrderAmount` property as not all sell side orders are submitted in `amountCash` quantities. There may also be `fees` associated with orders, that are described in the [SEC / TAF Fees](πŸ”—ο»Ώ) section.

Clients may also receive dividends and other [corporate action](πŸ”—ο»Ώ) activities that result in a cash balance being applied to the account on settlement date. These transaction types can immediately be applied to a clients wallet balance because they settle same day and are always included in same day settlement balance. In the event of a dividend a Partner would receive the following event message:

ο»Ώ
  • Where `payload.transaction.accountAmount` indicates the cash value that resulted as part of the dividend transaction.

#### For Non-US tax paying individuals, an additional `transactions.created` message is sent for the processing of the dividend withholding amount. In these instances only the Net amount should be applied to the clients wallet

## **Task F3** - Partner Wallet Balance Adjustments are Complete (UX/UI)