Release Notes Treasury Release Package January

V 1.0 (2014-03-22)

Release Notes TRP2014-Jan

Table of Contents
Part 1 Newsletter____________________________________________________________ 4 Part 2 Release Note __________________________________________________________ 5
General Description ________________________________________________________________ 5
General _________________________________________________________________________________ 5 New Features ___________________________________________________________________________ 5 Modifications/Enhancements of Existing Features _____________________________________________ 6 Bug Fixing ______________________________________________________________________________ 7 Short Term ______________________________________________________________________________ 8 New Features ___________________________________________________________________________ 8 Modifications/Enhancements of Existing Features ____________________________________________ 10 Bug Fixing _____________________________________________________________________________ 10 Frequently Asked Questions ______________________________________________________________ 11 Bonds __________________________________________________________________________________ 12 New Features __________________________________________________________________________ 12 Modifications/Enhancements of Existing Features ___________________________________________ 12 Bug Fixing ____________________________________________________________________________ 13 Known Issues __________________________________________________________________________ 14 Loans __________________________________________________________________________________ 14 New Features __________________________________________________________________________ 14 Modifications/Enhancements of Existing Features ___________________________________________ 15 Bug Fixing ____________________________________________________________________________ 15 Swaps__________________________________________________________________________________ 15 New Features __________________________________________________________________________ 15 Modifications/Enhancements of Existing Features ___________________________________________ 16 Bug Fixing ____________________________________________________________________________ 16 Exposure _______________________________________________________________________________ 17 New Features __________________________________________________________________________ 17 Modifications/Enhancements of Existing Features ___________________________________________ 17 Bug Fixing ____________________________________________________________________________ 17 OCP ____________________________________________________________________________________ 18 New Features __________________________________________________________________________ 18 Rates and Prices ________________________________________________________________________ 18 Modifications/Enhancements of Existing Features ___________________________________________ 18 Payments ______________________________________________________________________________ 19 New Features __________________________________________________________________________ 19 Bug Fixing ____________________________________________________________________________ 19 Accounting _____________________________________________________________________________ 19 Bug Fixing ____________________________________________________________________________ 20

2|Page

Financial Applications

Release Notes TRP2014-Jan

Reporting ______________________________________________________________________________ 20 New Features __________________________________________________________________________ 20 Modifications/Enhancements of Existing Features ___________________________________________ 20 Bug Fixing ____________________________________________________________________________ 21 SWIFT _________________________________________________________________________________ 21 Modifications/Enhancements of Existing Features ___________________________________________ 21 Bug Fixing ____________________________________________________________________________ 21 Hints _________________________________________________________________________________ 22 It is necessary not only to enable the SWIFT functionality (standard parametrisation script), but also to define the code for the Logical SWIFT Terminal (country-specific parametrisation sript), before being able to generate Swift Messages. ________________________________________________________________ 22

Part 3 Country-Specific Tools _________________________________________________ 23

New Features __________________________________________________________________________ 23 Modifications/Enhancements of Existing Features ____________________________________________ 23

Change Control ______________________________________________________________ 25

3|Page

Financial Applications

Release Notes TRP2014-Jan Part 1 Newsletter

This is the first Treasury Release Package in 2014, and we are trying to improve the way we document the announcement. In previous years, the Release Notes were containing details necessary for the Business Departments as well as for the IT Department, and the official announcement was made via a short eMail containing a short description of mayor topics. Now, the shipping to the Banks will be made through the Regional Offices, via Help Desk for Maintenance/Support Projects, and via the Project Platform Gemini for the Implementation Projects. And, the documentation has been separated in two main documents, this Newsletter_ReleaseNtesTRP214-Jan.docx, for the Business Departments, and a separated UpgradeGuide_TRPOct2013 _TRPJan2014.docx for the technical details related to the specific Upgrade Process, but also to Tool availability and versions and integration/compatibility questions. The following major topics are included in the Treasury Release Package January 2014, developed till end-of-January, and tested and bug-fixed in February and the first weeks of March: With the purpose of increasing work efficiency, all Tickets sent to Back Office for confirmation are now collected in a single List of Pending Confirmations and can be Reviewed, and Confirmed/Rejected from inside this list. Previously this feature was available for Loans and Bonds, but not for Short Term Tickets. For Asset-side Bonds, the handling of Custody Accounts has been included and the registration of the Payment Agent has been removed. All Forms used for Bonds and Loans have been reviewed and improved, based on Users feedback. Guarantors can now also be registered for Bonds. FX Swaps are now handled with a special Ticket Format, including all details for the Near Leg and the Far Leg. Via a special new mode in List Tickets, the daily monitoring and reporting needs for Swaps can be covered, and further details accessed in an user-friendly way. The report used for monitoring of the Open Currency Position now includes also the daily impact of interest accrual for Interbank Loans. The new version of the Accounting Balances report include not only accrued interests for all products, but also accrued taxes, and a new currency filter combined with the possibility to see the total net balance by currency for all balances related to Treasury Deals and Accounts. The number of decimals to be used for interest rates, exchange rates, prices and payment amounts is now fully parametrisable, in order to adapt better to local needs and changes.

4|Page

Financial Applications

Release Notes TRP2014-Jan Part 2 Release Note

General Description
This part lists the General changes, the ones which are available and can be applied to all countries. They are grouped per Product or per Area, as listed below.

