• Application Development methodology is developed by following ISO, CMM, and CMMI standard processes.more...
  • Application Development methodology is developed by following ISO, CMM, and CMMI standard processes.more...


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.

    • Account
    • RIM
    • Amount

 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.