We created a software package to valuate the Credit Value Adjustment (CVA) of a swap portfolio. Our client, active in banking and capital management in the Netherlands, wanted to evaluate its CVA position for the existing portfolio and see impact of new deals for a given counter party. The tool is specifically designed to consider the distribution of the exposure of a given counter party. This functionality allows for comparison between the regulatory value (BASEL III) and the economic value.
The tools was implemented on the Microsoft platform, using C#, Microsoft Visual Basic for Applications (VBA) and Excel.
The previously-implemented semi-automated business-used prototype of the daily fund transfer price (FTP) for the mortgage domain was moved to production from business to IT departments of a large Dutch bank and became an IT system under FAM responsibility.
The resulting fully-automated application was built on a consistent technology stack, which includes .NET, Visual Studio, C#, SQL-Server, SSIS package, QRM. The tool is accompanied by the corresponding graphical user interface (GUI) which was developed in ASP.NET.
This project turned out to be very challenging, especially because of: i) the interactions among various bank departments, including IT, FAM, FTP Centre and Mortgage Group; ii) the large technology stack involved. In all these cases we were in the lead.
Daily monitoring of liquidity has become a crucial job inside any bank. We implemented the Extract-Load-Transform (ETL) operations of liquidity tools for different trading desks for the modelling and risk-reporting departments in a large Dutch bank, which allows the bank to run its liquidity-monitoring tools daily.
Liquidity input data come from various sources and all have different formats. Some are Excel files, while some others are comma-separated text files. Moreover, date conventions are not standard and depends on external factors, such as Excel settings. In addition, all the different pieces of information have to be adjusted before they can be used. Such adjustments include specific selection and join operations.
Our input tool has been developed in C#. We have created in-memory databases and used LINQ to perform DB operations. The code has been unit-tested. Log text files and Excel output files are created daily. The tool has been accompanied by a self-contained user manual explaining the business logic, configuration setting and command-line arguments, exceptions that may arise during the execution.
Ugly Duckling was asked to give a second opinion on the hour estimation of a large IT implementation project of a financial solution developed by team outside the IT landscape. We started by creating a large detailed list of each activity and sub-activity expected to be carried out during the project. The list contained an optimistic as well as a pessimistic estimate.
The optimistic approach consider that all the (sub-)activities are carried out smoothly with no unexpected delays and/or additional exceptional activities. In the pessimistic approach things go wrong and/or unexpected activities arise, i.e. project risks materialise. The pessimistic approach estimates the extra time to deal with these risks.
Based on the list it was easy for management to assess whether estimations were within realistic bounds and where further investigation was needed.
The need for Multi Curve is becoming more clear in the marketplace. As a result many banks are moving from Single Curve valuation to Multi Curve, or have already done so. For a client we wrote a short paper list some of the pro’s and con’s of implementing Multi Curve. This paper was meant to trigger the discussion in the team and beyond.
We helped a Dutch bank establish a vision on the prepayments level(s) of their residential mortgage portfolio by hosting a series of expert meetings. The goal of the sessions was to establish the prepayment level the bank expects in the near future, that is within a horizon of 10 years. To this end the total prepayment level is split in 3 subparts: refinance, curtailments
and relocation. We prepared a list of key factors driving these subparts, which were refined during the first session. For the consecutive session we provide more data and give insights into the impact of the choices of the experts. The final output of the work was a new set of model parameters to use for the banks prepayment model along with the impact on the balance sheet of the update in parameters.
We derived a model to compute the penalty of Residential Mortgage in the case clients prepay their mortgage. The penalty conditions are described in the terms and conditions posted by the bank. We used these terms and conditions to derive a theoretical penalty. This approach allowed us to make a model, which doesn’t depend on statistical analysis.
For a large Dutch bank we created a detailed plan plus working prototype to replace the manual daily funds transfer prices (FTP) for the mortgages domain process with an automate system.
The resulting prototype achieved automation using the windows scheduler, Visual Basic scripts and Excel (with macro code). This prototype was the first step to automate the process and greatly reduced the workload for the business team charged with producing the daily prices. From an IT perspective this first round of automation was not enough as the prototype model didn’t fulfill the straight through processing required by IT as it still requires manual steps. In the second phase of the project we investigated which steps can be taken to achieve straight through processing. We suggested to migrate the solution to a more technically robust environment using C#, SISS package and SQL-server.
We were asked by a large Dutch bank to help model the pipeline option for their residential mortgage portfolio. We developed a model and implemented it in the bank's ALM software.
The pipeline of the mortgage portfolio consists of those mortgages that have been offered to clients, but not yet settled. Two groups of contracts exist: those with the option to pay the lower of the offer rate and the actual mortgage rate at the day of property transfer and those without. In both cases the client doesn’t need to wait till the end of the offer period before drawing funds. The timing of the funding needs of the client is considered to be independent of the option value. Other factors like delivery dates of the property and personal preferences are considered to dominate over economic considerations in this case. The choice was made to use historical client behavioral data to compute the probability of drawing funds at a certain period. This choice was made over considering new clients homo economicus and using option theory to calculate the economic value of this phenomenon.
Another factor we considered is the fact that the customer has the option not to accept the mortgage offer from the bank and seek funding elsewhere (i.e., not all offers convert to actual sales). We call this the acceptance option. Based on historical data the fraction of those offers that convert to sales are estimated for each period.
We were asked by a large Dutch bank to help with the automatic processing and testing of data. We used our Robot technology as part of the implementation.
Ugly Duckling has developed a number of products that help to process large amounts of data. We were asked by a Dutch bank’s Asset and Liability Management group to use this software to develop a prototype for a Robot that we code-named ‘Jan’.
Jan was able to monitor directories, mark up suspicious data, clean garbage data and, over time, monitor the quality of the data. The Robot Jan was able to do in 30 seconds what an analyst would take hours to do.