Refund of Initial Margin / Margin Call

The trades can have "Initial Margin (Deposit)" or "Margin Call" and these funds can be used in the trades but in case of they are not used, they should be returned to the client account.

Currently, this is happening in BOS but the moment when these funds are returning to the client account needs to change because it is not happening in the ideal moment. So the goal is Ebury is not holding client money longer than necessary and is not either refunding held funds in an early stage.

Prerequisites

Requirements (Scope and Scenarios) are defined in the EPIC Refund Margin Calls / Initial Margins However, they will be included in this document.

Scope

The feature to be redefined will impact all forward products: Window Forward, Fixed Forward, Fixed Synthetic, Window Synthetic Forward and NDF as they all are liable to require both Initial Margin and Margin Call.

Specifically for Margin Call, it will only impact clients under Classic Credit Conditions, where the Margin Call is allocated at trade level, and not at client level.

For both Initial Margin and Margin Call:
When Drawdown Funded and is on value date, check the Drawdown transit to FOFA → this should trigger the refund of both Initial Margin/Margin Call

For a Window Synthetic Forward, the steps are the same, with the only difference that the Drawdown refers to the Settlement (a.k.a. Synthetic Drawdown)

Scenarios

Window Forward, Fixed Forward and Window Synthetic Forward

For both Initial Margin and Margin Call, the expected behaviour is as follows:

  • Create a Window Forward with Initial Margin
  • Create a Margin Call
  • Fund both Initial Margin and Margin Call
  • Create a Drawdown for the full amount (status Booked)
  • Fwd balance gets zero (transit to FOFA)
  • Check no Initial Margin/Margin Call is returned
  • Fund the Drawdown
  • In value date, check the Drawdown transit to FOFA → this should trigger the refund of both Initial Margin/Margin Call
  • Check both Initial Margin and Margin Call are returned

For a Window Synthetic Forward, the steps are the same, with the only difference that the Drawdown refers to the Settlement (a.k.a. Synthetic Drawdown)

For a Fixed Synthetic

  • Create a SYN with Initial Margin
  • Create a Margin Call
  • Fund both Initial Margin and Margin Call
  • Once reaching fixing date, enter the fixing rate and the spot deal
  • Forward balance gets zero (transit to FOFA) → this is done in NDF Log page and it leads to the creation of the Settlement (Drawdown)
  • Check no Initial Margin/Margin Call is returned
  • Fund the Settlement
  • In value date, check the Settlement transits to FOFA → this should trigger the refund of both Initial Margin/Margin Call
  • Check both Initial Margin and Margin Call are returned

For a NDF (Non-Deliverable Forward deal)

  • Create a NDF with Initial Margin
  • Create a Margin Call
  • Fund both Initial Margin and Margin Call
  • Once reaching fixing date, enter the fixing rate
  • Forward balance gets zero (transit to FOFA) → this is done in NDF Log page and it leads to the creation of the Settlement (NDFSettlement)
  • Check no Initial Margin/Margin Call is returned
  • Fund the Settlement
  • If the fixing amount results in favor for the client, the Settlement should transit to FOFA
  • If the fixing amount results against the client, then fund the settlement amount and the Settlement should transit to FOFA
  • In value date, check the Settlement transits to FOFA → this should trigger the refund of both Initial Margin/Margin Call
  • Check both Initial Margin and Margin Call are returned

It can be repeated as many times as products we have.

It can be repeated where the Initial Margin/Margin Call has previously been partially refunded because, when doing Drawdowns, the dealer decided to use part of the available funds.

Reference Documents

Reference Document Location
MCGUIDE Guide to Margin Calls
IMMCEPC EPIC Refund Margin Calls / Initial Margins
ODTRRFC RFC Overdue trades

Problem Description

First, There is to identify the processes which are generating the refund movements.

Refund of Margin Call

In case of Margin Call there is to analyse where BOS is executing settlements.facades.money_workflow.MoneyWorkflowFacade.funds_from_margin_call_to_client

Please keep in mind that this problem is affecting to Classic Credit Conditions, for Dynamic Credit Conditions the logic is different and the funds cannot be returned using this process.

Refund of Margin Call (Processes)

Roll Facade

When a Roll is created for a Forward, this process refund the Margin Call of the original forward to the client account

Refund Margin Call (Manual Process)

It is a view in BOS where a user with Management permission can refund a specific Margin Call but this option is not available for these cases:

  • The Margin Call is not verified
  • The Margin Call has not balance
  • The Margin Call has not funds in
Verify Settlement

Method for verifying a settlement instance (FXSettlement or NDFSettlement, where the user needs Operations permission. If it is last settlement and there is amount available to be refunded to client balance, the Margin Call is refunded).

