3. Oracle FCPB – FCUBS Interface

Oracle FCPB – FCUBS interface has been primarily designed to enable the exchange of information between FCPB and FCUBS in terms of day-to-day transactions and maintenances for certain entities like Customer Creation, CASA Account Creation, TD Accounts Creation/ Transactions and Balances related to Loans and Liabilities. This chapter deals with the following interface and the explanation of the same from FCPB setup perspective:

This chapter contains the following sections:

3.1 Details of Data Received from Oracle FCUBS to Oracle FCPB

The details of the Interface Modules for Customer, CASA, Liabilities and TD are as given below:

Entity

Action

Frequency

Source

Target

CIF Authorization/Modification/Closure

Add

On-line

FCUBS

FCPB

Broker Data

Add

On-line

FCUBS

FCPB

CASA Account Creation

Add

On-line

FCUBS

FCPB

CASA Account Balances

Add

On-line

FCUBS

FCPB

TD Account Creation

Add

On-line

FCUBS

FCPB

TD Premature Withdrawal

Add

On-line

FCUBS

FCPB

TD Maturity with Interest Liquidation

Add

Batch

FCUBS

FCPB

Daily Accrued Interest on TD

Add

Batch

FCUBS

FCPB

Penalty on TD

Add

Batch

FCUBS

FCPB

Loan and Liability Information

Add

Batch

FCUBS

FCPB

3.2 Interface Details from FCUBS to FCPB

Any FCUBS-FCPB interface originating from FCPB is driven by the flag FCUBS_INTERFACE_FLAG=Y in REF_BANK_PARAMS. However, currently since we are only supporting Customer/CASA/TD interfaces originated from FCUBS are supported, hence the value is maintained as 'N'.

In FCUBS, we can assign Segments to customers. Based on certain factors, the RM in FCUBS decides whether a Retail customer is eligible for a Wealth Segment and if eligible, upgrades the customers to such a segment.

Whenever a customer is upgraded to Wealth set of segments, all his Accounts, Balances, TDs etc would be sent to FCPB as EOD File Handoffs. For Retail Customers who have not been assigned a Segment or Upgraded even once, the system will not send any notifications or EOD File Handoffs to FCPB.

3.3 Transfer of Data using XML Files

FCUBS sends XML based online notifications for Customer creation/modification, CASA account creation/modification and TD creation/transactions to FCPB for the Segmented Customers only. It does not send any XML notifications for retail customers that are not allotted any Segment in FCUBS.

This section contains the following topics:

3.3.1 Creating Customer Data

Whenever a customer is created in FCUBS with customer type as Individual or Corporate and if the Segment is also defined, notifications will be sent by FCUBS via an online notification XML to FCPB.

If Customer Category is defined as 'Broker' with Segment not being mentioned/blank, FCUBS will send an online Customer Creation Notification to FCPB. FCPB would create the details for a Broker in Broker Master Table. If the Segment is not mentioned for the ‘Broker’ created in FCUBS due to any reason, then the system will generate Segmentation Upgrade files at EOD for Broker. Thus resulting in a failure while uploading such Customer Segmentation Upgrade files in FCPB, as this ‘Broker’ as a customer is not created in FCPB.

3.3.1.1 SETUP Needed for Enabling Customer Creation Interface from FCUBS

Mapping of Client IT Type, Segment, Status, Client Classification and Client Category in FCPB:

FCPB has capability to define various types of Client IT Types like Individual, Corporate, NRI etc. These values are to be maintained in FCPB with the same values that are being maintained at FCUBS during Implementation. Similarly Client Category, Client Status are also maintained suitably in REF Tables of both FCPB and FCUBS systems. These tables are then synched-up via Transaction_Transformation screen, so that FCPB's internal names and values are mapped to FCUBS's names.

The important tables and screens to be synched-up between FCUBS and FCPB are mentioned below:

Tables

Screen Name

Navigation

REF_CLIENT_SEG

Client Segment

Master à CRM Related à Client Seg­ment

REF_CLIENT_STATUS

To be updated directly in the database

REF_CLIENT_IT_TYPE

Client IT Type

Master à CRM Related à Client IT Type

REF_CLIENT_CLASSIFICATION

To be updated directly in the database

REF_CLIENT_CATEGORY

Client Category

Master à CRM Related à Client Cate­gory

PREF_LANG_CODE

To be updated directly in the database

Handling of Mandatory fields in FCUBS and FCPB using Field Access Controller

The FAC framework of FCPB also supports you to maintain certain fields as Mandatory or Non-Mandatory for Demographics screen. Fields which are mandatorily from FCUBS should be setup as Mandatory in FCPB via FAC screen for Demographics.

Similarly, fields which are non-mandatory or not available in FCUBS need to be setup as Non-Mandatory in FCPB via FAC screen for Demographics. Such fields need to be updated by the RM in FCPB via Demographics screen with the actual values.

The following fields in FCPB are not available in FCUBS:

Restriction to Modify FCUBS Fields using Field Access Controller

You are not allowed to modify the fields that are mandatorily received from FCUBS (like Customer Name, Address, Status, Segment etc.) However, you can modify the fields which are exclusively maintained by FCPB (fields which are not maintained by FCUBS) like Client Entity, Hobbies, Preferred Communication Mode etc. The Implementer handles this using the Field Access Controller Framework of FCPB.

Automatic Login Creation for New Customer

