Core task is representation of (highly) structured interest rate deals in Murex based on deals in SAP and / or confirmations. In conjunction with this objective comes reconciliation (cash flow, call dates, trade details) as well as hedge effectiveness through consideration of hedge and underlying PVs.

Due to funding being the nature of the client's business, hedging is the main objective of these structured deals. The representation of these in Murex is a process of combining internal (Murex) and / or external (client) models in one or more deals. Multi-phased representations are usually the outcome when using internal models only, and linked trades of single-phased deals are the choice when using external models as well (this is due to limitations in the implementation of the external models).

The majority of the deals are based on IRS. Though, in order to implement structures with conversion options, OSWPs (swaptions) would have to be linked in as well.

My knowledge and understanding of Murex and Flex in technical terms has been helpful in identifying pitfalls (albeit minor, regarding fixing calendars and schedules, etc) in some of the models.

Reconciliation covers hedge deals as well as their underlying bonds / loans that are mainly entered as IRS. Measure for the counterparty PV reconciliation and the hedge effectiveness is basis point difference per nominal. However, this figure is misleading for amortizing / accreting deals (especially for longer maturities) due to the difficulty in devising a standard of how to consider the changing nominal within the calculation.

Business & technical analyst, interface analysis for upgrade of legal database system (LeDIS, product of the German association of public banks

BA, Management Information System for Asset Mgmt division, logical data model, feeds, data ingestion, validation & business rules, Snowflake cloud data platform

CTB, Murex, BO IT, Datamart & MxML Exchange, regulatory reporting

RTB, Murex trading floor support, Datamart, MxML Exchange, all aspects of trading, risk management, reporting, interfacing

C++ Developer, STAR (System for Tower Apron Requests, ATC for aircraft ground movements), software enhancement, tuning and partial redesign

Developer, Murex migration, Risk & Evaluation stream, market data, RTBS, batch imports, various interfaces, Datamart, Flex API, C++

Developer, Murex Flelx API, C++, Datamart, MxML Exchange. credit derivatives, migration interface, process single and packaged trades, generate mirrored risky loan trades

Developer, Murex, multi-curve framework and CSA integration, Pre-trade, Datamart

RTB, Murex trading floor support

Murex MLC test and configuration manager, Global Limits

Integration consultant, greenfield implementation of Global Treasury Management, Datamart, MxML Exchange

BA, IRD structured products migration, trade and market data export interface

Developer, Murex Flex API, inflation swaps/cap/floors, C++, setup of Reuters real-time market data feed

• Redesign and reimplementation of inflation model integration to Murex.

• The proposed new design is an abstraction layer, covering key aspects of both the IR Pricing and the Rate Curve APIs, generic to a great extent, enabling integration of new models by coding only model-specific and relevant logic, with no impact on existing models- code and the framework. Integration of new models does not require Flex interaction.

• On the pricing side, (external) instruments are flexibly associated with multiple (external) pricing models via configuration settings. The configuration file is necessary to facilitate the generic nature of the designed framework, so the code is not changed for minor implementation nuances. 

• Also, consultancy provided in setup and configuration of real-time data across the complete flow from provider to the seesions.

• Code review of the client's implementation. A document concluded the findings conveying tips and best-practice principles related to coding and the Flex API.

• In addition, the basic framework for the client's pricing implementation was designed and implemented. 

• At the client site one development environment was shared among multiple developers hindering development activities due to frequent need of coordination. To overcome this, the Murex server-side development environment was modified to support multiple developers in parallel making the mentioned coordination unnecessary. 

• Also, consulting provided to an extended team regarding real-time configuration and details of interaction between sessions, activity feeders and MDCS (Market Data Contribution Server).

• Murex implementation - description to follow.

• Flex development for Revaluation API, Volatility API, Rate Curve API, GMP, user-defined sensitivities. Consultancy in design and implementation to other teams for Flex. 

• Enhancements to the Volatility API were required in order to use a SABR model implementation for swaptions and cap/floors. The enhancement: among others, to include forward rate and underlying maturity. An improvised work-around was implemented using the Revaluation API. However, final implementation was against a subsequent enhancement of the main binary by Murex specific to Citadel's requirements. 

• The implementation is flexible enough to allow various input and output contexts per currency with regards to the nature of the input ATM volatilities and returned SABR volatility - each being normal or lognormal. Also, due to Murex's idiosyncratic format interpretation of normal and lognormal volatilities, the SABR implementation adjusted input and output format accordingly. (Format of normal volatility is in basis points, lognormal volatility is percentage.) 

• Model curves extensively used. Rate curve assignments necessary to map revaluation based on instrument and desk to a specific model curve. The Rate Curve API was used to provide discount factors and zero coupon rates to Murex. 

• Consultancy in setup and configuration of Murex environments for tuning and streamlining the various environments.

• General Murex configurations (indices, generators, desks, etc).

• Reporting data (cash management) via DAP (feeding data mart) for replication of an mReport.

• Market data (MDCS, activity feeders, subscription rules etc).

• MxML marginally used (very basic import workflow) - minimal MxML import structure for cap/floor, IRS, FRA.

First and main phase of a total of three planned for implementation of Murex 2.11 for Foreign Exchange and Money Markets. Front-to-back STP covering FO, reporting, risk, payments, accounting, settlements, etc.

Joined the project team at the very early stages and functioned as technical architect, provided high level design documents covering all known technical interfaces of the project as well as detailed specifications for some of the interfaces including RTI and Dealing 3000.

Devised conventions (ports, sites, hubs, etc) for configuration of all environments as well as a document laying out the framework for using Murex XML Requests (extensively used in scheduling and automation of EOD). 30 parallel DEV/SIT/UAT environments. Configured and tuned the environments consistently as many components and features were incrementally introduced. Set up MxML and configured many of the non-standard tasks.

RTI: muli-platform implementation. Murex hosted on AIX, driver for interaciton with Reuters Triarch compiled for Windows as AIX is not supported by Reuters. IDN_SELECTFEED and DDS sources used across all instruments (money market rates, swap rates, FX rates all imported via both sources). Also, targeting multiple desks, linked to different market data sets, with a single RTI channel (not possible in 2.10).

Dealing 3000: driver runs on Windows functioning as source task in a dedicated MxML Exchange workflow. Mapping from TOF to MXML DTD implemented in the workflow for FX spots/forwards/swaps and deposits. Deals imported as simple or packaged deals. Financial Engineering principles applied to import linked deals for outright forwards and swaps as well as FX spot deals of Sales. Murex Query/Parser functions called from MxML workflow to retrieve financial data and calculations necessary for the mapping of simple to linked deal structure.

Implemented custom MxML Exchange Task in Java to perform specific database updates against a custom data model. This data model keeps track of imported deals per source system. Any number of source systems supported. Target system is Murex. It also offers a mapping of any value in a source system to a Murex-value. Optionally, the mapping can be fine-grained to any Murex permutation of (family, group, type). This framework is used to keep track of deals imported via Dealing 3000, Reuters Electronic Trading and Logicscope. Mappings of Reuters counterpart codes to a Murex-specific portfolio, as well as Reuters trader codes to Murex users are maintained in this data model. This data is accessed via the mapping-implementation (formulas) in the MxML Exchange workflow.

Configured the Murex middleware to launch (triggered from Unix) a custom C++ process on Windows via a Murex Monitor Script. This approach was necessary in order to overcome a synchronisation flaw in a driver process, randomly preventing it from shutting down.

Technical environment

IBM AIX 5.2, Windows XP, Mx G2000 2.11 (distributed), MxML Exchange, Oracle 9i (9.2.0.5), SQL and PL/SQL, XML (XSL, XSLT, XPath), shell scripting, C++.

Implementation of Murex for Foreign Exchange and Money Markets. This covers all aspects of a front-to-back STP solution for FX Spots and Swaps as well as Loans / Deposits. Configuration of Murex components and technical design and implementation of all necessary components and interfaces needed for interchange to and from Murex to other systems operated by the client. Main technical focus is configuration and maintenance of the MxML Exchange Service to meet the client's needs throughout the pre- and post-production phases.

Among the tasks are also functional and technical specifications, implementation, unit testing, user acceptance testing, technical documentations and user guides.

Technical environment      

Sun Solaris (SunOS 5.9), Windows NT, Oracle 9i (9.2), Mx G2000, MxML, XML (XML, XSLT, XPath), Perl, Bourne and Kourne shell scripting.

Code review of a Bond Pricing System written in C++ for analysis and validation of an algorithm for curve fitting.

Good exposure to Mx G2000, have very good functional and technical understanding of Mx G2000 MxML Exchange Service and Flex API. (Due to my extensive experience with the Xetra VALUES API and the same approach taken in both VALUES and Flex, it was fairly straightforward from a technical point of view to deal with the Flex API.)

Front to back solution for managing ABCP (Asset Backed Commercial Papers) transactions based on Trade Receivables. The system manages Conduits, Transactions, Rollperiods, Issues, Offers and Trades as well as static data and other structures, and all necessary and relevant calculations are successively added to the application. Various types of documents (request for offers from trading groups, trade confirmations, back office accounting reports, etc) are created and sent via email and fax.

Inception of two frameworks mentioned below aiming at separating business logic from the generic tasks of the frameworks themselves.

Messaging Framework: an open framework for sending messages (emails, faxes, chat messages, etc) was designed. The first transport component, an email process (SMTP client) was developed and integrated into the framework. Applications using the Messaging Framework need only to call a stored procedure. (Comma-delimited recipients and attachments are also supported.)

Document Framework: open framework for creating documents - similar to the Messaging Framework, however, with specific variations to meet the differing requirements. The first process to create Excel documents from any template was developed and integrated into the framework. Any Excel template can be configured (introduced) in order for this process to create documents, also supporting sets of consecutive lines that could occur multiple times based on data, as opposed to static, fixed documents.

Technical environment      

Windows NT, MS Visual C++ 6, MS Visual Basic 6. MS SQL Server 7 (back)/ 2000 (front), MS Visual SourceSafe.

Design and implementation of a front to end STP (Straight Through Processing) settlement solution for FX, Exotics and Equity Derivatives. This solution is to be deployed in an Oracle 9i environment on a Solaris/Unix V8.0 platform. The end product is to be used for the global settlements of derivatives products. The design of this solution incorporates object-oriented approaches with advanced use of Oracle 9i object oriented features and C++. Other technologies in use include CORBA, MQ Series, Unix multithreading, IPC (Message Queues, Shared Memory and TCP/IP Sockets) and XML.

The delivered solution will be a dynamic real-time application responsible for all settlement activities for derivative products. The design of the solution is based on a multi-purpose rule based application driven by workflow methodologies. Special features included developing a C++ based XML parser, SWIFT messaging interface for MT102 payments and real-time MQ Series interfaces. Advanced features of Oracle 9i were fully utilized with a particular interest in object types, nested table types, VARRAY types and index-by tables.

Responsible for all main aspects of systems development lifecycle including functional specifications, technical design and architecture, technical specifications, development, documentation, unit testing and UAT (user acceptance testing) activities during the project.

Technical environment

Solaris 8, C/C++, IPC, Oracle 9i, PL/SQL, Pro C/C++, CORBA, MQ Series 5.2, C++ MQI API, TCP/IP, IRC, TOAD Xpert Edition (used primarily for debugging and as a data viewer, not for development), STL, XML (designed and implemented an XML-parser class), SWIFT, ClearCase.

Front-to-end STP solution for FX investment products for the UBS Singapore based business: design and implementation of a complete settlement infrastructure for FX derivatives and structured products. First release was successfully completed in December 2002, with further phase release completed in April 2003. The complete application was built on an Oracle 8i architecture.

The delivered solution was a dynamic real-time application responsible for all settlement activities for FX derivative products. The design of the solution was based on a multi-purpose rule based application driven by workflow definitions.

The technologies used included extensive use of C++, Oracle 8i, PL-SQL, Pro*C, SQL, MQ Series and Solaris multithreading features.

Task:

Responsible for all main aspects of systems development lifecycle including functional specifications, technical design and architecture, technical specifications, development, unit testing and UAT (user acceptance testing), post implementation support, documentation and end-client training activities during the project.

Technical environment      

Solaris 6 / 8, C/C++, Oracle 8i (8.1.6.3), PL/SQL, Pro C/C++, MQ Series 5.2, C++ MQI API, JBuilder, TOAD Xpert Edition (used primarily for debugging and as a data viewer, not for development) , WebSphere Application Server, STL, ClearCase.

Murex real time reporting application. A C++ based process was developed to interface with Murex (Murex Equity Product) for reporting of specific equity trading data. Transport methods supported are FTP and SMTP.

Design and implementation of a C++ process interfacing Murex and a reconciliation database. The feed process was parameterized to a great extent that enabled feeds of the various equity trading transaction types supported by the Murex implementation.

Responsible for all main aspects of systems development lifecycle including functional specifications, technical design and architecture, technical specifications, development, unit testing and UAT (user acceptance testing), post implementation support and end-client training activities during the project.

Technical environment      

Sun Solaris (SunOS 5.6/5.7), SNiFF+ 3.0.1, Sybase, Rogue Wave DBTools 3.0, C++, Xerces, Murex Equity Trading System, Murex OLK API.

Task                       

A C++ based process was developed to interface with Summit extracting trade data into a Sybase database for specific reporting and reconciliation. Later this process was further parameterized to enable additional filtering at application level.

A similar process was developed as a feed to a Sybase database polled by a Web client for reporting of trading activity on the Intranet.

3rd-level support, bugfixes and enhancements to existing C++ processes interfacing Summit and performing similar tasks.

Technical environment      

Sun Solaris (SunOS 5.6/5.7), SNiFF+ 3.0.1, Sybase, Rogue Wave DBTools 3.0, C++, Summit 3.2 (STK).

Task                       

The implementation of a workflow management system for loading products into the Warrant Trading System of Commerzbank. The graphical user interface comprised of instrument trees and spread sheets. The delivered application was a database client enabling DML (Data Manipulation Language) execution. This feature was designed and implemented to make the solution database independent. C++ wrapper classes were designed and implemented for ODBC dynamic column information and dynamic column binding.

Ongoing development of graphical user interfaces for the Warrant Trading System. Most development was undertaken using Visual C++ and MFC.

C++ wrapper DLL's were developed to enable the use of a pricing library implemented as a Visual Basic application.

Implementation of C DLL with only one exported function (with FORTRAN calling convention to support use in Visual Basic environment as well) computing the check-digit embedded in ISIN (International Security Identification Number). Basically, implemented the LUHN Formula (Modulus 10 Double Add Double checksum).

Developed an Adapter to the Warrant Trading System, enabling RTS (socket API) clients to be run against WTS (ActiveX API). Multithreaded, covering real time price feed, quote request handling, etc.

Design and implementation of a shared memory class, ultimately used to convey data, here the trade IDs, from a Sybase database to a Java process (involving JNI), which in turn dispatched audio and visual notifications to clients (trader applications).

Also a small DLL was written used via JNI on the client side to perform the sounds. A utility program was implemented which would run processes, binding them to a dedicated number of CPU's on the system (process affinity mask). This was to ensure that at least one CPU is not blocked and available in case the Java process consumes too much CPU time. (A production problem led to this requirement.)

Exchange connectivity, link from Warrant Trading System to Xetra, linking the quote-based WTS (electronic market making system of Commerzbank for equity derivatives) to order-based Xetra. 2 multithreaded processes make up this application. One provides a constant real time price feed to MISS (Xetra gateway on Commerzbank LAN). Another handles quote requests and all communication to and from either system.

An Interface between the Warrant Trading System and MQ Series was developed to implement the issuer-side of a specification devised by Commerzbank, Deutsche Bank and other warrant trading houses. This allowed major warrant trading companies to directly trade on Commerzbank's Warrant Trading Platform. Responsibilities on this project included the complete design, development and deployment of the application from the issuer side enabling communication between Issuer and Intermediary for off-line trading.

Responsibilities include major on-going support and maintenance as well as new development. All projects involved technical specifications, technical design and architecture, unit testing, system testing, release management support and technical documentation.

Technical environment

Sun Solaris (SunOS 5.6/5.7), Windows NT, MS Visual C++ 6.0, MFC, Win32 API, TCP/IP, Jbuilder, WebSphere Application Server, Sybase, XML, SNiFF+ 3.0.1, Rogue Wave DBTools 3.0, doxygen documentation, Murex OLK API, Xetra VALUES API and GATE (Xetra, wrapper class designed and implemented), MQ Series 5.0.

Enhancement and software correction of a voucher management system for prepaid phone cards. Updated shared memory structures and activation process software. Concepts for statistical functionality introduced and evaluated.

Technical environment

Digital Unix V4.0d, Oracle 7.3.

The implementation of ReCAS (Research Client Administration System). Java Servlets, CGI, DLLs and libraries, embedded SQL, packages and stored procedures with PL/SQL were developed and deployed for this project.

Developed various components on the ReCAS Administration Graphical User Interface. ReCAS made use of various databases, resulting in various production and test systems. Specific settings of the systems are controlled via this administration GUI. Adding new systems was as easy as updating components of the existing. All necessary dynamic software files are generated, libraries created and linked to applications and copied to the respective project directory.

An implementation loaded data into the ReTIS System (Research Time Series). A daemon monitoring process was developed to search specific directories for new data files. These data files were parsed to validate data before database loading.

Technical environment

Windows NT, MS Visual C++ 5.0, MFC, Win32 API, JBuilder, Oracle 8.050, PL/SQL, Netscape Enterprise Server 3.5.1.

The implementation of an interface between InstruNet to Origin. InstruNet is a hardware and software product family, providing an interface from computers to common laboratory equipment for data acquisition and control - it has a C API. Origin is software for technical graphics and data analysis. It facilitates implementation of sophisticated client applications by supporting development of application logic within C++ DLLs.

Technical environment

Windows NT, MS Visual C++ 4.0, Labtalk (scripting language of Origin).