Authorise New Settlement

An specific view, where the user needs Operations permission, to verify a NDF or Synthetic deal and send an email after verifying it and also, do extra action like set the fixing rate in the broker deal. If it is last settlement and there is amount available to be refunded to client balance, the Margin Call is refunded.

Drawdown: Save process

Every time that a Drawdown is updated with the method save if the balance available (which rests to be funded out) in a Forward Deal is zero, the Margin Call is refunded if it is partially or fully funded.

Delete Deal

The delete deal view refund the Margin Call if

  • The deal is unreconciled and the funds are received from a Margin Call.
  • The deal to delete is a Forward deal and the Margin Call is partially or fully funded.
State Machine: Forward deal closed action

When a Forward deal is closed, if it has Margin Call and it is partially or fully funded, this Margin Call is refunded.

State Machine: Non-Deliverable and Synthetic Forward deal closed action

When a Non-Deliverable or Synthetic Forward deal is closed, if it has Margin Call and it is partially or fully funded, this Margin Call is refunded.

Refund of Initial Margin (Deposit)

In case of Initial Margin there is to analyse where BOS is executing settlements.facades.money_workflow.MoneyWorkflowFacade.funds_from_initial_margin_to_client

Refund of Initial Margin (Processes)

Roll Facade

When a Roll is created for a Forward, this process refund the Initial Margin of the original forward to the client account

Verify Settlement

Method for verifying a settlement instance (FXSettlement or NDFSettlement, where the user needs Operations permission. If it is last settlement and there is amount available to be refunded to client balance, the Initial Margin is refunded).

Authorise New Settlement

A specific view, where the user needs Operations permission, to verify a NDF or Synthetic deal and send an email after verifying it and also, do extra action like set the fixing rate in the broker deal. If it is last settlement and there is amount available to be refunded to client balance, the Initial Margin is refunded.

Refund Trade Deposit (Manual Process)

It is a view in BOS where a user with Management permission can refund a specific Deposit. But this option is not available for these cases:

  • The Trade is deleted
  • The Trade is Closed
  • The Trade is Cancelled
  • The Trade is not verified
  • The Deposit of the trade is deleted
  • The Deposit of the trade is Closed
  • The Deposit of the trade is Cancelled
  • The Deposit of the trade has not funds in
  • The Deposit of the trade has preload funds in (pending to be authorised)
  • The Deposit of the trade has not balance (it is used)
  • The Deposit of the trade has not balance (it is used)
Refund Deposit (Manual Process)

It is a view in BOS where a user with Management permission can refund a specific Deposit. But this option is not available for these cases:

  • The Forward deal has not deposit
  • The Deposit has been used
  • The Deposit has not been funded
  • The Deposit is partially funded but not all Drawdowns have been created
  • The Deposit is partially funded but the Deposit balance in zero (it has been used)
Delete Deal

The delete deal view refund the Initial Margin if

  • The deal is unreconciled and the funds are received from the Deposit.
  • The deal to delete is a Forward deal and there is deposit balance.
State Machine: Forward deal closed action

When a Forward deal is closed, if it has Initial Margin and it is partially or fully funded, this Initial Margin is refunded.

Once all cases have been checked, there are some processes where the funds are refunded.

  • When the Settlements are verified / authorised
  • When the trades are deleted
  • When the trade are closed
  • When a Roll is done
  • Manual process
  • When a Drawdown is updated (Only Margin Calls)

Basically the funds will be refunded when a Settlement is verified/authorised and when the trade is closed (deleted, closed or rolled), so if the conditions are not the correct when the settlement is verified, there is to wait until the trade is closed or refund it manually and then Ebury is holding client money longer than necessary.

Also, this will affect the RFC Overdue trades because according to the points where the Margin Call is refunded, This will refund all Margin Call related to these overdue trades causing if the client won’t pay the Drawdown, Ebury will find ourselves without the margin call amount.

Background

What is an Initial Margin? and Why Ebury use it?

An Initial Margin, usually known as Deposit is a request for funds, to be held as a deposit against your forward contracts. They are defined in the Credit Conditions of the client and it is a percentage of the original Forward's amount.

The deposit is individual for each Forward and it is assigned in the creation process. Also, these funds can be used in the Drawdown of the forward, always the corresponding percentage of the Drawdown's amount. In case of not all amount is used, they will be returned to the client account.

This is a way to protect the high risk transactions.

What is a Margin Call? and Why Ebury use it?

A Margin Call is like the initial margin, a request for funds, to be held as a deposit against your forward contracts. But it is triggered if the exposure of a forward contract exceeds the agreed variation margin.