Whenever a customer is created in FCPB via the Create Customer XML from FCUBS, a script is executed to auto-generate the Login ID of the customer. This script makes an entry in the SMS_APP_USER table and assigns a Role to the customer which is same as one’s Segment (after appropriate transaction transformation to FCPB's specific Segment Codes). For supporting this, Roles are created for every segment. These roles are mapped as Customer Roles and the names of these roles are identical to the Segments maintained.

Identifying Customer Currency and Creation of Portfolios

Customer's Currency Code is an essential field while creating a customer without which a portfolio cannot be created in FCPB. The Create Customer Notification from FCUBS also contains the Customer_CCY for all Wealth Customers. Portfolios in FCPB get auto-created on creation of a new Customer with this Customer_CCY as the Portfolio Currency as well.

Directory Details for Corporate Clients

Currently, for corporate clients, FCPB supports only a single Director’s details.

Notification XML

For Customer Creation or modification, FCUBS sends the notification with the appropriate Namespace and Notif code. The namespace is decided by the implementer at the time of implementation and NOTIF_CODE would be “NOTIF_PB_CUSTOMER”.

Note

There is no difference in Namespace or NOTIF_CODE for Creation and Modification of a customer.

3.3.1.2 Process Flow

The following steps are involved in the process:

  1. On receipt of Customer New_CIF_AUTH_NOTIFICATION XML from FCUBS, the customer gets created in FCPB and the various tables get populated to store customer data like CRM_CLIENT_MASTER, CRM_CLIENT_PREFERENCES, CRM_CLIENT_ADDRESS etc. and CIF status gets updated to Active.
  2. Once the client status becomes active, the default portfolio for the client gets created. This is a customized script since different Banks would have different requirements for creating default portfolios i.e. specific Portfolio_Types (like RMM, SLF, HLD etc).
  3. Any modifications that are initiated at FCPB (like risk profiling and other details for which FCPB is the owner), are automatically updated in FCPB and are not sent to FCUBS for any further authorization.
  4. The COMPLIANCE_REQUIRED_YN flag in REF_BANK_PARAMS is maintained as ‘N’ so that the modifications via Demographics screen will not be sent to Compliance etc and status of Customer can be made Active immediately.
  5. When any modifications are made in the CIF demographic data in FCUBS (like address, email), a full screen response notification is sent back to FCPB with the amended details.
  6. The closure of CIF is also communicated from FCUBS to FCPB. On receipt of this closure intimation from FCUBS, the status of the customer changes to ‘Closed’.
  7. Updates based on Client IT Type:
  1. In FCUBS, customers can also be created quickly using the STDCIFAD screen. The Operational workflow is as follows:

3.3.2 Modifying Customer Data

If there are any modifications at FCUBS end, a full screen response notification is sent to FCPB with the amended details.

3.3.2.1 Process Flow

The following steps are involved in the process:

The closure of CIF is also communicated from FCUBS to FCPB. On receipt of this closure intimation from FCUBS, the status of the customer changes to ‘Closed’.

  1. Any change in Segment (either Segmentation Upgrade or Downgrade) is also expected as a part of Customer Modification. To support this, an additional element, the Customer Segmentation Status, is sent to FCPB which would have values; Segment-Upgrade – 'U' or Segment-Downgrade – 'D' and Segment-Reupgrade – ‘R’.
  2. If the Segment is modified in FCUBS, then FCPB updates the Client_Seg column with the new Segment Code in CRM_CLIENT_MASTER. Hence, the role of that customer changes based on the new segment, by first identifying the Role_ID with NAME = Segment's name from SMS_ROLE and then identifying User_id of the Customer from SMS_APP_USER. The system then updates SMS_USER_ROLE table for that User_Id with the ROLE_Id for the new Segment.

3.3.2.2 Updating Crm_Client_Master Table

The customer status in FCPB gets updated (i.e. Client_Status in CRM_CLIENT_MASTER) based on the following xml attributes.

Rules for updating the Client_Status in FCPB:

  1. A new column called 'Status_Description' is introduced in CRM_CLIENT_MASTER and it gets updated as mentioned below.
  1. Any change in Segment (either Segmentation Upgrade or Downgrade) is also expected as a part of Customer Modification. To support this, one more additional element, the Customer Segmentation Status, is sent to FCPB which would have values; Segment-Upgrade – 'U' or Segment-Downgrade – 'D' and Segment-Reupgrade – ‘R’.
  2. If the Segment is modified in FCUBS, then FCPB updates the Client_Seg column with the new Segment Code in CRM_CLIENT_MASTER. Hence, the role of that customer changes based on the new segment. by first identifying the Role_ID with NAME = Segment's name from SMS_ROLE and then identifying User_id of the Customer from SMS_APP_USER and updating SMS_USER_ROLE table for that User_Id with the ROLE_Id for the new Segment.

The Customer Modification XML includes the fields Segment, Branch ID, Banker ID, Client Status and Portfolio_ID.

The details of online notifications for Suspended Status Client are given below:

3.3.2.3 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental, online.
  2. For modification and closure, there would be a special notification message. For modification and closure, the notif code would be notif_co_customer_mod. When the customer details are modified, the txnstat would be ‘O’ and in case of closure, the txnstat would be ‘C’.
  3. On receiving closure notification from FCUBS, the CIF status in FCPB will stand closed.

3.3.3 Client Suspended Status

The details of online notifications for Suspended Status Client are given below:

3.3.3.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental online.
  2. If the customer is suspended for a temporary time period, the status of such customer is updated as Frozen in FCUBS and on receipt of notification xml the customer status in FCPB gets updated as S (Suspended status).
  3. This notification comes in the same way as any other modification notification from FCUBS. The same XML message gets transmitted with the ‘Frozen’ attribute being marked as ‘Y’.
  4. Similarly, if the Frozen status is revoked at FCUBS, it is again communicated to FCPB via customer modification notification XML with the Frozen attribute being marked as ‘N’. In this case, the client status in FCPB reverted back to ‘A’ (active status) provided the already available status of client is ‘S’.
  5. The notification message for communicating that the customer being Frozen would be NOTIF_CO_CUSTOMER_MOD and txnstat would be ‘O’ in this case.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    Updation in CRM_CLIENT_MASTER

    Client_status

    If Frozen is Y, then client_status would be made as ‘S’ (provided if already available sta­tus is A). Or if Frozen is N, then client_status would be made as ‘A’(provided the already available status for the client is S)

    Frozen

3.3.4 Broker Data

The Broker data is handed-off to FCPB using the XML format similar to Customer Creation

The details of online notifications for Broker are given below:

3.3.4.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental online.
  2. The broker is created in FCUBS and sent to FCPB.
  3. The notification message for broker creation would be same as of create customer notification - NOTIF_CO_CUSTOMER_NEW.
  4. If Customer Category is mentioned as BROKER, then FCPB will identify the same as broker and update the MST_Broker table.
  5. The modification notification XML message for broker modification would be same as of customer modification notification- NOTIF_CO_CUSTOMER_MOD.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    Broker_name (MST_BROKER)

    First Name

    FULLNAME (if FULLNAME not available, then FIRSTNAME)

    Broker_code (MST_BROKER)

    Broker code

    CUSTNO

    This tag would help in identify­ing if the CIF Notification is of broker or not

     

    CCATEGORY (In case of broker, it would be broker or B)

    Address1 (MST_BROKER)

    Address Line 1

    ADDRLN1

    Address2 (MST_BROKER)

    Address Line 2

    ADDRLN2

    Address3 (MST_BROKER)

    Address Line 3

    ADDRLN3

3.3.5 CASA Account Creation

The details of online notifications for CASA Account Creation are given below:

3.3.5.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental online.
  2. The asset type of products like current and savings account (CASA) would be created by FCUBS and the details would be handed off to FCPB.
  3. CA-New Customer Account-Notify-MSG service would be used by FCUBS to hand-off the account details to FCPB.
  4. The CASA Account would be created for customers whose status is Active. It is not opened for a Contact person.
  5. Once the notification message is received from FCUBS on the creation of CASA Account, the account details would be inserted into CRM_CLIENT_BANK_ACCOUNT. Once the account is created, no updates would be done to PMS_PORTFOLIO_HOLDING table. The Holdings would only be updated after receiving the CASA Balance Update Notification.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    Updation in CRM_CLIENT_BANK_ACCT

    BANK_ACC_ID(CRM_­CLIENT_BANK_ACCT)

     

    ACC

    CLIENT_ID(CRM_CLI­ENT_BANK_ACCT): Cli­ent_id is based on External_Id which is being sent as CUSTNO

     

    CUSTNO

    ACCT_CCY(CRM_CLI­ENT_BANK_ACCT)

     

    CCY

    ACCT_TYP(CRM_CLI­ENT_BANK_ACCT)

    Use existing logic of populat­ing PROD_ID and Instru­ment_ID to identify ACC_TYP

     

    ACCT_SUB_TYPE

     

    ACCTYPE (to be parame­terized with values like S, C)

    BANK_ID should be defaulted to value in BANK_ID of MST_­BANKS (It is assumed that only one branch of FCPB client (like BMO, BDB is going to be main­tained in the table)

     

     

    ACCT_STAT should be defaulted to A

     

     

    ACCT_ADDRESS respective address as in ADDRESS column of MST_BANKS table for the respective BANK_ID

     

     

    USE_IN_TRADING should be defaulted to Y

     

     

    BANK_NAME respec­tive name as in NAME column of MST_BANK table

     

     

    PREFFERED should be considered to be 1 if CASA account currency is equal to bank base currency and for other denominated accounts and any ongoing receipt of CASA accounts denominated in bank base currency would be defaulted to 0

     

     

    PORTFOLIO_ID(CRM_­CLIENT_BANK_ACCT)

    For deriving the portfolio_id the logic should be as follows:

    For non-Heldaway/Internal accounts, from pms_cli­ent_portfolio for a particular cli­ent, select the portfolio_id as the portfolio whose   Default_Portfolio = ’Y’ having the same portfolio_type as mentioned in ref_instrument_­type table for Instrument_­Type = ’CASA’. The crm_client_bank_account table would also store this  same portfolio_id for Asset accounts for easy reference and retrieval

     

    Banker_Client_Indicator (CRM_CLIENT_­BANK_ACCT)

    Should be defaulted/updated to ‘B’ for all CASA/TD records which r being inserted/updated from FCUBS Core Banking system

     

    Acct_branch

     

    Branch_code

    Acct_country_id

     

    Country_code

    Acct_description

     

    ADESC(if the description is more than 20 char, then FCPB should truncate it to the extent of 20 char and populate the same)

    Opening_Date

     

    ACCOPENDT

 

3.3.6 Customer CASA Account Balances Notification

The details of Customer CASA Account Balances Notifications are given below:

3.3.6.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental online.
  2. Any changes in the CASA Balances of the customer will be notified by FCUBS to FCPB.
  3. The notification code used by FCUBS to communicate the change in the customer balances would be “NOTIFY_AC_BAL”.
  4. On account balance notification, the PMS_PORTFOLIO_HOLDING table is populated with the Market_Value and Total_Acq_Cost columns based on the balances received in the notification message.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    SUB_PORTFOLIO_ID (PMS_PORTFO­LIO_HOLDING)

    CASA Account no

    CUST_AC_NO

    Client_id (PMS_PORTFO­LIO_HOLDING)

    CIF ID

    CUSTNO

    INSTRUMENT_CCY (PMS_PORTFO­LIO_HOLDING)

    Currency of the CASA Account

    CCY

    VALUE_DATE (PMS_PORTFO­LIO_HOLDING)

    The date of receipt of the balances

    Since it is online notification, the XML would be received as and when the balances are updated. So the date of receipt of the XML notification would be populated as value_date

    TOTAL_ACQ_COST (PMS_PORTFO­LIO_HOLDING)

    Actual Balance including unclear bal­ances

    ACBALANCE

    MARKET_VALUE (PMS_PORTFO­LIO_HOLDING)

    Balance available to be spent

    ACAVLBAL

    HOLD_AMOUNT (PMS_PORTFO­LIO_HOLDING)

    The current balance minus available bal­ance would give the blocked/hold amount

    ACBALANCE- ACAVLBAL

3.3.7 CASA Closure/Modification

The details of Customer CASA Closure/Modification Notifications are given below:

3.3.7.1 Process Flow

The following steps are involved in the process:

  1. Once a CASA Account gets closed in FCUBS, the same should get reflected in FCPB. NOTIF_CA_CUSTACC_MOD XML would be used to handover the CASA closure details to FCPB. When the txnstat tag reads as C, it indicates that the CASA account is closed.
  2. The Notification Code for CASA Modification/Closure will be: NOTIF_CUSTACCMOD_PB

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    CRM_CLIENT_BANK_ACCT

    TXNSTAT = ‘C’

    Bank_Acct_id

     

    ACC

    Client_id is based on External_Id which is being sent as CUSTNO

     

    CUSTNO

    Acct_Stat should change to ‘C’

     

     

    Closing_Date: Should be defaulted as Current Business Date on receipt of TXNSTAT as ‘C’

     

     
  3. CASA Accounts modified in FCUBS for the following fields, would also trigger a Modification XML and the system updates following fields in FCPB:

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    CRM_CLIENT_BANK_ACCT

    TXNSTAT = ‘O’

    Bank_Acct_id

     

    ACC

    Acct_CCY

     

    CCY

    Acct_Sub_Type

     

    ACCTYPE

    Update Client_id based on External_Id which is being sent as CUSTNO

     

    CUSTNO

    Opening_Date

     

    ACCOPENDT

    Acct_Branch

     

    Branch_Code

    Acct_Country_id

     

    Country_Code

    Acct_Description

     

    ADESC

Note

The CUSTNO can be modified only if no transactions have yet happened on that CASA account which means that once FCPB receives a CASA Balance Notification, there is no possibility of modifying the CUSTNO for that CASA account.

However, if a CASA account has been created with ‘0’ balance and a few days later, FCUBS user realises that an error has occurred in mapping the CUSTNO, then one may change the Customer Number which will trigger a Modification XML for CASA Account. For this scenario, FCPB also updates its own CRM_CLIENT_BANK_ACCOUNT table with the new/modified CUSTNO.

3.3.8 TD Account Creation

Following types of transactions related to TD are sent by FCUBS.

TD Transaction Types:

Whenever a TD gets booked in FCUBS, it is sent to FCPB by Online Notification.

The details of TD Account Creation Notification interface are given below:

3.3.8.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental online.
  2. Time Deposit would be created by FCUBS and the details will be handed off to FCPB.
  3. TD-New Account-Notify-MSG notification service would be used by FCUBS to hand-off the TD account details to FCPB.
  4. Once the notification message is received from FCUBS for creation of TD Account, the account details would be inserted into PMS_TRANSACTION, PMS_PORTFOLIO_HOLDING and PMS_TD_HOLDING_DETAILS tables.
  5. Once the account is created, the PMS_PORTFOLIO_HOLDING table is populated with Client Id, TD Account No, Market Value and Total Acquisition Cost columns with the deposit amount.
  6. PMS_TRANSACTION table would also store the details as mentioned above. The Bid-Ask indicator would be maintained as ‘B’ for the newly created TD account.
  7. PMS_TD_HOLDINGS_DETAILS table would also store details like Client ID, Portfolio ID, Sub Portfolio ID, Instrument ID, Prod ID, Balance, Currency, Maturity Date, Int_Rate, Tenor, Tenor_Dm, Account Status and Booking Date.
  8. Based on the XSD service used by FCUBS in transmitting the data to FCPB, the Tran_Type would be populated in PMS_TRANSACTION table. The Tran_Type would be inserted as ‘NEW’ in the PMS_TRANSACTION table.
  9. On insertion of the record in PMS_TRANSACTION table, advice would be generated for TD Account creation.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    TRAN_DATE

     

    ACCOPENDT

    TRAN_TYPE- to be defaulted to ‘NEW’

    Would be populated based on the xsd notification service received from FCUBS

     

    AMOUNT

     

    TDAMT

    AMT_CCY

     

    CCY

    CLIENT_ID

     

    CUSTNO

    SUB_PORTFOLIO_ID

     

    ACC

     

    SUB_PORTFO­LIO_ID(PMS_PORT­FOLIO_HOLDING)

     

    ACC

    CLI­ENT_ID(PMS_PORT­FOLIO_HOLDING)

     

    CUSTNO

    INSTRU­MENT_CCY(PMS_PORTFOLIO_HOLDING)

     

    CCY

    TOTAL_ACQ_COST (PMS_PORTFO­LIO_HOLDING)

    The TD deposit amount would be populated

    TDAMT

    MAR­KET_VALUE(PMS_PORTFOLIO_HOLDING)

    The TD deposit amount would be populated

    TDAMT

     

    CLIENT_ID(PMS_T­D_HOLDINGS_DE­TAILS)

     

    CUSTNO

    SUB_PORTFOLIO_ID

     

    ACC

    PROD_ID(it will have values like time deposit, call deposit etc)

     

    ACCLS(the same val­ues to be in sync with those values in FCPB)

    CURRENCY

     

    CCY

    MATURITY_DATE

     

    MATDT

    INT_RATE

     

    INTEREST_RATE under <Tddetails> sub­node

    TENOR

     

    DFTENOR

    TENOR_DM- to be defaulted to days

    Will be defaulted to D(days) since FCUBS would be sending the tenor details in days

     

    BOOKING_DATE

     

    ACCOPENDT

    Spread_Bps

     

    In Account Class for TD Product, define a UDF with FLDNAME as SPREAD (while creat­ing the TD Class) and the FIELD_VALUE for this UDF will contain the Spread

 

3.3.9 TD Modification

The details of TD Modification Notifications are given below:

3.3.9.1 Process Flow

The following steps are involved in the process:

  1. If an incorrect interest rate is entered by the operations person in FCUBS while booking a TD, the same can be corrected in FCUBS by invoking the TD Booking screen. This triggers a TD modification event, which is sent via an XML interface to FCPB. The Notification Code for such an operational modification event is <NOTIF_CODE>NOTIF_TDMOD_PB</NOTIF_CODE>.
  2. In ‘IC product preference screen (ICDPRMNT), “Main Interest Rate UDE” field should be maintained mandatorily as “TERM_RATE” UDE for FCUBS and FCPB integration. This UDE 'TERM_RATE' would be referred by FCPB to pick up the Modified Rate in TD Modification XML and updated in FCPB's INT_RATE column in PMS_TD_HOLDING_DETAILS

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    PMS_TD_HOLDINGS_DETAILS

    MATURITY_DATE

     

    MATDT

    INT_RATE

     

    UDE with value TERM_RATE

    TENO

     

    DFTENOR

Therefore, for any modification notification received from FCUBS, it should refer to these columns and update it with approriate values shown in the XML for that particular CPIS (CUSTNO, ACC).

3.3.10 TD Pre-Mature Withdrawal

The details of Customer CASA Account Balances Notifications are given below:

3.3.10.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be one time migration and daily incremental online.
  2. Whenever there is a pre-mature withdrawal of the deposit amount, FCUBS would notify FCPB on the same.
  3. The notif code to be used by FCUBS would be “NOTIF_ICREDM”.
  4. FCPB will insert the TD or CD transaction details for ‘PAR’ type of transaction into PMS_TRANSACTION. Based on the notif code, the system identifies the type and updates Tran_Type in PMS_TRANSACTION as ‘PAR’. The Bid_Ask_Indicator for ‘PAR’ transactions would be ‘S’ which means Transaction Processor should handle ‘PAR’ like a Sell transaction.
  5. Since the amount received in the PAR transaction will be the Withdrawn principal, the balance Principal will have to be calculated (as balance = previous balance from PMS_TD_HOLDINGS_DETAILS – withdrawal amount) and updated in PMS_PORTFOLIO_HOLDING with Buy Cost and Market Value (and all related fields like ACQ_COST_CL also reduced accordingly). Also PMS_TD_HOLDINGS_DETAILS to update fields like balance with the current balance principal after the partial withdrawal.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    Updation in PMS_TRANSACTION

    TRAN_TYPE- to be defaulted to ‘PAR’

    Would be populated based on the xsd notifica­tion service received from FCUBS

     

    AMOUNT

     

    REDEMPTION_AMT

    VALUE_DATE/Tran_Date

     

    CHECKERDT

    AMT_CCY

     

    ACCOUNT_CCY

    CLIENT_ID

     

    CUSTNO

    SUB_PORTFOLIO_ID

     

    TERM_ACNO

    Updation in PMS_PORTFOLIO_HOLDING

    TOTAL_ACQ_COST (PMS_PORTFO­LIO_HOLDING)

    Reduce the TD Buy Cost by the PAR Amt received i.e. by the REDEMP­TION_AMT

     

    MAR­KET_VALUE(PMS_PORTFOLIO_HOLDING)

    Reduce the TD Mar­ket_Value by the PAR Amt received i.e. by the REDEMPTION_AMT

     

    VALUE_­DATE(PMS_PORTFO­LIO_HOLDING)

     

    CHECKERDT

    Updation in PMS_TD_HOLDINGS_DETAILS

    BALANCE

    Reduce the BALANCE by the PAR Amt received i.e. by the REDEMP­TION_AMT

     

3.3.11 TD Rollover

The details of TD Rollover interface are given below:

3.3.11.1 Process Flow

The following steps are involved in the process:

  1. The Frequency of this notification would be daily incremental EOD.
  2. Time Deposit which are of Rollover type, would be auto-rolled over in FCUBS and the details would be handed off to FCPB as a part of FCUBS BOD in a new file format (Rollover Format)
  3. Even manual Rollovers performed by Operations at FCUBS end would be sent to FCPB using the same XML Rollover Format.
  4. Once the Rollover notification message is received from FCUBS, the transaction details would be inserted into PMS_TRANSACTION and updated in PMS_PORTFOLIO_HOLDING and PMS_TD_HOLDING_DETAILS tables.
  5. On rollover, PMS_PORTFOLIO_HOLDING table would be updated for Market_Value and Settled_MktValue columns with the rollover amount. But the TOTAL_ACQ_COST column (and derived fields in Cust_CCY, Household_CCY, PF_CCY etc) should remain untouched as it should continue to indicate the original booked TD's Principal Balance.
  6. PMS_TRANSACTION table would also store the renewal details with Transaction_Type 'RNW' as mentioned above. The Bid Ask indicator (column in Pms_Transaction table) for a Rollover TD would be a B (buy).
  7. PMS_TD_Holdings_Details table would also be updated for BALANCE (same as Rollover Amount), MATURITY_DATE (being sent in the Rollover XML), INT_RATE (being sent in the Rollover XML) and Rollover Type.
  8. PMS_TD_Holdings_Details table should not be updated for Booking Date and it should continue to reflect the same date as the original TD Booking Date.
  9. Interest_Amount would also be mentioned in the Rollover XML and if this value is not blank, Transaction Processor would create an INT transaction in PMS_Transaction and update Holdings fields related to Interest like Dividend_Interest (and its Fx converted fields)
  10. As part of the EOD after the Rollover, none of the MAT/INT records for the Rolled-over TD are available in the UBS_TDMAT File.

    FCPB Column Name

    Description

    FCUBS Element Name (as per the XML)

    Updation in PMS_TRANSACTION

    TRAN_DATE

    Indicating Rollover Date

    RENEWAL_DATE

    TRAN_TYPE- to be defaulted to ‘RNW’

    RNW

     

    AMOUNT

    Indicating Rollover Amount

    ROLLOVER_AMT

    VALUE_DATE

    Indicating Rollover Date

     

    AMT_CCY

    Rollover CCY

    CCY

    CLIENT_ID

     

    CUST_NO

    INTEREST_AMOUNT

    TP to create a Txn 'INT' based on this value

    ACCR_INT_BAL

    SUB_PORTFOLIO_ID

    TD Reference Number

    ACC

    Updation in PMS_PORTFOLIO_HOLDING

    SUB_PORTFOLIO_ID (PMS_PORTFO­LIO_HOLDING)

    To be referred just for identi­fying the CPIS record and NOT for upda­tion

     

    CLIENT_ID (PMS_PORTFO­LIO_HOLDING)

    To be referred just for identi­fying the CPIS record and NOT for upda­tion

     

    MARKET_VALUE AND SETTLED_MKT­VALUE (PMS_PORT­FOLIO_HOLDING)

    The TD roll­over amount would be pop­ulated

    ROLLOVER_AMT

    VALUE_DATE (PMS_PORTFO­LIO_HOLDING)

     

     

    Updation in PMS_TD_HOLDINGS_DETAILS

    CLIENT_ID (PMS_T­D_HOLDINGS_DE­TAILS)

     

     

    SUB_PORTFOLIO_ID

     

    ACC

    PROD_ID (it will have values like time deposit, call deposit etc)

     

     

    BALANCE

     

    ROLLOVER_AMT

    CURRENCY

     

     

    MATURITY_DATE

     

    NEW_MAT_DATE

    INT_RATE

     

    INT_RATE

    TENOR

     

    TENOR

    TENOR_DM- to be defaulted to days

     

     

    ROLLOVER TYPE

     

    ROLLOVER_TYPE

3.3.11.2 Business Rules and Validations for TD interfaces

Only ‘Active’ transactions for TD are handled using the interface and Transaction Delete would not be handled.

Rules for Handling TD Interfaces are Mentioned Below:

  1. After a ‘NEW’ transaction is received on Booking a TD with a particular TD-reference-number, any other ‘NEW’ transaction with the same reference number and same client should be rejected with the reason ‘Duplicate Booking transaction with same reference number already exists’.
  2. After a ‘NEW’ transaction is received on Booking a TD with a particular TD-reference-number, any other MAT or PAR  transaction for the same reference number with Transaction Date earlier than Booking Date should be rejected with reason ‘This is a new transaction; cannot be a SELL’ . This rejection logic is in-built in the Transaction Processor of FCPB which rejects SELLs without having a BUY.
  3. After a ‘NEW’ transaction is received on Booking a TD with a particular TD-reference-number, any other INT  transaction for the same reference number with Transaction Date earlier than Booking Date should be rejected with reason ‘Corporate Action cannot happen with new Client ID, Portfolio ID, Instrument ID or Subfolio ID’. This rejection logic is in-built in the Transaction Processor of FCPB which rejects Corporate Actions like INT without having Holdings for that CPIS.
  4. Whenever a ‘PAR’ Transaction is received, the system should first check if the ‘PAR’ amount is more than the remaining balance principal and if ‘PAR Amount’ is greater than the Balance, The system should reject the record with the reason ‘Withdrawal amount cannot be greater than remaining balance principal’.
  5. Backdated INT, PAR or MAT transactions should be allowed by the system, so long as it doesn’t fail the other rules as mentioned in rules 2, 3, 4 above.
  6. For the specified currency given along with the transaction, if system does not find FX Rate maintained for Instrument Currency against with either Customer Currency, Portfolio Currency, Household Currency, then system should reject with the reason ‘No FX Rate available for specified currencies’.
  7. If default Portfolio is not found for the client, then system should reject with the reason ‘No default portfolio exists for the client’.
  8. If no Instrument of type ‘TD’ is setup for the specified currency, then system should reject using reason ‘No Instrument exists for the specified currency’.
  9. If no relevant setup for Instrument and the specified currency is present, then system should reject with the reason ‘No Instrument_ALT / MST_BANKING_PROD_ALT setup exists for the Instrument with specified currency’.
  10. There should be no validation related to Transaction_Date falling on a Holiday and no rejection should be done even if the transaction_date is a System/Currency/Exchange holiday.
  11. All typical reject reasons in Enrichment procedures should be handled like mandatory-field checks giving reject reasons like: Invalid Amount, Invalid Date, Invalid A/C No, Invalid Transaction Type etc.

3.4 Data Transfer using File Upload Mechanism

In addition to the online interface mechanism, there is certain data which is expected to be received from FCUBS as part of file upload. The list is as given below:

This section contains the following topics:

3.4.1 TD Maturity along with Interest Liquidation

FCUBS system uses the CSV Format to send the TD maturity related details. Maturity and Interest liquidation are separate records in the same file. The same interest file format is also used in case of interest payment for pre-mature full withdrawal and also in case of pre-mature partial withdrawal.

The processing logic is mentioned in the below table:

Fields in the file format

Insertion in Respective tables

PMS_PORTFOLIO_HOLDINGS

PMS_TD_HOLDING_DETAILS

PMS_TRANSACTION(for MAT txn)

PMS_TRANSACTION(for INT txn or PEN txn)

TRAN REF NO

Can be stored as Ext_Tran_Idn or Ext_Tran_Ref

Can be stored as Ext_Tran_Idn or Ext_Tran_Ref

CUS­TOMER_NO

Client_id

Client_id

Client_id

Client_id

CUS­TOMER_NAME1

ignored

ignored

ignored

ignored

ACC

Sub_portfolio_id

Sub_portfolio_id

Sub_portfolio_id

Sub_portfo­lio_id

ACCOUNT_CLASS

Based on Account class(whether it is TD or call deposit, instrument id and instrument type would be popu­lated)- details in FCPB_FS_­CASA_Includein­holdings_Rel2.1- section 8)

Based on Account class(whether it is TD or call deposit, instrument id and instrument type would be popu­lated)- details in FCPB_FS_­CASA_Includein­holdings_Rel2.1- section 8)