General New Features 1. The number of decimals used for the display/capture of rates, prices, and amounts was reviewed once more, now implemented as fully parametrisable. For payment amounts, now also the amounts in TWA are handled based on the number of decimals defined for the currency of the payment. Our current database standard is 2 for payment amounts, 5 for interest rate codes, 7 for exchange and cash rates and 8 for Prices. There is an upper limitation set to 9 decimals. If the number of decimals is changed, old Deals still will show the rate precision using the old standard, (the create time of the message is relevant). If a new Deal is created, the Remarks always reflect current database settings. An information about the current parameter settings related to the precision is returned by the Mercury Service getInfo(), the key being DealwarePrecision. 2. Up to now, Ticket data was containing the Registration Date. With TRP January 2013, the attribute storing the Registration Date has been changed and in now keeping the Registration Time. The Registration Time is shown in List Tickets, Pending Confirmation and in the Ticket Printouts/Previews for Short Term Tickets (including the new FS Ticket). 3. The Calendar Control, used in different Dealware dialogs for the selection of dates, has been changed in order to be in line with the ISO standard weeks are now starting on Mondays, and not on Sundays, like previously. 4. To make screenshots from Dealware easier to analyse, the DATAVERSION has been included as additional information in the status bar. 5. An additional parametrisable DateAdjust has been created, in order to restrict the number of bank working days between an interest accrual date and the corresponding interest payment date for MM/LN/BN/BO. This restriction is working in both directions, back and forth. A default value of 5, if no specific parametrisation is found. An information about the current parameter settings returned by the Mercury Service getInfo(), the key being DealwareDealDateAdjust.

5|Page

Financial Applications

Release Notes TRP2014-Jan

6. An additional parametrisable MaxReconciliationDiff has been created, in order to restrict the amount differences accepted as normal during Reconciliation of paid amounts with agreed payments. The default value is set to 0.99. The adaptation of the Reconciliation dialog is not yet included in this Release Package. 7. Documentation: Due to frequent questions during installation/uprade of Mercury, especially in combination with the Dealware-Infoware connection, a document Mercury_Server_FAQs.docx has been prepared (ftp.quipugmbh.com /Quipu Software/Mercury)

Modifications/Enhancements of Existing Features 1. User-defined columns in List Tickets. By using a specific substring format in the comments (<ColumnName>=[ColumnContents]), users are able to dynamically add more columns into this dialog. Previoulsy, <ColumnName> was restricted to 7bit ASCII text without special characters and whitespaces and the whitespace being the only allowed separator. Therefore, e.g., userdefined Cyrillic Column Names were not possible. This has been changed now: The column name can contain any character except whitespaces, ;, ,, and *,; additionally, the set of allowed delimiters is now whitespace, ;, and ,. 2. Previously, just an empty page was shown by TWA if logging in with Read-Only access rights. Now, users can login, but cannot do anything more, and a message is displayed to explain the situation, e.g. asking them to ask for a permission change. 3. In the login dialog, where the password can be changed, there is now a help button explaining the password complexity rules, in the same manner as it was displayed up to now after a missed attempt by the user, but allowing an earlier information. 4. In the Account dialog, the Product Type control has been moved up and is located now directly under the Account Type control. This has been made to facilitate the Create if Accounts, where the Product Type represents a kind of Account Sub-type or sub-category. 5. Additional Party Types have been included: CentralBank, DomesticBank, PublicInstitution. They are needed in relationship to the implementation of Automatic Bookings, and in order to make a differentiation between the Institutions ruling a certain currency (FinancialCentre) and the Central Banks acting in a similar role as a Commercial Bank. 6. An additional Account Type has been created: Transitory. This Account Type is needed as counter-account for payments to and from Loro Accounts. Deal Accounts of type Transitory can be created, with the following restrictions: Own Bank as Account Holder as well as Account Provider, Product Type Standard, related to Trade Group TG900 (NoRisk). In TRP January, 6|Page

Financial Applications

Release Notes TRP2014-Jan

there is still no functionality related to this specific type of accounts; instead, as workaround, nostro accounts with OurBank=AccountHolder and OurBank=AccountProvider are used. 7. There is now the possibility to have On-Site and Off-Site ATM balances monitored separately in Dealwares Cash Status Report, but only for Customware.Net Banks having implemented a small database structure change, and only after having installed TwisterCWN Client V.0.6.9 and TwisterUserSrvCWN V.0.6.5. 8. Spanish Translations have been updated, the ones missing in TRP October and also the new ones from this TRP January. 9. Technical: The tool called previously DeleteQuipuUsers.exe, and existing in two different versions for Bankware and for Dealware, is now existing in two variants with different names: DwDeleteQuipuUsers.exe and BwDeleteQuipuUsers.exe 10. Technical: Starting with version 13.52, the Database Maintenance Tool DealwareSQL returns a reliable return code: 0 (no error) or 1 (error). Based on this, instructions like if errorlevel 1 can be used by DBA. For all previous DealwareSQL versions, the usage of the return codes does not make sense at all.

Bug Fixing 1. The Mercury Service getCounterPartyInfo() was not returning updated information after a limit registration; realized during debugging of IW load in PCH (loan failed after a limit update via DW, only solution was restarting Mercury). Fixed. 2. Previously, the crosscheck of access rights during login was not deep enough, the Valid-To-Date was not taken into account. Corrected. 3. For databases parametrised years ago, some Dealware users may not have a defined Short Code. For Users without Short Code it is not possible e.g. to change the Dealer Type. The Short Code is needed only for Front Officer when registering a Trade, before sending this Trade to confirmation by Back Office; in this pre-ticket situation, the temporary Deal ID is constructed based on the TimeStamp and the Short Code. Following change has been implemented: When a Dealer Type is changed, and there is no Short Code, the Short Code field is automatically filled with a short code proposal and the user has the possibility to edit this proposed short code. The Short Code control is enabled in the described way whenever there is a change in the Dealer Type or a change in the Short Name of the Dealer. 4. There is a specific scenario where the user can avoid the forced shutdown which we included for users not shutting down Dealware in the evening, before leaving. If there is an open dialog, with not applied changes, the functionality of the forced shutdown displays in the morning a message 7|Page