The deposit enables you to maintain your forward position at the agreed rate. Ebury offers uncommon flexibility around margin calls but generally they are required to be paid within two business days.

Businesses with multiple forward contracts often employ net positions to reduce their likelihood of being margin called. The exposure across their forward positions is collated to create a cumulative risk position, so that positive P&L on some contracts can help offset exposure on others. Margin calls are calculated differently for forward contracts and net positions.

Solution

First, according the scenarios these are the workflows required for each case:

Refund of Initial Margin (Processes)

Once knowing this and to avoid that any of the current processes (except the manual one) affect this requirement, the proposal is to move the logic of the Refund process to a service instead to have different processes to do the refund (Currently: MaringCallDepositMovementService.refund_deposit_to_client, MarginCall.refund, Deposit.refund_deposit and ForwardDeal.refund_deposit). Thus we avoid having different workflows/conditions to refund the Initial Margins and Margin Calls and help to manage and update the conditions when it will be necessary apply the refund.

Also, as this process is independent of the trades workflows in some cases, these processes will trigger the refund process that will be executed in a Celery queue and it will be executed synchronous for the cases where it is mandatory for the workflow (Example: delete deal)

So the new process for the current workflows is

Refund of Margin Call

Refund of Margin Call (Trigger)

Refund of Initial Margin (Deposit)

Refund of Initial Margin (Trigger)

Also, in order to apply the new requirement, we need to trigger the refund process when the Drawdowns and Settlements transit to FOFA status (Funds Out Full Allocated). Then following ths previous schemas, there is to include:

Refund of IM and MC (New Trigger)

And finally, as the trades can reach FOFA status before of value date, there is to execute a periodic task every day at 00:00 to check these trades and execute the refund process.

Refund of IM and MC (Periodic Task)

About the refund logic, it will contain all necessary checks before to move the funds from the Initial Margin and Margin Call. So the current logic in MaringCallDepositMovementService.refund_deposit_to_client, MarginCall.refund, Deposit.refund_deposit and ForwardDeal.refund_deposit will be moved and merged to RefundMarginCallInitialMarginService

Alternatives

Alternative 1: Same Logic without Celery

Basically, the idea of this alternative is similar that the previous solution, merging the logic in a new service and call this service each time that it is necessary to check if there is to do a refund of the Initial Margin and Margin Call.

Avoid creating a Celery queue, but the cases of the trades transits to FOFA before value date, the refunds should be done manually.

Alternative 2: Add the new cases for FOFA transition

Left the current workflows and add the execution of the refund process when the trades transit to FOFA in value date.

Refund of Margin Call

Refund of Margin Call (Alternative)

Refund of Initial Margin (Deposit)

Refund of Initial Margin (Alternative)

Caveats

This change only affect the trades related to Initial Margins and Margin Calls (Forwards) and in specific, there is a change in the trigger for Drawdowns and Settlements.

Operation

Remember: Specifically for Margin Call, it will only impact clients under Classic Credit Conditions, where the Margin Call is allocated at trade level, and not at client level.

The current workflows will trigger the refunds process as usual and two new trigger will be included:

  • When the trade transit to FOFA (Drawdowns and Settlements).
  • Every day at 00:00 for trades (Drawdowns and Settlements) with value date today.

A new celery queue will manage the tigger and run a service which checks the conditions and refund the Initial Margin/Margin Call if it is necessary.

Additionally, the trigger will accept a parameter to execute the service in that transition in case the process and the refund have dependency.

Security Impact

Create a new Celery queue and move the refund logic to a service, so it has not a security impact.

Performance Impact

Performance impact is similar that the current one due to the logic is already executed in some workflows. There is only to add the queries to load the deal (the asynchronous process need to load the trade and the Initial Margin/Margin Call, but the last one will not load in the current workflow) plus the executions when the trades (Drawdowns and Settlements) transit to FOFA and the periodic task at 00:00 (but this will be executed one time per day)

There is to keep in mind the instance where the queue will be assigned to avoid overloading the instance (but there is not a performance impact of this specific case, it is applicable to all new queues)

Developer Impact

Only to keep in mind if any new process needs to execute the refund of Initial Margin and/or Margin Call, there is to use the new trigger. Also, edit the service's logic if the new requirements does not match with the current logic.

Data Contracts

The fund movements are already created by the current workflows. Then this will have not an impact.

Data Sources

NA

Deployment

First there is to create the new celery queue and migrate the logic to a new service.

Once this part is done, it is possible to migrate the workflows to the async process adding the new workflows for FOFA status.

Dependencies

NA