AdditionalPaymentInformation

camt.028.001.01

Scope The Additional Payment Information message is sent by an account servicing institution to an account owner. This message is used to provide additional or corrected information on a payment instruction or statement entry, in order to allow reconciliation. Usage The Additional Payment Information message provides elements which are usually not reported in a statement or advice (such as full remittance information or identification of parties other than the account servicing institution and the account owner.) It complements information about a payment instruction that has already been received, in the form of one or several entries of the original payment instruction. The Additional Payment Information message covers one and only one original payment instruction. If several payment instructions need further details, multiple Additional Payment Information messages must be used, one for each of the payment instructions. The AdditionalPaymentInformation message may be used as a result of two investigation processes and in a way outlined below.

• A Claim Non Receipt workflow raised by the creditor or recipient of the payment: This means that the payment instruction has reached the creditor or beneficiary. The account owner needs further details or correct information for its reconciliation processes. The Additional Payment Information can be used to provide the missing information.
• A Request To Modify Payment workflow raised by the debtor or one of the intermediate agents upstream: When the payment instruction has reached its intended recipient and the modification does not affect the accounting at the account servicing institution, this Additional Payment Information message allows the account owner to receive further particulars or correct information about a payment instruction or an entry passed to its account. The Additional Payment Information message cannot be used to trigger a request for modification of a payment instruction activity. A Request To Modify Payment message must be used. In other words, if a debtor or one of intermediate agent (excluding the account servicing institution of the creditor) realises the some information was missing in the original payment instruction, he should not use an Additional Payment Information but instead a Request To Modify Payment message. It is assumed that when an account servicing institution sends out an Additional Payment Information message, the institution is fairly confident that this will resolve the case. Therefore it does not need to wait for a Resolution Of Investigation message. Neither does the account owner, or whoever receives the additional information, need to send back a Resolution Of Investigation message. Positive resolution in this case is implicit. Both parties are expected to close the case. In the event that the problem does not go away, a party can re-open the case.

Message Construction

Every ISO20022 message has at the highest level what we call ‘building blocks’. Because the message is constructed as immutable records, the association is by composition. Below you can see the relationship between the message and its constituent building blocks: For comparison, see the ISO20022 official specification

classDiagram
     direction LR
%% AdditionalPaymentInformation recursion level 0 with max 0
AdditionalPaymentInformation *-- "1..1" CaseAssignment : Assignment
AdditionalPaymentInformation *-- "1..1" Case : Case
AdditionalPaymentInformation *-- "1..1" PaymentInstructionExtract : Underlying
AdditionalPaymentInformation *-- "1..1" PaymentComplementaryInformation : Information
  

Now, we will zero-in one-by-one on each of these building blocks.

Assignment building block

Identifies the assignment. Represents the assignment of a case to a party. Assignment is a step in the overall process of managing a case. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% CaseAssignment recursion level 0 with max 1
class CaseAssignment{
    Identification IsoMax35Text
    Assigner IsoAnyBICIdentifier
    Assignee IsoAnyBICIdentifier
    CreationDateTime IsoISODateTime
}
  

CaseAssignment members

Case building block

Identifies the case. Information identifying a case. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% Case recursion level 0 with max 1
class Case{
    Identification IsoMax35Text
    Creator IsoAnyBICIdentifier
    ReopenCaseIndication IsoYesNoIndicator
}
  

Case members

Underlying building block

Identifies the underlying payment instruction. Details of a payment instruction. The information contained in this component is sufficient to retrieve a payment instruction. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% PaymentInstructionExtract recursion level 0 with max 1
class PaymentInstructionExtract{
    AssignerInstructionIdentification IsoMax35Text
    AssigneeInstructionIdentification IsoMax35Text
    CurrencyAmount IsoCurrencyAndAmount
    ValueDate IsoISODateTime
}
  

PaymentInstructionExtract members

Information building block

