OTC Credit/Equities Derivatives Workflow Testing Approach

In the evolving OTC derivatives industry, more and more Financial Institutions are inclined towards developing their own infrastructure to manage the OTC derivatives workflow to maintain the efficiency and accuracy of the workflows involved.

Here, in this article we will be discussing about testing the Credit Derivatives which constitutes more than 50 percent of market volume and Equity Derivatives which constitutes 5-10% of the total market volume.

Here is a typical structure of the Reconcilliation system X which is the system under analysis

Please note that DTCC is the Reconciliation and Confirmation system used for the Credit and Equity Derivatives. The Data is communicated to and fro to DTCC is in the form of xml's.

Test Approach 

There are a few workflows that are most commonly used in the Credit and Equities Derivatives -

1. New

2. Amend

3. Termination or Buyout

4. Increase

5. Exercise

6. Novations or Assignment

Each of these 6 workflows are very important because of their business importance. Now, we also have different products in the OTC Derivatives industry like CDS, LCDS, Index CDS, Equity Swap, Equity Index Swap etc and these 6 workflows need to be tested on each and and every product which would make the size of the test suite like the alps. To reduce the size, we need to follow the following approaches -

• Risk Based Testing
• Smart Testing where mix and match the workflows and scenarios because testing every workflow on every product is very difficult
• Automation by uploading bulk deals in DTCC and the upstream trading system for the deals to reconcille
• Automation using tools like QTP, Winrunner etc 

I will now take the example of a "New" or "Direct" workflow to explain the test cases required in the test suite -

• Party A books, Party B books. Deals matched
• Party A books, Party B books. Deals mismatched
• Party A books, Party B books. Deals mismatched, Party A modifies, Deals Match
• Party A books, Party B books. Deals mismatched, Party B modifies, Deals Match
• Party A books and cancels
• Party B books and cancels
• Party A books, Party B books. Deals mismatched, Party A cancels
• Party A books, Party B books. Deals mismatched, Party B cancels

Similarly we can also write these tese cases for other workflows as well

Gotchas

Since the data is communicated in this model in the form of xml's, there are mainly 2 kinds of code changes

1. Mapping of xml's

2. Coding of Workflows

Mostly the issues would surround the mapping changes as there are a lot of tags in the xml and the trick is to find the correct one, the issues around workflows would be incorrect handling of an event or unable to handle an event.

Defect Life Cycle

Explanation :
1. When anything thats a deviation from usual behavior/requirement occurs, a tester raises a defect which is in "Open" state. The tester should check in the available prod like environment if this defect is already existing in the production environment before marking the affected version.
2. If this issue is already present in production, then the first step is to check if this issue has already been reported in the previous releases, if not raise and mark the affected version as the current version and the production version in the defect details. Note that if a defect is already in production it may be deferred to the next release based upon the decision from business.
3. If this is not an existing issue in production, then its a new defect based on the code changes from the current release in which case the affected version can be marked as the Current relese version
4. After the tester has raised the defect and assigned to the release owner, the release owner would then assign this defect to the concerned developer who woul start the analysis of the defect
5. If in the analysis, the defect is found to be already reported then the defect is marked as duplicate and closed OR if the developer is unable to replicate the issue, then the developer should discuss it with the tester and if not reproducible then close it
6. After identifying the root cause of the defect, the developer starts fixing the code then the status of the defect is "In Development"
7. When issue is fixed and unit test cases passed, Developer should mark the defect as Development Complete and assign it back to the Release owner
8. The release owner would then check in the fix in the next build and after the deployment in the testing environment assigns it back to the tester
9. Tester would test the defect again based on all the positive and negative scenario around it
10. If the functionality is working fine after the fix, then the developer can mark the defect as closed OR if the defect is still persisting then again re-open the defect and assign it back to the developer