Newsletter Release Notes TRP2014 Jan

8/12/2019 Newsletter Release Notes TRP2014 Jan

1/25

Release NotesTreasury Release Package January

V 1.0 (2014-03-22)


2/25

Release Notes TRP2014-Jan

2 | P a g e

Financial Applications

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 ____________________________________________ 10Bug 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


Bug Fixing ____________________________________________________________________________ 15Swaps__________________________________________________________________________________ 15

New Features__________________________________________________________________________ 15


Bug Fixing ____________________________________________________________________________ 16

Exposure_______________________________________________________________________________ 17

New Features__________________________________________________________________________ 17


Bug Fixing ____________________________________________________________________________ 17

OCP____________________________________________________________________________________ 18

New Features__________________________________________________________________________ 18

Rates and Prices ________________________________________________________________________ 18Modifications/Enhancements of Existing Features ___________________________________________ 18

Payments ______________________________________________________________________________ 19

New Features__________________________________________________________________________ 19

Bug Fixing ____________________________________________________________________________ 19

Accounting _____________________________________________________________________________ 19

Bug Fixing ____________________________________________________________________________ 20


3/25


3 | P a g e


Reporting ______________________________________________________________________________ 20

New Features__________________________________________________________________________ 20


Bug Fixing ____________________________________________________________________________ 21

SWIFT _________________________________________________________________________________ 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


4/25


4 | P a g e


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 theBusiness 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_ReleaseNtes-

TRP214-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 confirmationare 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 ofthe 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 andthe 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 impactof interest accrual for Interbank Loans.

The new version of the Accounting Balances report include not only accrued interests for allproducts, 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 paymentamounts is now fully parametrisable, in order to adapt better to local needs and changes.


5/25


5 | P a g e


Part 2 Release Note

General Description

This part lists the General changes, the ones which are available and can be applied to all countries. Theyare 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 reviewedonce 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, theattribute storing the Registration Date has been changed and in now keeping the Registration

Time. The Registration Time is shown in List Tickets, Pending Confirmationand 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 beenchanged 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 asadditional information in the status bar.

5. An additional parametrisable DateAdjust has been created, in order to restrict the number ofbank 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.


6/25


6 | P a g e


6. An additional parametrisable MaxReconciliationDiff has been created, in order to restrict theamount 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 incombination 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(=[ColumnContents]), users are able to dynamically add more columns into this

dialog. Previoulsy, was restricted to 7bit ASCII text without special charactersand whitespaces and the whitespace being the only allowed separator. Therefore, e.g., user-

defined 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 explainingthe 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 nowdirectly 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 ascounter-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,


7/25


7 | P a g e


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 inDealwares Cash Status Report, but only for Customware.Net Banks having implemented asmall 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 onesfrom this TRP January.

9. Technical: The tool called previously DeleteQuipuUsers.exe, and existing in two differentversions 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 areliable 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 limitregistration; 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-Datewas not taken into account. Corrected.

3. For databases parametrised years ago, some Dealware users may not have a defined ShortCode. 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 forusers 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


8/25


8 | P a g e


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 andthe database is blocked for any writing activity).

5. In the small password dialog used for password changes during login, the [Cancel] button wasproducing 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 maximaldifference 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


9/25


9 | P a g e


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 "TR-

61961/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 automaticallydisplaying 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" ischosen, 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".


10/25


10 | P a g e


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 onlybe 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.


1. In Ticket Printouts related to Short Term Tickets (incl. FS), the field Registration Date has beenchanged 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/fromNostros) 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: IfOperative 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.


11/25


11 | P a g e


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; literalcomments 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 incomments: 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 ForeignCurrencies: For the case of two foreign currencies involved in one FX Deal, he stored official

exchange rates are used t identify the average local currencyamount, 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.


12/25


12 | P a g e


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 ofthe 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 inTWA, a tool called DeleteUnusedDebtSecurities has been compiled, removing DebtSecurities not

related to any Trade, together with the registered Coupon Dates, Prices, and Ratings.


1. List Bond Deals hasbeen enlarged with the columns Notional Traded, Trade date, MaturityDate) 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 BO-Bonds, 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 hasbeen 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


13/25


13 | P a g e


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, TreasuryBill, 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 Modescan bereached (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 addedas additional information.

Bug Fixing

1. Bug with the cursor when choosing a date. In the example reported, the Maturity Date falls on aSunday; 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 errormessage is shown when the Bond is Adjusted and the maturity date is on a holiday, causing the

[SAVE] button to be disabled.


14/25


14 | P a g e


6. For the case of Bonds with an issued volume of more than 99,999,999.99, in previous versionsthere 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 needto 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 sameas the Maturity Date.

9. All restrictions related to Blocking Dates during registration of Bonds have been removed. Bondsthat 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 BusinessRequirements.

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 donot have an automatic update for all related Deals, we may run in an inconsistent situationbetween 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 attributehas 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


15/25


15 | P a g e


instalments. This attribute is set automatically in the moment of first registration of a Loan. The

corresponding Mercury RPCs have been adapted.


1. Enlarging attributes for LN Mode in List Tickets. The Loan Mode can be reached (as up tonow) 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), DealFirst 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 thecurrency, 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 theNear 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 detailsrelevant 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


