Iso20022

MandateAcceptanceReportV07

pain.012.001.07

Scope The MandateAcceptanceReport message is sent from the agent of the receiver (debtor or creditor) of the MandateRequest message (initiation, amendment or cancellation) to the agent of the initiator of the MandateRequest message (debtor or creditor). A MandateAcceptanceReport message is used to confirm the acceptance or rejection of a MandateRequest message. Where acceptance is part of the full process flow, a MandateRequest message only becomes valid after a confirmation of acceptance is received through a MandateAcceptanceReport message from the agent of the receiver. Usage The MandateAcceptanceReport message can contain one or more confirmation(s) of acceptance or rejection of a specific Mandate Request. The messages can be exchanged between debtor agent and creditor agent and between debtor agent and debtor and creditor agent and creditor. The MandateAcceptanceReport message can be used in domestic and cross-border scenarios.

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
%% MandateAcceptanceReportV07 recursion level 0 with max 0
MandateAcceptanceReportV07 *-- "1..1" GroupHeader80 : GroupHeader
MandateAcceptanceReportV07 *-- "1..1" MandateAcceptance7 : UnderlyingAcceptanceDetails
MandateAcceptanceReportV07 *-- "0..1" SupplementaryData1 : SupplementaryData

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

GroupHeader building block

Set of characteristics to identify the message and parties playing a role in the mandate acceptance, but which are not part of the mandate. Set of characteristics shared by all individual transactions included in the message. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% GroupHeader80 recursion level 0 with max 1
class GroupHeader80{
    MessageIdentification IsoMax35Text
    CreationDateTime IsoISODateTime
}
GroupHeader80 *-- "0..2" IAuthorisation1Choice : Authorisation
GroupHeader80 *-- "0..1" PartyIdentification135 : InitiatingParty
GroupHeader80 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : InstructingAgent
GroupHeader80 *-- "0..1" BranchAndFinancialInstitutionIdentification6 : InstructedAgent
%% IAuthorisation1Choice recursion level 1 with max 1
%% PartyIdentification135 recursion level 1 with max 1
class PartyIdentification135{
    Name IsoMax140Text
    CountryOfResidence CountryCode
}
PartyIdentification135 *-- "0..1" PostalAddress24 : PostalAddress
PartyIdentification135 *-- "0..1" IParty38Choice : Identification
PartyIdentification135 *-- "0..1" Contact4 : ContactDetails
%% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification
%% BranchAndFinancialInstitutionIdentification6 recursion level 1 with max 1
BranchAndFinancialInstitutionIdentification6 *-- "1..1" FinancialInstitutionIdentification18 : FinancialInstitutionIdentification
BranchAndFinancialInstitutionIdentification6 *-- "0..1" BranchData3 : BranchIdentification

GroupHeader80 members

Member name Description Data Type / Multiplicity
MessageIdentification Point to point reference, as assigned by the instructing party, and sent to the instructed party, to unambiguously identify the message. Usage: The instructing party has to make sure that MessageIdentification is unique per instructed party for a pre-agreed period.
CreationDateTime Date and time at which the message was created. IsoISODateTime - Required 1..1
Authorisation User identification or any user key to be used to check the authority of the initiating party.
InitiatingParty Party that initiates the mandate message. PartyIdentification135 - Optional 0..1
InstructingAgent Agent that instructs the next party in the chain to carry out an instruction.
InstructedAgent Agent that is instructed by the previous party in the chain to carry out an instruction.

UnderlyingAcceptanceDetails building block

Provides information on the acceptance or rejection of the mandate request. Identifies the mandate, which is being accepted. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% MandateAcceptance7 recursion level 0 with max 1
MandateAcceptance7 *-- "0..1" OriginalMessageInformation1 : OriginalMessageInformation
MandateAcceptance7 *-- "1..1" AcceptanceResult6 : AcceptanceResult
MandateAcceptance7 *-- "0..1" IOriginalMandate8Choice : OriginalMandate
MandateAcceptance7 *-- "0..0" SupplementaryData1 : SupplementaryData
%% OriginalMessageInformation1 recursion level 1 with max 1
class OriginalMessageInformation1{
    MessageIdentification IsoMax35Text
    MessageNameIdentification IsoMax35Text
    CreationDateTime IsoISODateTime
}
%% AcceptanceResult6 recursion level 1 with max 1
class AcceptanceResult6{
    Accepted IsoYesNoIndicator
    AdditionalRejectReasonInformation IsoMax105Text
}
AcceptanceResult6 *-- "0..1" IMandateReason1Choice : RejectReason
%% IOriginalMandate8Choice recursion level 1 with max 1
%% SupplementaryData1 recursion level 1 with max 1
class SupplementaryData1{
    PlaceAndName IsoMax350Text
}
SupplementaryData1 *-- "1..1" IsoSupplementaryDataEnvelope1 : Envelope

MandateAcceptance7 members

Member name Description Data Type / Multiplicity
OriginalMessageInformation Provides information on the original message. OriginalMessageInformation1 - Optional 0..1
AcceptanceResult Provides detailed information on the acceptance result. AcceptanceResult6 - Required 1..1
OriginalMandate Provides the original mandate data. IOriginalMandate8Choice - Optional 0..1
SupplementaryData Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData1 - Unknown 0..0