Based on Account class(whether it is TD or call deposit, instru­ment id and instrument type would be popu­lated)- details in FCPB_FS_­CASA_In­cludeinholdings_Rel2.1- section 8)

Prod_id

TRN_DT

Tran_Date

Tran_Date

Value_Date

Maturity_­Date

LCY_AMOUNT

Amount

Amount

Dividend_Inter­est

Mat_Princi­pal(new field to be intro­duced)

AC_NO

Indicates Dr/Cr AcctNumber n ignored

Indicates Dr/Cr AcctNumber n ignored

ignored

ignored

AC_CCY

Amt_ccy

Amt_ccy

Instrument_Ccy

Currency

RECORD_STAT

ignored

ignored

ignored

Account_sta­tus

TRANS­ACTION_TYPE

Tran_­Type=should be defaulted to MAT

Tran_­Type=should be defaulted to INT/PEN

ignored

ignored

Addi­tional Attributes

BIDASK_IND field would be defaulted as S

TOTAL_ACQ_­COST, MAR­KET_VALUE, ACCRUED_INT, ACQ_­COST_CL, ACQ_­COST_PF, ACQ_­COST_SC would be made as zero

BALANCE field would be made as zero

FCUBS system sends the TD maturity related details as a part of their BOD process to ensure that the data of the TDs maturing on that particular date or TDs which have INTEREST transactions liquidated on that date should be received by FCPB on the BOD of that particular date for further processing.

