Payment Initiation Response

Response

XML format (ISO 20022 Customer Payment Status Report pain.002)

The ISO 20022 Customer Payment Status Report (pain.002) message is sent to the client to inform about the status of a payment instruction sent via LHV Connect with Payment Initiation (pain.001) message.

Customer Payment Status Report refers to the original Payment Initiation message and provides positive, negative and pending status updates to original payments. There can be many Customer Payment Status Reports per one Payment Initiation message - typically if any of the transactions was not accepted right away for any reason.

Payment status codes and descriptions

Statuses are reported on group level for the whole payment instruction (GrpSts and PmtInfSts tags) and separately for each payment (TxSts tag). Group level statuses are reported only in the first payment response message after the initial request. Further responses (if any) shall not contain GrpSts and PmtInfSts tags - you must process the result of every payment entry separately.

Group level statuses (OrgnlGrpInfAndSts.GrpSts and OrgnlPmtInfAndSts.PmtInfSts):

  • RJCT – all payments in original pain.001 Payment Information block have been rejected.

  • PDNG - pending, payments are pending on human intervention. Typically, waiting for SCA in the Internet Bank.

  • PART – if some of the payments in original pain.001 Payment Information block have reached one of the accepted statuses (ACSC, ACSP, ACWC), but some also rejected, then status is partially accepted.

  • ACSP - all payments in original pain.001 have reached at least one of the accepted statuses (ACSC, ACSP, ACWC), but not debited yet

  • ACSC - all payments in original pain.001 are debited from client’s account.

Single payment statuses (OrgnlPmtInfAndSts.TxInfAndSts.TxSts):

  • RJCT – rejected. Payment has been rejected (final status).

  • PDNG - pending. Payment is waiting for human intervention. Options: waiting for SCA in the Internet Bank or being reviewed by the Bank due to sanctions screening or manual corrections. More details below.

  • ACSP – accepted, settlement in process. Payment is being processed by the bank, it has not been debited from client account nor sent to clearing system. At least one more status update must follow (either accept or reject).

  • ACWC – accepted with change. Payment is being processed by the bank, it is not debited from client account. LHV has changed something about this payment. The reason for change is given in(3.25) tag. The changes are minor and do not harm the client’s intention. At least one more status is sent about this payment (either accept or reject).

  • ACSC – accepted, settlement completed and payment has been debited from client account. ACSC is typically the final status. In rare occasions it can be followed by RJCT - then already debited payment is credited back to the payment account.

XML Schema Validation

One of the first steps when generating the response for the original pain.001 message is actually validating the content of the XML according to the XML Schema Definition - XSD.

Depending on what Customer submitted and the validation results also the response message structure might be different:

  • In all cases when there is some fatal error with the payment initiation the response will contain OrgnlGrpInfAndSts.GrpSts = RJCT value.

  • When there are basic XML structure issues or the XML does not meet the XSD requirements the response message does not contain OrgnlMsgId reference - it is provided only when the XML can be fully parsed.

  • Customer should always find the relation between the original Payment Initiation request and Response first using Message-Request-Id and Message-Response-Id as including OrgnlMsgId is not guaranteed.

Samples

In this case there was a syntax error in XML - CdtrAcct.Id.IBAN value was not in correct format.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
    <CstmrPmtStsRpt>
        <GrpHdr>
            <MsgId>1000001941</MsgId>
            <CreDtTm>2024-05-20T08:08:51.865+01:00</CreDtTm>
            <InitgPty>
                <Id>
                    <OrgId>
                        <BICOrBEI>LHVBGB2LXXX</BICOrBEI>
                    </OrgId>
                </Id>
            </InitgPty>
        </GrpHdr>
        <OrgnlGrpInfAndSts>
            <OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>
            <GrpSts>RJCT</GrpSts>
            <StsRsnInf>
                <Rsn>
                    <Cd>NARR</Cd>
                </Rsn>
                <AddtlInf>Corrupted payment file:
