DPS RTGS Solution (CBK KASSIP)
In this solution, DPS Kuwait offers the implementation of following features to achieve STP support for INCOMING and OUTGOING Swift and KASSIP messages.
Message Sources
Payment instruction or financial transaction will be received through following two systems:
Connection with KASSIP PS (CBK)
This will done using CBK “Intercommunication protocol” which will require WAN
access. IBK will provide a machine/server which is connected to CBK WAN using VPN.
Connection with SWIFT Alliance (IBK)
This will be done through accessing a file system available on LAN. No direct connection to SWIFT alliance network or SWIFT system is required. All the incoming messages are being exported in to a designated folder in CSVs format. Our application will hook to the folder and will consume messages. Exported CSVs file contains one to more message that what we need to explore yet.
Message destination
Payment instruction or financial transaction received from message sources mentioned above will be routed to its target machine/system based on the STP policy and message routing rules. This proposal is considering the following systems/applications to the destination of the message:
Destination Systems (example) Input Format
Phoenix Through XAPI
Mosaic File
Musketeer XML File
TradeWind Communication Queue
Supported Messages
Application will support following set of messages:
Type Description
103 Single Customer Credit Transfer
102 Multiple Customer Credit Transfer
202 General Financial Institution Transfer
203 Multiple General Financial Institution Transfer
205 Financial Institution Transfer Execution
900 Confirmation of Debit
910 Confirmation of Credit
950 Statement Message
999 Free Format Message
198 Proprietary Message
(Notification of success/failure of settlement in SETS of 1xx)
298 Proprietary Message
(Notification of success/failure of settlement in SETS of 2xx)
NOTE : other messages are also supported like 7XX, 9XX series pertaining to trade finance transactions
STP Policy
To provide proper control and flexibility application will provide STP Policy setup feature. Each message will be checked against policy and if it conforms to policy, message will be automatically get exported to its target system. Target system will be selected based on the type and content of the message. STP process will be performed based on STP policy. There are three parameters involved in specifying STP policy.
Note (Phoenix) : Incoming message doest not contain RIM in it and that will be retrieved from core banking system (Phoenix ) based on account number specified in message.
Integration with Anti-money laundry (AML)
To provide a complete secure and regulatory compliance system, proposed solution provided provision of integration with anti-money laundry system. This allows banks to block all malicious financial transaction to protect banks form any future liabilities.
Message Routing Rules
There are different types of messages and each message contains a specific detail about the transaction and its purpose. One type of message can go to different systems based on its content. For example message type 103 can also go to Phoenix and also to TradeWind. How to decide where to send is depend on the content of the message. We have to provide a mechanism/function so STP admin can specify such rules.
Message Error handling
To make system more flexible and introduce fault tolerance, error management is introduced in to the proposed system. Any message either containing insufficient information or containing wrong information will be put in error messages queue for further processing.
System will allow administrator/employee to view the message contents to analyze the missing or insufficient information with the capability to edit it and post/push it to target systems.
Note: Proposed system will not send back the corrected or amended messages back to the source it originated from (SWIFT or KASSIP-CBK). This is bank’s employee responsibility to inform about the changes made in messages to CBK or SWIFT which is manual process.
Scenarios in which Message Error Handling might occur:
-
Messages without account number
-
Messages containing wrong account number
-
Credit account correct but wrong debit account and vice versa
-
Messages containing more than one messages (i.e 102, 103) one with correct information and other wrong information
-
Messages containing instruction in Arabic
-
Information in messages for special agents field 72
Delete/remove a message
System will allow admin or bank employee to remove the message from the queue. System will log this activity and message will be dumped into database. System will not physically remove it from database or file system.
Application Administration
Application administration module will allow IBK admin (employee) to specify the STP policies, Message Routing rules and other administration tasks.
Old and new Account number
It is important to notice that SWIFT writes old account numbers in exported messages where as core banking system uses new account number. Luckily, Mosaic is maintaining the mapping of OLD vs New. We have to make use of this mapping to replace old with new before exporting it to Target System.