Introduction to Customer Messages and Notes
Banks are in need of on-line messages which would alert the users regarding certain information of the customer, before they authorize any financial or non-financial activities. For example the administrator may warn the user that the customer for whom the current transaction is triggered has been involved in fraudulent activities or has defaulted in a loan payment, Garnishee, etc. This prevents either debiting or crediting such account etc.
The alert message should be easily configurable by the administrator and also alert the users regarding posting restriction created at both customer and account level in the system.
Customer - Container Switch: In Canadian market, there are 2 types of financial institutions namely credit unions and banks. The approach towards customer process is slightly different for both financial institutions. The differences are highlighted below.
Credit Unions
Credit Unions follow the 2 Layers for customer process as given below:
The first layer called the CIF layer contains the member’s name(s), addresses(s), social insurance number, sector, industry, residence, target, customer status etc. Each member is uniquely represented at the customer layer within the credit union.
A second layer is required to represent the relationships that members have among themselves. Information at this layer needs to be derived and maintained from the previous layer as per various rules explained below. This layer is referred to as “membership” or “container” layer.
In case of credit unions for any financial products all the owners related to a container and accounts of the owners are used for processing.
Banks
The banks in Canadian market follows the normal customer process wherein there is no differentiation of CIF and customer.
In case of banks for any financial products only the customer and accounts of the customer are used for processing.
As Canadian model bank support functionality for both credit unions and banks, there is a requirement to provide a switch at company level, so that the financial institution can be easily differentiated between bank and credit union.
The development has been done to raise override messages to alert the user while doing financial and non-financial transactions which can be configured by the administrator.
The below are functionality covered.
- Online Messages:
- Ability to set standard override messages.
- Ability to set any free text overrides messages.
- Messages are to be set for customers and should appear in all the financial and non-financial transactions done for customers.
- Posting restrict:
- Ability to set up the expiry date of a restriction.
- When a restriction is created at customer or account level, the administrator has the option of indicating the type of financial restriction that needs to be applied, that is either DR or CR, or both.
- Once the restriction has been put on a customer or account, for all financial transactions override will be raised. Until the override is authorized by user of the required class, the transaction will not be completed.
Standard messages:
- Ability to configure customised override messages.
- Ability to configure message start date and end date.
User restriction:
- Bank users are restricted to initiate any kind of transactions on their own accounts or accounts or products wherein they are associated as Relation customers or Joint owners.
- Ability is available to restrict the bank user from making any amendments on the existing record where the user is related to.
Customer – Container Switch
To differentiate the credit union banking process and normal banking process, a Flag (new field) has been introduced at company level.

New field has been introduced in Company application to differentiate the financial institution as a bank or a credit union. If the field is set as Yes, then the normal banking process will be followed by financial institution and if set to No or Null credit union related banking process will be followed by financial institution.
This is one time setup to differentiate bank and credit union.

Credit union process:
- In credit union process, it is mandatory to create 2 layers for customer (namely CIF and container) before creating any financial product like accounts, etc. Exception is register plan products.
- In credit union process, for all Canadian model bank functionality modules a container is used as reference, wherein based on container system fetches the owners (using the relationship code, etc.) and initiates the processes, where in normal banking process this is not relevant.
- When the Flag is set to No or Null, System follows credit union process, wherein container-owner concept comes in to picture.
In case of credit union for any functionality all the related owner at container level and accounts of related owners are used.
Banking process:
- In normal banking process, a normal customer is created and the same is used as a reference to process CAMB functionality. Hence the system check to fetch the owner based on customer is not relevant.
- When the Flag is set to Yes, System follows normal banking process wherein system does not look for owner based on customer.
In case of normal banking process for any functionality only the particular customer and accounts of that particular customer will be used.

In case of credit unions version, enquiries and menu of CAMB functionality have reference to container/ membership instead of customer which is not relevant to normal banking process. Hence 2 set of menu will be used one for credit union with reference to container/ membership term and relevant functionality and other for bank with no references to container/ membership concept.
In this topic