Bills and Collections User Guide

8.4.9 STP of MT742 – Reimbursement Claim

While processing MT742, initially, the system picks up Tag 21 of MT742 and checks if a valid LC contract is maintained. The LC contract is created if the corresponding MT740 is received. An MT742 received before MT740 and one received after MT740 are processed differently.

The system verifies whether the claim amount in MT742 is greater than the available amount in the underlying LC contract. If the amount is greater, the message is placed in ‘Pending Auth Receipt’ status with the repair reason ‘BC-FUND-NA’.

STP of MT742 generates bills contract in the ‘FINAL’ stage with the following attributes:

Operation of the related bills product is ‘PAYMENT’.
The bill amount is the sum of values in fields 32B and 33B.
The LC amount during booking of import bill is the value in field 32B
The LC liability amount is the sum of values in fields 32B and 33B.

While booking the import bill from an incoming MT742, the following details are inherited from the underlying LC as per (field 21):

Party Details
Our customer details
Our LC customer
Our LC reference
LC amount
LC liability amount in the 'Bills and Collections Contract Detailed' screen
The claiming bank of the contract matches the claiming bank of the existing LC.

The tenor details of the bills contract are picked up, as shown below:

The base date is fetched from the standard tenor maintained in BC product preferences.
Transit days are fetched from the transit days maintained for the BC product.
The maturity date is computed as base date + transit days.
The Nostro account is derived using SWIFT fields 57 and 58 in the following manner:
- If field 57 exists, the Nostro account maintained for the counterparty (as in field 57) will be used for crediting the amount claimed.
If field 57 is not present and field 58 exists, the Nostro account maintained for the counterparty (as in field 58) will be used for crediting the amount claimed.
If both fields 57 and 58 are not present, the Nostro account maintained for the counterparty (as in field 1) will be used for crediting amount claimed.

Values from the above mentioned fields are updated in the settlement message details of the Nostro account leg having the amount tag ‘BILL_AMOUNT’ or ‘BILL_AMT_EQIV’. Value of field 33B is stored as an FFT with FFT code ‘33ADDAMTCLMD’ under the message type ‘REIM_PAY_ADV’.

The system checks for the following during STP of MT742:

The mapped product should be of type ‘IMPORT’.
The operation of the bills product should be ‘PAYMENT’.
During the upload of bills contract, if the underlying LC is not present then the system will reject the record. The underlying LC is fetched using field 21.
Amount in field 32 cannot be more than the currently available amount of the LC.
Amount in field 33 cannot be more than outstanding liability amount of the LC.
The counterparty derived using field 52A or D should match with the counterparty of the party ‘ISSUING BANK’ defaulted from the underlying LC.
The counterparty derived using field 1(BIC of the sender) should match with the counterparty of the party ‘NEGOTIATING BANK’ defaulted from the underlying LC. If the party ‘NEGOTIATING BANK’ does not exist in the bill, then the party details of the same will be derived using field one and will be displayed in the party details of the import bill.
If the amount in field 34 is less than the sum of amounts in field 32 and field 33, the system will reject the record.

In case MT742 is received before MT740, the underlying LC contract will not be available in the system. In such instances, the system will place the MT742 in ‘Pending Auth Receipt’ status.

The STP process creates an authorized or unauthorized import bill based on the post upload status maintained in the Upload Source Preference screen.

Parent topic: Processes Running during Beginning of Day (BOD)