User's area
Acumen News n°21
We have the pleasure to present in this 21st issue of the Newsletter new functions and enhancements available in ACUMEN release 7.70 (from June 2010 to July 2011). Please contact us at if you wish to know more about these subjects, or if you wish to learn about all the changes performed on this new release.
Note that it does not include developments linked to our soon-to-come web version of Acumen, called AcumenNet. Also, interfaces from LOGIN-Acumen to ORACLE-Flexcube have been developed or enhanced and can be described further on request.
Deals and valuations
Islamic deals
The first phase of Islamic banking developments has started in Acumen: Murabaha deals are now available. The input is based on an underlying commodity which is bought (or sold) at spot price and sold (or bought) later at maturity price on behalf of a Customer. All the commodity characteristics are listed on the mask and can be described further. Similarly to a repo deal, the underlying rate can be calculated, called here "profit rate". The Murabaha is then handled by the modules like a standard short term deal, and the calculations are based on the "profit amount". Other types of Islamic deals will follow in next releases.
Floating rate spread valuations
New columns have been added in the PV PER LEG module for floating rate legs:
- "PV of spread" shows the present value of only the spread amount, based on the basis point spread of the deal;
- "PV w/o spread" shows the difference between the total PV of the leg and the "PV of spread";
- "Accrued of spread" shows the accrued interest from the last payment date up to valuation date.
Multiple yield curves per deal
It is now easier to value a floating rate deal with two curves, one for the discounting, and one for the simulation of forward rates. Several fields have been added at leg level and User Parameters level to specify which curve should be used in which case. This is especially useful for valuation of floating legs, caps/floors, swaptions, etc.
Risk Management
Portfolio Limits
Many enhancements have been brought to the Portfolio Limits module: The usage can now be based on complex calculation methods; the structure can be multi-level; the set-up can be simplified by using general rules instead of detailed levels; the maximum limit can be a fixed amount or the result of the sum of the total amounts used; and FX limits can be based on calculations produced by the FX position module. All this makes portfolio limits easier to set-up to allow management of daylight limits, stop/loss limits, position limits, etc.
Credit Limits per entity
It is now possible to define credit risk limits per entity. When two entities share the same Acumen database It allows to have for the same counterparty one limit for entity. When Acumen searches for a credit line (by counterparty, country or customer group), it takes only the credit lines for which the entity of the lines are identical to the entity of the deal. For example, a bank using Acumen has 2 entities LONDON and PARIS. Each entity has the same customers but consider that their credit risk exposure is different. The global credit risk exposure will be calculated for the entire entity, and then for different customers per entity.
Risk per Counterparty
The "Counterparty restriction" field and the "With all branches" check boxes have been added in the PORTFOLIO LIMIT and COLLATERAL MONITOR modules and related treatments; it works in the same way as in the CREDIT RISK module, allowing to view only deals of a specific counterparty or head office. Furthermore, the CREDIT RISK module has been adapted to multiple levels of counterparties (when a counterparty is linked to a head office, itself linked to a head office). Now, in the CREDIT RISK by HeadOffice and by HeadOffice/Ctpy/Contract, the head office shown is the highest one, and not the intermediate one. There can be as many levels as required.
Reporting
Audit trail by field
It is now possible to view all the changes done on one (or several) specific field(s) of the database. Up to now, the Activity module of Acumen was only able to show all changes done on a specified table (and on a specified period of dates, by specified users), for example the Counterparty table. Now, it is possible to define a filtering criterion that can be any field of the table. Then, when the module is processed, only the records having an activity on the chosen column(s) of the chosen table will be listed. It allows for example to view only rating information changes on the "Counterparty" table.
Report definition
Report definition has been made easier with several useful tools:
- Possibility to search a column to print or export by typing its letters, like "*RAT" to find ratings information;
- Possibility to select several columns and add them on the report all at once;
- Sort of columns available by logical order or alphabetical order.
Technical Issues
Illegal connections
Now when a user does an unsuccessful connection to ACUMEN or SYSLRMS (wrong user name or password), a log file is created in the folder indicated in the MQL.INI file. The file "connection.err" contains the following information: Date, Time, User Name, Server + Data Base, Module (ACUMEN, SYSLRMS), Hostname. This can be used to check unauthorized connection attempts.
High volumes of Counterparties
It is now possible to manage a very big number of counterparty records (at least 150 000). To do so, only the main counterparty data is loaded in memory. The same feature has been added for the "Account by Counterparty" table.
Rate feeding technologies
Two new set-ups have been done to replace the Datafeeder program that uploads rates real time:
- For one client, we have developed the Bloomberg WebService solution to replace the DDE technology. This allows to limit the quantity of rates requested and hence the cost;
- For another client, we have developed an interface which imports a flat file provided by Reuters, containing daily rates and prices saved periodically (rates are delayed, so cost is lower).
Monitor of Servers
All Acumen servers can be monitored remotely by the Monitor application: the "console" menu allows viewing the activity of those services to check their status, potential error messages, etc. It also allows stopping those services if needed, without requiring the access to the server. This remote management was already possible for the Information Server and the QScanner. It is now also possible for other services that run throughout the day (or night), like the QImpXml, QExpXml, QPrint and the Scheduler.