3.4.2 Daily Accrued Interest on TD

FCUBS uses CSV Format to send the daily accrued interest details.

The processing logic for the same is mentioned below:

Fields in File Format

Insertion in Respective Tables

 

PMS_PORTFOLIO_HOLD­INGS

PMS_TD_HOLDING_DE­TAILS

CUST_NO

Client_Id

Client_Id

SHORT_NAME

Ignored

ignored

ACC

Sub_portfolio_id

Sub_Portfolio_Id

ACCOUNT_CLASS

Based on Account class (whether it is TD or call deposit, instrument id and instrument type would be pop­ulated) - details in FCPB_FS_­CASA_Includeinholdings_Rel2.1- section 8)

Prod_Id

ACCRUED_AMOUNT

Accrued_Int

Accr_Int

ENT_DATE

Value_Date

LAST_INT_ACC_DATE

CCY

Instrument_CCY

Currency

RECORD_STAT

Ignored

Account_Status

PROD

Ignored

Ignored

3.4.3 Penalty on TD (applicable in case of pre-mature partial withdrawal and pre-mature complete withdrawal)

FCUBS supplies applicable Penalty details in the TD MATURITY file handoff itself. It would be sent immediately in case of a pre-mature full withdrawal (not as part of EOD process). But in case of pre-mature partial withdrawal, it would be sent as part of maturity EOD, when the complete amount is withdrawn.