Line 72, column 35, cvc-pattern-valid: Value '32234523 232342' is not facet-valid</AddtlInf>
            </StsRsnInf>
        </OrgnlGrpInfAndSts>
    </CstmrPmtStsRpt>
</Document>

Pending payments and human intervention

When payment receives PDNG status after ACSP status (payment is accepted by the customer or does not need SCA depening on the contract) it means that the payment needs human intervention and manual review. Depending on the case it can be a sanctions screening match or some other trigger that caused this. Direct communication with the customer might follow. When possible more details will be provided in the payment message narrative.

      <TxInfAndSts>
        ....
        <TxSts>PDNG</TxSts>
        <StsRsnInf>
          <Rsn>
            <Cd>NARR</Cd>
          </Rsn>
          <AddtlInf>In manual review</AddtlInf>
        </StsRsnInf>

When the manual intervention case is resolved the payment will continue normal flow and get ACSC or RJCT status depending on the decision and conditions.

Payment rejection due to account balance or limits

By default, all payments will be rejected right away when there is not enough free balance or payments limits to execute the payment. Only on special agreement with the customer system will continue to try executing such payments:

  • Every day all payments sent 00:00 - 18:00 (Estonian time) and partially accepted will be rejected 18:00+5 minutes (if conditions are not met by this time).

  • All payments sent 18:00 – 00:00 (Estonian time) and partially accepted will be rejected 5 minutes after sending.

Message structure (pain.002.001.10/pain.002.001.03)

Response message version depends on the message used to initialize the original payment.

  • If payment is initialized with old pain.001.001.03, then old pain.002.001.03 is provided in response.

  • If payment is initialized with new pain.001.001.09 then new pain.002.001.10 is provided in response.

Pain.002 schema file: pain.002.001.10.xsd.

Note: Old pain.002.001.03 and upcoming version pain.002.001.10 are very similar. Differences are mentioned in "LHV Requirement" column.

Group Header – mandatory, occurs once. Set of characteristics shared by all individual payments included in the status report message. Original Group Information And Status – occurs once. Refers to original Payment Initiation Group Level information. Transaction Information And Status – optional and repetitive. Includes information about the original payment and its status.

Message root

<CstmrPmtStsRpt>

Group header

MULT.MESSAGE ELEMENTXML TAGLHV Requirement

[1..1]

+GroupHeader

<GrpHdr>

[1..1]

++MessageIdentification

<MsgId>

Unique message id created by LHV.

[1..1]

++CreationDateTime

<CreDtTm>

Creation date and time.

[0..1]

++InitiatingParty

<InitgPty>

[0..1]

+++Identification

<Id>

[0..1]

++++OrganisationIdentification

<OrgId>

[0..1]

+++++AnyBIC

<AnyBIC>

LHV’s BIC. Note: In old version of pain.002.001.03 this field is named BIC

[1..1]

+OriginalGroupInformationAndStatus

<OrgnlGrpInfAndSts>

[1..1]

++OriginalMessageIdentification

<OrgnlMsgId>

Original pain.001.001.09 Group Level Message Id.

[1..1]

++OriginalMessageNameIdentification

<OrgnlMsgNmId>

Value ‘pain.001.001.09’.

[0..1]

++GroupStatus

<GrpSts>

Specifies the Group status of all payments in the original pain.001 message. Status codes explained above.

[0..n]

++StatusReasonInformation

<StsRsnInf>

[0..1]

+++Reason

<Rsn>

[1..1]

++++Code

<Cd>

If Group Status is RJCT, then filled with ‘NARR’. In this case, Additional Information is also filled.

[0..n]

+++AdditionalInformation

<AddtlInf>

If Reason Code is filled with ‘NARR’, error description is present here. See Group Level Errors.

[0..n]

+OriginalPaymentInformationAndStatus

<OrgnlPmtInfAndSts>

[1..1]

++OriginalPaymentInformationId

<OrgnlPmtInfId>

Original pain.001.001.09 Payment Information Id.

[0..1]

++PaymentInformationStatus

<PmtInfSts>

Specifies the Group status of one PmtInf block in the original pain.001 message. Status codes explained Status codes explained above.