Financial Applications

Release Notes TRP2014-Jan

about a Login error and remind the users to shutdown correctly in the evenings, and a Lose Changes? box appears. If the user presses Cancel to this message box, the applications stays open; other open dialogs outside the one with the unsaved changes are closed, but the application not, and the user can continue to make changes/registrations without being correctly registered as logged-in. Fixed (the message box does not appear anymore in this situation and the database is blocked for any writing activity). 5. In the small password dialog used for password changes during login, the [Cancel] button was producing an exception. Fixed in DW 4.3.x and 4.2.x 6. In List Currencies, there is a checkbox (marked by default) used to show only active currencies. This was giving the expected result for cases where Currencies are currently active and for currencies which have never been activated. But, for the special case where a Currency was active for a while, but is not active anymore, the currency was shown under the "active" currencies. Fixed. 7. Some sorting problems have been solved for List Tickets. 8. There was an exception when clicking on the Logo at the Left upper corner, and also a missing graphic in Help > About section, same origin. Fixed now. 9. For several DW installations there was the need to re-set a parameter used for the maximal difference between rates calculated from interest amounts registered by users in the LN/BO/BN Payment Plan and the rates registered by the user for the Tickets included in these Payment Plans. If the gap between the given and the calculated rate is higher than defined by the parameter, it is not possible to send a Ticket to Back Office for confirmation. During the Upgrade to TRP January, this gap definition will be automatically be set to the current default. It may be necessary to change the parameter for cases where Banks do register e.g. Loans with very small amounts and many installments. If there is a need for, your Regional Office will prepare and deliver a compiled script for reparametrisation.

Short Term New Features 1. The new feature refers to Short Term Deals (MM including Rollover, FX, TR, CI, CH, CN): Short-term tickets still not confirmed by Back Office, but already Sent by Front Office are now displayed also in the list of "Pending Confirmations", and - when selected - the "Confirm" button enables. If the "Confirm" button is used or if the selected Ticket is double-clicked, in the List of Confirmations, the Ticket Printout is displayed, with an additional header allowing the registration of a Comment, and the usage of the "Reject" or the "Confirm" button. If the 8|Page

Financial Applications

Release Notes TRP2014-Jan

selected Ticket has already expired, the small dialog "Ticket expired" opens and displays a text like "This Ticket was created 2012-12-17 and is now expired; Ticket status changed from pending confirmation to expired" (this dialog is closed via the "OK" button). If a Ticket changes the status to "expired" like explained, it disappears automatically from the Confirmation List. If the button "Reject" is used without filing in a comment, a small dialog pops up (called "Reject Ticket") displaying the message "You have to enter a reason remark for the Reject". (The button "Confirm" can be used with empty comment). If "Yes" is used, a message pops up displaying "This Ticket was created 2013-07-12 and is now expired; Ticket status changed from pending confirmation to expired", and the Ticket ID in the header is shown as "TR61961/1 [expired][Rejected]". If a comment is entered and then the "Reject" button used, a message (called "Reject Ticket") is shown displaying a message like "Ticket TR-61961/1 was registered 2013-07-12. If you reject this Ticket it will immediately expire. Do you want to proceed?"; the buttons "Yes" and "No" can be used. Remarks are created automatically displaying the status change during the reject, the reason, and the status change during the expiration. The number of Tickets shown in "Pending Confirmation" and the number of Tickets shown in "List Tickets" is equal, if Status = "pending confirmation" and the correct period FromDate ToDate is selected. From "List Tickets", if the button "Ticket/SWIFT..." is used, a very similar Ticket Printout is shown as when using the "Confirm" button in "List Confirmation" (to be tested for each Ticket type) - the difference is only the Header part in the Confirmation dialog. From "List Tickets", if the button "Open Ticket..." is used, the Ticket dialog is opened. A ticket in status "pending confirmation" opened by a Back Officer (or a Demo User not having created this ticket as Front Officer) via the "Open Ticket.." dialog from "List Tickets", will show buttons "Confirm", "Reject" and "Ticket/SWIFT" (as long as the ticket is not expired). If "Confirm" is used and the Ticket is confirmed, an opened "Pending Confirmation" dialog will NOT be refreshed automatically ... if this ticket is opened from the Confirmation List without a refresh, the Ticket Confirmation dialog will open displaying the message "ERROR: Ticket status Confirmed but Pending Confirmation required" (after closing the message, the "Confirmation List" will not anymore contain this ticket). If "Reject" is used and the Ticket is rejected, a message like "Ticket MM-30743/1 was registered 2013-12-09. If you reject this Ticket it will immediately expire. Do you want to proceed?" is shown, if "Yes" is chosen, a small dialog called "Reject Remark for Ticket MM-30743/1" is displayed and can be used for the mandatory registration of a reject message. A "Reject" changes the status of a Ticket to "Under Negotiation" (will immediately expire if opened later than on Registration Date) and changes the status of the related Entries to "Deleted".

9|Page

Financial Applications

Release Notes TRP2014-Jan

A ticket in status "pending confirmation" opened by the Front Officer we can have different scenarios. On the Registration Date, the same Front Officer can make a Cancel/Storno as long as the Ticket has status "Pending Confirmation"; other Front Officer need to be working in "maintenance mode" in order to use the Cancel/Storno button . Outside the Registration Date (as long as the ticket is not expired), a Ticket in status "Pending Confirmation" can only be Cancel/Storno by a Front Officer in "maintenance mode". An Expire is identical to the usage of the Cancel/Storno button by a Front Officer (just another status set), and very similar to a Delete (Front Office, before sending to Back Office). The default behaviour in "List Tickets" is now changed, a double-click in the grid list is opening by default the DealSwiftReport (for all Ticket types outside Swaps, for Swaps the "old" Swap dialog opens, the one reachable from the menu), same as the button "Ticket/SWIFT...". In order to open the DealTicket dialog, the "Open Ticket..." button needs to be used. TicketList has now two buttons, "Ticket/SWIFT..." and "Open Ticket..." (in general, the only remaining way to open a DealTicket dialog is TicketList button "Open Ticket..."). ConfirmationList is being refreshed automatically when the Confirmation dialog is being closed.

