KonradBieniek | UX

Background

The Foreign Exchange business is based on either spot or forward currency contracts. In a forward contract you buy or sell one currency in exchange for another at a specified price for a specified future date. Many times, especially with corporate clients, we have a customer who entered into a forward contract but wants his profit or loss now. Since the client is effectively closing out the contract, the bank would need to net present value the position and close it.

What does an npv involve and what was My role?

In an NPV we are discounting the client's profit/loss and amending the date of delivery to the agreed on present value date (usually within a week of the request). For the Middle Office / Trade Support team at Credit Suisse NPV'ing foreign exchange trades was an additional process to the main remit, secondary to the day to day tasks. While being a part of the Middle office team tasked with this process I engaged myself to find a solution.

Problem:

At many financial intuitions the NPV process is automated, a button can be clicked an in turn it creates related back-end bookings automatically. At Credit Suisse this process was very manual. Because the process is so manual and time consuming, sales and clients were very unhappy about turnaround time. The Middle Office team was burdened because of the individual involvement required and the prospect of monetary losses from trades being rebooked by human hands. 

How might we automate the manual process of NPV'ing foreign exchange forward trades and create a process that is faster and more automated?

Discover

Inquiry

I approached the IT staff to determine if there was any existing tool which could be repurposed to improve the current process. The intention was that if I could pinpoint a way to make the process less manual within an existing framework or with an existing tool, it would be easier to push through than a new build. The IT trading floor team, although very friendly and usually collaborative with my desk, had their own remit at the time and were not authorized to spend time on this project.

Design

Iteratation>>solution

I began looking into other automated booking processes that I came across as a member of the Middle Office team. One day I realized that Credit Suisse had an automated solution for when trades were booked into different branches of the firm. For example, a trade executed by a New York trader for a Japanese client required CS New York to face CS Tokyo so the client would be facing their home branch of CS Tokyo. The solution for this was an automated booking that was initiated when middle office amended the CS New York to an internal client code "CSFB". This amendment would not break any of the risk legs in trading blotters so posed no risk to traders. The tool would then automatically book an additional trade facing the client as well as one trade facing CS New York.

A lightbulb went off in my head. Why couldn't we use this same framework for an NPV booking. Upon breaking down the process it was doing exactly what was needed:

• Amends an existing trade and would effectively cancel it.

• No risk legs were cancelled so no re-bookings were required.

• Finally, the client facing trade automatically created would be the same as our booking against the client with a new value date to the client, completing the process.

Define

Armed with a proposal, a problem in need of a solution and feedback from sales and middle office on the pain points with the current process, I wrote a lengthy email presenting this idea to the COO in New York. I would like to state that the COO in question wasn't too familiar with our NPV process on a granular level.  Even though I had explained each piece to him to the best of my ability the response was to leave this issue to IT and focus on other things; this wasn't part of the Middle Office job description. He left me with the response that he didn't want to risk green-lighting the proposal.

Dejected but still confident the idea would work I reached out to the COO in London. My thought process was that since this London based COO used to work on the same Middle Office team as I it would be much easier to get his buy-in. My hypothesis turned out to be correct, his response was that "the idea is brilliant" and he wished he thought of it years ago. He told me to run with it, gather the information, run testing and he'd help me present it to the NY COO. If it failed it would be my responsibility.

Testing and Working with stake holders:

Step 1: Was to create a dummy code called NPV. This code would mimic the CSFB code I described prior which was used for multiple branch booking. I had to reach out to Compliance/Legal and alert them to what I was proposing. From their point of view I was creating a non-client/non-branch code so I had to ensure this would show up correctly in their systems. Once the process and reasons were explained to their team I reached out to IT to create the code. 

Step 2: Was working with IT to link the current branch booking tool to the newly created NPV client code and have it initiate the automatic booking once that code was entered. The process was fairly simple for IT to complete since it was an existing tool. They were able to clone the process and change the links from CSFB to the NPV code. I tested this with them in a production environment of our booking system.

Step 3: Since IT and I confirmed the physical bookings worked automatically and no risk legs were broken by amending trades to NPV the next step involved testing with OPS. I reached out to the OPS team to follow through their process downstream. I amended a bookingand asked them to ensure the trades would show in their systems. The team confirmed all looked good.

Step 4: Once Ops confirmed they saw the newly created client trade with a new date I reached out to the Settlements team to also confirm that they saw the same on their end and in their systems. Confirmation was received that everything flowed down correctly.

Step 5: Lastly the testing steps were repeated in the live booking environment. 

Delivery

I put together an email and presentation which included all my findings to the COO in New York. My presentation included:

• An explanation of the current process.

• Information gathered from users (Sales and Middle Office) on why there is a problem.

• An explanation of the proposed solution.

• The sign-off from all the teams and stakeholders involved.

• The confirmation of successful testing.

• A business case focusing on the current length of completion changing from days to minutes as well as mitigating of monetary risk by removing any manual bookings.

The old Process vs. new redesigned process

Result and Conclusion

The proposed solution solved for: Time, Risk and Client Relationships. The new NPV process I proposed was adopted by New York, then disseminated to London and Singapore Middle Office teams. Credit Suisse uses this process to NPV foreign exchange trades for clients to this day. The Sales team was very happy with the solution as they were able to promise instant completion of NPVs to their clients highly improving their relationships. The Middle Office teams were able to remove a large workload and because the new process was so easy sales people were comfortable completing it themselves.

Looking back as a UX designer:

Having now trained in UX I can see how important a process is for project success. I was able to loosely fit this endeavor into various facets of my current UX process. The Middle Office and Sales teams were my users in this case and I could have synthesized them into personas. One differentiator however was that I was one of them. The initial proposal was rejected by the COO in New York. The takeaway for me is that putting together my research, testing, sign-offs, a finalized proposal and presenting it logically and cohesively was what ultimately allowed this new process to be adopted and approved.