Additional information to the underlying payment instruction. Additional information from the underlying payment instruction which cannot be transferred in a regular statement message. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% PaymentComplementaryInformation recursion level 0 with max 1
class PaymentComplementaryInformation{
    SenderToReceiverInformation IsoMax35Text
}
PaymentComplementaryInformation *-- "0..1" IRemittanceInformation3Choice : RemittanceChoice
PaymentComplementaryInformation *-- "0..1" PartyIdentification1 : Debtor
PaymentComplementaryInformation *-- "0..1" CashAccount3 : DebtorAccount
PaymentComplementaryInformation *-- "0..1" BranchAndFinancialInstitutionIdentification : FirstAgent
PaymentComplementaryInformation *-- "0..1" IAmountType1Choice : Amount
PaymentComplementaryInformation *-- "0..1" CashAccount3 : NostroVostroAccount
PaymentComplementaryInformation *-- "0..1" Intermediary1 : Intermediary
PaymentComplementaryInformation *-- "0..1" BranchAndFinancialInstitutionIdentification : FirstSettlementAgent
PaymentComplementaryInformation *-- "0..1" BranchAndFinancialInstitutionIdentification : LastSettlementAgent
PaymentComplementaryInformation *-- "0..1" BranchAndFinancialInstitutionIdentification : IntermediarySettlementAgent
PaymentComplementaryInformation *-- "0..1" PartyIdentification1 : Creditor
PaymentComplementaryInformation *-- "0..1" CashAccount3 : CreditorAccount
%% IRemittanceInformation3Choice recursion level 1 with max 1
%% PartyIdentification1 recursion level 1 with max 1
class PartyIdentification1{
    Name IsoMax70Text
}
PartyIdentification1 *-- "0..1" PostalAddress1 : PostalAddress
PartyIdentification1 *-- "0..1" IParty1Choice : Identification
%% CashAccount3 recursion level 1 with max 1
class CashAccount3{
    Type CashAccountType3Code
    Currency CurrencyCode
    Name IsoMax70Text
}
CashAccount3 *-- "1..1" IAccountIdentification1Choice : Identification
%% BranchAndFinancialInstitutionIdentification recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification *-- "1..1" FinancialInstitutionIdentification1 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification *-- "0..1" BranchData : BranchIdentification
%% IAmountType1Choice recursion level 1 with max 1
%% CashAccount3 recursion level 1 with max 1
class CashAccount3{
    Type CashAccountType3Code
    Currency CurrencyCode
    Name IsoMax70Text
}
CashAccount3 *-- "1..1" IAccountIdentification1Choice : Identification
%% Intermediary1 recursion level 1 with max 1
class Intermediary1{
    Role IsoMax35Text
}
Intermediary1 *-- "1..1" IPartyIdentification1Choice : Identification
Intermediary1 *-- "0..1" Account1 : Account
%% BranchAndFinancialInstitutionIdentification recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification *-- "1..1" FinancialInstitutionIdentification1 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification *-- "0..1" BranchData : BranchIdentification
%% BranchAndFinancialInstitutionIdentification recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification *-- "1..1" FinancialInstitutionIdentification1 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification *-- "0..1" BranchData : BranchIdentification
%% BranchAndFinancialInstitutionIdentification recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification *-- "1..1" FinancialInstitutionIdentification1 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification *-- "0..1" BranchData : BranchIdentification
%% PartyIdentification1 recursion level 1 with max 1
class PartyIdentification1{
    Name IsoMax70Text
}
PartyIdentification1 *-- "0..1" PostalAddress1 : PostalAddress
PartyIdentification1 *-- "0..1" IParty1Choice : Identification
%% CashAccount3 recursion level 1 with max 1
class CashAccount3{
    Type CashAccountType3Code
    Currency CurrencyCode
    Name IsoMax70Text
}
CashAccount3 *-- "1..1" IAccountIdentification1Choice : Identification
  

PaymentComplementaryInformation members

Extensibility and generalization considerations

To facilitate generalized design patterns in the system, the AdditionalPaymentInformation implementation follows a specific implementaiton pattern. First of all, AdditionalPaymentInformation impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, AdditionalPaymentInformationDocument implements IOuterDocument. Because AdditionalPaymentInformation implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type AdditionalPaymentInformation.

classDiagram
    class IOuterRecord
    AdditionalPaymentInformation --|> IOuterRecord : Implements
    AdditionalPaymentInformationDocument --|> IOuterDocument~AdditionalPaymentInformation~ : Implements
    class IOuterDocument~AdditionalPaymentInformation~ {
        AdditionalPaymentInformation Message
     }
  

Document wrapper for serialization

The only real purpose AdditionalPaymentInformationDocument serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:camt.028.001.01’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using AdditionalPaymentInformation.ToDocument() method. The returned AdditionalPaymentInformationDocument value will serialize correctly according to ISO 20022 standards.

