Bowmen Group MultiCurrency

This document details the Bowmen Group Limited (BGL) approach to implementing multiple currencies within the Archer solutions. This approach can be demonstrated in an existing Proof of Concept. The example screens shown are included only as indicators of example layouts; future engagements can use a different screen and field configurations successfully with the underlying principles of this approach.

For further details and to discuss using this approach please speak to your BGL representative or e- mail sales@bowmengroup.com.

Overview

There are many requirements that call for the possibility of a user entering a financial amount into the Archer system:

• Loss Events: actual (or near miss) losses incurred by a company and logged in the system to be reported against actuated Risks and failing Controls

• Risks: entering financial impact amounts

• Action Plans: entering costs of a change

Most large companies' cross borders and deal with more than one currency, which can be problematic with the out-of-box Archer approach of entering them only in a single currency with no exchange rates held.

Key points for a workable multiple-currency approach are:

• Should store a single ‘base’ currency to allow for central reporting vs local reporting of financial figures.

• Should allow for a large number of ‘local’ currencies to be held, along with their exchange rates – potentially holding every currency in existence.

• Should be able to hold a date that the exchange rate applies to; this allows for ‘historic’ rates to be held and used for items (such as Loss Events) that are entered into the system a period of time after they actually occurred.

• If selecting a ‘historic’ currency rate, the system shouldn’t force the user to manually select the correct currency rate from a list with the applicable dates shown; the user should enter an occurrence date and then the system should show only the currency rates that are applicable.

• If a ‘current’ rate is being used, then the system should allow for this rate to change – either automatically updating the child record in-line with the updated rate or else freezing the rate upon entry (or at a specific point in a workflow) and no longer reflecting any future changes to the rate.

Approach

Currency holder

The central idea behind this approach is to introduce a new On Demand Application (ODA- Archer terminology see Glossary: to hold the currency exchange rates. The basic layout of this ODA is:

The fields are:

• Currency Code: holds a dropdown of possible currency codes

• Rate: holds the rate back to base

• Type: either ‘One Off’ or ‘Ongoing’(see below for more detail)

• Currency: system calculated field holding the text of the currency code (used as a key field)

• Applicable Date: the date that the exchange rate applies for (only applies to One Off entries)

Data loading

A single Data feed (Archer terminology, see Glossary) is used to feed in the up-to-date exchange rate for your chosen currencies daily; if only Ongoing (Current) rates are used then the frequency of update can be changed (updating either more or less frequently) as desired. For the One Off (Historic) methodology to work the rates needs to be loaded daily– if this is problematic then the system can be set up to re-load the existing rate in every day except for the ones where a true update happens.

Using currencies

There are two main approaches to linking an existing Application (Archer terminology, see Glossary) to the currency records:

One-off (Historic)

With this approach, the user first enters a date field (such as an occurrence date for a Loss Event), a ‘local’ financial amount and then selects the currency they wish to use. The system only shows the user the correct currency exchange rates from the date entered and will then pick up and use that exchange rate for the calculation back to base. The end user only has to make simple selections and data entries; the system handles the process of matching dates and exchange rates instantaneously.

It is not able that the ‘first published’ date of the record (a system generated date of when the record was created) could be used to lock the date of the exchange rate for this approach, if needed.

The Loss Events application is an example of this use case – the date of occurrence might be days or weeks in the past by the time they are entered into Archer. This approach allows the user to select the date to use the correct exchange rate.

Ongoing (Current)

With this approach, the user selects from a list of currencies and enters a local currency amount. The system then picks up the current exchange rate and works out the base amount instantaneously.

This raises the question of when (if at all) the system should update the record with the latest exchangerate.3sub-approaches to this have been developed (although a completely different approach could be taken if needed):

Set once

With this sub-approach, the system picks up the exchange rate at the time the user selects the currency; this is then locked in and will not be updated as the exchange rate changes in future – there is the possibility of allowing the user to change the currency again, which would mean picking up the ‘current’ exchange rate at that point in time or locking down the field so they can’t change the currency and the exchange rate stays locked.

An example use case of this sub-approach is a KRI/KCI/KPI– this data is entered once and then viewed and reported on so the exchange rate shouldn’t change.

Updated until X

With this sub-approach, the system continues to update the exchange rate for the chosen currency until the record reaches a pre-defined point in its lifecycle / workflow. At that point, the system locks down the exchange rate and doesn’t allow for future changes. It is also highly recommended to lock down the currency selection field at that moment to prevent future changes.

This sub-approach is utilized in Remediation Plans – the estimated cost of the plan could be updated with the current exchange rate until it is approved / until it is completed.

Always updated

With this sub-approach, the system continues to update the exchange rate for the chosen currency forever; future changes to the exchange rate are always picked up and shown on the child record.

An example use case of this sub-approach is entering a financial impact in the Risk Register – this should always be kept up-to-date with the latest exchange rate so that the true ‘current’ predicted cost is always reported at group level.

Example screens

Example–Selecting a Currency

In the below example, the user is being presented with a choice of 4 currencies (including the base currency of GBP) – this same, simple screen would be presented regardless of the approach (One Off or Ongoing) – the Rate column can even be dropped to leave only the currency code on the screen.

Example–All Approaches

In the below screen (showing all approaches):

• An exchange rate for EUR is used from the 28 of November 2016

• The Current – Set Once rate was frozen upon selection and the rate has since changed (twice)

• The Current – Updated Until Approved rate was updated once and then frozen and the rate has since changed

• The Current– Always Updated rate has continued to update and shows the currentrate

Example–Local Currency Reporting

Example–Group Reporting (Base Currency)

Technical requirements

For the system described above, the following are the necessary requirements:

1. A working Archer system

2. 1 available Data feed slot

3. 1 available ODA

For quotes and pricing of BGL time to implement the solution, please contact your BGL representative or sales@bowmengroup.com.

Glossary

Term	Definition
Application	Within Archer, an Application is the term used for a form / data screen/ ‘bucket’ for a particular type of data; i.e. the Risk Register is held in an Application, the Control Procedures are held in a separate Application
Data feed	Within Archer, a Data feed is an automated, scheduled process That manipulates data in the system (or imports data from external systems).
On Demand Application (ODA)	Within Archer, an ODA is an On-Demand Application; this is an Application (see above) that is a blank sheet in terms of a starting point and can be configured to capture any kind of data. These were purchased from .