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:
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 |
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.
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:
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.
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 Segment |
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 Category |
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.
The following steps are involved in the process:
If there are any modifications at FCUBS end, a full screen response notification is sent to FCPB with the amended details.
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’.
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:
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:
The following steps are involved in the process:
The details of online notifications for Suspended Status Client are given below:
The following steps are involved in the process:
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 status 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 |
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:
The following steps are involved in the process:
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 identifying 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 |
The details of online notifications for CASA Account Creation are given below:
The following steps are involved in the process:
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_CLIENT_BANK_ACCT): Client_id is based on External_Id which is being sent as CUSTNO |
|
CUSTNO |
ACCT_CCY(CRM_CLIENT_BANK_ACCT) |
|
CCY |
ACCT_TYP(CRM_CLIENT_BANK_ACCT) |
Use existing logic of populating PROD_ID and Instrument_ID to identify ACC_TYP |
|
ACCT_SUB_TYPE |
|
ACCTYPE (to be parameterized 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 maintained 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 respective 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_client_portfolio for a particular client, 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 |
The details of Customer CASA Account Balances Notifications are given below:
The following steps are involved in the process:
FCPB Column Name |
Description |
FCUBS Element Name (as per the XML) |
SUB_PORTFOLIO_ID (PMS_PORTFOLIO_HOLDING) |
CASA Account no |
CUST_AC_NO |
Client_id (PMS_PORTFOLIO_HOLDING) |
CIF ID |
CUSTNO |
INSTRUMENT_CCY (PMS_PORTFOLIO_HOLDING) |
Currency of the CASA Account |
CCY |
VALUE_DATE (PMS_PORTFOLIO_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_PORTFOLIO_HOLDING) |
Actual Balance including unclear balances |
ACBALANCE |
MARKET_VALUE (PMS_PORTFOLIO_HOLDING) |
Balance available to be spent |
ACAVLBAL |
HOLD_AMOUNT (PMS_PORTFOLIO_HOLDING) |
The current balance minus available balance would give the blocked/hold amount |
ACBALANCE- ACAVLBAL |
The details of Customer CASA Closure/Modification Notifications are given below:
The following steps are involved in the process:
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’ |
|
|
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.
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:
The following steps are involved in the process:
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_PORTFOLIO_ID(PMS_PORTFOLIO_HOLDING) |
|
ACC |
CLIENT_ID(PMS_PORTFOLIO_HOLDING) |
|
CUSTNO |
INSTRUMENT_CCY(PMS_PORTFOLIO_HOLDING) |
|
CCY |
TOTAL_ACQ_COST (PMS_PORTFOLIO_HOLDING) |
The TD deposit amount would be populated |
TDAMT |
MARKET_VALUE(PMS_PORTFOLIO_HOLDING) |
The TD deposit amount would be populated |
TDAMT |
|
||
CLIENT_ID(PMS_TD_HOLDINGS_DETAILS) |
|
CUSTNO |
SUB_PORTFOLIO_ID |
|
ACC |
PROD_ID(it will have values like time deposit, call deposit etc) |
|
ACCLS(the same values to be in sync with those values in FCPB) |
CURRENCY |
|
CCY |
MATURITY_DATE |
|
MATDT |
INT_RATE |
|
INTEREST_RATE under <Tddetails> subnode |
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 creating the TD Class) and the FIELD_VALUE for this UDF will contain the Spread |
The details of TD Modification Notifications are given below:
The following steps are involved in the process:
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).
The details of Customer CASA Account Balances Notifications are given below:
The following steps are involved in the process:
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 notification 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_PORTFOLIO_HOLDING) |
Reduce the TD Buy Cost by the PAR Amt received i.e. by the REDEMPTION_AMT |
|
MARKET_VALUE(PMS_PORTFOLIO_HOLDING) |
Reduce the TD Market_Value by the PAR Amt received i.e. by the REDEMPTION_AMT |
|
VALUE_DATE(PMS_PORTFOLIO_HOLDING) |
|
CHECKERDT |
Updation in PMS_TD_HOLDINGS_DETAILS |
||
BALANCE |
Reduce the BALANCE by the PAR Amt received i.e. by the REDEMPTION_AMT |
|
The details of TD Rollover interface are given below:
The following steps are involved in the process:
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_PORTFOLIO_HOLDING) |
To be referred just for identifying the CPIS record and NOT for updation |
|
CLIENT_ID (PMS_PORTFOLIO_HOLDING) |
To be referred just for identifying the CPIS record and NOT for updation |
|
MARKET_VALUE AND SETTLED_MKTVALUE (PMS_PORTFOLIO_HOLDING) |
The TD rollover amount would be populated |
ROLLOVER_AMT |
VALUE_DATE (PMS_PORTFOLIO_HOLDING) |
|
|
Updation in PMS_TD_HOLDINGS_DETAILS |
||
CLIENT_ID (PMS_TD_HOLDINGS_DETAILS) |
|
|
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 |
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:
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:
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 |
||
CUSTOMER_NO |
Client_id |
Client_id |
Client_id |
Client_id |
CUSTOMER_NAME1 |
ignored |
ignored |
ignored |
ignored |
ACC |
Sub_portfolio_id |
Sub_portfolio_id |
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 populated)- details in FCPB_FS_CASA_Includeinholdings_Rel2.1- section 8) |
Based on Account class(whether it is TD or call deposit, instrument id and instrument type would be populated)- details in FCPB_FS_CASA_Includeinholdings_Rel2.1- section 8) |
Based on Account class(whether it is TD or call deposit, instrument id and instrument type would be populated)- details in FCPB_FS_CASA_Includeinholdings_Rel2.1- section 8) |
Prod_id |
TRN_DT |
Tran_Date |
Tran_Date |
Value_Date |
Maturity_Date |
LCY_AMOUNT |
Amount |
Amount |
Dividend_Interest |
Mat_Principal(new field to be introduced) |
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_status |
TRANSACTION_TYPE |
Tran_Type=should be defaulted to MAT |
Tran_Type=should be defaulted to INT/PEN |
ignored |
ignored |
Additional Attributes |
BIDASK_IND field would be defaulted as S |
TOTAL_ACQ_COST, MARKET_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.
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_HOLDINGS |
PMS_TD_HOLDING_DETAILS |
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 populated) - 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 |
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 |
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.
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 notifications/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:
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:
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_ACCOUNT_CREATE_SEGUP.csv before picking up any other feeds from shared location.
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).
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.
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
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.