Modifications/Enhancements of Existing Features 1. In Ticket Printouts related to Short Term Tickets (incl. FS), the field Registration Date has been changed to Registration Time. For Tickets already registered with Dealware 4.3.2 or higher, where the Registration Time is captured, the exact timestamp will be displayed. For Tickets registered before, the date and a text message is displayed in the box Registration Time (e.g. 2014-02-20 (Registration Date)). 2. As the menu option Cash Nostro (DealTickets related to cash deposits/withdrawals to/from Nostros) is now required by almost all Banks, this option existing since Dealware 3.8.0 - has been included as standard. The menu option can be removed for specific Banks, on demand, via a compiled script.

Bug Fixing 1. Realized during the testing phase in PCB UKR, but later also mentioned by users in PCB DEU: If Operative System User Names do contain non-7bit-ASCII symbols, TRP April, TRP August, and TRP October have problems with Logins, the attachment of Files to Deal Tickets, the usage of the SWIFT confirmation messages, comments/remarks related to Deal Tickets, and some more features related on one or the other form to paths.

10 | P a g e

Financial Applications

Release Notes TRP2014-Jan

Regarding the topic of using Dealware under Windows 7 or Windows 8 (Russian version), combined with User Names containing Cyrillic characters, there was a need for an additional database structure change (included in UpgradeForRel425, DealwareSQL 13.48) in order to adapt a database field storing a Registry Key for a specific Terminal. Login with non-ASCII OS login name works fine as well as handling files with 'strange' filenames (append, show; literal comments tested as well). The fix has been tested for file handling with Cyrillic, Arabic/Farsi, Greek, Armenian, Japanese (katakana, kanji), Ivrit and 'fancy' letters/filenames. Showing files after double click on them only works if a handling application is registered under Windows OS, e.g. MS Office for Word and Excel files. As Windows XP reaches end of life 2014-04-08, Microsoft will quit any further support for this OS on this day; no changes related to an usage under Windows XP will be made, therefore (see also GITIS). 2. NOT a bug, but maybe looking like a bug before analyzing FX Tickets, effective rate shown in comments: We do have the case of a Deal of 1,000.00 in Currency#1, equivalent to 1,123.46 in Currency#2, based on calculations made with the Rate of 1.1234567. There are 7 digits after the decimal point used for the Rate, but the amounts in Currency#1 and Currency#2 are rounded to 2 digits after the decimal points (as defined/parametrised for payments in this specific currency). The bigger the amounts, the more you will see "effective rates" shown in comments with 7 decimals ... but, as the calculation of the "effective calculated rate" in the Remark section is the rate calculated based on the two amounts, the rounding can be different. Let's go to an extreme situation: We use 1.00 as Currency#1 amount and a DealRate of 1.1234567, giving 1.12 in Currency#2; the calculation of the effective rates gives 1.1200000. This is to explain why the Deal Rate is NOT the same as the effective rate shown in the comments. Frequently Asked Questions 1. calculated effective rate shown in comments for FX Deals, if the Deal involves two Foreign Currencies: For the case of two foreign currencies involved in one FX Deal, he stored official exchange rates are used t identify the average local currency amount, and this single average local currency amount is used to calculate the calculated effective rate. Stored official exchange rates are valid until further notice, but they expire after a certain number of days (parametrizable). A calculation example: EUR 250,000.00 with the stored rate of 10.851297 gives a local currency amount of 2,712,824.25 and USD 337.675.00with the stored rate of 7.00300 gives a local currency amount of 2,699,036.28; we sum up the two local currency amounts, divide by 2 and et the virtual local currency amount of 2,705,930.26; this virtual local currency amount is now used to split the FCY-FCY Deal into two FX Deals involving local currency, EUR 250,000.00 @ LCY 2,705,930.26 gives a calculated effective rate of 10.8237210 and USD 337,675.00 @ LCY 2,705,930.26 gives a calculated effective interest rate of 8.0134160.

11 | P a g e

Financial Applications

Release Notes TRP2014-Jan

Bonds New Features 1. A Guarantor can be captured and stored now optionally - for Debt Securities (GuaranteedBy), similar to the already previously existing Issuer (IssuedBy), when creating or updating a Debt Security. It is also possible to delete previously registered Guarantor. 2. For asset-sided Bonds, a Custody-To and a Custody-From Account can be now optionally captured and stored. Only accounts existing with product type Custody can be selected for this purpose. The mechanism is the same as used for the Deal Accounts involved in money transfers related to a Ticket, referring to the account from which we make outgoing payments, the account on which we receive incoming payment and the counterparty account to which we make outgoing payments. Custody accounts are only available for selection in the corresponding controls, but not in the controls related to standard settlement accounts. 3. BUY and SELL activities for BN-Bonds: The settlement controls of a ticket are now taken out of the BUY/SELL pop-up windows and are shown if required to be selected by the user - below the Payment Plan. Depending on the next item to be sent as a ticket (coupon or buy/sell of principal), the counter-party, counter-party accounts and custody accounts are shown. If the next item is a coupon, only the control WeReceiveOn is shown. As the user selects the counter-party and its accounts, the chosen values are shown in the Payment Plan grid for verification before sending to back office. 4. As temporal solution, until an implementation of a Delete for Debt Securities can be included in TWA, a tool called DeleteUnusedDebtSecurities has been compiled, removing DebtSecurities not related to any Trade, together with the registered Coupon Dates, Prices, and Ratings.

