3. HKFPS Processing
3.1 Outbound Credit Transfer Processing
3.1.1 OBPM Internal/External Queues
Exception queues are not applicable.
Transactions are logged in queue in case of any validation failure and upfront rejected with the appropriate error message depending on the stage at which transaction failed.
Below are the validation done on Save of the transaction:
Mandatory checks are done as per current functionality for processing outbound payments
Below fields are mandatory in the request for HKFPS outbound payment:
l Host Code
l Network Code
l Source Code
l Payer Account Number
l Payee Bank Clearing Code
l Payee Account Number
l Payee Mobile Number
l Payee Email ID
l Payee FPS ID
l Payee Name
l Transfer Currency
l Transfer Amount
l Instruction Date
3.1.3 Referential Integrity Check & Initial Validations
Following parameters are validated with the static maintenances available for existence of the values:
Network code: Validated against the static maintenances (PMDNWCOD) available.
Currency Codes: In HKFPS Network Currency preferences (PKDHKFNC), a record should be available for the Network Code, Network Currency combination. i.e HKD, RMB as required.
Host Code: This field is checked against valid host codes available in Host Code maintenance (STDHSTCD)
Transaction Branch Code: This has to be a valid branch maintained in system.
Debit Customer (Payer): This is validated to check whether customer number is valid and existing.
Customer Account (Payer): The customer account is verified to check whether it is valid and existing for the customer.
Transaction Branch - HKFPS Network Directory Check: To identify if the network is allowed for the bank branch clearing code (Transaction Branch), system performs below check:
l Derive the transaction branch clearing code from 'Branch Identifier for HKFPS Network (PKDHKFBR)' based on the transaction branch code.
l Check if the Network Directory key is maintained as same in the following screens/tables:
– Network Directory Key maintained at 'HKFPS Network Directory (PKDHKFDR)' for the derived transaction branch clearing code = Network Directory Key maintained at 'HKFPS Network Currency Details (PKDHKFNC)' for the corresponding network code- transfer currency.
l If the above condition is not satisfied, a proper error message is given 'Transaction Branch clearing code, Network Directory Key combination does not match the Network Currency - Network Directory combination.
On Us Transfer: If the payee account belongs to the same Bank and Host and Dispatch is not applicable, then 'On Us Transfer' flag is checked by the system during processing. This flag indicates that payee account is internal to Bank and dispatch to Network is not applicable.
If any of the above validation fails, transaction is rejected with proper error code.
3.1.4 Holiday Check & Date Derivation
Holiday Check i.e., Branch Holidays, Network Holidays are not applicable for outbound HKFPS payments if processing mode is real time as maintained in (PKDOCTPF).
Activation Date is derived as same as Instruction Date.
Future date as Instruction Date is not allowed. Transaction is rejected with proper error code.
If Instruction date is back-dated, Activation date is moved to Current date.
3.1.5 Network Validations & Special Character Replacement
Payer/Payee/Bank/Additional details entered for a payment transaction are validated against valid characters allowed for the network.
l HKFPS Allowed characters set: A-Z, a-z, 0-9
l HKFPS Allowed special characters: !@#$%^&*()_+{}|:<>?-=();',./
If fields contain any invalid HKFPS character, then transaction is rejected with proper error code. Following fields are validated:
l Payer Name, Payer ID
l Payee Mobile Number, Payee Email ID, Payee FPS ID, Payee Name, Payee ID
l Remarks
Special characters entered in a payment transaction are validated and replaced with specific characters as defined in Special Characters maintenance
Duplicate checks are done during transaction processing. Payment fields maintained for duplicate check in Source maintenance (PMDSORCE) are matched with all the payments booked within the duplicate period.
Booking date of the payments are considered for checking duplicate payments. Duplicate period is considered based on the number of days maintained for duplicate check for the source (PMDSORCE). If the maintenance is not available, no duplicate check is done.
Transaction is rejected with proper error code in case of duplicate transaction.
The following parameters are available for duplicate check:
l Payer Account : DBTR_ACC
l Payee Account: CRDTR_ACC (Mobile Number, Email ID, FPS ID is mapped to this element.)
l Transfer Amount: TFR_AMT
l Instruction Date: VALUE_DATE
l Payee Bank Clearing Code: CRDTR_BANK_CODE (For HKFPS, Clearing Codes are mapped for this element)
Below are the validations done on Authorization of the transaction:
Sanction check for HKFPS outbound payment transaction is done on payment activation date (current dated).
System verifies whether sanction check is applicable in Network Preferences, for outbound transaction type and initiates sanction check validation. Sanction check reference number is generated by system.
Out queue name for sending the sanction check relevant transaction details and In queue name for the response is fetched from 'Sanction Check System' maintenance.
Sanction Check system provides a response for the request. External system sanction status can be mapped to a system sanction status. This maintenance is available as part of Sanction Check Maintenance.
The system sanction status can be:
l Approved: Sanction check is approved by the external system
l Interim: Interim status or approval with override is received from external system
l Rejected.:This indicates that the contract failed sanction check.
If the sanction check response status for a payment transaction is 'Approved', then further processing continues.
If the sanction check response status is 'Interim' or 'Rejected' then transaction is rejected with proper error code.
The seizure functionality of parking the funds to Seizure GL applies if a transaction is rejected and “Seize on Reject” flag is enabled at Sanctions Check System maintenance.
During seizure processing, the customer account (for outbound)/Nostro or Clearing GL (for incoming) is debited and Compliance Suspense GL is credited. Transaction Charges are not computed. Dispatch/Message generation is skipped for outbound transactions. Transaction status is marked as 'Cancelled' and 'SC Seizure' flag at transaction level is marked as 'Yes'.
3.1.8 Small FX Limit Check & Currency Conversion
For a cross currency payment transaction where debit currency and transfer currency are different, exchange rate maintained for the transaction branch in the Core system is considered.
If Small FX limit is defined in HKFPS Outbound Credit Transfer Preferences' (PKDOCTPF), then the auto rate pick up happens only if the transfer amount is within the small FX limit.
Transfer amount is converted limit currency maintained using midrate of FX rate type linked and limit check is done.
Exchange Rate Type is based on HKFPS Outbound Credit Transfer Preferences' (PKDOCTPF), maintained. Buy/Sell indicator is derived by the system based on the currency pair maintenance available.
If the transfer amount is above the small FX limit specified, system checks whether External Exchange Rate is applicable in HKFPS Outbound Credit Transfer Preferences' (PKDOCTPF).
If external system is available the transaction details, then system interfaces with external system for receiving the exchange rate along with FX Reference Number.
Based on the response received, exchange rate is populated and further processing of transaction continues.
If Small FX limit is not maintained auto rate pick up is done for all cross currency payment transactions without any limit check.
Payment is rejected in the following cases with proper error code details:
l Exchange Rate derivation based on core system maintenance fails
l Small FX limit is breached and no external exchange rate system maintenance is available
For transactions received from UI input, exchange rate is already available as part of transaction details and no processing on exchange rate is done again.
Charge computation for HKFPS payment transaction is made based on the “External Pricing Applicable” flag set at Source Network Preferences level.
If External pricing is not applicable for the Source and Network combination, then Charge and tax for HKFPS Payment transaction is calculated based on the Pricing Code linked in the outbound credit transfer payment preferences (PKDOCTPF).
Pricing components applicable to the price code and the attributes like whether the component is a charge or tax, Pricing currency and the exchange rate type are derived from Pricing Code maintenance (PPDCDMNT).
For the payment source of the transaction and applicable service model of debit customer, pricing values are fetched from Pricing Value Maintenance (PPDVLMNT).
The pricing value record valid for current date only is considered. Any pricing value record maintained with a future effective date is excluded.
Charge components are processed prior to tax components involved. If a charge component is waived, the related tax also is waived automatically.
If “External Pricing Applicable” flag is set as Yes at Source Network Preferences, charge calculation is skipped and system captures the pricing details from External Pricing System.
If the pricing check response status is 'Interim' or 'Rejected', then transaction is rejected with proper error code.
Payments is sending debit accounting entries pertaining to payment amount and charge/tax amounts to external system for credit checks. ECA checks are done on activation date (current dated).
External Credit Approval is done for all the external accounts for which debit entries are getting posted. Debit account entry details are sent in JMS queues to external ECA system.
Transaction ECA status is updated based on the response received from the external system.
The ECA system is expected to validate the following and send the response:
l Existence of the account
l Currency of the account specified is correct
l Account belongs to the customer specified
l Account exists on the specified branch
l Account is authorized, active & open
l Account status is Normal i.e., not Dormant
l Debit is not restricted on the account
l Clear available balance in the account is greater than the transaction amount specified
l Amount block is successfully executed for the specified transaction amount. Expiry date of the transaction is transaction value date
If the ECA response status for a payment transaction is 'Approved', then further processing continues
If ECA validation fails i.e. the status is 'Interim' or 'Rejected', transaction is rejected with proper error codes.
3.1.11 Accounting Preferences Check
Before Messaging: If the accounting preference chosen for the Network is 'Before Messaging' as maintained in 'HKFPS Outbound Credit Transfer Preferences' (PKDOCTPF), the Message Generation and Handoff of Payment message is subsequent to debit/credit accounting for the outbound payment. However, the payment processor do not wait for the accounting success/failure response from Accounting/DDA system.
l In case of payment rejection as per pacs.002 response from network, Accounting reversal request is sent to DDA system and payment status is reversed.
On Confirmation from CI: If the accounting preference selected is 'On confirmation from ICL', the debit /credit accounting is passed only after the receipt of pacs.002 response from network. If the payment is rejected the balance block (ECA) reversal request is sent to DDA system.
Accounting entries: The following details are sent to accounting system in an xml format to External Accounting System as part of Debit/Credit liquidation:
|
Details in Accounting hand-off |
Debit Liquidation |
Credit Liquidation |
|---|---|---|
|
Accounting Event |
DRLQ |
CRLQ |
|
Amount Tag |
XFER_AMT |
XFER_AMT |
|
Transaction Account |
Payer Account |
Outward Clearing GL maintained in the Accounting code. If Nostro Account (Network Account) is maintained in (PKDOCTPF) that is considered |
|
Offset Account |
This is picked from the Debit Liquidation Accounting code maintenance. |
This is picked from the Credit Liquidation Accounting code maintenance. |
|
Transaction Currency |
Debit Account Currency |
Transfer Currency |
|
Transaction Amount |
Debit Amount |
Transfer Amount |
|
Transaction Date/Value Date |
Activation Date |
Activation Date |
|
Offset Currency |
Transfer Currency |
Transfer Currency |
|
Offset Amount |
Transfer Amount |
Transfer Amount |
|
Local Currency Amount |
If either transaction currency or offset currency is local currency, corresponding amount is handed off as local currency amount.
If not, transfer amount is converted to local currency in mid-rate. |
Local currency amount of DRLQ is used. |
Network Cutoff check is not applicable for outbound HKFPS payments if processing mode is real time as maintained in (PKDOCTPF).
3.1.13 Message Generation and Dispatch
Only 'Real Time' processing mode is supported.
System generates real-time dispatch of pacs.008 message with single payment transaction in HKFPS standard ISO 20022 format.
Message dispatch is done on activation date (current dated) for real time payments.
Before dispatch of the outbound pacs.008 message, system checks if the outbound payment is On-Us Transfer or not.
If the outbound payment is derived as 'On-Us Transfer' (Yes), then system further checks
l If 'Dispatch On-Us Transfer' flag is 'checked' or 'un-checked' at 'HKFPS Outbound Credit Transfer Payment Preferences screen (PKDOCTPF).
– If 'Y' (Checked), then system hand-off the outbound pacs.008 message to FPS.
– If 'N' (Un-checked), then outbound pacs.008 message is not handed off to FPS. Instead system automatically books an inbound credit transfer payment for the same.
On Us Transfer: Payer & Payee Account numbers are within the different branches of the same bank or within the same branch. A record for payee bank clearing code is present in 'Branch Identifier for HKFPS Network (PKDHKFBR)'.
l If the outbound payment is not a 'On-Us Transfer',
– Outbound pacs.008 message is handed off to FPS.
Notifications are posted asynchronously to Notification Queue in a generic xml format for payment status (and is available for consumption to external systems.
Applicable Notification events: PAYMENT_SUCCESS, PAYMENT_CANCEL, PAYMENT_CREDIT_CONFIRMED (on receipt of pacs.002).
The generated notifications can be viewed from Notification Browser (PMSNOTFY)
3.1.16 Inbound Pacs.002 Payment Settlement Message Processing
On receipt of incoming pacs.002, system matches to the original outbound payment based on 'Message ID'.
l Check <Document><pacs.002.001.08">, if <TxInfAndSts/TxSts> is 'ACSC' or not,
l Match based on <OrgnlMsgId> of incoming pacs.002 = <MsgId> of outgoing pacs.008
l and update the outbound CT payment settlement status (New Field in main) 'Settled', 'Rejected' or 'Pending' (i.e. pacs.002 message yet to be received).
|
Reason Code <TxInfAndSts/TxSts> |
Settlement Status |
Transaction Status |
|---|---|---|
|
If 'ACSC |
Settled |
Processed |
|
If Other than 'ACSC |
Rejected |
Rejected |
3.2 Inbound Credit Transfer Processing
3.2.1 OBPM Internal/External Queues
Exception queues are not applicable.
Transactions are logged in queue (except the below) in case of any validation failure and upfront rejected with the appropriate error message depending on the stage at which transaction failed:
l Sanction Check - However Payment is auto- rejected (with appropriate reject reason code) in case SC Response is 'Rejected', 'Interim'. None of the queue actions are allowed.
l EAC Check - However Payment is auto- rejected (with appropriate reject reason code) in case EAC Response is 'Rejected', 'Interim'. None of the queue actions are allowed.
l Exchange Rate Queue - Rate Input, Resend actions are allowed.
3.2.2 Message Upload - Account Branch/Host/Network/Transaction Type Derivation
Background job is available for reading the incoming pacs.008 message and to populate the data into staging table. Source code is derived as 'HKFPS'.(Hard-Coded Value)
System performs branch, network & value date resolutions at this stage.
Transaction Account Branch & Host Resolution:
l System derives the transaction account branch from the below tag in the incoming pacs.008 message:
l <CdtrAgt\FinInstnId\BICFI\ClrSysMmbId\MmbId>
l Above, transaction branch clearing code is compared with branch codes mapped in 'Branch Identifier for HKFPS Network (PKDHKFBR)'
l Once the branch code is identified, system checks Core maintenance for branches (STDCRBRN) to derive the linked Host code for the branch.
Network & Transaction Type Resolution
l Network Code is derived based on 'Network Directory Key' (Hard-Coded Value 'HKFPS') maintained in 'HKFPS Network Currency Details (PKDHKFNC)'.
l The Transaction type* is derived as 'Incoming' based on the network code maintained in 'HKFPS Inbound Credit Transfer Preferences' (PKDICTPF)
l * This term has been used as reference. There is no corresponding field.
Payment Value Date Resolution
l Holiday Check i.e., Branch Holidays are not applicable for inbound HKFPS payments if processing mode is real time as maintained in (PKDICTPF).
l Interbank Settlement Date <IntrBkSttlmDt> is considered as Instruction date for incoming payment.
l Activation Date is derived as same as Instruction Date.
l If Instruction date is back-dated, Activation date is moved to Current date.
Transaction reference number is generated as per existing logic.
Reference Numbers as received from incoming message are stored in the following fields:
l Transaction Identification stored in Original Transaction ID
l End to end Identification stored in End to End ID
l Clearing system reference stored in FPS Reference Number
Interbank settlement amount/currency is considered as transfer currency for incoming transactions
System performs mandatory field checks & referential integrity checks during transaction saving.
3.2.2.1 Payee Account Verification Check
System checks for the following from the incoming pacs.008 message:
l <LclInstrm><Prtry> ="SKIP_PYE_VRF".
l If the above condition is satisfied, in case of any subsequent validation failure during processing of inbound payments, system generates pacs.004 payment return message.
Below fields are mandatory for booking HKFPS incoming payment:
l Host Code
l Transaction Branch
l Network Code
l Source Code
l Payer Account Number
l Payer Bank Clearing Code
l Payee Bank Clearing Code
l Payee Account Number
l Transfer Currency
l Transfer Amount
l Instruction Date
3.2.4 Referential Integrity Check & Initial Validations
Following parameters are validated with the static maintenances available for existence of the values:
Network code: Validated against the static maintenances (PMDNWCOD) available.
Currency Codes: In HKFPS Network Currency preferences (PKDHKFNC), a record should be available for the Network Code, Network Currency combination. i.e HKD, RMB as required.
Host Code: This field is checked against valid host codes available in Host Code maintenance (STDHSTCD).
Transaction Branch Code: This has to be a valid branch in core maintenance.
Payee Customer Account: This is validated to check whether customer number is valid and existing.
Payee Customer Account: The customer account is verified to check whether it is valid and existing for the customer.
Duplicate checks are done during transaction processing. Payment fields maintained for duplicate check in Source maintenance (PMDSORCE) are matched with all the payments booked within the duplicate period.
Transaction is rejected with proper error code in case of duplicate transaction.
The following parameters are available for duplicate check:
l Payer Account : DBTR_ACC
l Payee Account: CRDTR_ACC (Mobile Number, Email ID, FPS ID is mapped to this element.)
l Transfer Amount: TFR_AMT
l Instruction Date: VALUE_DATE
l Payee Bank Clearing Code: CRDTR_BANK_CODE (For HKFPS, Clearing Codes is mapped for this element)
Sanction check for HKFPS incoming payment transaction is done on payment activation date.
If sanction is approved, the transaction is resumed with the further processing.
In case of seizure, Nostro account is debited, and the Seizure GL is credited. (No response is generated)
If the status is rejected, interim or timed out, the transaction is rejected. If SC status is,
l Rejected/Interim- Transaction is returned.
– System do not consider SC Final Response for the 'interim' status.
l Pending - OBPM awaits a response from SC system and based on the response received, it processes further as above.
For a cross currency payment transaction where debit currency and transfer currency are different, exchange rate maintained for the transaction branch in the Core system is considered.
If Small FX limit is defined in HKFPS Inbound Credit Transfer Preferences (PKDICTPF), then the auto rate pick up happens only if the transfer amount is within the small FX limit.
Transfer amount is converted limit currency maintained using midrate of FX rate type linked and limit check is done.
Exchange Rate Type is based on HKFPS Inbound Credit Transfer Preferences' (PKDICTPF), maintained. Buy/Sell indicator is derived by the system based on the currency pair maintenance available.
If the transfer amount is above the small FX limit specified, system checks whether External Exchange Rate is applicable in HKFPS Inbound Credit Transfer Preferences' (PKDICTPF).
If external system is available the transaction details, then system interfaces with external system for receiving the exchange rate along with FX Reference Number.
Based on the response received, exchange rate is populated and further processing of transaction continues.
If Small FX limit is not maintained auto rate pick up is done for all cross currency payment transactions without any limit check.
Payment is moved to Exchange Rate Queue in the following cases with proper error code details:
l Exchange Rate derivation based on core system maintenance fails.
l Small FX limit is breached and no external exchange rate system maintenance is available.
l Only Resend, Rate Input actions are allowed from the queue.
Credit entry details to payee account are sent to external DDA system for validating external account status.
Credit amount net of charges to be credited to customer account is sent in the JMS request header details. Details about transaction amount, transaction code, netting details and component wise charge details are also part of request message.
l If External Account Check is 'Approved', the transaction is marked as 'Processed'.
l If the EAC status is 'Rejected', 'Interim', then the transaction is returned.
l System do not consider EAC/DDA Final Response for the 'interim' status.
If the EAC status is 'Pending', OBPM awaits a response from EAC/DDA system and based on the response received, it processes further as above.
Charge/Tax computation is similar to HKFPS inbound transactions.
Internal pricing calculations is performed for the inbound payment, if applicable.
3.2.10 Debit/Credit Liquidation
Debit and credit liquidation is done based on the accounting code maintained in HKFPS Inbound Credit Transfer Preferences (PKDICTPF).
The following details are sent to accounting system in an xml format to External Accounting System as part of Debit/Credit liquidation:
|
Details in Accounting hand-off |
Debit Liquidation |
Credit Liquidation |
|---|---|---|
|
Accounting Event |
DRLQ |
CRLQ |
|
Amount Tag |
XFER_AMT |
XFER_AMT |
|
Transaction Account |
Inward Clearing GL maintained in the Accounting code. If Nostro Account (Network Account) is maintained in (PKDICTPF) that is considered. |
Payee Account |
|
Offset Account |
This is picked from the Debit Liquidation Accounting code maintenance. |
This is picked from the Credit Liquidation Accounting code maintenance. |
|
Transaction Currency |
Transfer Currency |
Credit Account Currency |
|
Transaction Amount |
Transfer Amount |
Credit Amount |
|
Transaction Date/Value Date |
Activation Date |
Activation Date |
|
Offset Currency |
Transfer Currency |
Transfer Currency |
|
Offset Amount |
Transfer Amount |
Transfer Amount |
|
Local Currency Amount |
Local currency amount of DRLQ is used |
If either transaction currency or offset currency is local currency, corresponding amount is handed off as local currency amount.
If not, transfer amount is converted to local currency in mid-rate. |
.
Notifications are posted asynchronously to Notification Queue in a generic xml format for payment status and is available for consumption to external systems.
Applicable Notification events: PAYMENT_SUCCESS.
The generated notifications can be viewed from Notification Browser (PMSNOTFY)