[0..n]

++TransactionInformationAndStatus

<TxInfAndSts>

[0..1]

+++OriginalInstructionIdentification

<OrgnlInstrId>

Original payment order number.

[0..1]

+++OriginalEndToEndId

<OrgnlEndToEndId>

Not used.

[0..1]

+++TransactionStatus

<TxSts>

Payment status. Status codes explained above.

[0..n]

+++StatusReasonInformation

<StsRsnInf>

[0..1]

+++OriginalTransactionReference

<OrgnlTxRef>

Payment scheme information

[1..1]

++++PaymentTypeInformation

<PmtTpInf>

[1..1]

+++++ServiceLevel

<SvcLvl>

[1..1]

++++++Proprietary

<Prtry>

Payment scheme code - Code Set: Payment scheme.

[0..1]

++++Reason

<Rsn>

[1..1]

+++++Code

<Cd>

If Transaction Status is ACWC or RJCT, then ‘NARR’.

[0..n]

++++AdditionalInformation

<AddtlInf>

If Reason Code is ‘NARR’, then description or scheme reject code is given here. For Transaction Status ‘ACWC’, see Reason for Change; for Transaction Status ‘RJCT’, see Transaction Level Errors. For payment scheme error codes see Code Set: Payment Scheme Reject Codes.

[0..1]

+++AccountServicerReference

<AcctSvcrRef>

Unique payment ID assigned by the bank.

[0..1]

+++OriginalTransactionReference

<OrgnlTxRef>

[0..1]

++++Amount

<Amt>

[1..1]

+++++InstructedAmount

<InstdAmt Ccy="AAA">

[0..1]

++++RequestedExecutionDate

<ReqdExctnDt>

Execution date requested by client.

[0..1]

++++Debtor

<Dbtr>

[0..1]

+++++Pty

<Pty>

Note: In old version of pain.002.001.03 this element does not exist

[0..1]

++++++Name

<Nm>

Debtor’s name.

[0..1]

++++DebtorAccount

<DbtrAcct>

[1..1]

+++++Identification

<Id>

{Or

++++++IBAN

<IBAN>

Debtor’s IBAN or Virtual IBAN.

{Or

++++++Other

<Othr>

Debtor's non-IBAN account number (for example, UK account number).

Or}}

+++++++Identification

<Id>

Account number.

[0..1]

++++DebtorAgent

<DbtrAgt>

[1..1]

+++++FinancialInstitutionId

<FinInstnId>

[1..1]

++++++BICFI

<BICFI>

LHV’s BIC. Note: In old version of pain.002.001.03 this field is named BIC

[0..1]

++++CreditorAgent

<CdtrAgt>

[1..1]

+++++FinancialInstitutionId

<FinInstnId>

[1..1]

++++++BICFI

<BICFI>

Creditor’s bank BIC. Note: In old version of pain.002.001.03 this field is named BIC

[0..1]

++++Creditor

<Cdtr>

[0..1]

+++++Pty

<Pty>

Note: In old version of pain.002.001.03 this element does not exist

[1..1]

++++++Name

<Nm>

Creditor’s name.

[0..1]

++++CreditorAccount

<CdtrAcct>

[1..1]

+++++Identification

<Id>

[0..1]

++++++IBAN

<IBAN>

Creditor’s IBAN. UK Faster Payments - used when also payment request contained IBAN.

[0..1]

++++++Other

<Othr>

[1..1]

+++++++Identification

<Id>

Creditor’s account number which is not IBAN. UK Faster Payments - used when also payment request contained sort code + domestic account nr.

Error codes

Group level errors

GROUP STATUSADDITIONAL INFORMATIONDESCRIPTION

RJCT

Duplicate message.

Message with this id already exists.

RJCT

Duplicate message.

Duplicate payment information block in file.

RJCT

Uploading file failed. Faulty number of payments in file header.

Invalid Number Of Transactions in Header Level.

RJCT

Uploading file failed. Faulty control sum in file header.

Invalid Control Sum in Header Level.

RJCT