Modifications/Enhancements of Existing Features 1. List Bond Deals has been enlarged with the columns Notional Traded, Trade date, Maturity Date) and allows filtering by Issuer, Currency, ISIN, Counterparty. 2. List Registered Bonds improved, the column Notional has been renamed to Notional Owned, and the report allows filtering by Issuer, Currency, ISIN, Bond Type. 3. For BN-Bonds, the Payment Agent has been removed (Database, Mercury, and TWA). For BOBonds, the Counterparty is called Payment Agent, based on his role, like before. 4. It is possible now to refresh the settlement accounts in a user-friendly way. An extra control has been placed near the [SEND] and [UPDATE] buttons, allowing users optionally to fix a new account for the We receive On part. The account WeReceiveOn can be changed for next next 12 | P a g e

Financial Applications

Release Notes TRP2014-Jan

ticket or all unsent future entries by selecting the account and pressing SEND or UPDATE. Pressing SEND will additionally create a ticket from the next unfixed row of the Payment Plan. The saved changes will be visible in the Payment Plan and in the List of AccountEntries in Dealware. 5. The label of the Deal ID was added for BO-Bonds. 6. When TWA shows a bond where the issuer does not currently have the state Certified Issuer in the database, TWA will show the name of the issuer with the suffix Not Certified Issuer. 7. A review was done related to the allowed Bond Types for BN-Bonds (Senior Bond, Treasury Bill, Commercial Paper, Covered Bond (Public Pfandbrief), Covered Bond (Mortgage Pfandbrief) and for BO-Bonds (Senior, Subordinated (KWG), Subordinated (Other). If a Bond was stored in the database a time ago, and an inconsistent/not-allowed value is retrieved, TWA will prevent the users from pressing other buttons like [SAVE], [SEND], [UPDATE], etc., forcing the user first to select one of the permitted option. 8. Enlarging attributes for BN Mode and BO Mode in List Tickets. The Bond Modes can be reached (as up to now) via selection of BN/BO in the Deal Group control or by using BN/BO as prefix for the search string in Ticket ID Prefix. Additional columns added are not Ticket related, but Deal related: Deal DCF, and Deal Accrual Method. 9. In List Tickets, for BO and BN Modus, Day Count Fraction and Accrual Method has been added as additional information.

Bug Fixing 1. Bug with the cursor when choosing a date. In the example reported, the Maturity Date falls on a Sunday; the cursor was active for Saturday but not for Sunday, and the user was forced to enter manually the date. 2. The Trade Date must now be on or before the Settlement Date of a bond. 3. Previously it was possible to register Starting Date earlier than Trade Date, but not anymore. 4. The First Coupon Date has been restricted to be strictly greater than the Issue Date and less or equal to the Maturity Date. 5. Based on a problem in Beta Test Unit, for a zero bond which could not be saved: Now, an error message is shown when the Bond is Adjusted and the maturity date is on a holiday, causing the [SAVE] button to be disabled.

13 | P a g e

Financial Applications

Release Notes TRP2014-Jan

6. For the case of Bonds with an issued volume of more than 99,999,999.99, in previous versions there was a problem with the width of the columns (all tickets could be seen, but not in a very nice way). Fixed. 7. For bonds with Accrual Method Adjusted, where accrual date and payment date always need to be the same, it was not possible to edit the payment plan but it was possible to edit the Coupon Schedule. But, changing the coupon date to a different one in the Coupon Schedule, changed automatically the accrual date in the payment plan, but not the payment date, leading to an inconsistent situation. Now, changing the coupon date changes the linked payments accrual and payment dates. 8. Additionally, editing the last Coupon date has been disabled, as it needs to be always the same as the Maturity Date. 9. All restrictions related to Blocking Dates during registration of Bonds have been removed. Bonds that are meant to be issued need to have all its dates set to newer dates than the blocking date.. 10. Notional Issued has been changed into Notional Traded, following the Business Requirements. 11. Problems fixed, related to the manual registration of wrong formatted dates (e.g. 2013 -3-12), where the filed for the coupon rates was not getting enabled, and the only possibility to correct was removing the manually types date and selecting the correct date via the Calendar Control. Known Issues 1. As users are allowed to edit the Coupon Schedule, e.g. modifying an interest rate, and as we do not have an automatic update for all related Deals, we may run in an inconsistent situation between an interest rate changed at the level of the Coupon Schedule and an interest rates stored at the level of the Deal, especially if several Deals are related to the same Bond. If this occur, it will not be possible to send further changes done in the Payment Plan (e.g. a SELL) to Back Office for confirmation. A specialized compiled script need to be prepared in these situations

Loans New Features 1. For Loans (and technically also for Bonds, but probably not needed), a new database attribute has been added, allowing the possibility to make a differentiation between payment plans having just one single principal repayment and payment plans initially agreed with several

14 | P a g e

Financial Applications

Release Notes TRP2014-Jan

instalments. This attribute is set automatically in the moment of first registration of a Loan. The corresponding Mercury RPCs have been adapted. Modifications/Enhancements of Existing Features 1. Enlarging attributes for LN Mode in List Tickets. The Loan Mode can be reached (as up to now) via selection of LN in the Deal Group control or by using LN as prefix for the search string in Ticket ID Prefix. Additional columns added are not Ticket related, but Deal related: Deal Init. Rate, Deal Maturity (last principal repayment), Deal First Disb., Deal DCF, Deal Acc.Meth. and Bullet (Yes/No).

Bug Fixing 1. During the registration of a new Loan, it was possible to change the counterparty and/or the currency, without a removal of the data registered before in the We Pay To control. Fixed, now the We Pay To control resets in these cases.

Swaps New Features 1. A special Deal Ticket printout has been implemented for FX Swaps, containing details for the Near Leg as well as for the Far Leg (including the FX Ticket ID and Status) in separated boxes. The FS-Deal ID is now included in the header part and the Ticket Type is displayed as FX SWAP DEAL TICKET. In the box where the activity is shown for FX Tickets, we do have in this case SWAP. Swap Points and Profit/Loss are displayed in a box between the Legs and the Signature part. This Ticket Printout can be viewed from List Tickets (FS mode) as well as Swap using the standard button *SWIFT/Ticket+.This new FS ticket layout includes also the Registration Time (instead of the previously existing Registration Date), displaying a timestamp for Tickets registered with Dealware versions 3.2 or higher. For Tickets registered before the change of the database field was implemented, the date and a text message is displayed in the box Registration Time (e.g. 2014-02-20 (Registration Date). This Ticket Printout can be reached via the button *Ticket/SWIFT+ from the FS-Ticket dialog or from List Tickets in FS-Mode. 2. New mode FS (swap) included in List Tickets. In order to be able to include certain details relevant only for the FX Swap case, this separated mode has been included. This special mode can be reached via selection of FS in the Deal Group control or by using FS as prefix for the search string in Ticket ID Prefix. The mark [ERROR9] is displayed for cases where there is no matching amount between the Near Leg and the Far Leg (should not be the case, but was technically possible before); for these Swaps, the 2 FX Tickets need to be unlinked: Use [Open 15 | P a g e

Financial Applications

Release Notes TRP2014-Jan

Ticket + in order to reach the Swap dialog, remove the warning shown, and Un-link. Additionally to the standard columns Deal Type, Ticket Is, Trade date, Counterparty and Comments, this mode includes: At Deal level: Ccies (e.g. EURUSD), Swap Points (e.g. -0.25), Profit/Loss (e.g. 122.26) For the Near Leg: Near Leg (e.g. FX-20710/1), Value Date, Our Move (e.g. WE SELL EUR), Amount, Cp. Move (e.g. CP BUYS < USD), Amount, Deal Rate For the Far Leg: Far Leg (e.g. FX-20711/1), Value Date, Our Move (e.g. WE BUY EUR), Amount, Cp. Move (e.g. CP SELLS < USD), Amount, Deal Rate

3. Remarks can now be attached to the FS-Ticket itself (new media message type called SwapIndividual). This kind of remarks are created being in the TicketPrintout (similar as we are doing for LN/BO/BN), and stored simultaneously in both FX-Tickets; they are visible from each of the involved FX, marked with the prefix *SWAP+. For this type of remarks, the Print Flag cannot be changed from inside one of the FX-Tickets. Re: messages can be created in one of the FX but are then only valid for this FX (and not visible in the FS or the other FX ticket). The Print Flag can be changed inside the FS Ticket Printout. No additional Re: messages can be created inside the FS (this feature can be added on demand later).

Modifications/Enhancements of Existing Features 1. Reviewed Swap dialog: All references to a Deal for both legs changed to Ticket. FS Swap Ticket ID displayed now additionally above both legs, SwapPoints/Profit/Loss line moved below both legs. *Details+ buttons for both legs removed, new button *SWIFT/Ticket+ created, opening the Ticket Printout for FS. 2. For List Tickets, in modes (all exc. swap) and FX, the underlying FX Tickets are shown instead of the FS-Ticket, but marked like e.g. FX-20710 *FS+. 3. For List Tickets, uniformly for all modes, Short Term Tickets (incl. FS) can be reached via the button *Open Ticket+, and all Ticket Printouts can be reached via the button *Ticket/SWIFT+

Bug Fixing 1. Some minor bugs fixed in List Tickets, for FX Swaps.

16 | P a g e

Financial Applications

Release Notes TRP2014-Jan

Exposure New Features 1. The third grid inside Product-Specific Exposure report has got a button for showing details of the mentioned Tickets, similar as already before existing for Country Exposure and Daily Exposure, but also including information for e.g. Nostros (the Account Statement is shown).

Modifications/Enhancements of Existing Features 1. Counterparties with Exposures but without at least Global Exposures should theoretically - not exist. Previously, they were not shown in Product-Specific Exposure. Now they have been included. When there is no Limit defined, the exposure shows up as negative amount in Free Total Limit. 2. Counterparties without Exposures and without Limits are not anymore shown in the first grid of Product-Specific Exposure. 3. In Product-specific Exposures, when a Trade Group is selected in the second grid, the status shown for the 3rd grid is now displayed as Retrieving data (as it can be quite lengthy to fill the 3rd grid with all the Deals making up the Exposure shown in the second grid).This way the user knows that something is being calculated. 4. In Product-specific Exposure, Daily Exposure, and Country Exposure, the previously displayed Complete Name for a Financial Party has been replaced by the Short Name .

Bug Fixing 1. By mistake, the report Product-Specific Exposure was showing always figures as of today, independently of the Report Date selection in the header part of the dialog. This has been fixed, the specific settlement date is now taken into account for the decrease of an exposure. 2. In previous versions, Nostros being overdrawn were also taken into consideration for the Exposure, with their real (negative) balance, leading to wrong (too low) exposures and high unused limits. Fixed now. 3. A bug was fixed related to the selection of Counterparties shown in the first grid. 4. A bug was fixed related to the parametrization of the Duration Code for Limit Agreements. In the TRP October, the Duration Codes 7D and 14D have been replaced by the corresponding 17 | P a g e

Financial Applications

Release Notes TRP2014-Jan

1W and 2W codes for future processing, but no deep enough analysis made related to already stored Limit Agreements using this code. For PCB ROU, there was a warning LimitAgreement::DurationCode Enum Item undefined shown in the logfile produced during recreate of Backups. A specialized Recoding Script will be prepared for the repair. UpgradeForRel434 also contains the recoding.

OCP New Features 1. The impact of Accrued Interests for LN/BO/BN/MM is now included in Balance Position report. Additionally, the FX Contra Account Balances are calculated based on the Report Day Official Exchange Rates, from the FX Position Account Balances (and not anymore transaction-based as before). A line for totals has been added, amounts are calculated and shown only for Local Currency columns. The Entry Type box in the header has been replaced by the Viewpoint, allowing the selections Include Agreed Entries (default: marked), Include Expected Entries (default: not marked), and Include Accrued Interest (default: marked).The previously existing, right-side button *Trades+ has been replaced by *Show Details+, enabled if there is anything displayed in the grid, opening the Accounting Balances report, carrying over the Report Date and for the case a row in the grid is highlighted carrying over also the Currency from this line. If the checkbox for the accrued interests has been marked, on top of the FX Position Account Balances, the accrued interest for Value Date = Report Date are calculated and added to the displayed amounts (same calculation as in Accounting Balances).

Rates and Prices Modifications/Enhancements of Existing Features 1. TwisterCWN is now importing also the Commercial Rates used in the Banking Module for FX Operations, and storing it in DW database. The report List Account Entries is showing this rate in the comment part. This info is especially important for the case of FC/FC Trades with Customers, not showing any rate in the Rate column of the report. 2. Price Import: When price for a value date and published datetime is available, if the MercuryPriceImport tries to update the price again for same ISIN and if published date is different than the one in the table for the same value date then it updates the price instead skipping (like before). Tool was adapted to import the price together with yield or price alone.

18 | P a g e

Financial Applications

Release Notes TRP2014-Jan

3. There is now the possibility to store Units (e.g. 100, if the official exchange rate is published as: 100 HRK = 25,538697) in the database. All Rate Import tools will be adapted during next weeks, and the way Rates are published by Mercury Services (for consumers like e.g. Infoware, Customware.Net) will be enlarged. But, the List Rates dialog will be adapted only for TRP April.

Payments New Features 1. An additional parameter can now be stored, describing the maximum amount of different allowed for the (later to be implemented) feature of automatic Reconciliation between an agreed payment and a performed payment. Default is 0.99

Bug Fixing 1. TwisterCWN was showing an error when run in RESYNC mode. Fixed in version TwisterUserSrvCWN 0.6.6 & TwisterCWN 0.6.10 2. The initial balance in the report Account Statement, for the case the checkbox include agreed ones being NOT checked, was including the agreed entries in the calculation. Now, also for Banks not being up to date with the confirmation of payments (a situation which is frequent during Implementation Projects), the verification of Balances is possible and accurate. The initial balance calculation is now refreshed every time the checkbox include agreed payments changed.

Accounting Modifications/Enhancements of Existing Features 1. Accrued Interest amounts for MM are now included in Accounting Balances. For the special case that a Money Market has Value Date as well as Maturity Date in the period selected for the evaluation, the accrued interest appears in the Paid in Period column, if the Money Market is still outstanding, the accrued interest appears in the Amount (Value Date End) column. For all other cases, the behavior of the report is the same as already known for Bonds and Loans. 2. Accounting Balances: By Currency Filtering and Total Open Position. In order to improve the link resp. comparison with the Balance Position report, The Type box in the left header part is now separated in two sections, left-handed the Assets and right-handed the Liabilities. A Currency control has been added, default selection (all). If a single Currency has been selected, the new Open Position control displays the total in this currency, for the type of 19 | P a g e

Financial Applications

Release Notes TRP2014-Jan

assets resp. liabilities chosen and displayed in List of Deals. The date selection controls have been cut in width and placed once beside the other. 3. A checkbox Include Taxes exists now in Accounting Balances, default un-checked. By setting a mark in tis checkbox, the accrued taxes are shown as additional component in the List of Deals, for Loans and Bonds, in a very similar manner as it is done for accrued interests.

Bug Fixing 1. Nostro balance bug fixed. Mismatch in the NostroBalance when compared to AccountStatement dialog. The bug was final balance on the blocking date was not included.

Reporting New Features 1. The database has been modified in order to allow the storage of local accounting and reporting criteria, together with their relationship to international accounting and reporting characteristics. The functionality for filling/adapting these criteria via the applications, and the publication of these criteria via Mercury WebServices will be included in the next Treasury Release Package. 2. Another database modification was made to have the possibility to capture the 2-digit alphanumeric country ISO code, needed for official reporting in e.g. ECU. 3. The new WebService getPayment() is now publishing both the incoming payments and outgoing payments. By default, the outgoing payment is returned, by specifying the Payment Type as 'incoming', incoming payments returned and when None, both the outgoing and incoming payments is returned. When comparing to the getOutgoingPayments Call, the prefixes 'Omt' and 'Imt' have been added to all the attributes, in order to have an easier differentiation between attributes related to the incoming money transfers and attributes related to the outgoing money transfers. For Incoming Payments, if existing (and this is the case if a SSI account has been defined for this Counterparty), the Source Account will be also published.

Modifications/Enhancements of Existing Features 1. The Mercury WebService getBalances() is now publishing accrued interest for MM/LN/BO/BN, additionally. The dataset published now is: PrincipalOutstanding', 'AccruedNotPaidInterest', 'DealId', 'Currency', PrincipalContractual', 'AccruedInterestContractual', 'ProductId'.

20 | P a g e

Financial Applications

Release Notes TRP2014-Jan

2. Additional information related to Rollovers (RolloverId, RolloverAmount) for Money Markets is published now also in getMoneyMarketPayments(). 3. Addition information CreatedAsBullet is published in getLoanContracts(), getBondContracts(), getLoanPayments(), getBondPayments(). 4. Additional information InterestTransfer (related to the accrued interest accumulated in the moment of a BUY/SELL activity, part of the payment amount) is published in getBondPayments()

Bug Fixing 1. The Mercury WebService getBondPayments() was not returning the part of the payment related to the accrued coupon in the moment of buying/selling, now fixed. 2. Already in Mercury V.1.5.2.8, but not detected before, and fixed now for TRP October (Mercury V.2.0.2.1) as well as for TRP January: The Mercury Web Services getExchangeRates() and getInterestRate(), getInterestRates() were showing an exception when used. 3. Mercury 2.0.2 was by mistake returning unsigned amounts in getExchangePayments(), detected by the IW/BRP in PCB DEU. Fixed for version 2.0.2.1 (TRP October) and version 2.1.2 (TRP January).

SWIFT Modifications/Enhancements of Existing Features 1. Previously, the SWIFT message for Confirmation of an FX Deal (MT300) and the SWIFT message containing the settlement instruction for the outgoing payment related to an FX Deal (MT202) were generated together. Now, the MT202 part has been removed, as for Banks using Customware.Net the MT202 is generated by the Payments Module (on Value Date). The part related to the Confirmation of the Deal is like before generated by the Treasury Module (on Trade Date). Also included in DW 4.2.5.5. Bug Fixing 1. The generated MT300, for confirmation of FX Deals, was never tested before (but already existing for several years). Now, it was tested by several Banks, and PCB DEU compiled a detailed gap analysis between the implemented MT300 and a modified MT300 accepted by the SWTFT Server. Based on this description, MT300 has been adapted and can now be used to interchange

21 | P a g e

Financial Applications

Release Notes TRP2014-Jan

confirmations with other Banks (tested between PCB ARM and PCB DEU). Also included in DW 4.2.5.5. Hints It is necessary not only to enable the SWIFT functionality (standard parametrisation script), but also to define the code for the Logical SWIFT Terminal (country-specific parametrisation sript), before being able to generate Swift Messages.

22 | P a g e

Financial Applications

Release Notes TRP2014-Jan Part 3 Country-Specific Tools

New Features 1. A new tool for the automatic background import of Official Exchange Rates has been prepared for Colombia: COL: QuipuRateImportForCOL (V1.0.1) 2. A new tool for the automatic background import of Official Exchange Rates has been prepared for Colombia: UKR: QuipuRateImportFoUKR (V1.0.0) 3. A new tool for the historic import of Official Exchange Rates for BNR has been prepared for Romania: ROU: QuipuRateImportForBNR (V1.0.0)

Modifications/Enhancements of Existing Features 1. The Rate Import tool for Ecuador needed an adaptation, the website rates were previously taken from was not working anymore. Adaptations for the new location has been included in QuipuRateImportForECU (V1.2.1). 2. All interest rates needed for NSR purposes as raw data for the calculation of the monthly historical swap curves are now captured additionally with the tool QuipuRateImporForDEU (V2.2.0), taking the data from the Bloomberg FTP and storing them in a separated Rate Stream called Isdafix inside the PCH DW database. The tool runs automatically in the background, capturing USDSwap (published at 20:00), EURSwap (published at 12:30), and USDLibor (published at 13:30) rates. 3. The Rate Import tool for Romania needed an additional function for the Proxy user authentication, to provide encrypted password instead clear text password. Adaptation was included in QuipuRateImportForROU (1.2.0). 4. Mercury Client importing Prices from text files (very similar to the case of the RateImports). Last changes: Yield can also be imported in addition to the price if available, when not only price can be imported skipping the yield information. Adaptation was included in MercuryPriceImport.exe (1.1.0). 5. Mercury password, possibility to specify clear text password instead MD5 password. For Proxy authentication password, possibility to specify encrypted password instead clear text. The creation of encrypted password is described in the user manual delivered together with the tool. Adaptation was included in QuipuRateImportForALB (1.2.0).

23 | P a g e

Financial Applications

Release Notes TRP2014-Jan

6. Mercury password, possibility to specify clear text password instead MD5 password. For Proxy authentication password, possibility to specify encrypted password instead clear text. The creation of encrypted password is described in the user manual delivered together with the tool. 7. Adaptation was included in QuipuRateImportForARM (1.2.0). 8. Proxy authentication password, possibility to specify encrypted password instead clear text. The creation of encrypted password is described in the user manual delivered together with the tool. Adaptation was included in QuipuRateImportForBIH (1.2.0). 9. Mercury password, possibility to specify clear text password instead MD5 password. Proxy authentication included. For Proxy authentication password, possibility to specify encrypted password instead clear text. The creation of encrypted password is described in the user manual delivered together with the tool. Adaptation was included in QuipuRateImportForBOL (1.1.0). 10. Technical Update. Adapted was included in MercuryRateImport.exe (1.1.0). 11. Technical Update. Adapted was included in QuipuRateImportForECB (1.2.0). 12. Mercury password, possibility to specify clear text password instead MD5 password. For Proxy authentication password, possibility to specify encrypted password instead clear text. The creation of encrypted password is described in the user manual delivered together with the tool. Adapted was included in QuipuRateImportForMKD (1.2.0). 13. Technical Update. Adapted was included in QuipuRateImportForNIC (1.1.0)

24 | P a g e

Financial Applications

Release Notes TRP2014-Jan Change Control

Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 1.0 Date Reviser Changes Initial draft updated updated updated updated updated Format updates, only Including last minute changes Final version

2014-01-30 Inga 2014-02-15 Inga 2014-03-11 Inga 2014-03-12 Christian 2014-03-12 Inga 2014-03-15 Sudhakar 2014-03-17 Inga 2014-03-20 Inga 2014-03-22 Inga

25 | P a g e

Financial Applications