STP of Inbound Messages
Inbound SWIFT payment and non-payment messages are received by the EMS module of Oracle Banking Payments and stored in the Inbound directory The STP function then reads and processes the messages.
The system first resolves the source code of the transaction and routes it to
a particular system (e.g. SWIF, COVR) or user defined queue based on the Cover Queue
Rule maintenance. For messages routed to SWIF queue, the STP function then creates
transactions of the following types for the payment messages:
- Inbound Customer Transfer
- Inbound Bank transfer
- Inbound Customer Transfer with Cover
- Outbound Customer Transfer (in case of Inbound Customer Transfer pass-through payment)
- Outbound Cover Transfer (in case of Inbound Cover Transfer pass-through payment)
- Outbound Bank Transfer (in case of Inbound Bank Transfer pass-through payment/ Inbound Bank Transfer for Own Accounts)
If the system is unable to resolve the Debit account, then the transaction is parked in Process Exception queue.
In case of any exceptions during the STP of an Inbound message, the message
is marked with Process Status as ‘Repair’.
Note:
- When an inbound MT 103/202 message is sent with a party identifier (which is a valid debit account in our books) in Field 53 and with a valid Reverse Message Agreement, then a fresh outbound payment is created.
- If the agreement is not valid or when the start /end date/ limit amount is breached, then the transaction is parked in Business Override queue.
- Since these messages are customer initiated, validations for Debit authority and Cover queue are skipped.
This sections contains the following sub-sections:
- Debit Account Resolution
For Reverse messages, the Field 53 is checked whether it has the account sub-field /D/ or / C/ or not. If the sub-field is present, then account number is picked ignoring the sub-field and reverse message check is done. - MT202 Unmatched Queue Validation
- External Validations for Advisory Messages
Parent topic: Straight-Through Processing