Introduction to Multi-Company and Multi-Branch (MCMB)
Temenos Transact architecture supports the set-up of multiple company in one instance of Temenos Transact. The companies can operate independently or can share record types and certain files. Companies can also share the operation of Nostro accounts and Security Management System (SMS) in Temenos Transact, which maintains the security of access at company level. All these are covered separately in this guide.
The following types of company exists in the MCMB set up.
- Master Company – This is the first company setup in a Temenos Transact installation (normally BNK) and it owns a complete set of data tables. The master company can also be a lead company. The master company is present in all types of Temenos Transact environment.
- Lead Company – Sometimes called Parent Company. A lead company is defined on installation by indicating that the financial tables are to be owned by the company being created. Typically a Lead Company is used to represent a legal entity in the real world. It can have its own base currency and COB. It can be set up to share (or not) certain data sets with other companies. However, it will store all financial level data in its own set of tables.
- Branch Company – Sometimes called Book Company, is a typical Temenos Transact Company.
- It is always linked to a Lead Company.
- A branch always shares Lead Company’s Base currency, batch holiday table and COB.
- In a multi-branch set-up, all financial level data is held in the same single physical database as the Lead Company; although logically they are separated by the branch ID. For example, if there are 10 branches with the same Lead Company, there will be one Account table whereas if 10 branches are set up as lead companies, they will have 10 Account tables.
- A Branch can be linked to only one Lead Company. One Branch Company cannot be linked to another Branch Company. A branch always shares its local currency and batch holiday table with its lead company.
- Accounting Company – also called Accounting Unit.
- AU is an optional module and has a user guide of its own therefore not covered fully in this guide.
- The AU Functionality allows separate financial books to be maintained in a company or a branch. For example, a bank can produce books for individual business lines operating while still maintaining company as a whole.
- It shares the same currency, batch holiday table and COB similar to Branch company.
Transactions can take place between accounts in different companies using intercompany accounting functionality. Consolidated reporting, combined companies, can be produced using the consolidation functionality.
Sharing Information between Companies
The decision on what to share needs careful consideration as once set up, it cannot be changed. These decisions are taken when the system is initially installed before the system build begins.
The system classifies applications by the application type and are an inherent part of the system when installed. The classifications enable share/not share decisions when MCMB is set-up.
- The sharing options are available to lead companies.
- Branch companies will always share the files of the lead company.
- New companies can be added and existing companies can be decommissioned.
- Classification of the applications is delivered as part of the system build.
The following list explains each Application Type.
| Application Type | Description |
|---|---|
| INT - Installation level |
There is only one copy of installation level application in a Temenos Transact database, so the actual application name does not include a company mnemonic. The following are the examples of INT level application:
|
| CUS - Customer level |
The CUSTOMER and related applications includes the customer number in the key. Examples of CUS level application:
|
| CST - Customer tables | Parameter tables related to customer examples include INDUSTRY and SECTOR, together with parameter tables for limits, collateral and position management. This type of table can be shared between lead companies. |
| FIN - Financial |
There is always one copy of a financial application for each lead company. All branches linked to a lead company share the same financial application. The following are the examples of FIN applications:
|
| FRP - Financial reporting | There is one copy of a financial application for every company in the system. For example, the COB job list applications and REPGEN work files (like RGP.TRANS.JOURNAL2). |
| FTD - Financial application definitions |
Financial parameter applications that does not contain data with amounts or rates linked to a particular local currency. For example, GEN.CONDITION type tables and BASIC.INTEREST. This type of application can be shared between lead companies.
|
| FTF - Financial application data |
Financial parameter applications that contain financial data, often contain local currency amounts. The following are the example of FTF application:
TAX application can be shared between lead companies.
|
| CCY - Currency applications |
Contains currency related information, for example, CURRENCY and PERIODIC.INTEREST. This type of application can be shared between lead companies.
|
| NOS - Nostro applications |
Applications related to Nostro accounts. For example, AGENCY and NOSTRO.ACCOUNT. This type of application can be shared between lead companies.
|
Facilitating MCMB Environment
Facilitating MCMB environment requires a number of functions to be in place. These are:
- Grouping structure
- Intercompany accounting
- Branch Holiday
- Global Processing for COBs
Creating a Group
Temenos Transact uses company codes to identify companies (if it is a lead company, a branch company or an accounting company). The format of the company code is CC GGG LLLL, where:
- CC is the country code.
- GGG is the company group code.
- LLLL is the local code.
The system facilitates grouping of operating companies into reporting groups. For example, a bank has operations in different countries and want to group them by these jurisdictions. Another bank wants to set up a regional group for all its branches in South of England and one for all its branches in North of England.
The group code is part of the 'T24 Company’ key and as such helps in identifying a particular operating company of 'T24 Companies’ that have been set up.
Thus for each of the T24 Company forming part of the same operating company, the group must be the same. Therefore, the same group codes need to be created at each of the locations where the organisation is operating the Temenos Transact system.
Thus, the COMPANY.GROUP code forms the centre portion of the individual records in COMPANY, for example, GB0010001.
Intercompany Accounting
Inter-company accounting is an important part of the configuration in an MCMB environment. It facilitates the accounting between companies set up in the environment - be it lead companies or branch companies.
When there are a large number of branches, multi-book accounting needs a large number of internal accounts, as each company needs an account with other company, potentially in many currencies. For this type of environment, it is better for the inter-company accounting to go through the head or regional office. So, only the head office holds an account with each branch so that an intercompany transaction is channeled through the Head Office. For example, Branch 1 has business with Branches 2, 3 and 4 in different currencies with each. Instead of Branch 1 having intercompany accounts with each of 2, 3 and 4 branches, it just has one account with its Head Office, which will channel the transactions to the other branches. Thus, reducing the number of intercompany accounts required.
Branches Working on Holidays
In a multi-branch environment, there are possibilities that all branches might not follow the working practices of the lead company. For example, the head office may not work at weekends, whereas the branches may be working. This is facilitated in the COMPANY application and the following fields are available:
- Official Holiday – Indicates the business holiday table for the local country.
- Branch Holiday – Indicates the business holiday table for this company.
- Batch Holiday – Indicates the holiday table that controls the days on which the COB processing occurs.
For example, it is possible to setup the system to run the COB processing 365 days per year, with some branches open on weekends for restricted business activities.
Global Processing
Global processing allows the Close of Business (COB) processing in a multi-company environment to be run independently at the lead company or lead company group level. If the lead companies in a Temenos Transact instance are located in a variety of time zones, then the COB processing takes place at a convenient time for the relevant group or company, while the other members of the group are still online.
The global processing module also provides the following functionalities:
- Full transaction management in the end of day process.
- A resilient fault-tolerant end of day process (the system does stop due to an error with a contract).
- Use of online backups rather than traditional backup.
- Global processing functionality is restricted to lead companies, that is, all branches linked to a lead company are processed together.
- Ability to post accounting entries to companies that are offline from a company that is online.
Deactivation of Company
This functionality allows the users to deactivate a company in the Transact. To deactivate a company, the Deactivate field in the COMPANY application must be set to ‘Y’ in the respective COMPANY record at the database level by special IT maintenance operation team and the field is not available for manual input through any screen or API. Before deactivating a company, the bank needs to make sure,
- There should not be any cross-company transactions. All future dated transactions posted before the deactivation of the company does not take place once the company is deactivated.
- All background services and BATCH jobs must be shut down.
- No active users can log in into the system during the deactivation process.
Implications of Lead Company Deactivation
The restrictions, errors, and impact of deactivating a lead company in Transact are listed below:
- Users cannot create new transactions, contracts, accounts, customers, or arrangements and generate accounting for deactivated companies.
- Creating new data items, new tables and installing new products for deactivated companies are not allowed.
- When a lead company is deactivated, the branches of the lead company are automatically deactivated, and all services are stopped.
- Inter-company transactions and interfaces involving deactivated companies are restricted.
- Users cannot configure references to deactivated companies in the INTERCO.PARAMETER application.
- Automated services like OFS or user-initiated services and signing into deactivated companies are restricted.
- For transactions with a settlement account belonging to the deactivated company or its branches, an error message is triggered during validation or record commitment, preventing the transaction.
- During the creation of a new company in the COMPANY.CREATE application, if the Default Company field is set to the deactivated company, the system triggers an error message during validation or record commitment, preventing the creation of the new company.
- Upon receiving OFS instructions using the deactivated company code, the system returns an error message, rejecting the transaction.
- New records cannot be created using the mnemonic of the deactivated company in the BATCH application. The system triggers an error message and prevents the creation when trying to create a new record using the deactivated company mnemonic.
- Running COB for the deactivated company is not possible. The system does not initiate the COB process for the company, ensuring no batches or services are run. Any existing batch and service for a deactivated company will not run.
- When the user runs COB for all companies, the system runs batches or services only for active companies, skipping the deactivated company.
In this topic