16/25


16 | P a g e


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 SELLEUR), 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 BUYEUR), 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 calledSwapIndividual). 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 cannotbe 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).


1. Reviewed Swap dialog: All references to a Deal for both legs changed to Ticket. FS Swap TicketID 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 insteadof 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 thebutton *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.


17/25


17 | P a g e


Exposure

New Features

1. The third grid inside Product-Specific Exposure report has got a button for showing details ofthe 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).


1. Counterparties with Exposures but without at least Global Exposures should theoretically - notexist. 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 ofProduct-Specific Exposure.

3. In Product-specific Exposures, when a Trade Group is selected in the second grid, the statusshown for the 3

rdgrid is now displayed as Retrieving data (as it can be quite lengthy to fill the

3rdgrid 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, thepreviouslydisplayed Complete Namefor 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 theExposure, 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


18/25


18 | P a g e


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 LocalCurrency 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 *ShowDetails+, 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


1. TwisterCWN is now importing also the Commercial Rates used in the Banking Module for FXOperations, 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 datetimeis available, if theMercuryPriceImport 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.


19/25


19 | P a g e


3. There is now the possibility to store Units (e.g. 100, if the official exchange rate is publishedas: 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 differentallowed 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 versionTwisterUserSrvCWN 0.6.6 & TwisterCWN 0.6.10

2. The initial balance in the report Account Statement, for the case the checkbox include agreedones 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


1. Accrued Interest amounts for MM are now included in Accounting Balances. For the specialcase 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 thelink 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


20/25


20 | P a g e


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 settinga mark in tis checkbox, the accrued taxes are shown as additional component in the List ofDeals, 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 AccountStatementdialog. 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 reportingcriteria, 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 alpha-numeric country ISO code, needed for official reporting in e.g. ECU.

3. The new WebService getPayment() is now publishing both the incoming payments and outgoingpayments. 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.


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'.


21/25


21 | P a g e


2. Additional information related to Rollovers (RolloverId, RolloverAmount) for Money Markets ispublished 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 themoment 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 relatedto 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 (MercuryV.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(), detectedby the IW/BRP in PCB DEU. Fixed for version 2.0.2.1 (TRP October) and version 2.1.2 (TRP

January).

SWIFT


1. Previously, the SWIFT message for Confirmation of an FX Deal (MT300) and the SWIFT messagecontaining 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 alreadyexisting 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


22/25


22 | P a g e


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 todefine the code for the Logical SWIFT Terminal (country-specific parametrisation sript), before being able

to generate Swift Messages.


23/25


23 | P a g e


Part 3 Country-Specific Tools

New Features

1. A new tool for the automatic background import of Official Exchange Rates has been preparedfor Colombia: COL: QuipuRateImportForCOL (V1.0.1)

2. A new tool for the automatic background import of Official Exchange Rates has been preparedfor Colombia: UKR: QuipuRateImportFoUKR (V1.0.0)

3. A new tool for the historic import of Official Exchange Rates for BNR has been prepared forRomania: ROU: QuipuRateImportForBNR (V1.0.0)


1. The Rate Import tool for Ecuador needed an adaptation, the website rates were previously takenfrom 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 monthlyhistorical 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 userauthentication, 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). Lastchanges: 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 Proxyauthentication 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).


24/25


24 | P a g e


6. Mercury password, possibility to specify clear text password instead MD5 password. For Proxyauthentication password, possibility to specify encrypted password instead clear text. The


7.

Adaptation was included in QuipuRateImportForARM (1.2.0).

8. Proxy authentication password, possibility to specify encrypted password instead clear text. Thecreation 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. Proxyauthentication 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


Adapted was included in QuipuRateImportForMKD (1.2.0).

13.Technical Update. Adapted was included in QuipuRateImportForNIC (1.1.0)


25/25


25 | P a g e

Fi i l A li ti

Change Control

Version Date Reviser Changes

0.1 2014-01-30 Inga Initial draft

0.2 2014-02-15 Inga updated


0.4 2014-03-12 Christian updated


0.6 2014-03-15 Sudhakar updated

0.7 2014-03-17 Inga Format updates, only

0.8 2014-03-20 Inga Including last minute changes

1.0 2014-03-22 Inga Final version

Documents

Newsletter Release Notes TRP2014 Jan