Uploading file failed. Faulty number of payments in Payment Information block.

Invalid Number Of Transactions in referenced Payment Information block.

RJCT

Uploading file failed. Faulty control sum in Payment Information block.

Invalid Control Sum in referenced Payment Information block.

RJCT

Uploading file failed. Faulty sender account [IBAN].

At least one IBAN or Virtual IBAN does not exist. First bad number encountered is added to error message.

RJCT

Corrupted payment file: [validation error description]

XML file doesn’t pass XSD validation. Reference to invalid value is given if possible.

RJCT

No rights to debtor’s account.

Transaction level errors

TRANSACTION STATUSADDITIONAL INFORMATIONDESCRIPTION

RJCT

Duplicate payment

RJCT

Account temporarily closed

RJCT

Account closed

RJCT

Creditor account is closed

RJCT

Reason not given

RJCT

Technical problem. Try again

RJCT

Invalid creditor address or name

RJCT

Incorrect account number

RJCT

Account number is not correct

RJCT

Invalid account number or sort code

RJCT

Creditor address is missing/not correct

RJCT

Invalid creditor name

RJCT

Missing or invalid reference

RJCT

Problem with amount. Contact bank

RJCT

Instant payment forbidden, try European payment

RJCT

Payment declined, try European payment

RJCT

Payment declined

RJCT

Payment declined. Regulatory reasons. Try European payment

RJCT

Reference number is invalid or returned for no reason, try European payment

RJCT

Other reason

RJCT

Reference number invalid.

RJCT

Cross-border payments from this account are prohibited.

RJCT

Invalid creditor’s name.

RJCT

Creditor's Correspondent BIC not valid.

RJCT

Invalid client account number / account not found.

RJCT

Payments from one Trader account to another are not allowed.

RJCT

Trader account. Not allowed currency.

RJCT

Description or reference number must be entered.

RJCT

Debtor's organisation identification code is faulty.

RJCT

Creditor's Bank BIC not valid.

RJCT

Creditor's organisation identification code is faulty.

RJCT

Creditor's account number not valid.

RJCT

Creditor's private person identification code is faulty.

RJCT

Insufficient daily limit available.

RJCT

Invalid currency.

RJCT

Payment to the same account.

RJCT

Payment to receiver account not allowed.

RJCT

Ultimate debtor's organisation identification code is faulty.

RJCT

Ultimate debtor's private person identification code is faulty.

RJCT

Insufficient monthly limit available.

RJCT

Correspondent Bank BIC not valid.

RJCT

Account and BIC country codes not matching.

RJCT

Account and BIC country codes not matching. Check the account number of the recipient and the BIC number of the recipient bank.

RJCT

Debtor's private person identification code is faulty.

RJCT

Insufficient funds available.

RJCT

Signature weight is less than 100%.

RJCT

Creditor account number is incorrect. IBAN is mandatory.

RJCT

Invalid payment order no.

RJCT

Other reason.

RJCT

Payment description is too long. Please use maximumcharacters.

RJCT

Please use Latin characters only.

RJCT

This BIC does not conform to the format. Enter the name and address of the creditor’s bank. Insert the creditor’s bank code (such as ABA or Fedwire) before the name of the creditor’s bank.

RJCT

Uploading file failed. Faulty sender account.

RJCT

Technical problem. Try again

RJCT

Requested by customer

RJCT

Payment declined. Regulatory reasons

RJCT

Incorrect creditor´s bank data

RJCT

Uploading file failed. Unparsable value in Instruction for Debtor Agent [InstrForDbtrAgt]

RJCT

RUB payment codes missing (INN, VO, KPP)

RJCT

Debtor's account not active.

Virtual IBAN exists, but is not active

RJCT

Invalid debtor's name

Virtual IBAN holder name does not match with payment order (PmtInf.Dbtr.Nm) or debtor name missing if payment is from indirect agent's existing account.

RJCT

Invalid return code

Invalid payment scheme return code is used

RJCT

Original payment not received

Payment to be returned does not exist

Previouspain.001.001.03 formatNextSamples

Last updated