Typical Bugs Found in Custodian Statements

There are always bugs in data

1266

image source: Google

Sadly, there are always bugs in data. Canopy process helps to find these bugs and fix them. Below are some samples of bugs we typically find

Inconsistency between API/Datafeed and official month end statements

2500

Inconsistency between API/Datafeed and the official Month-end statement

This is the most frequently found bug. Typically the API/Datafeed is generated by a process that is slightly different from the process that generates the official month end statements. Very often there is a gap of a few hours between the 'snapshot' for month end statement being taken and the API/Datafeed being generated.

Markets of course continue to trade in the mean time and the API/Datafeed snapshot gets updated prices whenever it is run. This generates a material inconsistency between the official month end statement and the API/Datafeed provided by the same bank.

This creates a significant issue for wealth managers and SFOs, where the principal expects a to the cent accurate reconciliation between the official month end statement and reporting generated from the API/Datafeed.

Usual order of magnitude of this inconsistency is about 1% of account value (i.e. a USD 30mm account will show a USD 300k mismatch)

Transactions reported next day

2500

Transactions executed after the data processing cut-off are typically reported the following day

Financial markets typically trade during business hours as per the local timezone (e.g. NYSE is open from 9.30am to 4pm on most days). A typical customer's custodian may not be in the same timezone as the assets that they are buying e.g. a Singapore based customer might be trading in US stocks with a Singapore based bank/broker.

Most banks process data via a batch process (i.e. a 'end-of-day' process is run after business closes for that day). This batch process starts after the cut-off, which is typically 5pm local time.

This means that any transactions done on the same day, but after the data processing cut-off for that bank, will get reported the next day. This causes frequent mismatches

Transaction confirmation contains Order Date as Trade Date

2500

Email confirmation from the bank acknowledging the existence of this error

Some banks have a bug in their system that processes customer's orders. For some reason, in case the order is filled, the transaction is reported with Trade Date = Order Date. e.g. If an order was placed on 15-Apr but got executed only on 20-Apr, the transaction is reported with a Trade Date of 15-Apr (which causes a reconciliation break for the closing positions of 15-Apr)

Margin loans 'disappear' under certain circumstances

2500

Email confirmation from the bank acknowledging the existing of this error

Some banks have a system glitch that shows certain margins loans as having been repaid (and the bank reports a higher networth as a result). This issue is more common for one-off structured trades

Next months opening balance is different from the previous months closing

2500

Mismatch between Opening Balance and previous period's Closing Balance (Sample 1)

2500

Mismatch between Opening Balance and previous period's Closing Balance (Sample 1)

This error is encountered frequently. It is typically due to different parts of the bank systems using Trade Date and Settlement Date as the key metric

Transactions reported in duplicate

2500

Email confirmation from the bank acknowledging duplicate transactions

Sometimes we can transactions missing or reported in duplicate. This typically happens when there is a public holiday in some bookings centers and not in other booking centers of the same bank

Key Transaction Details Missing

2500

Email confirmation from the bank acknowledging missing details