Backdated funds for TMS
We need to report the backdated funds to TMS consistently. Given the same input, in different generation times, we obtain the same output and the results must match.
Problem Description
At this moment, we are reporting the value date of a Current Account Entry (the balance entries), where this date may be in the past at creation time. This produces that if we generate a report for a specific open-close date and after that, a backdated fund is generated, if we re-generate the report with the same open-close date the result will change.
From Finance team, they need a consistent data in their reports, so the value date MUST be always >= at creation time, never before.
Background
Common background
A backdated fund usually happens when we receive funds to be matched against a client balance and for any reason, like the AML or any other screening reason, the fund is held for some days. After all checks are OK, the fund is fully authorised and the entry is created in the client balance, but with the original value date of the physical entry (Bank Account Entry).
At this moment, we have in BOS two database fields for the Currency Account Entries:
- date: Mostly used along BOS and it stores the original value date of the related entry (the Bank Account Entry or the original balance entry if we are doing a reversal).
- value_datetime: Newer field added -that actually has the logic we are looking for in this epic- but only exposed in the BOS API (get_client_transaction and get_client_transactions endpoints).
Specific background
The current base logic which return the value date for an ActualCashFlowDeal message is:
- For the field DealDate, we return the minimum between the date and the creation time.
- For the field ValueDate, we return directly date.
Solution
Modify the ValueDate calculation to return value_datetime instead of date.
Alternatives
Just for the record but we don't encourage going with this alternative in this RFC.
Change the creation of Currency Account Entries to store the proper value in the date field.
Caveats
There are three scenarios where we are sending ActualCashFlowDeal but we don't work with the balance entries:
- Legacy Payment Fee Cash Flow (we work with the payment to generate the message)
- Recon Deals Cash Flow (we work with the Bank Account Entries to generate the message, used for the End of Day Reconciliation report)
- Fee Cash Flow (we work with the related trade to generate the message)
For those scenarios, we would need a specification, or we assume they are out of this scope.
Operation
Current BOS process to send the QXTs.
Security Impact
N/A
Performance Impact
N/A
Developer Impact
The Money On Account report is working as expected for the Finance team at this moment. Even though -as part of this RFC- we will ensure that the figures obtained for both processes are the same.
Data Consumer Impact
Our TMS team might need a historical report of all ActualCashFlowDeal after the changes.
Deployment
Current BOS releases process.
Dependencies
None.