Introduction to Multi-Currency Accounts
Multi-Currency Accounts (MCYAAR) is a module under the Arrangement Architecture (AA) umbrella of products and is part of the Temenos Retail Banking suite of products.
The MCYAAR module provides multi-currency account capabilities and maintenance for a financial institution. The module allows the user to create a multi-currency account, making use of Retail Accounts to maintain the currency wise positions of any allowed currencies, without diminishing the existing accounts features and functionalities.
Some of the key features are:
- Create a multi-currency account arrangement
- Create and link multiple sub-accounts with a single base currency account at any time
- Define base currency and allowed currencies
- Perform credit transactions for the multi-currency (MCY) account
- Route funds to proper currency accounts based on the payment currency
- Supports single or multiple ownership for the MCY account
- Link single/multiple debit cards to MCY sub-accounts
- Combined statement generation.
Limitations
- MCY accounts are not enabled to be linked to Transaction Cycler for retrying bill settlements or payments.
- MCY accounts are not enabled to have periodic charges, calculated charges configured at the MCY level.
- MCY accounts are not enabled to invoice the charges, periodic charges that cannot be captialised.
- Unauthorised overdraft cannot be monitored under the MCY level when there is no limit attached to the account.
- To lock funds, the locked event should be placed at the sub-account level with the locked event type having that has account link set to yes.
- Funds should not be locked at the MCY account level.
- MCY accounts cannot act as settlement accounts in lending, deposit or account arrangements.
- MCY accounts cannot form part of a standing order.
- MCY accounts are not enabled to configure activity restrictions at the MCY level.
- MCY accounts are not enabled to configure dormancy.
- MCY accounts are not enabled to be configured as the liquidation account in contract based applications like LC, Forex, and so on.
- MCY accounts are not enabled to link to retail sweeping or cash pooling or notional pooling modules.
- Transactions to MCY account is enabled to be posted through Payment Order application or APIs through the GAI. Teller, Funds Transfer or Data Capture are not enabled for Transaction Processing in MCY accounts.
- TPH or Payment Order does not process the transaction from the MCY account level directly. The sub-account number is replaced in the PI or GAI level.
- Manual Funds authorisation request (using the AC.FUNDS.AUTHORISATION application) and automatic retry for funds (using Transaction Recycler module) is not applicable for MCY accounts including the sub accounts (for each currency).
- For a payments initiated through Payment Order or TPH, the system performs a funds check. In case of insufficient funds at the MCY account or the subaccount level (based on credit check configuration), the system raises error and payment is cancelled. Therefore, manual funds authorisation or automatic retry of funds is blocked for MCY accounts and its sub accounts.
- MCY accounts are retail accounts – HVT feature is not enabled for MCY accounts.
- MCY accounts are not enabled with passbook feature.
- Existing AR accounts cannot be added to existing MCY account structure.
- Currently one sub-account can be created per currency in a MCY structure.
- AR accounts cannot be changed to MCY accounts using change product. They are different product lines.
- Credit check is based on the working balance including the limit available. Advanced credit configuration using the Balance Availability condition is not possible for MCY accounts.
- Automatic position transfer is triggered only when account results in negative balance due to transactions. Automatic position transfer is not enabled for account moving to negative balance due to any interest or charge capitalisation.
Configuration
The AA.PRODUCT.LINE provides high-level definition of the business components (Property Classes) required to construct a product belonging to that line.
The Product Lines are defined by Temenos and cannot be modified. The financial institution then uses these building blocks to construct the individual multi-currency products, which can then be made available for sale to its customers. The following Property Classes are enabled for the MCY Product Line.
- Account
- Activity API
- Activity Mapping
- Activity Messaging
- Activity Charges
- Activity Presentation
- Alerts
- Balance Availability
- Charges
- Closure
- Constraint
- Customer
- Eligibility
- Officers
- Statement
- Sub Arrangement Rules
- Settlement
- Payoff
- Payment Schedule
- Pricing Rules
- Limit
The AA.PROPERTY is an instance of AA.PROPERTY.CLASS and these components constitute an account product. The Property Classes and Properties are made mandatory or optional based on the AA.PRODUCT.GROUP level but subject to the Product Line definition. The AA.PRODUCT.DESIGNER is used to create the account products required.
Illustrating Model Parameters
The product conditions of a Property Class are evaluated to bring out the features of the Property Class. The system defaults the values in the product condition in an arrangement during its creation. The negotiability or default values and other restrictions are also defined in the product condition. These product conditions along with the properties derived from the Property Classes are grouped together to build products.
The product conditions are dated and some of the product conditions have currency as part of their ID. When the currency forms a part of the product condition ID, the user needs to create different conditions for each currency in which the product is available. When a new condition is created or an existing one is amended, the product to which the condition is linked has to be proofed and published.
Multi-Currency Account Model Parameters are:
|
Parameter |
Description |
|---|---|
| Account | The Account Property Class is used by all account-based products. This Property Class primarily controls the description of the account. The ACCOUNT property allows the user to define and control Balance Treatment, Posting Restriction, Linked Account Number (for memo accounts), Currency Market, Date Convention related setup for the Account. Although account names are typically account specific, generic titles can be defaulted from the product and can be replaced or given additional detail at the arrangement level. Each product defined and processed in AA can have a single ACCOUNT Property defined. |
| Activity Charges | The Activity Charges Property Class defines the charges that has to be applied when a particular activity is triggered on the arrangement. The charges so applied can be made-due, capitalised or deferred. The user can enable auto settle the charges made-due from unallocated credit balance by setting the Auto Settle field to Yes. In accounts, charges are enabled for dormancy, settle payoff and ageing. This Property Class is also used for all AA related modules. Charges are set for various other activities. |
| Activity Mapping | The Activity Mapping Condition in Multi-Currency Product line is limited only to map the events in MCY arrangement to a named activity of Record Event Activity (a non-financial activity). There are no financial activities in MCY arrangements and the Activity mapping for transaction activities are also blocked. |
| Balance Availability | It is an optional property class that holds the settings related to available balance updates, credit checking at the MCY account level and automatic position transfer control (position transfer) for the MCY product line. For the MCY product line, only the Def Credit Check, Avl Bal Update, Position Adjustment and Adjustment Order fields are allowed for input. The system raises errors if the user inputs any field other than Def Credit Check, Avl Bal Update, Position Adjustment and Adjustment Order for the MCY product line. It also raises an error if the Component option in the Def Credit Check field is configured for the MCY product line. |
| Charge | The Charge Property Class is used for all charge calculations in AA. The primary purpose of this Property Class is to enable calculation of charge. The charge defined can be a scheduled charge, a periodic charge or an activity based charge. The charge can be fixed or calculated based on band or level. The currency in which the charge has to be applied can also be defined. It is possible to define a minimum charge and also waive the charge. |
| Closure | The Closure Property Class defines the rules and behavior for processing closure of an arrangement. An arrangement account can be closed automatically or manually and it is defined in the product condition. On reversal of a new arrangement, closure is triggered automatically. |
| Customer | The Customer Property Class is used by all products. This Property Class is used to define all the parties involved in an arrangement and their respective roles. The customer is always defined at the arrangement level. Each arrangement can have one or more legal owners defined in OWNER. |
| Eligibility | The Eligibility Property Class is used to evaluate eligibility of a customer for a specific product based on a set of rules. The eligibility evaluation is triggered at a given frequency or when there is a static change for the customer. First the EB.CONTEXT has to be created. Based on this, rules are defined using Rules Engine. Once these rules are validated, the EB.RULES.VERSION and EB.RULES are created in the system. |
| Officers | The Officers Property Class enables the user to define:
Each product defined and processed in AA can have a single OFFICERS Property defined. |
| Statement | The Statement Property Class is used to define the legacy ACCT.STATEMENT feature at AA level. Statements may be produced daily (every working day), every 1-9 weeks, twice a month (on the 15th and the last day of the month) or every 1-12 months on any day of the month. Up to nine statement cycles may be specified for each Account and each statement cycle is independent. In addition to this, special interim statements can be enabled. This Property Class also controls if advices are to be produced or not, when interest and charges are applied, and whether detailed interest statements (interest scale) should be produced. |
| Sub Arrangement Rules | The Sub-Arrangement Property Class allows the user to define the conditions for currency accounts under a MCY structure. The Sub-Arrangement Rules Property Class is available for the MCY Accounts Product Line. This Property Class enables to set rules for the sub-arrangements under a master arrangement. It is attached to the MCY Accounts product to control the allowed customers, currencies and products of the currency wise sub-accounts. |
| Settlement |
The Settlement Property Class enables the user to indicate the settlement account for collecting charges at the MCY level. The system defaults it with the first created sub-account and it can be changed based on customer request. The settlement can be any AR account. Payin or Payout settlement account can be used to indicate payment type specific or property specific settlement accounts. During a live closure, the settlement account is used to liquidate the account funds before closing the arrangement. This account should not be one of the sub-account of the same MCA structure. |
| Payment Schedule | The Payment Schedule Property Class is used to define rules and default schedule of repayments for a product. At the arrangement level it specifies the exact repayment schedule to be applied for the arrangement contract |
| Payoff | The Payoff Property Class allows the user to perform a simulation of account closure and execute the same, if required. The Payoff property can be used to simulate a combined closure at the MCY arrangement level. The system calculates the settlement amount to generate a payoff bill (as an information type of bill) during the closure simulation of the MCY arrangement with its underlying sub-accounts. |
| Pricing Rules | The Pricing Rules Property Class handles the rules governing the selection of appropriate relationship pricing plan, the frequency of selection reassessment and updates the relationship pricing adjustment on the financial arrangement. |
| Limit | The Limit Property Class primarily controls the use of Limit module in the Product. We can define the LIMIT.REFERENCE applicable for specific product such that the system defaults the same in an arrangement or give the Limit Serial as NEW at the arrangement level for new limit. The MCY module can also have self-contained secondary limit without having an actual limit attached to it. Overdraft Status, notice credit check etc for the MCY module is handles through the Limit Property Class.
Further limits can be set to use the Limit module or it can be managed in the arrangement architecture framework. Fields related to Facility Product Line and External Product Lines are restricted for MCY module. |
Illustrating Model Products
The Multi-Currency Account (MCYAAR) Product Line provides multi-currency functionality for Accounts. This module allows the user to create a MCY account under the MCY Account Product Line.
|
S.No |
Product Name |
Features |
|---|---|---|
| 1 | Multi-Currency Account |
|
| 2 | Multi Currency Account - Gold |
|
In this topic