End-to-End Payment Processing

This process covers the payment processing workflow in Payment Engine: from importing payment transaction data, to fully automated straight-through processing (STP) in the Payment Processing, Routing Control, and Clearing Processing components, through to exporting external payment items for forwarding to an account management system.

STP stops only if errors occur during enrichment and validation and route processing that the system cannot handle automatically. In this case, the system sends exceptions to Exception Control. Exception handling is semi-automated; therefore, as soon as an error has been corrected, STP is resumed.

Note Note

This process is also relevant to cross-border payment processing; however, it does not include the process steps that are specific to cross-border payments. For more information, see Basic Cross-Border STP.

End of the note.

Process

The following steps give an example of a typical payment processing scenario:

When a financial institution receives a payment file from a customer, a periodic job or monitoring function in the file-management software recognizes that there is a new file to be sent to Payment Engine.

For more information, see File Handler (FS-PE-FH).
Based on the information in the file, such as channel, medium, format, path, and file name, the Input Manager recognizes and selects the correct format converter. The format converter reads the file, maps the input format to the Payment Engine metaformat, and stores the payment order in the Payment Engine database.

Note

Any information or fields in the original payment order that are not required for processing in Payment Engine can be stored in the File Handler Database. This ensures that the Output Manager still has all the original data available in case information about the incoming payment order is to be placed in an outgoing order after processing.

End of the note.

For more information, see File Handler Database and Input Manager.
The system checks the payment order in terms of formal and referential accuracy, material errors, and consistency. If required, the system enriches the payment information.

For more information, see Payment Processing (FS-PE-POP) and Enrichment and Validation.
The system sends the ordering party item (the debit side of a credit transfer) to route processing, where a route is determined. This route is always internal. It can lead directly to the internal account management system where the account of the ordering party is managed or it can lead first to an application that performs a credit-limit check.

The credit-limit check authorizes the payment based on the limit or the current amount available in the account of the ordering party. The requested amount is reserved, pending authorization. If the payment is authorized, Payment Engine forwards a reservation request to the account management system.
The system releases the payment order for processing (after successful authorization of the ordering party) and transfers the recipient items (the credit side of a credit transfer) of the payment order to route processing.

The system determines the route, the associated clearing agreement, and the value date agreement for each recipient item.

For more information, see Routing Control (FS-PE-RP).
The system transfers the recipient items to clearing and settlement, enriched with a reference to the routes, the clearing agreements, and the value date agreements.

The system uses the route and clearing agreement information to determine how the recipient items should be further processed.

For more information, see Clearing Processing (FS-PE-CP).
If a reservation request was sent for the ordering party item and all recipient items have been successfully posted, the reservation is changed to a posting request.

This completes processing of the incoming payment order in Payment Engine.
If the system placed recipient items in collectors to be forwarded as part of a batch, it monitors these collectors. It determines whether any of items fulfill the closing criteria, such as the maximum number of items and maximum total amount.

Note

The system constantly checks and updates the collectors by an independent process, separate from the primary process. The system also checks whether collectors need to be closed when a certain time limit is reached.

End of the note.
When a collector is closed, the system generates a clearing item (collector total) and routes the clearing item to the account management system that contains the clearing account (a nostro or vostro account) for posting.

Note

From this step, incoming payment orders can be finalized and final correspondence can be triggered. An incoming payment order is finalized when all payment items are finalized, that is, posted or assigned to an outgoing payment order and incoming processing is completed.

End of the note.
The system creates a new outgoing payment order that contains all payment items in the clearing collector and forwards the outgoing payment order from Clearing Processing to Output Manager in the Payment Engine metaformat.
Output Manager recognizes the correct format converter from the channel, medium, and target format information included in the outgoing payment order and maps the outgoing metaformat to the target format.

Note

All information and fields of the original payment order are available during mapping (partially read from the File Handler Database by the format converter and partially derived from the outgoing payment order in metaformat). Additionally, the system performs format-dependent checks on the outgoing payment order in the format converter.

End of the note.

For more information, see Output Manager.
Output Manager transfers the payment order to the relevant outgoing channel in the target format.