SupplementaryData building block

Additional information that cannot be captured in the structured elements and/or any other specific block. Additional information that can not be captured in the structured fields and/or any other specific block. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% SupplementaryData1 recursion level 0 with max 1
class SupplementaryData1{
    PlaceAndName IsoMax350Text
}
SupplementaryData1 *-- "1..1" IsoSupplementaryDataEnvelope1 : Envelope
%% IsoSupplementaryDataEnvelope1 recursion level 1 with max 1

SupplementaryData1 members

Member name Description Data Type / Multiplicity
PlaceAndName Unambiguous reference to the location where the supplementary data must be inserted in the message instance. In the case of XML, this is expressed by a valid XPath. IsoMax350Text - Optional 0..1
Envelope Technical element wrapping the supplementary data. IsoSupplementaryDataEnvelope1 - Required 1..1

Extensibility and generalization considerations

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

classDiagram
    class IOuterRecord
    MandateAcceptanceReportV07 --|> IOuterRecord : Implements
    MandateAcceptanceReportV07Document --|> IOuterDocument~MandateAcceptanceReportV07~ : Implements
    class IOuterDocument~MandateAcceptanceReportV07~ {
        MandateAcceptanceReportV07 Message
     }

Document wrapper for serialization

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

classDiagram
    MandateAcceptanceReportV07Document *-- MandateAcceptanceReportV07 : 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:pain.012.001.07">
    <MndtAccptncRpt>
        <GrpHdr>
            <!-- GroupHeader inner content -->
        </GrpHdr>
        <UndrlygAccptncDtls>
            <!-- UnderlyingAcceptanceDetails inner content -->
        </UndrlygAccptncDtls>
        <SplmtryData>
            <!-- SupplementaryData inner content -->
        </SplmtryData>
    </MndtAccptncRpt>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_rUYODdcBEeq_l4BJLVUF2Q"
  previousVersion="_bf9SMW2PEei3KuUgpx7Xcw"
  name="MandateAcceptanceReportV07"
  definition="Scope&#xD;&#xA;The MandateAcceptanceReport message is sent from the agent of the receiver (debtor or creditor) of the MandateRequest message (initiation, amendment or cancellation) to the agent of the initiator of the MandateRequest message (debtor or creditor).&#xD;&#xA;A MandateAcceptanceReport message is used to confirm the acceptance or rejection of a MandateRequest message. Where acceptance is part of the full process flow, a MandateRequest message only becomes valid after a confirmation of acceptance is received through a MandateAcceptanceReport message from the agent of the receiver.&#xD;&#xA;Usage&#xD;&#xA;The MandateAcceptanceReport message can contain one or more confirmation(s) of acceptance or rejection of a specific Mandate Request.&#xD;&#xA;The messages can be exchanged between debtor agent and creditor agent and between debtor agent and debtor and creditor agent and creditor.&#xD;&#xA;The MandateAcceptanceReport message can be used in domestic and cross-border scenarios."
  registrationStatus="Registered"
  messageSet="_AnUXc_2YEeG0oal_knwJ7A"
  xmlTag="MndtAccptncRpt"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <constraint
    xmi:id="_rUYOD9cBEeq_l4BJLVUF2Q"
    previousVersion="_bf9SM22PEei3KuUgpx7Xcw"
    name="SupplementaryDataRule"
    definition="The SupplementaryData building block at message level must not be used to provide additional information about a transaction. The SupplementaryData element at transaction level should be used for that purpose."
    registrationStatus="Provisionally Registered" />
  <messageBuildingBlock
    xmi:id="_rUYOF9cBEeq_l4BJLVUF2Q"
    previousVersion="_bf9SNW2PEei3KuUgpx7Xcw"
    name="GroupHeader"
    definition="Set of characteristics to identify the message and parties playing a role in the mandate acceptance, but which are not part of the mandate."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="GrpHdr"
    complexType="_G-MfEW49EeiU9cctagi5ow" />
  <messageBuildingBlock
    xmi:id="_rUYOGdcBEeq_l4BJLVUF2Q"
    previousVersion="_bf9SN22PEei3KuUgpx7Xcw"
    name="UnderlyingAcceptanceDetails"
    definition="Provides information on the acceptance or rejection of the mandate request."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="UndrlygAccptncDtls"
    complexType="_bOCIcdcZEeqRFcf2R4bPBw" />
  <messageBuildingBlock
    xmi:id="_rUYOG9cBEeq_l4BJLVUF2Q"
    previousVersion="_bf9SOW2PEei3KuUgpx7Xcw"
    name="SupplementaryData"
    definition="Additional information that cannot be captured in the structured elements and/or any other specific block."
    registrationStatus="Provisionally Registered"
    minOccurs="0"
    xmlTag="SplmtryData"
    complexType="_Qn0zC9p-Ed-ak6NoX_4Aeg_468227563" />
  <messageDefinitionIdentifier
    businessArea="pain"
    messageFunctionality="012"
    flavour="001"
    version="07" />
</messageDefinition>

ISO Building Blocks

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