classDiagram
    AdditionalPaymentInformationDocument *-- AdditionalPaymentInformation : Document
  

Sample of message format

This is an abbreviated version of what the message should look like.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.028.001.01">
    <camt.028.001.01>
        <Assgnmt>
            <!-- Assignment inner content -->
        </Assgnmt>
        <Case>
            <!-- Case inner content -->
        </Case>
        <Undrlyg>
            <!-- Underlying inner content -->
        </Undrlyg>
        <Inf>
            <!-- Information inner content -->
        </Inf>
    </camt.028.001.01>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_FNvJVtE-Ed-BzquC8wXy7w_-95467495"
  name="AdditionalPaymentInformation"
  definition="Scope&#xD;&#xA;The Additional Payment Information message is sent by an account servicing institution to an account owner.&#xD;&#xA;This message is used to provide additional or corrected information on a payment instruction or statement entry, in order to allow reconciliation.&#xD;&#xA;Usage&#xD;&#xA;The Additional Payment Information message provides elements which are usually not reported in a statement or advice (such as full remittance information or identification of parties other than the account servicing institution and the account owner.) It complements information about a payment instruction that has already been received, in the form of one or several entries of the original payment instruction.&#xD;&#xA;The Additional Payment Information message covers one and only one original payment instruction. If several payment instructions need further details, multiple Additional Payment Information messages must be used, one for each of the payment instructions.&#xD;&#xA;The AdditionalPaymentInformation message may be used as a result of two investigation processes and in a way outlined below.&#xD;&#xA;- A Claim Non Receipt workflow raised by the creditor or recipient of the payment: This means that the payment instruction has reached the creditor or beneficiary. The account owner needs further details or correct information for its reconciliation processes. The Additional Payment Information can be used to provide the missing information.&#xD;&#xA;- A Request To Modify Payment workflow raised by the debtor or one of the intermediate agents upstream: When the payment instruction has reached its intended recipient and the modification does not affect the accounting at the account servicing institution, this Additional Payment Information message allows the account owner to receive further particulars or correct information about a payment instruction or an entry passed to its account.&#xD;&#xA;The Additional Payment Information message cannot be used to trigger a request for modification of a payment instruction activity. A Request To Modify Payment message must be used. In other words, if a debtor or one of intermediate agent (excluding the account servicing institution of the creditor) realises the some information was missing in the original payment instruction, he should not use an Additional Payment Information but instead a Request To Modify Payment message.&#xD;&#xA;It is assumed that when an account servicing institution sends out an Additional Payment Information message, the institution is fairly confident that this will resolve the case. Therefore it does not need to wait for a Resolution Of Investigation message. Neither does the account owner, or whoever receives the additional information, need to send back a Resolution Of Investigation message. Positive resolution in this case is implicit. Both parties are expected to close the case. In the event that the problem does not go away, a party can re-open the case."
  registrationStatus="Registered"
  messageSet="_urpIICeJEeOCeO5e7islRQ"
  xmlName="camt.028.001.01"
  xmlTag="camt.028.001.01"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <messageBuildingBlock
    xmi:id="_FNvJV9E-Ed-BzquC8wXy7w_1337484755"
    name="Assignment"
    definition="Identifies the assignment."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="Assgnmt"
    complexType="_T9Dpetp-Ed-ak6NoX_4Aeg_588710247" />
  <messageBuildingBlock
    xmi:id="_FNvJWNE-Ed-BzquC8wXy7w_1326400714"
    name="Case"
    definition="Identifies the case."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="Case"
    complexType="_SpAnotp-Ed-ak6NoX_4Aeg_136183535" />
  <messageBuildingBlock
    xmi:id="_FNvJWdE-Ed-BzquC8wXy7w_1723515214"
    name="Underlying"
    definition="Identifies the underlying payment instruction."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="Undrlyg"
    complexType="_VQgOUtp-Ed-ak6NoX_4Aeg_-769020295" />
  <messageBuildingBlock
    xmi:id="_FNvJWtE-Ed-BzquC8wXy7w_-1310325832"
    name="Information"
    definition="Additional information to the underlying payment instruction."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="Inf"
    complexType="_PgmFMdp-Ed-ak6NoX_4Aeg_-1588306924" />
  <messageDefinitionIdentifier
    businessArea="camt"
    messageFunctionality="028"
    flavour="001"
    version="01" />
</messageDefinition>

ISO Building Blocks

The following items are used as building blocks to construct this message.