The processing logic is mentioned below:

Fields in File Format

Insertion in Tables

 

PMS_TRANSACTION (for PEN txn)

CUSTOMER_NO

Client_Id

CUSTOMER_NAME1

Ignored

ACC

Sub_portfolio_id

ACCOUNT_CLASS

Based on Account class whether it is TD or call deposit, instrument id and instrument type would be populated.

S_TRANSACTION_TYPE

Tran_Type = should be defaulted to PEN

TRN_DT

Tran_Date

LCY_AMOUNT

Amount

ACC_CCY

Amt_CCY

AC_NO

Bank_Acct_id

RECORD_STAT

Ignored

3.4.4 Loan and Liability Information

FCUBS uses CSV Format to hand-off the loan and liability information:

All the relevant fields are inserted into PMS_PROD_BAL table. An entry is also made in CRM_CLIENT_BANK_ACCT as well. The details are mentioned below:

The processing logic is mentioned below:

Fields in File Format

Insertion in Respective Tables

 

CRM_CLIENT_BANK_ACCT

CUSTOMER_ID

Client_id

ACCOUNT_NUMBER

BANK_ACCT_ID

PROD

Acct_Typ

ACCT_ADDRESS

Ignore ACCT_ADDRESS and default Address from MST_BANK

For a liability product, the portfolio id would not be populated in CRM_CLIENT_BANK_ACCT (as it is currently being followed in the application).

While updating the Amount column in PMS_PROD_BAL table, if the Amount provided in the Prod Bal file for LIABILITY type of Prod ID (by referring MST_BANKING_PROD table's ASSET_LIAB_IND as 'L') is a positive value, it is updated with a negative sign. FCUBS would be sending Loan/Liability Amounts as positive and hence these are inserted as negative values in the PROD_BAL table so that in the Networth portlet of Customer Dashboard, it gets deducted from Investment/Portfolio value to display the Total value.

3.5 Segment Upgrade/Downgrade Interfaces

Whenever a customer is upgraded to PWM set of segments, all his Accounts, Balances, TDs etc would be sent to FCPB as EOD File Handoffs. For Retail Customers who have not been assigned a Segment or Upgraded even once, no notifications or EOD File Handoffs would be sent to FCPB.

Also, once a customer is downgraded, the CIF Modification online interface would be sent by FCUBS to FCPB to inform about this downgrade. In this case, FCPB would update the Client_Status as 'S' (Suspended) in CRM_CLIENT_MASTER table. It also updates the newly introduced column Status_Description with description as 'Suspended due to Downgrade from Core Banking System'.

Suspended customers in FCPB are not allowed to place orders or trade though their Portfolio Details can be viewed via Portfolio Maintenance/Analysis screens etc. as per currently existing functionality in FCPB.

Note

Even if a customer gets downgraded, subsequent flow of TD-deal information/account no­tifications/balances notifications will continue to flow into FCPB from FCUBS.

If the downgraded customer gets re-upgraded in FCUBS, then the CIF Modification online interface would send the Status as ’Re-upgraded (R). This would prompt FCPB also to update the status back to 'A' (Active) and activate the customer for all normal activities in FCPB like Order Placement etc. In case of such re-upgrades, FCUBS does not send the set of files related to portfolio and other handoffs as part of the EOD Segmentation Upgrade to FCPB.

Additional Validations to Customer Creation screen to support Segmentation Upgrade:

  1. FCUBS would validate that when CIF creation is done for first time, the segment status cannot be ‘Downgrade’.
  2. If the RM (or any other user) who is creating the CIF decides to leave the segment related fields blank, then those customer data would not be handed-off to FCPB.
  3. FCUBS would also validate that once a customer is downgraded, later the status can only be changed to re-upgrade..  

It is assumed that no closed CASA account details would be handed off by FCUBS as a part of segmentation upgrade files.

Only online notifications are planned for CASA creation and modification and any field level change of CASA would trigger a modification. 

Note

As a part of customer upgrade files, FCUBS will not send any modification of accounts. It’s a one-time hand-off of all the accounts for the upgraded customer.

The set of interfaces/files for Segmentation Upgrade/Downgrade are detailed in the below sections.

This section contains the following topics:

3.5.1 Customer File Upload – Segmentation Upgrade

Once a customer gets upgraded as per the segmentation rules, FCUBS sends an online notification based on which customer gets created in FCPB. FCUBS also generates an EOD file handoff for these customers and sends it to FCPB. Subsequent updates to these customers will be received via online notifications.

Whenever a customer is created in FCPB, a script is executed which auto-creates the Login ID of the customer and makes an entry in SMS_APP_USER table. The Password field in SMS_APP_USER will be updated as blank and will not have any significance, since FCPB expects SSO for Customers from FCDB. The Role given to the customer would be the same as his Segment (after appropriate transaction transformation to FCPB's specific Segment Codes). For supporting this, Roles would have to be created for every segment which can be mapped as Customer Role and the name of these roles would be identical to the Segment.

EXT_Portfolio_Id - In the current Rel12.0, FCPB assumes that the Bank will create only one Investment Portfolio for each Customer and hence multiple Portfolio IDs will not be supported, at FCUBS end.

Note

FCPB must pick CUSTOMER_MASTER_SEGUP.csv file first and then CASA_AC­COUNT_CREATE_SEGUP.csv before picking up any other feeds from shared location.

3.5.2 Customer Account File Upload – Segmentation Upgrade

Once the customer gets upgraded as per the segmentation rules, FCUBS will generate an EOD file handoff for these Customer Accounts to be uploaded into FCPB. Subsequent modifications to these Customer Accounts then get updated via online notifications.

The Customer's preferred address would be sent to FCPB from FCUBS as a part of the CASA Account creation/modification XML notification as well as via Segmentation Upgrade file. Since Acct_Address is a part of the Branch setup/screen and not part of the FCUBS CASA Account screen, the Acct_Address cannot be sent. Hence FCPB must ignore these address fields and it should default CASA_Account related tables with Home Bank's Address (as maintained in MST_BANK table).

3.5.3 Customer Balances File Upload – Segmentation Upgrade

Once a customer gets upgraded as per the segmentation rules, FCUBS will generate an EOD file handoff for these customer balances to be uploaded into FCPB. Separate files for CASA Balances and Liabilities Balances would be sent by FCUBS. Subsequent modifications to these customer balances then get updated via online notifications.

Processes then get triggered to copy Settled_Market_Value from Market_Value column in PMS_PORTFOLIO_HOLDINGS since CASA Instrument Type does not require any separate Settlement.

For Liabilities Balances which are being sent in the UBS_SEG_PRODBL file while updating the Amount column in PMS_Prod_Bal table, if the Amount provided in the Prod Bal file for LIABILITY type of Prod ID is a positive value, it is updated with a negative sign in the Prod_Bal table so that in the Networth portlet of Customer Dashboard, it gets deducted from Investment/Portfolio value to display the Total value.

3.5.4 Customer TD Deals File Upload – Segmentation Upgrade

Once a customer gets upgraded as per the segmentation rules, FCUBS will generate an EOD file handoff for all customer TD deals to be uploaded into FCPB.

Following are the different File uploads which would be sent by FCUBS. For TD, three types of files would be received by FCPB as a result of Segmentation Upgrade:

Transactions/Deals for new Bookings, Partial Uplift and Rollovers called TD-DEAL Booking

Since it is a common format being proposed for all the 3 transaction types, certain fields would be mandatory for specific Tran_types.

Example: Spread is mandatory only for Booking Transaction Type and not for PAR or RNW. Similarly, Rollover Type is mandatory only for RNW transaction types.

Since these are post settled deals which are indicative of the fact that the advice has already been generated and sent across to the customer, FCPB will not generate advices for the same.

Spread is also one of the expected fields in the Segmentation Upgrade format for TD Booking. To capture Spread (in BPS) at FCUBS end, the Account Class for TD Product is created with a UDF with FLDNAME as SPREAD and the Field_Value for this UDF will contain the Spread. This Field_Valule would also be sent in the Segmentation Upgrade file.

Transactions for Interest, Penalty and Maturity: Called TD-DEALMAT

The same format would be used for EOD batch handoff and customer upgrade handoff for the TD Maturity/Interest/Penalty file.

FCUBS will only send Active TDs as part of Segmentation Upgrade handoffs. No Closed/Matured TD Bookings or any other transactions/Holdings regarding Matured TDs would be sent.

For NEW, PAR, RNW, INT, MAT and PEN records received as part of Segmentation Upgrade, system updates the Settlement Flag as 'Y' in PMS_TRANSACTION. Processes then get triggerred to copy Settled Market Value from Market_Value column in PMS_PORTFOLIO_HOLDINGS since TD Instrument Type does not require any separate Settlement.

Since this is indicative of the fact that the advice has already been generated and sent across to the customer, FCPB will not generate advices for the same.

Holdings level file with Accrued Interest as of Date for TD:

Since Accrued Interest is already sent everyday as a part of EOD from FCUBS to FCPB, there would be no separate file to be sent specially for Segmentation Upgrade. The same process of sending Accrued Interest file as explained in earlier section on Daily Accrued Interest on TD would be sent to capture the Accrued Interest by FCPB.

FCUBS will only send Active TDs as part of Segmentation Upgrade handoffs. No Accrued Interest for Closed/Matured TDs would be sent.

Subsequent lifecycle of these deals will be via online notifications as is present today

3.5.5 Customer Online Notification – Segmentation Downgrade

Once a customer gets downgraded as per the segmentation rules, FCUBS will generate an online Customer Modification notification with the status as 'D' or 'Downgraded'. Even if a customer gets downgraded subsequent flow of deal information/account notifications/balances notifications will continue to flow into FCPB from FCUBS.

After a downgrade, FCPB would update the Client_Status as 'S' (for Suspended) in CRM_Client_Master and default a newly introduced column in CRM_Client_Master called ' Status_Description with 'Suspended due to Downgrade from Core Banking System'. Suspended customers in FCPB are not allowed to place orders or trade (i.e. place Deals), though their Portfolio Details can be viewed via Portfolio Maintenance/Analysis screens etc.

Once a customer gets downgraded, it may also happen that the same customer gets re-upgraded later. In such cases, though FCUBS would send the online notification of re-upgrade via the Customer Modification XML, at EOD it restricts the Segmentation Upgrade set of files and does not send the same to FCPB. If FCUBS sends these files after re-upgrade, they would get rejected as duplicates in FCPB.

Once FCPB receives such a Modification XML wherein Status is changed to 'Active'/'Re-upgrade' for a customer who is currently in 'Suspended' status in FCPB, FCPB would update the status in CRM_CLIENT_MASTER back to 'Active' and also update the Status_Description column to 'Re-upgrade from Core Banking System'. Once the status is 'Active', the customer would be able to do all activities permitted in FCPB for active customers like placing of orders and transactions etc.

3.6 Assumptions

  1. It is assumed that FCUBS EOD process would run and get completed before triggering the FCPB EOD process. All the Interface-related processing for Segmentation-Upgrade/Recon that is required to be handled by FCPB would be triggered as a part of FCPB's EOD process.
  2. Create Customer with From FCUBS Mode: Create Customer Menu would be removed in FCPB so that customer creation only happens from FCUBS. Common REF tables in FCPB and FCUBS have to be synchronized via Transaction_Transformation screen so that FCPB's internal names/values are mapped to FCUBS's names. These are: REF_CLIENT_SEG, REF_CLIENT_STATUS, REF_CLIENT_IT_TYPE, REF_CLIENT_CLASSIFICATION, REF_CLIENT_CATEGORY
  3. In FCUBS, customers can be created quickly via the STDCIFAD screen also and following is the expected Operational workflow to be followed for the same
    • If a customer is created in FCUBS via the STDCIAD screen and later if such a customer is designated as a Wealth customer via the Segmentation screen, then the Bank Operations user should remember that the STDCIFAD screen does not have an RM Id Field, which is a mandatory/important field for FCPB integration.
    • Hence the user has to first go to the Modify Customer screen in UBS and enter the RM Id
    • Then go to the Segment Association screen and fill in the other details like Segment, Upgrade Status etc
    • Only if the above workflow is followed, Customer Creation notification would be accepted by FCPB successfully.
  1. FAC Setup to support Create Customer from FCUBS: All Mandatory Fields coming from FCUBS should be kept non-modifiable in FAC for Demographics screen. This is to make sure that user is not allowed to modify any of the fields which are mandatorily being sent by FCUBS and present in the Create Customer XML (like External Id, Home Address, Status, Acquisition Date, Segment etc). However, the user should be allowed to modify any field which is exclusively maintained by FCPB (and not by FCUBS) like Client Entity, Hobbies, Preferred Communication Mode etc. or even non-mandatory fields like Occupation, Work Address, First Name etc. These fields need to keep modifiable in FAC and Demographics screen. These should be handled by the Implementation team using Field Access Controller screen and framework in FCPB.
  2. Create Customer for BROKER: If Customer_Category is 'BROKER', then even though the Segment is BLANK, FCUBS would send an online Customer Creation Notification to FCPB and FCPB would enter the details for a Broker in MST_Broker table. We assume that nobody would enter Segment in FCUBS screen for Broker category and in case if it is done by mistake, there would be Segmentation Upgrade files generated at EOD even for Broker, which would result in rejection of these records in FCPB. Hence for BROKER Category, Segment should not be filled in the FCUBS screen.
  3. Banker Id from FCUBS would be the Same as Wealth Department's RM: This is an assumption we are making that the same RM would service the customer from Core Banking and FCPB side. Because that's the only way we can map a customer's Primary RM after receiving Banker_Code from FCUBS (as a part of Customer Creation interface). Similar assumption is being made on Customer's Unit/Home Branch - Since FCUBS would be sending the customer's branch, the Branch/Unit Hierarchy in FCUBS and FCPB is assumed to be synchronized and the same.
  4. Synchronization of other REF tables: Few REF tables need to maintain same values in FCUBS and FCPB and this should be considered as a pre-requisite for every Implementation. These are viz. REF_CURRENCY, REF_COUNTRY, CRM_UNIT_MASTER, CRM_BANKER etc. For certain other tables like REF_CLIENT_CATEGORY, REF_CLIENT_IT_TYPE, REF_SEGMENT, PBS_LANGUAGE_SUPPORT etc, implementation team has to synch-up with FCUBS and maintain Transaction Transformation in FCPB for such entities.
  5. Role Setup in FCPB based on Segments Supported by the Bank: Roles would have to be created for every segment which are mapped as Customer Role and the name of these roles would be identical to the Segment. Whenever a customer is created in FCPB via the Create Customer XML from FCUBS, a script is executed to auto-create the Login Id of the customer and makes an entry in SMS_APP_USER table. The Role given to the customer would be the same as his Segment (after appropriate transaction transformation to FCPB's specific Segment Codes). For supporting this, Roles would have to be created for every segment which are mapped as Customer Role and the name of these roles would be identical to the Segment.
  6. Segmentation Upgrade Files: Since FCUBS has the capability to run multiple-EODs in different branches and Head Office, in order to avoid multiple Segmentation Upgrade Files being sent by each branch (for same customer or even for different customers); FCUBS has configured sending the Segmentation Upgrade files as part of Head Office's EOD Process only. This process will therefore collate data for all newly-upgraded customers across all Branches and send Customer Master/ Prod Bal/Accounts/CASA/TD-Deals in single consolidated files (for each entity-interface) no matter where the TD-Deal/Account originated.
  7. TD Booking: Only Fixed Interest Type of TDs and of Simple Interest Type would be supported in this release. No Floating TDs or Compound Interest Type would be supported. Dual Currency Deposits would also not be supported in this Release.
  8. TD Rollover: Only Rollover Types of Principal or Principal+Interest would be supported in this release. Special Amount Rollovers would not be supported.
  9. Recurring Deposit TDs: In this release, Top-Up event for Recurring Deposits would not be supported by FCPB. Recurring Deposits expects that an automatic top-up of the Deposit Booking Amount is performed by FCUBS as per the pre-determined top-up frequency, which should trigger a new XML/Notification with the top-up-amount mentioned. This Notification/workflow is not available in the current release between FCUBS and FCPB.
  10. Discounted TDs workflow in FCUBS: Discounted TDs are those wherein Interest is paid upfront to the Customer, FCUBS would be sending this INT transaction as a part of BOD of the Business Date after the Booking Date. Also Accrued Interest sent daily for such Discounted TDs would be ‘0’ everyday till 1 day prior to Maturity Date.
  11. TD with Interest Liquidation to TD A/C: In this release, there is a limitation to support TDs where Interest Liquidation is to TD Account instead of CASA Account. Such TDs are either capitalized /non-capitalized TD or Autorollover / Manual Rollover P+I TDs or Recurring Deposit TDs where again the Interest is credited to TD A/C. The limitation here is that in UBS full uplift is allowed to the extent of Principal + Interest Liquidated + Interest Accrued since last liquidation. However in FCPB, since Partial/Full uplift is allowed only to the extent of Balance Outstanding Principal, such withdrawals would get rejected in FCPB
  12. TD Modification: FCPB would be referring to the UDE named 'TERM_RATE' to pick up modified Interest Rate in TD Modification. Hence in IC product preference screen (ICDPRMNT), “Main Interest Rate UDE” field should be maintained mandatorily as “TERM_RATE” UDE for FCUBS and FCPB integration.
  13. Autorollover with Segmentation limitation: There is a limitation in case an operator segments a customer on a particular date and on the next date any of this customer's TDs get Auto-Rolled over. Such Rollover XMLs currently fail to be accepted by FCPB because the Segmentation details of the TDs booked have not yet been sent to PB at the time the Autorollover XML has reached FCPB. What this means is that RMs/Bank Operators need to be made aware that if they are integrating with FCPB, then if they are expecting an Autorollover anytime between next Calendar Date and Next Business Date (this will take care of Holidays in between today's date and Next Business Date also); then they should not be segmenting the Customer today. They should operationally ensure that such customers are segmented on the Next Business Date.
  14. Future Dated TD Booking limitation: In this release there is a limitation on opening TDs with account opening date in future. FCPB rejects any booking with future booking date. Hence in FCUBS if a TD is booked with pay in through Cheque and after considering Floating/Check Clearing days as say 2 days; the account opening date will consider the next business day which would be in the future. An enhancement may be taken up by FCPB in the future to allow such future dated TDs also.
  15. Zero Balance TD limitation: In FCUBS, TDs can be created with ‘0’ balance (i.e. Recurring Deposit TDs etc) wherein the Booking Amount is credited later. When such TD Booking XMLs are sent to FCPB, FCPB is accepting the TD and creating a Zero Booking Amount for the TD. This will however create a problem when customer tries to withdraw the TD in UBS later, and this PAR XML will be rejected by FCPB saying 'PAR amount cannot be greater than Balance Principal'.
  16. Customer Creation/Modification: For corporate clients in this release, FCPB can support only 1 Director and his details. If more than 1 director is input in FCUBS, FCPB is having capability to show only first one.