camt

type AccountReportingRequestV02 ¶

type AccountReportingRequestV02 struct {

	// Set of elements used to provide further details on the message.
	GroupHeader *iso20022.GroupHeader43 `xml:"GrpHdr"`

	// Set of elements used to provide further details on the reporting request.
	ReportingRequest []*iso20022.ReportingRequest2 `xml:"RptgReq"`
}

Scope The AccountReportingRequest message is sent by the account owner, either directly or through a forwarding agent, to one of its account servicing institutions. It is used to ask the account servicing institution to send a report on the account owner's account in a BankToCustomerAccountReport (camt.052.001.02), a BankToCustomerStatement (camt.053.001.02) or a BankToCustomerDebitCreditNotification (camt.054.001.02). Usage The AccountReportingRequest message is used to advise the account servicing institution of funds that the account owner expects to have credited to its account. The message can be used in either a direct or a relay scenario.

func (a *AccountReportingRequestV02) AddGroupHeader() *iso20022.GroupHeader43

func (a *AccountReportingRequestV02) AddReportingRequest() *iso20022.ReportingRequest2

type AccountReportingRequestV03 ¶

type AccountReportingRequestV03 struct {

	// Set of elements used to provide further details on the message.
	GroupHeader *iso20022.GroupHeader59 `xml:"GrpHdr"`

	// Set of elements used to provide further details on the reporting request.
	ReportingRequest []*iso20022.ReportingRequest3 `xml:"RptgReq"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The AccountReportingRequest message is sent by the account owner, either directly or through a forwarding agent, to one of its account servicing institutions. It is used to ask the account servicing institution to send a report on the account owner's account in a BankToCustomerAccountReport (camt.052.001.03), a BankToCustomerStatement (camt.053.001.03) or a BankToCustomerDebitCreditNotification (camt.054.001.03). Usage The AccountReportingRequest message is used to advise the account servicing institution of funds that the account owner expects to have credited to its account. The message can be used in either a direct or a relay scenario.

func (a *AccountReportingRequestV03) AddGroupHeader() *iso20022.GroupHeader59

func (a *AccountReportingRequestV03) AddReportingRequest() *iso20022.ReportingRequest3

func (a *AccountReportingRequestV03) AddSupplementaryData() *iso20022.SupplementaryData1

type AdditionalPaymentInformation ¶

type AdditionalPaymentInformation struct {

	// Identifies the assignment.
	Assignment *iso20022.CaseAssignment `xml:"Assgnmt"`

	// Identifies the case.
	Case *iso20022.Case `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.PaymentInstructionExtract `xml:"Undrlyg"`

	// Additional information to the underlying payment instruction.
	Information *iso20022.PaymentComplementaryInformation `xml:"Inf"`
}

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.

func (a *AdditionalPaymentInformation) AddAssignment() *iso20022.CaseAssignment

func (a *AdditionalPaymentInformation) AddCase() *iso20022.Case

func (a *AdditionalPaymentInformation) AddInformation() *iso20022.PaymentComplementaryInformation

func (a *AdditionalPaymentInformation) AddUnderlying() *iso20022.PaymentInstructionExtract

type AdditionalPaymentInformationV03 ¶

type AdditionalPaymentInformationV03 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment2 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.UnderlyingTransaction1Choice `xml:"Undrlyg"`

	// Additional information to the underlying payment instruction.
	Information *iso20022.PaymentComplementaryInformation2 `xml:"Inf"`
}

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 (for example 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.

func (a *AdditionalPaymentInformationV03) AddAssignment() *iso20022.CaseAssignment2

func (a *AdditionalPaymentInformationV03) AddCase() *iso20022.Case2

func (a *AdditionalPaymentInformationV03) AddInformation() *iso20022.PaymentComplementaryInformation2

func (a *AdditionalPaymentInformationV03) AddUnderlying() *iso20022.UnderlyingTransaction1Choice

type AdditionalPaymentInformationV04 ¶

type AdditionalPaymentInformationV04 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"`

	// Additional information to the underlying payment instruction.
	Information *iso20022.PaymentComplementaryInformation3 `xml:"Inf"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

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 (for example 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.

func (a *AdditionalPaymentInformationV04) AddAssignment() *iso20022.CaseAssignment3

func (a *AdditionalPaymentInformationV04) AddCase() *iso20022.Case3

func (a *AdditionalPaymentInformationV04) AddInformation() *iso20022.PaymentComplementaryInformation3

func (a *AdditionalPaymentInformationV04) AddSupplementaryData() *iso20022.SupplementaryData1

func (a *AdditionalPaymentInformationV04) AddUnderlying() *iso20022.UnderlyingTransaction2Choice

type AdditionalPaymentInformationV05 ¶

type AdditionalPaymentInformationV05 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"`

	// Additional information to the underlying payment instruction.
	Information *iso20022.PaymentComplementaryInformation4 `xml:"Inf"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

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 (for example 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.

func (a *AdditionalPaymentInformationV05) AddAssignment() *iso20022.CaseAssignment3

func (a *AdditionalPaymentInformationV05) AddCase() *iso20022.Case3

func (a *AdditionalPaymentInformationV05) AddInformation() *iso20022.PaymentComplementaryInformation4

func (a *AdditionalPaymentInformationV05) AddSupplementaryData() *iso20022.SupplementaryData1

func (a *AdditionalPaymentInformationV05) AddUnderlying() *iso20022.UnderlyingTransaction2Choice

type AdditionalPaymentInformationV06 ¶

type AdditionalPaymentInformationV06 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"`

	// Additional information to the underlying payment instruction.
	Information *iso20022.PaymentComplementaryInformation5 `xml:"Inf"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The AdditionalPaymentInformation 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 AdditionalPaymentInformation message provides elements which are usually not reported in a statement or advice (for example 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 AdditionalPaymentInformation message covers one and only one original payment instruction. If several payment instructions need further details, multiple AdditionalPaymentInformation 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 ClaimNonReceipt 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 AdditionalPaymentInformation can be used to provide the missing information. - A RequestToModifyPayment 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 AdditionalPaymentInformation message allows the account owner to receive further particulars or correct information about a payment instruction or an entry passed to its account. The AdditionalPayment Information message cannot be used to trigger a request for modification of a payment instruction activity. A RequestToModifyPayment 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 AdditionalPaymentInformation but instead a RequestToModifyPayment message. It is assumed that when an account servicing institution sends out an AdditionalPaymentInformation 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 ResolutionOfInvestigation 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.

func (a *AdditionalPaymentInformationV06) AddAssignment() *iso20022.CaseAssignment3

func (a *AdditionalPaymentInformationV06) AddCase() *iso20022.Case3

func (a *AdditionalPaymentInformationV06) AddInformation() *iso20022.PaymentComplementaryInformation5

func (a *AdditionalPaymentInformationV06) AddSupplementaryData() *iso20022.SupplementaryData1

func (a *AdditionalPaymentInformationV06) AddUnderlying() *iso20022.UnderlyingTransaction2Choice

type AdditionalPaymentInformationV07 ¶

type AdditionalPaymentInformationV07 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.UnderlyingTransaction3Choice `xml:"Undrlyg"`

	// Additional information to the underlying payment instruction.
	Information *iso20022.PaymentComplementaryInformation6 `xml:"Inf"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The AdditionalPaymentInformation 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 AdditionalPaymentInformation message provides elements which are usually not reported in a statement or advice (for example 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 AdditionalPaymentInformation message covers one and only one original payment instruction. If several payment instructions need further details, multiple AdditionalPaymentInformation 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 ClaimNonReceipt 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 AdditionalPaymentInformation can be used to provide the missing information. - A RequestToModifyPayment 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 AdditionalPaymentInformation message allows the account owner to receive further particulars or correct information about a payment instruction or an entry passed to its account. The AdditionalPayment Information message cannot be used to trigger a request for modification of a payment instruction activity. A RequestToModifyPayment 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 AdditionalPaymentInformation but instead a RequestToModifyPayment message. It is assumed that when an account servicing institution sends out an AdditionalPaymentInformation 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 ResolutionOfInvestigation 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.

func (a *AdditionalPaymentInformationV07) AddAssignment() *iso20022.CaseAssignment3

func (a *AdditionalPaymentInformationV07) AddCase() *iso20022.Case3

func (a *AdditionalPaymentInformationV07) AddInformation() *iso20022.PaymentComplementaryInformation6

func (a *AdditionalPaymentInformationV07) AddSupplementaryData() *iso20022.SupplementaryData1

func (a *AdditionalPaymentInformationV07) AddUnderlying() *iso20022.UnderlyingTransaction3Choice

type BankServicesBillingStatementV01 ¶

type BankServicesBillingStatementV01 struct {

	// Provides header details on the billing statement report.
	ReportHeader *iso20022.ReportHeader3 `xml:"RptHdr"`

	// Group of bank services billing statements with the same sender and receiver characteristics.
	BillingStatementGroup []*iso20022.StatementGroup1 `xml:"BllgStmtGrp"`
}

Scope The BankServicesBillingStatement message is used to send from a Financial Institution (FI) to its wholesale customers (corporations, governments, institutions, etc.), information describing the FI’s billing of services rendered in the form of an electronic statement in a standardised format. The BankServicesBillingStatement is a periodic (usually end of month) recounting of all service chargeable events that occurred during a reporting cycle, typically a calendar month, along with detailed tax and currency translation information. Account balance information, although strongly recommended, is not required. Usage The BankServicesBillingStatement message is designed to provide details related to invoices (or an advice of debit) which a financial institution may supply to its customers. The BankServicesBillingStatement is not expressly designed to be an invoice, nor to replace invoices currently in use. The message may be used as an invoice by agreement between the sender and the receiver. No regulatory or legislative requirements were considered when creating this message standard. Users of the BankServicesBillingStatment message are cautioned to be aware of any regulatory or legal requirement for invoices before replacing existing invoices. The BankServicesBillingStatement message can supply the detail supporting separate invoices or debits but it is not the invoice or advice of debit of record. The BankServicesBillingStatement message must accurately reflect all the charge and tax related events that occurred during the calendar month and how the FI and taxing authorities were compensated for these events. The BSB does not ask the Financial Institution to revise its established pricing and billing procedures. How, when and what the customer is actually charged for remains in place. The BankServicesBillingStatement message asks the Financial Institution to aggregate and report what actually happened during the calendar month. The BankServicesBillingStatement message is intended for use with the ISO 20022 Business Application Header.

func (b *BankServicesBillingStatementV01) AddBillingStatementGroup() *iso20022.StatementGroup1

func (b *BankServicesBillingStatementV01) AddReportHeader() *iso20022.ReportHeader3

type BankServicesBillingStatementV02 ¶

type BankServicesBillingStatementV02 struct {

	// Provides header details on the billing statement report.
	ReportHeader *iso20022.ReportHeader3 `xml:"RptHdr"`

	// Group of bank services billing statements with the same sender and receiver characteristics.
	BillingStatementGroup []*iso20022.StatementGroup2 `xml:"BllgStmtGrp"`
}

Scope The BankServicesBillingStatement message is used to send from a Financial Institution (FI) to its wholesale customers (corporations, governments, institutions, etc.), information describing the FI’s billing of services rendered in the form of an electronic statement in a standardised format. The BankServicesBillingStatement is a periodic (usually end of month) recounting of all service chargeable events that occurred during a reporting cycle, typically a calendar month, along with detailed tax and currency translation information. Account balance information, although strongly recommended, is not required. Usage The BankServicesBillingStatement message is designed to provide details related to invoices (or an advice of debit) which a financial institution may supply to its customers. The BankServicesBillingStatement is not expressly designed to be an invoice, nor to replace invoices currently in use. The message may be used as an invoice by agreement between the sender and the receiver. No regulatory or legislative requirements were considered when creating this message standard. Users of the BankServicesBillingStatement message are cautioned to be aware of any regulatory or legal requirement for invoices before replacing existing invoices. The BankServicesBillingStatement message can supply the detail supporting separate invoices or debits but it is not the invoice or advice of debit of record. The BankServicesBillingStatement message must accurately reflect all the charge and tax related events that occurred during the calendar month and how the FI and taxing authorities were compensated for these events. The BankServicesBillingStatement does not ask the financial institution to revise its established pricing and billing procedures. How, when and what the customer is actually charged for remains in place. The BankServicesBillingStatement message asks the financial institution to aggregate and report what actually happened during the calendar month. The BankServicesBillingStatement message is intended for use with the ISO 20022 Business Application Header.

func (b *BankServicesBillingStatementV02) AddBillingStatementGroup() *iso20022.StatementGroup2

func (b *BankServicesBillingStatementV02) AddReportHeader() *iso20022.ReportHeader3

type BankToCustomerAccountReportV01 ¶

type BankToCustomerAccountReportV01 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader23 `xml:"GrpHdr"`

	// Reports on a cash account.
	Report []*iso20022.AccountReport9 `xml:"Rpt"`
}

Scope The Bank-to-Customer Account Report message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. Usage The Bank-to-Customer Account Report message can contain reports for more than 1 account. It provides information for cash management and/or reconciliation. It can be used to : - report pending and booked items; - provide balance information It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement that is required due to local legal stipulations, the Bank-to-Customer Account Statement message should be used.

func (b *BankToCustomerAccountReportV01) AddGroupHeader() *iso20022.GroupHeader23

func (b *BankToCustomerAccountReportV01) AddReport() *iso20022.AccountReport9

type BankToCustomerAccountReportV02 ¶

type BankToCustomerAccountReportV02 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader42 `xml:"GrpHdr"`

	// Reports on a cash account.
	Report []*iso20022.AccountReport11 `xml:"Rpt"`
}

Scope The BankToCustomerAccountReport message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerAccountReport message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to: - report pending and booked items; - provide balance information. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement, the Bank-to-Customer Account Statement message should be used.

func (b *BankToCustomerAccountReportV02) AddGroupHeader() *iso20022.GroupHeader42

func (b *BankToCustomerAccountReportV02) AddReport() *iso20022.AccountReport11

type BankToCustomerAccountReportV03 ¶

type BankToCustomerAccountReportV03 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on a cash account.
	Report []*iso20022.AccountReport12 `xml:"Rpt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerAccountReport message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerAccountReport message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to: - report pending and booked items; - provide balance information. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement, the Bank-to-Customer Account Statement message should be used.

func (b *BankToCustomerAccountReportV03) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerAccountReportV03) AddReport() *iso20022.AccountReport12

func (b *BankToCustomerAccountReportV03) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerAccountReportV04 ¶

type BankToCustomerAccountReportV04 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on a cash account.
	Report []*iso20022.AccountReport16 `xml:"Rpt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerAccountReport message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerAccountReport message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to: - report pending and booked items; - provide balance information. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement, the Bank-to-Customer Account Statement message should be used.

func (b *BankToCustomerAccountReportV04) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerAccountReportV04) AddReport() *iso20022.AccountReport16

func (b *BankToCustomerAccountReportV04) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerAccountReportV05 ¶

type BankToCustomerAccountReportV05 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on a cash account.
	Report []*iso20022.AccountReport18 `xml:"Rpt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerAccountReport message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerAccountReport message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to: - report pending and booked items; - provide balance information. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement, the Bank-to-Customer Account Statement message should be used.

func (b *BankToCustomerAccountReportV05) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerAccountReportV05) AddReport() *iso20022.AccountReport18

func (b *BankToCustomerAccountReportV05) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerAccountReportV06 ¶

type BankToCustomerAccountReportV06 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on a cash account.
	Report []*iso20022.AccountReport19 `xml:"Rpt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerAccountReport message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of the entries reported to the account, and/or to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerAccountReport message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to: - report pending and booked items; - provide balance information. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). For a statement, the Bank-to-Customer Account Statement message should be used.

func (b *BankToCustomerAccountReportV06) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerAccountReportV06) AddReport() *iso20022.AccountReport19

func (b *BankToCustomerAccountReportV06) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerDebitCreditNotificationV01 ¶

type BankToCustomerDebitCreditNotificationV01 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader23 `xml:"GrpHdr"`

	// Notifies debit and credit entries for the account.
	Notification []*iso20022.AccountNotification1 `xml:"Ntfctn"`
}

Scope The Bank-to-Customer Debit/Credit Notification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. Usage The Bank-to-Customer Debit/Credit Notification message can contain reports for more than 1 account. It provides information for cash management and/or reconciliation. It can be used to : - report pending and booked items; - notify one or more debit entries; - notify one or more credit entries; - notify a combination of debit and credit entries It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). It does not contain balance information.

func (b *BankToCustomerDebitCreditNotificationV01) AddGroupHeader() *iso20022.GroupHeader23

func (b *BankToCustomerDebitCreditNotificationV01) AddNotification() *iso20022.AccountNotification1

type BankToCustomerDebitCreditNotificationV02 ¶

type BankToCustomerDebitCreditNotificationV02 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader42 `xml:"GrpHdr"`

	// Notifies debit and credit entries for the account.
	Notification []*iso20022.AccountNotification2 `xml:"Ntfctn"`
}

Scope The BankToCustomerDebitCreditNotification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. Usage The BankToCustomerDebitCreditNotification message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to : - report pending and booked items; - notify one or more debit entries; - notify one or more credit entries; - notify a combination of debit and credit entries. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). It does not contain balance information.

func (b *BankToCustomerDebitCreditNotificationV02) AddGroupHeader() *iso20022.GroupHeader42

func (b *BankToCustomerDebitCreditNotificationV02) AddNotification() *iso20022.AccountNotification2

type BankToCustomerDebitCreditNotificationV03 ¶

type BankToCustomerDebitCreditNotificationV03 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Notifies debit and credit entries for the account.
	Notification []*iso20022.AccountNotification5 `xml:"Ntfctn"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerDebitCreditNotification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. Usage The BankToCustomerDebitCreditNotification message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It can be used to : - report pending and booked items; - notify one or more debit entries; - notify one or more credit entries; - notify a combination of debit and credit entries. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). It does not contain balance information.

func (b *BankToCustomerDebitCreditNotificationV03) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerDebitCreditNotificationV03) AddNotification() *iso20022.AccountNotification5

func (b *BankToCustomerDebitCreditNotificationV03) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerDebitCreditNotificationV04 ¶

type BankToCustomerDebitCreditNotificationV04 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Notifies debit and credit entries for the account.
	Notification []*iso20022.AccountNotification7 `xml:"Ntfctn"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerDebitCreditNotification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. Usage The BankToCustomerDebitCreditNotification message can contain reports for more than one account. It provides information for cash management and/or reconciliation. The BankToCustomerDebitCreditNotification message can be used to : - report pending and booked items; - notify one or more debit entries; - notify one or more credit entries; - notify a combination of debit and credit entries. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). It does not contain balance information.

func (b *BankToCustomerDebitCreditNotificationV04) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerDebitCreditNotificationV04) AddNotification() *iso20022.AccountNotification7

func (b *BankToCustomerDebitCreditNotificationV04) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerDebitCreditNotificationV05 ¶

type BankToCustomerDebitCreditNotificationV05 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Notifies debit and credit entries for the account.
	Notification []*iso20022.AccountNotification11 `xml:"Ntfctn"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerDebitCreditNotification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. Usage The BankToCustomerDebitCreditNotification message can contain reports for more than one account. It provides information for cash management and/or reconciliation. The BankToCustomerDebitCreditNotification message can be used to : - report pending and booked items; - notify one or more debit entries; - notify one or more credit entries; - notify a combination of debit and credit entries. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). It does not contain balance information.

func (b *BankToCustomerDebitCreditNotificationV05) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerDebitCreditNotificationV05) AddNotification() *iso20022.AccountNotification11

func (b *BankToCustomerDebitCreditNotificationV05) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerDebitCreditNotificationV06 ¶

type BankToCustomerDebitCreditNotificationV06 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Notifies debit and credit entries for the account.
	Notification []*iso20022.AccountNotification12 `xml:"Ntfctn"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerDebitCreditNotification message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It can be used to inform the account owner, or authorised party, of single or multiple debit and/or credit entries reported to the account. Usage The BankToCustomerDebitCreditNotification message can contain reports for more than one account. It provides information for cash management and/or reconciliation. The BankToCustomerDebitCreditNotification message can be used to : - report pending and booked items; - notify one or more debit entries; - notify one or more credit entries; - notify a combination of debit and credit entries. It can include underlying details of transactions that have been included in the entry. It is possible that the receiver of the message is not the account owner, but a party entitled by the account owner to receive the account information (also known as recipient). It does not contain balance information.

func (b *BankToCustomerDebitCreditNotificationV06) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerDebitCreditNotificationV06) AddNotification() *iso20022.AccountNotification12

func (b *BankToCustomerDebitCreditNotificationV06) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerStatementV01 ¶

type BankToCustomerStatementV01 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader23 `xml:"GrpHdr"`

	// Reports on booked entries and balances for a cash account.
	Statement []*iso20022.AccountStatement1 `xml:"Stmt"`
}

Scope The Bank-to-Customer Statement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. Usage The Bank-to-Customer Statement message can contain reports for more than 1 account. It provides information for cash management and/or reconciliation. It contains information on booked entries only. It can include underlying details of transactions that have been included in the entry. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account (and therefore are "binding" and also balance information. Depending on services agreed between banks and their customers, "binding" statements can be generated and exchanged intraday. Depending on legal requirements in local jurisdictions, "end-of-day" statements may need to be mandatorily generated and exchanged. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient).

func (b *BankToCustomerStatementV01) AddGroupHeader() *iso20022.GroupHeader23

func (b *BankToCustomerStatementV01) AddStatement() *iso20022.AccountStatement1

type BankToCustomerStatementV02 ¶

type BankToCustomerStatementV02 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader42 `xml:"GrpHdr"`

	// Reports on booked entries and balances for a cash account.
	Statement []*iso20022.AccountStatement2 `xml:"Stmt"`
}

Scope The BankToCustomerStatement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerStatement message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It contains information on booked entries only. It can include underlying details of transactions that have been included in the entry. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account and also balance information. Depending on services and schedule agreed between banks and their customers, statements may be generated and exchanged accordingly, for example for intraday or prior day periods. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient).

func (b *BankToCustomerStatementV02) AddGroupHeader() *iso20022.GroupHeader42

func (b *BankToCustomerStatementV02) AddStatement() *iso20022.AccountStatement2

type BankToCustomerStatementV03 ¶

type BankToCustomerStatementV03 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on booked entries and balances for a cash account.
	Statement []*iso20022.AccountStatement3 `xml:"Stmt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerStatement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerStatement message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It contains information on booked entries only. It can include underlying details of transactions that have been included in the entry. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account and also balance information. Depending on services and schedule agreed between banks and their customers, statements may be generated and exchanged accordingly, for example for intraday or prior day periods. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient).

func (b *BankToCustomerStatementV03) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerStatementV03) AddStatement() *iso20022.AccountStatement3

func (b *BankToCustomerStatementV03) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerStatementV04 ¶

type BankToCustomerStatementV04 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on booked entries and balances for a cash account.
	Statement []*iso20022.AccountStatement4 `xml:"Stmt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerStatement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerStatement message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It contains information on booked entries only. It can include underlying details of transactions that have been included in the entry. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account and also balance information. Depending on services and schedule agreed between banks and their customers, statements may be generated and exchanged accordingly, for example for intraday or prior day periods. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient).

func (b *BankToCustomerStatementV04) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerStatementV04) AddStatement() *iso20022.AccountStatement4

func (b *BankToCustomerStatementV04) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerStatementV05 ¶

type BankToCustomerStatementV05 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on booked entries and balances for a cash account.
	Statement []*iso20022.AccountStatement5 `xml:"Stmt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerStatement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerStatement message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It contains information on booked entries only. It can include underlying details of transactions that have been included in the entry. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account and also balance information. Depending on services and schedule agreed between banks and their customers, statements may be generated and exchanged accordingly, for example for intraday or prior day periods. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient).

func (b *BankToCustomerStatementV05) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerStatementV05) AddStatement() *iso20022.AccountStatement5

func (b *BankToCustomerStatementV05) AddSupplementaryData() *iso20022.SupplementaryData1

type BankToCustomerStatementV06 ¶

type BankToCustomerStatementV06 struct {

	// Common information for the message.
	GroupHeader *iso20022.GroupHeader58 `xml:"GrpHdr"`

	// Reports on booked entries and balances for a cash account.
	Statement []*iso20022.AccountStatement6 `xml:"Stmt"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The BankToCustomerStatement message is sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries booked to the account, and to provide the owner with balance information on the account at a given point in time. Usage The BankToCustomerStatement message can contain reports for more than one account. It provides information for cash management and/or reconciliation. It contains information on booked entries only. It can include underlying details of transactions that have been included in the entry. The message is exchanged as defined between the account servicer and the account owner. It provides information on items that have been booked to the account and also balance information. Depending on services and schedule agreed between banks and their customers, statements may be generated and exchanged accordingly, for example for intraday or prior day periods. It is possible that the receiver of the message is not the account owner, but a party entitled through arrangement with the account owner to receive the account information (also known as recipient).

func (b *BankToCustomerStatementV06) AddGroupHeader() *iso20022.GroupHeader58

func (b *BankToCustomerStatementV06) AddStatement() *iso20022.AccountStatement6

func (b *BankToCustomerStatementV06) AddSupplementaryData() *iso20022.SupplementaryData1

type CancelCaseAssignment ¶

type CancelCaseAssignment struct {

	// Identifies the assignment.
	Assignment *iso20022.CaseAssignment `xml:"Assgnmt"`

	// Identifies the case.
	Case *iso20022.Case `xml:"Case"`
}

Scope The Cancel Case Assignment message is sent by a case creator or case assigner to a case assignee. This message is used to request the cancellation of a case. Usage The Cancel Case Assignment message is used to stop the processing of a case at a case assignee when a case assignment is incorrect or when the root cause for the case disappears (such as the account owner was able to reconcile after sending a Claim Non Receipt message). The Cancel Case Assignment message can be used to stop the processing of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Cancel Case Assignment message covers one and only one case at a time. If several case assignments need to be cancelled, then multiple Cancel Case Assignment messages must be sent. The Cancel Case Assignment message must be forwarded by all subsequent case assignee(s) in the case processing chain until it reaches the end point. When an agent re-assigns the Cancel Case Assignment to a subsequent case assignee, this agent must send a Notification Of Case Assignment message to its assigner.. When the Cancel Case Assignment instruction has been acted upon by the relevant case assignee, a Resolution Of Investigation message is sent to the case assigner or case creator, in reply. The Cancel Case Assignment message must not be used for other purposes. If, for example, a request to modify payment fails, and the case creator requests the cancellation of the payment, then a Request To Cancel Payment message must be used, with the case identification of the original Request To Modify Payment message. In this context it is incorrect to use the Cancel Case Assignment message.

func (c *CancelCaseAssignment) AddAssignment() *iso20022.CaseAssignment

func (c *CancelCaseAssignment) AddCase() *iso20022.Case

type CancelCaseAssignmentV02 ¶

type CancelCaseAssignmentV02 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment2 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`
}

Scope The Cancel Case Assignment message is sent by a case creator or case assigner to a case assignee. This message is used to request the cancellation of a case. Usage The Cancel Case Assignment message is used to stop the processing of a case at a case assignee when a case assignment is incorrect or when the root cause for the case disappears (such as the account owner was able to reconcile after sending a Claim Non Receipt message). The Cancel Case Assignment message can be used to stop the processing of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Cancel Case Assignment message covers one and only one case at a time. If several case assignments need to be cancelled, then multiple Cancel Case Assignment messages must be sent. The Cancel Case Assignment message must be forwarded by all subsequent case assignee(s) in the case processing chain until it reaches the end point. When an agent re-assigns the Cancel Case Assignment to a subsequent case assignee, this agent must send a Notification Of Case Assignment message to its assigner. When the Cancel Case Assignment instruction has been acted upon by the relevant case assignee, a Resolution Of Investigation message is sent to the case assigner or case creator, in reply. The Cancel Case Assignment message must not be used for other purposes. If, for example, a request to modify payment fails, and the case creator requests the cancellation of the payment, then a Customer or FIToFI Payment Cancellation Request message must be used, with the case identification of the original Request To Modify Payment message. In this context it is incorrect to use the Cancel Case Assignment message.

func (c *CancelCaseAssignmentV02) AddAssignment() *iso20022.CaseAssignment2

func (c *CancelCaseAssignmentV02) AddCase() *iso20022.Case2

type CancelCaseAssignmentV03 ¶

type CancelCaseAssignmentV03 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Cancel Case Assignment message is sent by a case creator or case assigner to a case assignee. This message is used to request the cancellation of a case. Usage The Cancel Case Assignment message is used to stop the processing of a case at a case assignee when a case assignment is incorrect or when the root cause for the case disappears (such as the account owner was able to reconcile after sending a Claim Non Receipt message). The Cancel Case Assignment message can be used to stop the processing of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Cancel Case Assignment message covers one and only one case at a time. If several case assignments need to be cancelled, then multiple Cancel Case Assignment messages must be sent. The Cancel Case Assignment message must be forwarded by all subsequent case assignee(s) in the case processing chain until it reaches the end point. When an agent re-assigns the Cancel Case Assignment to a subsequent case assignee, this agent must send a Notification Of Case Assignment message to its assigner. When the Cancel Case Assignment instruction has been acted upon by the relevant case assignee, a Resolution Of Investigation message is sent to the case assigner or case creator, in reply. The Cancel Case Assignment message must not be used for other purposes. If, for example, a request to modify payment fails, and the case creator requests the cancellation of the payment, then a Customer or FIToFI Payment Cancellation Request message must be used, with the case identification of the original Request To Modify Payment message. In this context it is incorrect to use the Cancel Case Assignment message.

func (c *CancelCaseAssignmentV03) AddAssignment() *iso20022.CaseAssignment3

func (c *CancelCaseAssignmentV03) AddCase() *iso20022.Case3

func (c *CancelCaseAssignmentV03) AddSupplementaryData() *iso20022.SupplementaryData1

type CaseStatusReport ¶

type CaseStatusReport struct {

	// Specifies generic information about an investigation report.
	Header *iso20022.ReportHeader `xml:"Hdr"`

	// Identifies the case.
	Case *iso20022.Case `xml:"Case"`

	// Defines the status of the case.
	Status *iso20022.CaseStatus `xml:"Sts"`

	// Identifies the last assignment performed.
	NewAssignment *iso20022.CaseAssignment `xml:"NewAssgnmt,omitempty"`
}

Scope The Case Status Report message is sent by a case assignee to a case creator or case assigner. This message is used to report on the status of a case. Usage A Case Status Report message is sent in reply to a Case Status Report Request message. This message - covers one and only one case at a time. (If a case assignee needs to report on several cases, then multiple Case Status Report messages must be sent.) - may be forwarded to subsequent case assigner(s) until it reaches the end point - is able to indicate the fact that a case has been assigned to a party downstream in the payment processing chain - may not be used in place of a Resolution Of Investigation (except for the condition given in the next bullet point) or Notification Of Case Assignment message - may be skipped and replaced by a Resolution Of Investigation message if at the moment when the request for a investigation status arrives, the assignee has obtained a solution. (In this case a Resolution Of Investigation message can be sent in lieu of a Case Status Report and the case may be closed.)

func (c *CaseStatusReport) AddCase() *iso20022.Case

func (c *CaseStatusReport) AddHeader() *iso20022.ReportHeader

func (c *CaseStatusReport) AddNewAssignment() *iso20022.CaseAssignment

func (c *CaseStatusReport) AddStatus() *iso20022.CaseStatus

type CaseStatusReportRequest ¶

type CaseStatusReportRequest struct {

	// Identifies the party requesting the status, the requested party, the identification and the date of the status.
	RequestHeader *iso20022.ReportHeader `xml:"ReqHdr"`

	// Identifies the case.
	Case *iso20022.Case `xml:"Case"`
}

Scope The Case Status Report Request message is sent by a case creator or case assigner to a case assignee. This message is used to request the status of a case. Usage The Case Status Report Request message must be answered with a Case Status Report message. It can be used to request the status of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Case Status Report Request message covers one and only one case at a time. If a case creator or case assigner needs the status of several cases, then multiple Case Status Report Request messages must be sent. The Case Status Report Request message may be forwarded to subsequent case assignee(s) in the case processing chain. The processing of a case generates Notification Of Case Assignment and/or Resolution Of Investigation messages to the case creator/case assigner. They alone should provide collaborating parties sufficient information about the progress of the investigation. The Case Status Report Request must therefore only be used when no information has been received from the case assignee within the expected time frame. An agent may suspense an investigation by classifying it as overdue if he, after sending the request for status, does not receive any response after a long time. Agents may set their individual threshold wait-time.

func (c *CaseStatusReportRequest) AddCase() *iso20022.Case

func (c *CaseStatusReportRequest) AddRequestHeader() *iso20022.ReportHeader

type CaseStatusReportRequestV02 ¶

type CaseStatusReportRequestV02 struct {

	// Identifies the party requesting the status, the requested party, the identification and the date of the status.
	RequestHeader *iso20022.ReportHeader2 `xml:"ReqHdr"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`
}

Scope The CaseStatusReportRequest message is sent by a case creator or case assigner to a case assignee. This message is used to request the status of a case. Usage The Case Status Report Request message must be answered with a Case Status Report message. It can be used to request the status of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Case Status Report Request message covers one and only one case at a time. If a case creator or case assigner needs the status of several cases, then multiple Case Status Report Request messages must be sent. The Case Status Report Request message may be forwarded to subsequent case assignee(s) in the case processing chain. The processing of a case generates Notification Of Case Assignment and/or Resolution Of Investigation messages to the case creator/case assigner. They alone should provide collaborating parties sufficient information about the progress of the investigation. The Case Status Report Request must therefore only be used when no information has been received from the case assignee within the expected time frame. An agent may suspend an investigation by classifying it as overdue if, this agent, after sending the request for the status of the investigation, does not receive any response after a long time. Agents may set their individual threshold wait-time.

func (c *CaseStatusReportRequestV02) AddCase() *iso20022.Case2

func (c *CaseStatusReportRequestV02) AddRequestHeader() *iso20022.ReportHeader2

type CaseStatusReportRequestV03 ¶

type CaseStatusReportRequestV03 struct {

	// Identifies the party requesting the status, the requested party, the identification and the date of the status.
	RequestHeader *iso20022.ReportHeader4 `xml:"ReqHdr"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The CaseStatusReportRequest message is sent by a case creator or case assigner to a case assignee. This message is used to request the status of a case. Usage The Case Status Report Request message must be answered with a Case Status Report message. It can be used to request the status of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Case Status Report Request message covers one and only one case at a time. If a case creator or case assigner needs the status of several cases, then multiple Case Status Report Request messages must be sent. The Case Status Report Request message may be forwarded to subsequent case assignee(s) in the case processing chain. The processing of a case generates Notification Of Case Assignment and/or Resolution Of Investigation messages to the case creator/case assigner. They alone should provide collaborating parties sufficient information about the progress of the investigation. The Case Status Report Request must therefore only be used when no information has been received from the case assignee within the expected time frame. An agent may suspend an investigation by classifying it as overdue if, this agent, after sending the request for the status of the investigation, does not receive any response after a long time. Agents may set their individual threshold wait-time.

func (c *CaseStatusReportRequestV03) AddCase() *iso20022.Case3

func (c *CaseStatusReportRequestV03) AddRequestHeader() *iso20022.ReportHeader4

func (c *CaseStatusReportRequestV03) AddSupplementaryData() *iso20022.SupplementaryData1

type CaseStatusReportV03 ¶

type CaseStatusReportV03 struct {

	// Specifies generic information about an investigation report.
	Header *iso20022.ReportHeader2 `xml:"Hdr"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`

	// Defines the status of the case.
	Status *iso20022.CaseStatus2 `xml:"Sts"`

	// Identifies the change of an assignment for an investigation case from an assigner to a new assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	NewAssignment *iso20022.CaseAssignment2 `xml:"NewAssgnmt,omitempty"`
}

Scope The Case Status Report message is sent by a case assignee to a case creator or case assigner. This message is used to report on the status of a case. Usage A Case Status Report message is sent in reply to a Case Status Report Request message. This message - covers one and only one case at a time. (If a case assignee needs to report on several cases, then multiple Case Status Report messages must be sent.) - may be forwarded to subsequent case assigner(s) until it reaches the end point - is able to indicate the fact that a case has been assigned to a party downstream in the payment processing chain - may not be used in place of a Resolution Of Investigation (except for the condition given in the next bullet point) or Notification Of Case Assignment message - may be skipped and replaced by a Resolution Of Investigation message when the request for a investigation status is received at the time the assigner has resolved the case. (In this case a Resolution Of Investigation message can be sent instead of a Case Status Report and the case may be closed.)

func (c *CaseStatusReportV03) AddCase() *iso20022.Case2

func (c *CaseStatusReportV03) AddHeader() *iso20022.ReportHeader2

func (c *CaseStatusReportV03) AddNewAssignment() *iso20022.CaseAssignment2

func (c *CaseStatusReportV03) AddStatus() *iso20022.CaseStatus2

type CaseStatusReportV04 ¶

type CaseStatusReportV04 struct {

	// Specifies generic information about an investigation report.
	Header *iso20022.ReportHeader4 `xml:"Hdr"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Defines the status of the case.
	Status *iso20022.CaseStatus2 `xml:"Sts"`

	// Identifies the change of an assignment for an investigation case from an assigner to a new assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	NewAssignment *iso20022.CaseAssignment3 `xml:"NewAssgnmt,omitempty"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Case Status Report message is sent by a case assignee to a case creator or case assigner. This message is used to report on the status of a case. Usage A Case Status Report message is sent in reply to a Case Status Report Request message. This message - covers one and only one case at a time. (If a case assignee needs to report on several cases, then multiple Case Status Report messages must be sent.) - may be forwarded to subsequent case assigner(s) until it reaches the end point - is able to indicate the fact that a case has been assigned to a party downstream in the payment processing chain - may not be used in place of a Resolution Of Investigation (except for the condition given in the next bullet point) or Notification Of Case Assignment message - may be skipped and replaced by a Resolution Of Investigation message when the request for a investigation status is received at the time the assigner has resolved the case. (In this case a Resolution Of Investigation message can be sent instead of a Case Status Report and the case may be closed.)

func (c *CaseStatusReportV04) AddCase() *iso20022.Case3

func (c *CaseStatusReportV04) AddHeader() *iso20022.ReportHeader4

func (c *CaseStatusReportV04) AddNewAssignment() *iso20022.CaseAssignment3

func (c *CaseStatusReportV04) AddStatus() *iso20022.CaseStatus2

func (c *CaseStatusReportV04) AddSupplementaryData() *iso20022.SupplementaryData1

type ClaimNonReceipt ¶

type ClaimNonReceipt struct {

	// Identifies an assignment.
	Assignment *iso20022.CaseAssignment `xml:"Assgnmt"`

	// Identifies a case.
	Case *iso20022.Case `xml:"Case"`

	// Identifies the payment instruction for which the Creditor has not received the funds.
	// Note:
	// In case of a missing cover, it must be the Field 20 of the received MT103.
	// In case of a claim non receipt initiated by the Debtor, it must be the identification of the instruction (Field 20 of MT103, Instruction Identification of the Payment Initiation or the Bulk Credit Transfer).
	Underlying *iso20022.PaymentInstructionExtract `xml:"Undrlyg"`

	// Indicates if the claim non receipt is a missing cover. The absence of the component means that the message is not for a missing cover.
	MissingCover *iso20022.MissingCover `xml:"MssngCover,omitempty"`
}

Scope The Claim Non Receipt message is sent by a case creator/case assigner to a case assignee. This message allows to initiate an investigation in case the beneficiary of a payment has not received an expected payment. Usage Note 1: Although there are cases where a creditor would contact the creditor's bank when claiming non-receipt, the activity only retained the scenario where the beneficiary claims non-receipt with its debtor, the debtor in its turn contacting the first agent. Therefore the investigation follows the same route as the original instruction. Note 2: This message is also used to report a missing cover. The rationale behind this is that the beneficiary of the cover (receiver of the payment instruction) missing the cover would be in the very same position as a beneficiary expecting a credit to its account and would therefore trigger the same processes. In case of a Missing cover, the case will be assigned to the sender of the payment instruction, before following the route of the payment instruction.

func (c *ClaimNonReceipt) AddAssignment() *iso20022.CaseAssignment

func (c *ClaimNonReceipt) AddCase() *iso20022.Case

func (c *ClaimNonReceipt) AddMissingCover() *iso20022.MissingCover

func (c *ClaimNonReceipt) AddUnderlying() *iso20022.PaymentInstructionExtract

type ClaimNonReceiptV03 ¶

type ClaimNonReceiptV03 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment2 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`

	// Identifies the payment instruction for which the Creditor has not received the funds.
	// Usage: In case of a missing cover, it must be the identification of the related payment instruction.
	// In case of a claim non receipt initiated by the debtor, it must be the identification of the instruction.
	Underlying *iso20022.UnderlyingTransaction1Choice `xml:"Undrlyg"`

	// Provides the cover related information of a claim non receipt investigation. The absence of the component means that the message is not a cover related investigation.
	CoverDetails *iso20022.MissingCover2 `xml:"CoverDtls,omitempty"`
}

Scope The Claim Non Receipt message is sent by a case creator/case assigner to a case assignee. This message is used to initiate an investigation for missing funds at the creditor (missing credit entry to its account) or at an agent along the processing chain (missing cover for a received payment instruction). Usage The claim non receipt case occurs in two situations: - The creditor is expecting funds from a particular debtor and cannot find the corresponding credit entry on its account. In this situation, it is understood that the creditor will contact its debtor, and that the debtor will trigger the claim non receipt case on its behalf. A workflow where the creditor directly addresses a Claim Non Receipt message to its account servicing institution is not retained. - An agent in the processing chain cannot find a cover payment corresponding to a received payment instruction. In this situation, the agent may directly trigger the investigation by sending a Claim Non Receipt message to the sender of the original payment instruction. The Claim Non Receipt message covers one and only one payment instruction at a time. If several expected payment instructions/cover instructions are found missing, then multiple Claim Non Receipt messages must be sent. Depending on the result of the investigation by a case assignee (incorrect routing, errors/omissions when processing the instruction or even the absence of an error) and the stage at which the payment instruction is being process, the claim non receipt case may lead to a: - Request To Cancel Payment message, sent to the subsequent agent in the payment processing chain, if the original payment instruction has been incorrectly routed through the chain of agents. (This also implies that a new, corrected, payment instruction is issued). - Request To Modify Payment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction. If the above situations occur, the assignee wanting to request a payment cancellation or payment modification should first send out a Resolution Of Investigation with a confirmation status that indicates that either cancellation (CWFW) modification (MWFW) or unable to apply (UWFW) will follow. (See section on Resolution Of Investigation for more details). In the cover is missing, the case assignee may also simply issue the omitted cover payment or when the initial cover information was incorrect, update the cover (through modification and/or cancellation as required) with the correction information provided in the ClaimNonReceipt message. The case assignee will issue a Resolution Of Investigation message with the CorrectionTransaction element mentioning the references of the cover payment. The Claim Non Receipt message may be forwarded to subsequent case assignees.

func (c *ClaimNonReceiptV03) AddAssignment() *iso20022.CaseAssignment2

func (c *ClaimNonReceiptV03) AddCase() *iso20022.Case2

func (c *ClaimNonReceiptV03) AddCoverDetails() *iso20022.MissingCover2

func (c *ClaimNonReceiptV03) AddUnderlying() *iso20022.UnderlyingTransaction1Choice

type ClaimNonReceiptV04 ¶

type ClaimNonReceiptV04 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the payment instruction for which the Creditor has not received the funds.
	// Usage: In case of a missing cover, it must be the identification of the related payment instruction.
	// In case of a claim non receipt initiated by the debtor, it must be the identification of the instruction.
	Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"`

	// Provides the cover related information of a claim non receipt investigation. The absence of the component means that the message is not a cover related investigation.
	CoverDetails *iso20022.MissingCover3 `xml:"CoverDtls,omitempty"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Claim Non Receipt message is sent by a case creator/case assigner to a case assignee. This message is used to initiate an investigation for missing funds at the creditor (missing credit entry to its account) or at an agent along the processing chain (missing cover for a received payment instruction). Usage The claim non receipt case occurs in two situations: - The creditor is expecting funds from a particular debtor and cannot find the corresponding credit entry on its account. In this situation, it is understood that the creditor will contact its debtor, and that the debtor will trigger the claim non receipt case on its behalf. A workflow where the creditor directly addresses a Claim Non Receipt message to its account servicing institution is not retained. - An agent in the processing chain cannot find a cover payment corresponding to a received payment instruction. In this situation, the agent may directly trigger the investigation by sending a Claim Non Receipt message to the sender of the original payment instruction. The Claim Non Receipt message covers one and only one payment instruction at a time. If several expected payment instructions/cover instructions are found missing, then multiple Claim Non Receipt messages must be sent. Depending on the result of the investigation by a case assignee (incorrect routing, errors/omissions when processing the instruction or even the absence of an error) and the stage at which the payment instruction is being process, the claim non receipt case may lead to a: - Request To Cancel Payment message, sent to the subsequent agent in the payment processing chain, if the original payment instruction has been incorrectly routed through the chain of agents. (This also implies that a new, corrected, payment instruction is issued). - Request To Modify Payment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction. If the above situations occur, the assignee wanting to request a payment cancellation or payment modification should first send out a Resolution Of Investigation with a confirmation status that indicates that either cancellation (CWFW) modification (MWFW) or unable to apply (UWFW) will follow. (See section on Resolution Of Investigation for more details). In the cover is missing, the case assignee may also simply issue the omitted cover payment or when the initial cover information was incorrect, update the cover (through modification and/or cancellation as required) with the correction information provided in the ClaimNonReceipt message. The case assignee will issue a Resolution Of Investigation message with the CorrectionTransaction element mentioning the references of the cover payment. The Claim Non Receipt message may be forwarded to subsequent case assignees. The ClaimNonReceipt message has the following main characteristics: - Case Identification: The case creator assigns a unique case identification. This information will be passed unchanged to subsequent case assignee(s). - Underlying Payment: The case creator refers to the underlying payment instruction for the unambiguous identification of the payment instruction. This identification needs to be updated by the subsequent case assigner(s) in order to match the one used with their case assignee(s). - MissingCoverIndicator: The MissingCoverIndication element distinguishes between a missing cover situation (when set to YES) or a missing funds situation (when set to NO). - CoverCorrection The CoverCorrection element allows the case assigner to provide corrected cover information, when these are incorrect in the underlying payment instruction for which the cover is issued.

func (c *ClaimNonReceiptV04) AddAssignment() *iso20022.CaseAssignment3

func (c *ClaimNonReceiptV04) AddCase() *iso20022.Case3

func (c *ClaimNonReceiptV04) AddCoverDetails() *iso20022.MissingCover3

func (c *ClaimNonReceiptV04) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *ClaimNonReceiptV04) AddUnderlying() *iso20022.UnderlyingTransaction2Choice

type ClaimNonReceiptV05 ¶

type ClaimNonReceiptV05 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the payment instruction for which the Creditor has not received the funds.
	// Usage: In case of a missing cover, it must be the identification of the related payment instruction.
	// In case of a claim non receipt initiated by the debtor, it must be the identification of the instruction.
	Underlying *iso20022.UnderlyingTransaction3Choice `xml:"Undrlyg"`

	// Provides the cover related information of a claim non receipt investigation. The absence of the component means that the message is not a cover related investigation.
	CoverDetails *iso20022.MissingCover3 `xml:"CoverDtls,omitempty"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Claim Non Receipt message is sent by a case creator/case assigner to a case assignee. This message is used to initiate an investigation for missing funds at the creditor (missing credit entry to its account) or at an agent along the processing chain (missing cover for a received payment instruction). Usage The claim non receipt case occurs in two situations: - The creditor is expecting funds from a particular debtor and cannot find the corresponding credit entry on its account. In this situation, it is understood that the creditor will contact its debtor, and that the debtor will trigger the claim non receipt case on its behalf. A workflow where the creditor directly addresses a Claim Non Receipt message to its account servicing institution is not retained. - An agent in the processing chain cannot find a cover payment corresponding to a received payment instruction. In this situation, the agent may directly trigger the investigation by sending a Claim Non Receipt message to the sender of the original payment instruction. The Claim Non Receipt message covers one and only one payment instruction at a time. If several expected payment instructions/cover instructions are found missing, then multiple Claim Non Receipt messages must be sent. Depending on the result of the investigation by a case assignee (incorrect routing, errors/omissions when processing the instruction or even the absence of an error) and the stage at which the payment instruction is being process, the claim non receipt case may lead to a: - Request To Cancel Payment message, sent to the subsequent agent in the payment processing chain, if the original payment instruction has been incorrectly routed through the chain of agents. (This also implies that a new, corrected, payment instruction is issued). - Request To Modify Payment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction. If the above situations occur, the assignee wanting to request a payment cancellation or payment modification should first send out a Resolution Of Investigation with a confirmation status that indicates that either cancellation (CWFW) modification (MWFW) or unable to apply (UWFW) will follow. (See section on Resolution Of Investigation for more details). In the cover is missing, the case assignee may also simply issue the omitted cover payment or when the initial cover information was incorrect, update the cover (through modification and/or cancellation as required) with the correction information provided in the ClaimNonReceipt message. The case assignee will issue a Resolution Of Investigation message with the CorrectionTransaction element mentioning the references of the cover payment. The Claim Non Receipt message may be forwarded to subsequent case assignees. The ClaimNonReceipt message has the following main characteristics: - Case Identification: The case creator assigns a unique case identification. This information will be passed unchanged to subsequent case assignee(s). - Underlying Payment: The case creator refers to the underlying payment instruction for the unambiguous identification of the payment instruction. This identification needs to be updated by the subsequent case assigner(s) in order to match the one used with their case assignee(s). - MissingCoverIndicator: The MissingCoverIndication element distinguishes between a missing cover situation (when set to YES) or a missing funds situation (when set to NO). - CoverCorrection The CoverCorrection element allows the case assigner to provide corrected cover information, when these are incorrect in the underlying payment instruction for which the cover is issued.

func (c *ClaimNonReceiptV05) AddAssignment() *iso20022.CaseAssignment3

func (c *ClaimNonReceiptV05) AddCase() *iso20022.Case3

func (c *ClaimNonReceiptV05) AddCoverDetails() *iso20022.MissingCover3

func (c *ClaimNonReceiptV05) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *ClaimNonReceiptV05) AddUnderlying() *iso20022.UnderlyingTransaction3Choice

type CustomerPaymentCancellationRequestV01 ¶

type CustomerPaymentCancellationRequestV01 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment2 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case,omitempty"`

	// Provides details on the number of transactions and the control sum of the message.
	ControlData *iso20022.ControlData1 `xml:"CtrlData,omitempty"`

	// Identifies the payment instruction to be cancelled.
	Underlying []*iso20022.UnderlyingTransaction1 `xml:"Undrlyg"`
}

Scope The Customer Payment Cancellation Request message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The Customer Payment Cancellation Request message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The Customer Payment Cancellation Request message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested cancellation - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction, ...) - Reject Investigation message when the case assignee is unable or not authorised to perform the requested cancellation - Notification Of Case Assignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain. A Customer Payment Cancellation Request message concerns one and only one original payment instruction at a time. When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the Resolution Of Investigation message. The processing of a Customer Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The Customer Payment Cancellation Request message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original Customer Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'.

func (c *CustomerPaymentCancellationRequestV01) AddAssignment() *iso20022.CaseAssignment2

func (c *CustomerPaymentCancellationRequestV01) AddCase() *iso20022.Case2

func (c *CustomerPaymentCancellationRequestV01) AddControlData() *iso20022.ControlData1

func (c *CustomerPaymentCancellationRequestV01) AddUnderlying() *iso20022.UnderlyingTransaction1

type CustomerPaymentCancellationRequestV02 ¶

type CustomerPaymentCancellationRequestV02 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case,omitempty"`

	// Provides details on the number of transactions and the control sum of the message.
	ControlData *iso20022.ControlData1 `xml:"CtrlData,omitempty"`

	// Identifies the payment instruction to be cancelled.
	Underlying []*iso20022.UnderlyingTransaction6 `xml:"Undrlyg"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Customer Payment Cancellation Request message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The Customer Payment Cancellation Request message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The Customer Payment Cancellation Request message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested cancellation - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction, ...) - Reject Investigation message when the case assignee is unable or not authorised to perform the requested cancellation - Notification Of Case Assignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain. A Customer Payment Cancellation Request message concerns one and only one original payment instruction at a time. When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the Resolution Of Investigation message. The processing of a Customer Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The Customer Payment Cancellation Request message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original Customer Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The Customer Payment Cancellation Request message has the following main characteristics: The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). For the Customer Payment Cancellation Request message has been made optional, as the message might be used outside of a case management environment where the case identification is not relevant. Moreover, the case identification may be present at different levels: - One unique case is defined per cancellation request message: If multiple underlying groups, payment information blocks or transactions are present in the message and the case assignee has already forwarded the transaction for which the cancellation is requested, the case cannot be forwarded to the next party in the chain (see rule on uniqueness of the case) and the case creator will have to issue individual cancellation requests for each underlying individual transaction. In response to this cancellation request, the case must also be present at the message level in the Resolution of Investigation message. - One case per original group, payment information or transaction present in the cancellation request: For each group, payment information block or transaction within the payment information, a unique case has been assigned. This means, when a payment instruction has already been forwarded by the case assignee, the cancellation request may be forwarded to next party in the payment chain, with the unique case assigned to the transaction. When the group can only be cancelled partially, new cancellation requests need however to be issued for the individual transactions within the group for which the cancellation request has not been successful. In response to this cancellation request, the case must be present in the cancellation details identifying the original group or transaction in the Resolution of Investigation message. - No case used in cancellation request message: The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.

func (c *CustomerPaymentCancellationRequestV02) AddAssignment() *iso20022.CaseAssignment3

func (c *CustomerPaymentCancellationRequestV02) AddCase() *iso20022.Case3

func (c *CustomerPaymentCancellationRequestV02) AddControlData() *iso20022.ControlData1

func (c *CustomerPaymentCancellationRequestV02) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *CustomerPaymentCancellationRequestV02) AddUnderlying() *iso20022.UnderlyingTransaction6

type CustomerPaymentCancellationRequestV03 ¶

type CustomerPaymentCancellationRequestV03 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case,omitempty"`

	// Provides details on the number of transactions and the control sum of the message.
	ControlData *iso20022.ControlData1 `xml:"CtrlData,omitempty"`

	// Identifies the payment instruction to be cancelled.
	Underlying []*iso20022.UnderlyingTransaction7 `xml:"Undrlyg"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Customer Payment Cancellation Request message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The Customer Payment Cancellation Request message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The Customer Payment Cancellation Request message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested cancellation - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction, ...) - Reject Investigation message when the case assignee is unable or not authorised to perform the requested cancellation - Notification Of Case Assignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain. A Customer Payment Cancellation Request message concerns one and only one original payment instruction at a time. When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the Resolution Of Investigation message. The processing of a Customer Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The Customer Payment Cancellation Request message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original Customer Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The Customer Payment Cancellation Request message has the following main characteristics: The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). For the Customer Payment Cancellation Request message has been made optional, as the message might be used outside of a case management environment where the case identification is not relevant. Moreover, the case identification may be present at different levels: - One unique case is defined per cancellation request message: If multiple underlying groups, payment information blocks or transactions are present in the message and the case assignee has already forwarded the transaction for which the cancellation is requested, the case cannot be forwarded to the next party in the chain (see rule on uniqueness of the case) and the case creator will have to issue individual cancellation requests for each underlying individual transaction. In response to this cancellation request, the case must also be present at the message level in the Resolution of Investigation message. - One case per original group, payment information or transaction present in the cancellation request: For each group, payment information block or transaction within the payment information, a unique case has been assigned. This means, when a payment instruction has already been forwarded by the case assignee, the cancellation request may be forwarded to next party in the payment chain, with the unique case assigned to the transaction. When the group can only be cancelled partially, new cancellation requests need however to be issued for the individual transactions within the group for which the cancellation request has not been successful. In response to this cancellation request, the case must be present in the cancellation details identifying the original group or transaction in the Resolution of Investigation message. - No case used in cancellation request message: The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.

func (c *CustomerPaymentCancellationRequestV03) AddAssignment() *iso20022.CaseAssignment3

func (c *CustomerPaymentCancellationRequestV03) AddCase() *iso20022.Case3

func (c *CustomerPaymentCancellationRequestV03) AddControlData() *iso20022.ControlData1

func (c *CustomerPaymentCancellationRequestV03) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *CustomerPaymentCancellationRequestV03) AddUnderlying() *iso20022.UnderlyingTransaction7

type CustomerPaymentCancellationRequestV04 ¶

type CustomerPaymentCancellationRequestV04 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case,omitempty"`

	// Provides details on the number of transactions and the control sum of the message.
	ControlData *iso20022.ControlData1 `xml:"CtrlData,omitempty"`

	// Identifies the payment instruction to be cancelled.
	Underlying []*iso20022.UnderlyingTransaction11 `xml:"Undrlyg"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Customer Payment Cancellation Request message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The Customer Payment Cancellation Request message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The Customer Payment Cancellation Request message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested cancellation - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction, ...) - Reject Investigation message when the case assignee is unable or not authorised to perform the requested cancellation - Notification Of Case Assignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain. A Customer Payment Cancellation Request message concerns one and only one original payment instruction at a time. When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the Resolution Of Investigation message. The processing of a Customer Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The Customer Payment Cancellation Request message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original Customer Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The Customer Payment Cancellation Request message has the following main characteristics: The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). For the Customer Payment Cancellation Request message has been made optional, as the message might be used outside of a case management environment where the case identification is not relevant. Moreover, the case identification may be present at different levels: - One unique case is defined per cancellation request message: If multiple underlying groups, payment information blocks or transactions are present in the message and the case assignee has already forwarded the transaction for which the cancellation is requested, the case cannot be forwarded to the next party in the chain (see rule on uniqueness of the case) and the case creator will have to issue individual cancellation requests for each underlying individual transaction. In response to this cancellation request, the case must also be present at the message level in the Resolution of Investigation message. - One case per original group, payment information or transaction present in the cancellation request: For each group, payment information block or transaction within the payment information, a unique case has been assigned. This means, when a payment instruction has already been forwarded by the case assignee, the cancellation request may be forwarded to next party in the payment chain, with the unique case assigned to the transaction. When the group can only be cancelled partially, new cancellation requests need however to be issued for the individual transactions within the group for which the cancellation request has not been successful. In response to this cancellation request, the case must be present in the cancellation details identifying the original group or transaction in the Resolution of Investigation message. - No case used in cancellation request message: The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.

func (c *CustomerPaymentCancellationRequestV04) AddAssignment() *iso20022.CaseAssignment3

func (c *CustomerPaymentCancellationRequestV04) AddCase() *iso20022.Case3

func (c *CustomerPaymentCancellationRequestV04) AddControlData() *iso20022.ControlData1

func (c *CustomerPaymentCancellationRequestV04) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *CustomerPaymentCancellationRequestV04) AddUnderlying() *iso20022.UnderlyingTransaction11

type CustomerPaymentCancellationRequestV05 ¶

type CustomerPaymentCancellationRequestV05 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case,omitempty"`

	// Provides details on the number of transactions and the control sum of the message.
	ControlData *iso20022.ControlData1 `xml:"CtrlData,omitempty"`

	// Identifies the payment instruction to be cancelled.
	Underlying []*iso20022.UnderlyingTransaction12 `xml:"Undrlyg"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The CustomerPaymentCancellationRequest message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The CustomerPaymentCancellationRequest message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The CustomerPaymentCancellationRequest message must be answered with a: - ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested cancellation - ResolutionOfInvestigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction, ...) - RejectInvestigation message when the case assignee is unable or not authorised to perform the requested cancellation - NotificationOfCaseAssignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain. A CustomerPaymentCancellationRequest message concerns one and only one original payment instruction at a time. When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the ResolutionOfInvestigation message. The processing of a CustomerPaymentCancellationRequest message case may lead to a DebitAuthorisationRequest message sent to the creditor by its account servicing institution. The CustomerPaymentCancellationRequest message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original CustomerPaymentCancellationRequest message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The CustomerPaymentCancellationRequest message has the following main characteristics: The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). For the CustomerPaymentCancellationRequest message has been made optional, as the message might be used outside of a case management environment where the case identification is not relevant. Moreover, the case identification may be present at different levels: - One unique case is defined per cancellation request message: If multiple underlying groups, payment information blocks or transactions are present in the message and the case assignee has already forwarded the transaction for which the cancellation is requested, the case cannot be forwarded to the next party in the chain (see rule on uniqueness of the case) and the case creator will have to issue individual cancellation requests for each underlying individual transaction. In response to this cancellation request, the case must also be present at the message level in the Resolution of Investigation message. - One case per original group, payment information or transaction present in the cancellation request: For each group, payment information block or transaction within the payment information, a unique case has been assigned. This means, when a payment instruction has already been forwarded by the case assignee, the cancellation request may be forwarded to next party in the payment chain, with the unique case assigned to the transaction. When the group can only be cancelled partially, new cancellation requests need however to be issued for the individual transactions within the group for which the cancellation request has not been successful. In response to this cancellation request, the case must be present in the cancellation details identifying the original group or transaction in the Resolution of Investigation message. - No case used in cancellation request message: The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.

func (c *CustomerPaymentCancellationRequestV05) AddAssignment() *iso20022.CaseAssignment3

func (c *CustomerPaymentCancellationRequestV05) AddCase() *iso20022.Case3

func (c *CustomerPaymentCancellationRequestV05) AddControlData() *iso20022.ControlData1

func (c *CustomerPaymentCancellationRequestV05) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *CustomerPaymentCancellationRequestV05) AddUnderlying() *iso20022.UnderlyingTransaction12

type CustomerPaymentCancellationRequestV06 ¶

type CustomerPaymentCancellationRequestV06 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case,omitempty"`

	// Provides details on the number of transactions and the control sum of the message.
	ControlData *iso20022.ControlData1 `xml:"CtrlData,omitempty"`

	// Identifies the payment instruction to be cancelled.
	Underlying []*iso20022.UnderlyingTransaction15 `xml:"Undrlyg"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The CustomerPaymentCancellationRequest message is sent by a case creator/case assigner to a case assignee. This message is used to request the cancellation of an original payment instruction. The CustomerPaymentCancellationRequest message is issued by the initiating party to request the cancellation of an initiation payment message previously sent (such as CustomerCreditTransferInitiation or CustomerDirectDebitInitiation). Usage The CustomerPaymentCancellationRequest message must be answered with a: - ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested cancellation - ResolutionOfInvestigation message with a negative final outcome when the case assignee may perform the requested cancellation but fails to do so (too late, irrevocable instruction, ...) - RejectInvestigation message when the case assignee is unable or not authorised to perform the requested cancellation - NotificationOfCaseAssignment message to indicate whether the case assignee will take on the case himself or reassign the case to a subsequent party in the payment processing chain. A CustomerPaymentCancellationRequest message concerns one and only one original payment instruction at a time. When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner. It may provide some details about the return in the ResolutionOfInvestigation message. The processing of a CustomerPaymentCancellationRequest message case may lead to a DebitAuthorisationRequest message sent to the creditor by its account servicing institution. The CustomerPaymentCancellationRequest message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original CustomerPaymentCancellationRequest message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The CustomerPaymentCancellationRequest message has the following main characteristics: The case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s). For the CustomerPaymentCancellationRequest message has been made optional, as the message might be used outside of a case management environment where the case identification is not relevant. Moreover, the case identification may be present at different levels: - One unique case is defined per cancellation request message: If multiple underlying groups, payment information blocks or transactions are present in the message and the case assignee has already forwarded the transaction for which the cancellation is requested, the case cannot be forwarded to the next party in the chain (see rule on uniqueness of the case) and the case creator will have to issue individual cancellation requests for each underlying individual transaction. In response to this cancellation request, the case must also be present at the message level in the Resolution of Investigation message. - One case per original group, payment information or transaction present in the cancellation request: For each group, payment information block or transaction within the payment information, a unique case has been assigned. This means, when a payment instruction has already been forwarded by the case assignee, the cancellation request may be forwarded to next party in the payment chain, with the unique case assigned to the transaction. When the group can only be cancelled partially, new cancellation requests need however to be issued for the individual transactions within the group for which the cancellation request has not been successful. In response to this cancellation request, the case must be present in the cancellation details identifying the original group or transaction in the Resolution of Investigation message. - No case used in cancellation request message: The cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.

func (c *CustomerPaymentCancellationRequestV06) AddAssignment() *iso20022.CaseAssignment3

func (c *CustomerPaymentCancellationRequestV06) AddCase() *iso20022.Case3

func (c *CustomerPaymentCancellationRequestV06) AddControlData() *iso20022.ControlData1

func (c *CustomerPaymentCancellationRequestV06) AddSupplementaryData() *iso20022.SupplementaryData1

func (c *CustomerPaymentCancellationRequestV06) AddUnderlying() *iso20022.UnderlyingTransaction15

type DebitAuthorisationRequest ¶

type DebitAuthorisationRequest struct {

	// Identifies the case assignment.
	Assignment *iso20022.CaseAssignment `xml:"Assgnmt"`

	// Identifies the case.
	Case *iso20022.Case `xml:"Case"`

	// Identifies the underlying payment instructrion.
	Underlying *iso20022.PaymentInstructionExtract `xml:"Undrlyg"`

	// Detailed information about the request.
	Detail *iso20022.DebitAuthorisationDetails `xml:"Dtl"`
}

Scope The Debit Authorisation Request message is sent by an account servicing institution to an account owner. This message is used to request authorisation to debit an account. Usage The Debit Authorisation Request message must be answered with a Debit Authorisation Response message. The Debit Authorisation Request message can be used to request debit authorisation in a: - request to modify payment case (in the case of a lower final amount or change of creditor) - request to cancel payment case (full amount) - unable to apply case (the creditor whose account has been credited is not the intended beneficiary) - claim non receipt case (the creditor whose account has been credited is not the intended beneficiary) The Debit Authorisation Request message covers one and only one payment instruction at a time. If an account servicing institution needs to request debit authorisation for several instructions, then multiple Debit Authorisation Request messages must be sent. The Debit Authorisation Request must be used exclusively between the account servicing institution and the account owner. It must not be used in place of a Request To Modify Payment or Request To Cancel Payment message between subsequent agents.

func (d *DebitAuthorisationRequest) AddAssignment() *iso20022.CaseAssignment

func (d *DebitAuthorisationRequest) AddCase() *iso20022.Case

func (d *DebitAuthorisationRequest) AddDetail() *iso20022.DebitAuthorisationDetails

func (d *DebitAuthorisationRequest) AddUnderlying() *iso20022.PaymentInstructionExtract

type DebitAuthorisationRequestV03 ¶

type DebitAuthorisationRequestV03 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment2 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`

	// Identifies the underlying payment instructrion.
	Underlying *iso20022.UnderlyingTransaction1Choice `xml:"Undrlyg"`

	// Detailed information about the request.
	Detail *iso20022.DebitAuthorisationDetails3 `xml:"Dtl"`
}

Scope The Debit Authorisation Request message is sent by an account servicing institution to an account owner. This message is used to request authorisation to debit an account. Usage The Debit Authorisation Request message must be answered with a Debit Authorisation Response message. The Debit Authorisation Request message can be used to request debit authorisation in a: - request to modify payment case (in the case of a lower final amount or change of creditor) - request to cancel payment case (full amount) - unable to apply case (the creditor whose account has been credited is not the intended beneficiary) - claim non receipt case (the creditor whose account has been credited is not the intended beneficiary) The Debit Authorisation Request message covers one and only one payment instruction at a time. If an account servicing institution needs to request debit authorisation for several instructions, then multiple Debit Authorisation Request messages must be sent. The Debit Authorisation Request must be used exclusively between the account servicing institution and the account owner. It must not be used in place of a Request To Modify Payment or Request To Cancel Payment message between subsequent agents.

func (d *DebitAuthorisationRequestV03) AddAssignment() *iso20022.CaseAssignment2

func (d *DebitAuthorisationRequestV03) AddCase() *iso20022.Case2

func (d *DebitAuthorisationRequestV03) AddDetail() *iso20022.DebitAuthorisationDetails3

func (d *DebitAuthorisationRequestV03) AddUnderlying() *iso20022.UnderlyingTransaction1Choice

type DebitAuthorisationRequestV04 ¶

type DebitAuthorisationRequestV04 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the underlying payment instructrion.
	Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"`

	// Detailed information about the request.
	Detail *iso20022.DebitAuthorisation1 `xml:"Dtl"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Debit Authorisation Request message is sent by an account servicing institution to an account owner. This message is used to request authorisation to debit an account. Usage The Debit Authorisation Request message must be answered with a Debit Authorisation Response message. The Debit Authorisation Request message can be used to request debit authorisation in a: - request to modify payment case (in the case of a lower final amount or change of creditor) - request to cancel payment case (full amount) - unable to apply case (the creditor whose account has been credited is not the intended beneficiary) - claim non receipt case (the creditor whose account has been credited is not the intended beneficiary) The Debit Authorisation Request message covers one and only one payment instruction at a time. If an account servicing institution needs to request debit authorisation for several instructions, then multiple Debit Authorisation Request messages must be sent. The Debit Authorisation Request must be used exclusively between the account servicing institution and the account owner. It must not be used in place of a Request To Modify Payment or Request To Cancel Payment message between subsequent agents.

func (d *DebitAuthorisationRequestV04) AddAssignment() *iso20022.CaseAssignment3

func (d *DebitAuthorisationRequestV04) AddCase() *iso20022.Case3

func (d *DebitAuthorisationRequestV04) AddDetail() *iso20022.DebitAuthorisation1

func (d *DebitAuthorisationRequestV04) AddSupplementaryData() *iso20022.SupplementaryData1

func (d *DebitAuthorisationRequestV04) AddUnderlying() *iso20022.UnderlyingTransaction2Choice

type DebitAuthorisationRequestV05 ¶

type DebitAuthorisationRequestV05 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Identifies the underlying payment instruction.
	Underlying *iso20022.UnderlyingTransaction3Choice `xml:"Undrlyg"`

	// Detailed information about the request.
	Detail *iso20022.DebitAuthorisation2 `xml:"Dtl"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Debit Authorisation Request message is sent by an account servicing institution to an account owner. This message is used to request authorisation to debit an account. Usage The Debit Authorisation Request message must be answered with a Debit Authorisation Response message. The Debit Authorisation Request message can be used to request debit authorisation in a: - request to modify payment case (in the case of a lower final amount or change of creditor) - request to cancel payment case (full amount) - unable to apply case (the creditor whose account has been credited is not the intended beneficiary) - claim non receipt case (the creditor whose account has been credited is not the intended beneficiary) The Debit Authorisation Request message covers one and only one payment instruction at a time. If an account servicing institution needs to request debit authorisation for several instructions, then multiple Debit Authorisation Request messages must be sent. The Debit Authorisation Request must be used exclusively between the account servicing institution and the account owner. It must not be used in place of a Request To Modify Payment or Request To Cancel Payment message between subsequent agents.

func (d *DebitAuthorisationRequestV05) AddAssignment() *iso20022.CaseAssignment3

func (d *DebitAuthorisationRequestV05) AddCase() *iso20022.Case3

func (d *DebitAuthorisationRequestV05) AddDetail() *iso20022.DebitAuthorisation2

func (d *DebitAuthorisationRequestV05) AddSupplementaryData() *iso20022.SupplementaryData1

func (d *DebitAuthorisationRequestV05) AddUnderlying() *iso20022.UnderlyingTransaction3Choice

type DebitAuthorisationResponse ¶

type DebitAuthorisationResponse struct {

	// Identifies an assignment.
	Assignment *iso20022.CaseAssignment `xml:"Assgnmt"`

	// Identifies a case.
	Case *iso20022.Case `xml:"Case"`

	// Indicates if the debit authorisation is granted or not.
	Confirmation *iso20022.DebitAuthorisationConfirmation `xml:"Conf"`
}

Scope The Debit Authorisation Response message is sent by an account owner to its account servicing institution. This message is used to approve or reject a debit authorisation request. Usage The Debit Authorisation Response message is used to reply to a Debit Authorisation Request message. The Debit Authorisation Response message covers one and only one payment instruction at a time. If an account owner needs to reply to several Debit Authorisation Request messages, then multiple Debit Authorisation Response messages must be sent. The Debit Authorisation Response message indicates whether the account owner agrees with the request by means of a code. It also allows further details to be given about the debit authorisation, such as acceptable amount and value date for the debit. The Debit Authorisation Response message must be used exclusively between the account owner and the account servicing institution. It must not be used in place of a Resolution Of Investigation message between subsequent agents.

func (d *DebitAuthorisationResponse) AddAssignment() *iso20022.CaseAssignment

func (d *DebitAuthorisationResponse) AddCase() *iso20022.Case

func (d *DebitAuthorisationResponse) AddConfirmation() *iso20022.DebitAuthorisationConfirmation

type DebitAuthorisationResponseV02 ¶

type DebitAuthorisationResponseV02 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment2 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case2 `xml:"Case"`

	// Indicates if the debit authorisation is granted or not.
	Confirmation *iso20022.DebitAuthorisationConfirmation2 `xml:"Conf"`
}

Scope The Debit Authorisation Response message is sent by an account owner to its account servicing institution. This message is used to approve or reject a debit authorisation request. Usage The Debit Authorisation Response message is used to reply to a Debit Authorisation Request message. The Debit Authorisation Response message covers one and only one payment instruction at a time. If an account owner needs to reply to several Debit Authorisation Request messages, then multiple Debit Authorisation Response messages must be sent. The Debit Authorisation Response message indicates whether the account owner agrees with the request by means of a code. It also allows further details to be given about the debit authorisation, such as acceptable amount and value date for the debit. The Debit Authorisation Response message must be used exclusively between the account owner and the account servicing institution. It must not be used in place of a Resolution Of Investigation message between subsequent agents.

func (d *DebitAuthorisationResponseV02) AddAssignment() *iso20022.CaseAssignment2

func (d *DebitAuthorisationResponseV02) AddCase() *iso20022.Case2

func (d *DebitAuthorisationResponseV02) AddConfirmation() *iso20022.DebitAuthorisationConfirmation2

type DebitAuthorisationResponseV03 ¶

type DebitAuthorisationResponseV03 struct {

	// Identifies the assignment of an investigation case from an assigner to an assignee.
	// Usage: The Assigner must be the sender of this confirmation and the Assignee must be the receiver.
	Assignment *iso20022.CaseAssignment3 `xml:"Assgnmt"`

	// Identifies the investigation case.
	Case *iso20022.Case3 `xml:"Case"`

	// Indicates if the debit authorisation is granted or not.
	Confirmation *iso20022.DebitAuthorisationConfirmation2 `xml:"Conf"`

	// Additional information that cannot be captured in the structured elements and/or any other specific block.
	SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"`
}

Scope The Debit Authorisation Response message is sent by an account owner to its account servicing institution. This message is used to approve or reject a debit authorisation request. Usage The Debit Authorisation Response message is used to reply to a Debit Authorisation Request message. The Debit Authorisation Response message covers one and only one payment instruction at a time. If an account owner needs to reply to several Debit Authorisation Request messages, then multiple Debit Authorisation Response messages must be sent. The Debit Authorisation Response message indicates whether the account owner agrees with the request by means of a code. It also allows further details to be given about the debit authorisation, such as acceptable amount and value date for the debit. The Debit Authorisation Response message must be used exclusively between the account owner and the account servicing institution. It must not be used in place of a Resolution Of Investigation message between subsequent agents.

func (d *DebitAuthorisationResponseV03) AddAssignment() *iso20022.CaseAssignment3

func (d *DebitAuthorisationResponseV03) AddCase() *iso20022.Case3

func (d *DebitAuthorisationResponseV03) AddConfirmation() *iso20022.DebitAuthorisationConfirmation2

func (d *DebitAuthorisationResponseV03) AddSupplementaryData() *iso20022.SupplementaryData1

type Document00700201 ¶

type Document00700201 struct {
	XMLName xml.Name                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.007.002.01 Document"`
	Message *RequestToModifyPayment `xml:"camt.007.002.01"`
}

func (d *Document00700201) AddMessage() *RequestToModifyPayment

type Document00800201 ¶

type Document00800201 struct {
	XMLName xml.Name                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.008.002.01 Document"`
	Message *RequestToCancelPayment `xml:"camt.008.002.01"`
}

func (d *Document00800201) AddMessage() *RequestToCancelPayment

type Document02600101 ¶

type Document02600101 struct {
	XMLName xml.Name       `xml:"urn:iso:std:iso:20022:tech:xsd:camt.026.001.01 Document"`
	Message *UnableToApply `xml:"camt.026.001.01"`
}

func (d *Document02600101) AddMessage() *UnableToApply

type Document02600103 ¶

type Document02600103 struct {
	XMLName xml.Name          `xml:"urn:iso:std:iso:20022:tech:xsd:camt.026.001.03 Document"`
	Message *UnableToApplyV03 `xml:"UblToApply"`
}

func (d *Document02600103) AddMessage() *UnableToApplyV03

type Document02600104 ¶

type Document02600104 struct {
	XMLName xml.Name          `xml:"urn:iso:std:iso:20022:tech:xsd:camt.026.001.04 Document"`
	Message *UnableToApplyV04 `xml:"UblToApply"`
}

func (d *Document02600104) AddMessage() *UnableToApplyV04

type Document02600105 ¶

type Document02600105 struct {
	XMLName xml.Name          `xml:"urn:iso:std:iso:20022:tech:xsd:camt.026.001.05 Document"`
	Message *UnableToApplyV05 `xml:"UblToApply"`
}

func (d *Document02600105) AddMessage() *UnableToApplyV05

type Document02700101 ¶

type Document02700101 struct {
	XMLName xml.Name         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.027.001.01 Document"`
	Message *ClaimNonReceipt `xml:"camt.027.001.01"`
}

func (d *Document02700101) AddMessage() *ClaimNonReceipt

type Document02700103 ¶

type Document02700103 struct {
	XMLName xml.Name            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.027.001.03 Document"`
	Message *ClaimNonReceiptV03 `xml:"ClmNonRct"`
}

func (d *Document02700103) AddMessage() *ClaimNonReceiptV03

type Document02700104 ¶

type Document02700104 struct {
	XMLName xml.Name            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.027.001.04 Document"`
	Message *ClaimNonReceiptV04 `xml:"ClmNonRct"`
}

func (d *Document02700104) AddMessage() *ClaimNonReceiptV04

type Document02700105 ¶

type Document02700105 struct {
	XMLName xml.Name            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.027.001.05 Document"`
	Message *ClaimNonReceiptV05 `xml:"ClmNonRct"`
}

func (d *Document02700105) AddMessage() *ClaimNonReceiptV05

type Document02800101 ¶

type Document02800101 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.028.001.01 Document"`
	Message *AdditionalPaymentInformation `xml:"camt.028.001.01"`
}

func (d *Document02800101) AddMessage() *AdditionalPaymentInformation

type Document02800103 ¶

type Document02800103 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.028.001.03 Document"`
	Message *AdditionalPaymentInformationV03 `xml:"AddtlPmtInf"`
}

func (d *Document02800103) AddMessage() *AdditionalPaymentInformationV03

type Document02800104 ¶

type Document02800104 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.028.001.04 Document"`
	Message *AdditionalPaymentInformationV04 `xml:"AddtlPmtInf"`
}

func (d *Document02800104) AddMessage() *AdditionalPaymentInformationV04

type Document02800105 ¶

type Document02800105 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.028.001.05 Document"`
	Message *AdditionalPaymentInformationV05 `xml:"AddtlPmtInf"`
}

func (d *Document02800105) AddMessage() *AdditionalPaymentInformationV05

type Document02800106 ¶

type Document02800106 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.028.001.06 Document"`
	Message *AdditionalPaymentInformationV06 `xml:"AddtlPmtInf"`
}

func (d *Document02800106) AddMessage() *AdditionalPaymentInformationV06

type Document02800107 ¶

type Document02800107 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.028.001.07 Document"`
	Message *AdditionalPaymentInformationV07 `xml:"AddtlPmtInf"`
}

func (d *Document02800107) AddMessage() *AdditionalPaymentInformationV07

type Document02900101 ¶

type Document02900101 struct {
	XMLName xml.Name                   `xml:"urn:iso:std:iso:20022:tech:xsd:camt.029.001.01 Document"`
	Message *ResolutionOfInvestigation `xml:"camt.029.001.01"`
}

func (d *Document02900101) AddMessage() *ResolutionOfInvestigation

type Document02900103 ¶

type Document02900103 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.029.001.03 Document"`
	Message *ResolutionOfInvestigationV03 `xml:"RsltnOfInvstgtn"`
}

func (d *Document02900103) AddMessage() *ResolutionOfInvestigationV03

type Document02900104 ¶

type Document02900104 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.029.001.04 Document"`
	Message *ResolutionOfInvestigationV04 `xml:"RsltnOfInvstgtn"`
}

func (d *Document02900104) AddMessage() *ResolutionOfInvestigationV04

type Document02900105 ¶

type Document02900105 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.029.001.05 Document"`
	Message *ResolutionOfInvestigationV05 `xml:"RsltnOfInvstgtn"`
}

func (d *Document02900105) AddMessage() *ResolutionOfInvestigationV05

type Document02900106 ¶

type Document02900106 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.029.001.06 Document"`
	Message *ResolutionOfInvestigationV06 `xml:"RsltnOfInvstgtn"`
}

func (d *Document02900106) AddMessage() *ResolutionOfInvestigationV06

type Document02900107 ¶

type Document02900107 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.029.001.07 Document"`
	Message *ResolutionOfInvestigationV07 `xml:"RsltnOfInvstgtn"`
}

func (d *Document02900107) AddMessage() *ResolutionOfInvestigationV07

type Document03000101 ¶

type Document03000101 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.030.001.01 Document"`
	Message *NotificationOfCaseAssignment `xml:"camt.030.001.01"`
}

func (d *Document03000101) AddMessage() *NotificationOfCaseAssignment

type Document03000103 ¶

type Document03000103 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.030.001.03 Document"`
	Message *NotificationOfCaseAssignmentV03 `xml:"NtfctnOfCaseAssgnmt"`
}

func (d *Document03000103) AddMessage() *NotificationOfCaseAssignmentV03

type Document03000104 ¶

type Document03000104 struct {
	XMLName xml.Name                         `xml:"urn:iso:std:iso:20022:tech:xsd:camt.030.001.04 Document"`
	Message *NotificationOfCaseAssignmentV04 `xml:"NtfctnOfCaseAssgnmt"`
}

func (d *Document03000104) AddMessage() *NotificationOfCaseAssignmentV04

type Document03100101 ¶

type Document03100101 struct {
	XMLName xml.Name              `xml:"urn:iso:std:iso:20022:tech:xsd:camt.031.001.01 Document"`
	Message *RejectCaseAssignment `xml:"camt.031.001.01"`
}

func (d *Document03100101) AddMessage() *RejectCaseAssignment

type Document03100103 ¶

type Document03100103 struct {
	XMLName xml.Name                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.031.001.03 Document"`
	Message *RejectInvestigationV03 `xml:"RjctInvstgtn"`
}

func (d *Document03100103) AddMessage() *RejectInvestigationV03

type Document03100104 ¶

type Document03100104 struct {
	XMLName xml.Name                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.031.001.04 Document"`
	Message *RejectInvestigationV04 `xml:"RjctInvstgtn"`
}

func (d *Document03100104) AddMessage() *RejectInvestigationV04

type Document03200101 ¶

type Document03200101 struct {
	XMLName xml.Name              `xml:"urn:iso:std:iso:20022:tech:xsd:camt.032.001.01 Document"`
	Message *CancelCaseAssignment `xml:"camt.032.001.01"`
}

func (d *Document03200101) AddMessage() *CancelCaseAssignment

type Document03200102 ¶

type Document03200102 struct {
	XMLName xml.Name                 `xml:"urn:iso:std:iso:20022:tech:xsd:camt.032.001.02 Document"`
	Message *CancelCaseAssignmentV02 `xml:"CclCaseAssgnmt"`
}

func (d *Document03200102) AddMessage() *CancelCaseAssignmentV02

type Document03200103 ¶

type Document03200103 struct {
	XMLName xml.Name                 `xml:"urn:iso:std:iso:20022:tech:xsd:camt.032.001.03 Document"`
	Message *CancelCaseAssignmentV03 `xml:"CclCaseAssgnmt"`
}

func (d *Document03200103) AddMessage() *CancelCaseAssignmentV03

type Document03300101 ¶

type Document03300101 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.033.001.01 Document"`
	Message *RequestForDuplicateInstruction `xml:"camt.033.001.01"`
}

func (d *Document03300101) AddMessage() *RequestForDuplicateInstruction

type Document03300103 ¶

type Document03300103 struct {
	XMLName xml.Name                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.033.001.03 Document"`
	Message *RequestForDuplicateV03 `xml:"ReqForDplct"`
}

func (d *Document03300103) AddMessage() *RequestForDuplicateV03

type Document03300104 ¶

type Document03300104 struct {
	XMLName xml.Name                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.033.001.04 Document"`
	Message *RequestForDuplicateV04 `xml:"ReqForDplct"`
}

func (d *Document03300104) AddMessage() *RequestForDuplicateV04

type Document03400103 ¶

type Document03400103 struct {
	XMLName xml.Name      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.034.001.03 Document"`
	Message *DuplicateV03 `xml:"Dplct"`
}

func (d *Document03400103) AddMessage() *DuplicateV03

type Document03400104 ¶

type Document03400104 struct {
	XMLName xml.Name      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.034.001.04 Document"`
	Message *DuplicateV04 `xml:"Dplct"`
}

func (d *Document03400104) AddMessage() *DuplicateV04

type Document03500102 ¶

type Document03500102 struct {
	XMLName xml.Name                           `xml:"urn:iso:std:iso:20022:tech:xsd:camt.035.001.02 Document"`
	Message *ProprietaryFormatInvestigationV02 `xml:"PrtryFrmtInvstgtn"`
}

func (d *Document03500102) AddMessage() *ProprietaryFormatInvestigationV02

type Document03500103 ¶

type Document03500103 struct {
	XMLName xml.Name                           `xml:"urn:iso:std:iso:20022:tech:xsd:camt.035.001.03 Document"`
	Message *ProprietaryFormatInvestigationV03 `xml:"PrtryFrmtInvstgtn"`
}

func (d *Document03500103) AddMessage() *ProprietaryFormatInvestigationV03

type Document03600101 ¶

type Document03600101 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.036.001.01 Document"`
	Message *DebitAuthorisationResponse `xml:"camt.036.001.01"`
}

func (d *Document03600101) AddMessage() *DebitAuthorisationResponse

type Document03600102 ¶

type Document03600102 struct {
	XMLName xml.Name                       `xml:"urn:iso:std:iso:20022:tech:xsd:camt.036.001.02 Document"`
	Message *DebitAuthorisationResponseV02 `xml:"DbtAuthstnRspn"`
}

func (d *Document03600102) AddMessage() *DebitAuthorisationResponseV02

type Document03600103 ¶

type Document03600103 struct {
	XMLName xml.Name                       `xml:"urn:iso:std:iso:20022:tech:xsd:camt.036.001.03 Document"`
	Message *DebitAuthorisationResponseV03 `xml:"DbtAuthstnRspn"`
}

func (d *Document03600103) AddMessage() *DebitAuthorisationResponseV03

type Document03700101 ¶

type Document03700101 struct {
	XMLName xml.Name                   `xml:"urn:iso:std:iso:20022:tech:xsd:camt.037.001.01 Document"`
	Message *DebitAuthorisationRequest `xml:"camt.037.001.01"`
}

func (d *Document03700101) AddMessage() *DebitAuthorisationRequest

type Document03700103 ¶

type Document03700103 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.037.001.03 Document"`
	Message *DebitAuthorisationRequestV03 `xml:"DbtAuthstnReq"`
}

func (d *Document03700103) AddMessage() *DebitAuthorisationRequestV03

type Document03700104 ¶

type Document03700104 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.037.001.04 Document"`
	Message *DebitAuthorisationRequestV04 `xml:"DbtAuthstnReq"`
}

func (d *Document03700104) AddMessage() *DebitAuthorisationRequestV04

type Document03700105 ¶

type Document03700105 struct {
	XMLName xml.Name                      `xml:"urn:iso:std:iso:20022:tech:xsd:camt.037.001.05 Document"`
	Message *DebitAuthorisationRequestV05 `xml:"DbtAuthstnReq"`
}

func (d *Document03700105) AddMessage() *DebitAuthorisationRequestV05

type Document03800101 ¶

type Document03800101 struct {
	XMLName xml.Name                 `xml:"urn:iso:std:iso:20022:tech:xsd:camt.038.001.01 Document"`
	Message *CaseStatusReportRequest `xml:"camt.038.001.01"`
}

func (d *Document03800101) AddMessage() *CaseStatusReportRequest

type Document03800102 ¶

type Document03800102 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.038.001.02 Document"`
	Message *CaseStatusReportRequestV02 `xml:"CaseStsRptReq"`
}

func (d *Document03800102) AddMessage() *CaseStatusReportRequestV02

type Document03800103 ¶

type Document03800103 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.038.001.03 Document"`
	Message *CaseStatusReportRequestV03 `xml:"CaseStsRptReq"`
}

func (d *Document03800103) AddMessage() *CaseStatusReportRequestV03

type Document03900101 ¶

type Document03900101 struct {
	XMLName xml.Name          `xml:"urn:iso:std:iso:20022:tech:xsd:camt.039.001.01 Document"`
	Message *CaseStatusReport `xml:"camt.039.001.01"`
}

func (d *Document03900101) AddMessage() *CaseStatusReport

type Document03900103 ¶

type Document03900103 struct {
	XMLName xml.Name             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.039.001.03 Document"`
	Message *CaseStatusReportV03 `xml:"CaseStsRpt"`
}

func (d *Document03900103) AddMessage() *CaseStatusReportV03

type Document03900104 ¶

type Document03900104 struct {
	XMLName xml.Name             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.039.001.04 Document"`
	Message *CaseStatusReportV04 `xml:"CaseStsRpt"`
}

func (d *Document03900104) AddMessage() *CaseStatusReportV04

type Document04000102 ¶

type Document04000102 struct {
	XMLName xml.Name                            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.040.001.02 Document"`
	Message *FundEstimatedCashForecastReportV02 `xml:"camt.040.001.02"`
}

func (d *Document04000102) AddMessage() *FundEstimatedCashForecastReportV02

type Document04000103 ¶

type Document04000103 struct {
	XMLName xml.Name                            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.040.001.03 Document"`
	Message *FundEstimatedCashForecastReportV03 `xml:"FndEstmtdCshFcstRptV03"`
}

func (d *Document04000103) AddMessage() *FundEstimatedCashForecastReportV03

type Document04000104 ¶

type Document04000104 struct {
	XMLName xml.Name                            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.040.001.04 Document"`
	Message *FundEstimatedCashForecastReportV04 `xml:"FndEstmtdCshFcstRpt"`
}

func (d *Document04000104) AddMessage() *FundEstimatedCashForecastReportV04

type Document04100102 ¶

type Document04100102 struct {
	XMLName xml.Name                            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.041.001.02 Document"`
	Message *FundConfirmedCashForecastReportV02 `xml:"camt.041.001.02"`
}

func (d *Document04100102) AddMessage() *FundConfirmedCashForecastReportV02

type Document04100103 ¶

type Document04100103 struct {
	XMLName xml.Name                            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.041.001.03 Document"`
	Message *FundConfirmedCashForecastReportV03 `xml:"FndConfdCshFcstRptV03"`
}

func (d *Document04100103) AddMessage() *FundConfirmedCashForecastReportV03

type Document04100104 ¶

type Document04100104 struct {
	XMLName xml.Name                            `xml:"urn:iso:std:iso:20022:tech:xsd:camt.041.001.04 Document"`
	Message *FundConfirmedCashForecastReportV04 `xml:"FndConfdCshFcstRpt"`
}

func (d *Document04100104) AddMessage() *FundConfirmedCashForecastReportV04

type Document04200102 ¶

type Document04200102 struct {
	XMLName xml.Name                                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.042.001.02 Document"`
	Message *FundDetailedEstimatedCashForecastReportV02 `xml:"camt.042.001.02"`
}

func (d *Document04200102) AddMessage() *FundDetailedEstimatedCashForecastReportV02

type Document04200103 ¶

type Document04200103 struct {
	XMLName xml.Name                                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.042.001.03 Document"`
	Message *FundDetailedEstimatedCashForecastReportV03 `xml:"FndDtldEstmtdCshFcstRptV03"`
}

func (d *Document04200103) AddMessage() *FundDetailedEstimatedCashForecastReportV03

type Document04200104 ¶

type Document04200104 struct {
	XMLName xml.Name                                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.042.001.04 Document"`
	Message *FundDetailedEstimatedCashForecastReportV04 `xml:"FndDtldEstmtdCshFcstRpt"`
}

func (d *Document04200104) AddMessage() *FundDetailedEstimatedCashForecastReportV04

type Document04300102 ¶

type Document04300102 struct {
	XMLName xml.Name                                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.043.001.02 Document"`
	Message *FundDetailedConfirmedCashForecastReportV02 `xml:"camt.043.001.02"`
}

func (d *Document04300102) AddMessage() *FundDetailedConfirmedCashForecastReportV02

type Document04300103 ¶

type Document04300103 struct {
	XMLName xml.Name                                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.043.001.03 Document"`
	Message *FundDetailedConfirmedCashForecastReportV03 `xml:"FndDtldConfdCshFcstRptV03"`
}

func (d *Document04300103) AddMessage() *FundDetailedConfirmedCashForecastReportV03

type Document04300104 ¶

type Document04300104 struct {
	XMLName xml.Name                                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.043.001.04 Document"`
	Message *FundDetailedConfirmedCashForecastReportV04 `xml:"FndDtldConfdCshFcstRpt"`
}

func (d *Document04300104) AddMessage() *FundDetailedConfirmedCashForecastReportV04

type Document04400101 ¶

type Document04400101 struct {
	XMLName xml.Name                                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.044.001.01 Document"`
	Message *FundConfirmedCashForecastReportCancellationV01 `xml:"camt.044.001.01"`
}

func (d *Document04400101) AddMessage() *FundConfirmedCashForecastReportCancellationV01

type Document04400102 ¶

type Document04400102 struct {
	XMLName xml.Name                                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.044.001.02 Document"`
	Message *FundConfirmedCashForecastReportCancellationV02 `xml:"FndConfdCshFcstRptCxlV02"`
}

func (d *Document04400102) AddMessage() *FundConfirmedCashForecastReportCancellationV02

type Document04400103 ¶

type Document04400103 struct {
	XMLName xml.Name                                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.044.001.03 Document"`
	Message *FundConfirmedCashForecastReportCancellationV03 `xml:"FndConfdCshFcstRptCxl"`
}

func (d *Document04400103) AddMessage() *FundConfirmedCashForecastReportCancellationV03

type Document04500101 ¶

type Document04500101 struct {
	XMLName xml.Name                                                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.045.001.01 Document"`
	Message *FundDetailedConfirmedCashForecastReportCancellationV01 `xml:"camt.045.001.01"`
}

func (d *Document04500101) AddMessage() *FundDetailedConfirmedCashForecastReportCancellationV01

type Document04500102 ¶

type Document04500102 struct {
	XMLName xml.Name                                                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.045.001.02 Document"`
	Message *FundDetailedConfirmedCashForecastReportCancellationV02 `xml:"FndDtldConfdCshFcstRptCxlV02"`
}

func (d *Document04500102) AddMessage() *FundDetailedConfirmedCashForecastReportCancellationV02

type Document04500103 ¶

type Document04500103 struct {
	XMLName xml.Name                                                `xml:"urn:iso:std:iso:20022:tech:xsd:camt.045.001.03 Document"`
	Message *FundDetailedConfirmedCashForecastReportCancellationV03 `xml:"FndDtldConfdCshFcstRptCxl"`
}

func (d *Document04500103) AddMessage() *FundDetailedConfirmedCashForecastReportCancellationV03

type Document05200101 ¶

type Document05200101 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.052.001.01 Document"`
	Message *BankToCustomerAccountReportV01 `xml:"BkToCstmrAcctRptV01"`
}

func (d *Document05200101) AddMessage() *BankToCustomerAccountReportV01

type Document05200102 ¶

type Document05200102 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.052.001.02 Document"`
	Message *BankToCustomerAccountReportV02 `xml:"BkToCstmrAcctRpt"`
}

func (d *Document05200102) AddMessage() *BankToCustomerAccountReportV02

type Document05200103 ¶

type Document05200103 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.052.001.03 Document"`
	Message *BankToCustomerAccountReportV03 `xml:"BkToCstmrAcctRpt"`
}

func (d *Document05200103) AddMessage() *BankToCustomerAccountReportV03

type Document05200104 ¶

type Document05200104 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.052.001.04 Document"`
	Message *BankToCustomerAccountReportV04 `xml:"BkToCstmrAcctRpt"`
}

func (d *Document05200104) AddMessage() *BankToCustomerAccountReportV04

type Document05200105 ¶

type Document05200105 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.052.001.05 Document"`
	Message *BankToCustomerAccountReportV05 `xml:"BkToCstmrAcctRpt"`
}

func (d *Document05200105) AddMessage() *BankToCustomerAccountReportV05

type Document05200106 ¶

type Document05200106 struct {
	XMLName xml.Name                        `xml:"urn:iso:std:iso:20022:tech:xsd:camt.052.001.06 Document"`
	Message *BankToCustomerAccountReportV06 `xml:"BkToCstmrAcctRpt"`
}

func (d *Document05200106) AddMessage() *BankToCustomerAccountReportV06

type Document05300101 ¶

type Document05300101 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.053.001.01 Document"`
	Message *BankToCustomerStatementV01 `xml:"BkToCstmrStmtV01"`
}

func (d *Document05300101) AddMessage() *BankToCustomerStatementV01

type Document05300102 ¶

type Document05300102 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.053.001.02 Document"`
	Message *BankToCustomerStatementV02 `xml:"BkToCstmrStmt"`
}

func (d *Document05300102) AddMessage() *BankToCustomerStatementV02

type Document05300103 ¶

type Document05300103 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.053.001.03 Document"`
	Message *BankToCustomerStatementV03 `xml:"BkToCstmrStmt"`
}

func (d *Document05300103) AddMessage() *BankToCustomerStatementV03

type Document05300104 ¶

type Document05300104 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.053.001.04 Document"`
	Message *BankToCustomerStatementV04 `xml:"BkToCstmrStmt"`
}

func (d *Document05300104) AddMessage() *BankToCustomerStatementV04

type Document05300105 ¶

type Document05300105 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.053.001.05 Document"`
	Message *BankToCustomerStatementV05 `xml:"BkToCstmrStmt"`
}

func (d *Document05300105) AddMessage() *BankToCustomerStatementV05

type Document05300106 ¶

type Document05300106 struct {
	XMLName xml.Name                    `xml:"urn:iso:std:iso:20022:tech:xsd:camt.053.001.06 Document"`
	Message *BankToCustomerStatementV06 `xml:"BkToCstmrStmt"`
}

func (d *Document05300106) AddMessage() *BankToCustomerStatementV06

type Document05400101 ¶

type Document05400101 struct {
	XMLName xml.Name                                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.054.001.01 Document"`
	Message *BankToCustomerDebitCreditNotificationV01 `xml:"BkToCstmrDbtCdtNtfctnV01"`
}

func (d *Document05400101) AddMessage() *BankToCustomerDebitCreditNotificationV01

type Document05400102 ¶

type Document05400102 struct {
	XMLName xml.Name                                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.054.001.02 Document"`
	Message *BankToCustomerDebitCreditNotificationV02 `xml:"BkToCstmrDbtCdtNtfctn"`
}

func (d *Document05400102) AddMessage() *BankToCustomerDebitCreditNotificationV02

type Document05400103 ¶

type Document05400103 struct {
	XMLName xml.Name                                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.054.001.03 Document"`
	Message *BankToCustomerDebitCreditNotificationV03 `xml:"BkToCstmrDbtCdtNtfctn"`
}

func (d *Document05400103) AddMessage() *BankToCustomerDebitCreditNotificationV03

type Document05400104 ¶

type Document05400104 struct {
	XMLName xml.Name                                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.054.001.04 Document"`
	Message *BankToCustomerDebitCreditNotificationV04 `xml:"BkToCstmrDbtCdtNtfctn"`
}

func (d *Document05400104) AddMessage() *BankToCustomerDebitCreditNotificationV04

type Document05400105 ¶

type Document05400105 struct {
	XMLName xml.Name                                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.054.001.05 Document"`
	Message *BankToCustomerDebitCreditNotificationV05 `xml:"BkToCstmrDbtCdtNtfctn"`
}

func (d *Document05400105) AddMessage() *BankToCustomerDebitCreditNotificationV05

type Document05400106 ¶

type Document05400106 struct {
	XMLName xml.Name                                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.054.001.06 Document"`
	Message *BankToCustomerDebitCreditNotificationV06 `xml:"BkToCstmrDbtCdtNtfctn"`
}

func (d *Document05400106) AddMessage() *BankToCustomerDebitCreditNotificationV06

type Document05500101 ¶

type Document05500101 struct {
	XMLName xml.Name                               `xml:"urn:iso:std:iso:20022:tech:xsd:camt.055.001.01 Document"`
	Message *CustomerPaymentCancellationRequestV01 `xml:"CstmrPmtCxlReq"`
}

func (d *Document05500101) AddMessage() *CustomerPaymentCancellationRequestV01

type Document05500102 ¶

type Document05500102 struct {
	XMLName xml.Name                               `xml:"urn:iso:std:iso:20022:tech:xsd:camt.055.001.02 Document"`
	Message *CustomerPaymentCancellationRequestV02 `xml:"CstmrPmtCxlReq"`
}

func (d *Document05500102) AddMessage() *CustomerPaymentCancellationRequestV02

type Document05500103 ¶

type Document05500103 struct {
	XMLName xml.Name                               `xml:"urn:iso:std:iso:20022:tech:xsd:camt.055.001.03 Document"`
	Message *CustomerPaymentCancellationRequestV03 `xml:"CstmrPmtCxlReq"`
}

func (d *Document05500103) AddMessage() *CustomerPaymentCancellationRequestV03

type Document05500104 ¶

type Document05500104 struct {
	XMLName xml.Name                               `xml:"urn:iso:std:iso:20022:tech:xsd:camt.055.001.04 Document"`
	Message *CustomerPaymentCancellationRequestV04 `xml:"CstmrPmtCxlReq"`
}

func (d *Document05500104) AddMessage() *CustomerPaymentCancellationRequestV04

type Document05500105 ¶

type Document05500105 struct {
	XMLName xml.Name                               `xml:"urn:iso:std:iso:20022:tech:xsd:camt.055.001.05 Document"`
	Message *CustomerPaymentCancellationRequestV05 `xml:"CstmrPmtCxlReq"`
}

func (d *Document05500105) AddMessage() *CustomerPaymentCancellationRequestV05

type Document05500106 ¶

type Document05500106 struct {
	XMLName xml.Name                               `xml:"urn:iso:std:iso:20022:tech:xsd:camt.055.001.06 Document"`
	Message *CustomerPaymentCancellationRequestV06 `xml:"CstmrPmtCxlReq"`
}

func (d *Document05500106) AddMessage() *CustomerPaymentCancellationRequestV06

type Document05600101 ¶

type Document05600101 struct {
	XMLName xml.Name                             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.056.001.01 Document"`
	Message *FIToFIPaymentCancellationRequestV01 `xml:"FIToFIPmtCxlReq"`
}

func (d *Document05600101) AddMessage() *FIToFIPaymentCancellationRequestV01

type Document05600102 ¶

type Document05600102 struct {
	XMLName xml.Name                             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.056.001.02 Document"`
	Message *FIToFIPaymentCancellationRequestV02 `xml:"FIToFIPmtCxlReq"`
}

func (d *Document05600102) AddMessage() *FIToFIPaymentCancellationRequestV02

type Document05600103 ¶

type Document05600103 struct {
	XMLName xml.Name                             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.056.001.03 Document"`
	Message *FIToFIPaymentCancellationRequestV03 `xml:"FIToFIPmtCxlReq"`
}

func (d *Document05600103) AddMessage() *FIToFIPaymentCancellationRequestV03

type Document05600104 ¶

type Document05600104 struct {
	XMLName xml.Name                             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.056.001.04 Document"`
	Message *FIToFIPaymentCancellationRequestV04 `xml:"FIToFIPmtCxlReq"`
}

func (d *Document05600104) AddMessage() *FIToFIPaymentCancellationRequestV04

type Document05600105 ¶

type Document05600105 struct {
	XMLName xml.Name                             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.056.001.05 Document"`
	Message *FIToFIPaymentCancellationRequestV05 `xml:"FIToFIPmtCxlReq"`
}

func (d *Document05600105) AddMessage() *FIToFIPaymentCancellationRequestV05

type Document05600106 ¶

type Document05600106 struct {
	XMLName xml.Name                             `xml:"urn:iso:std:iso:20022:tech:xsd:camt.056.001.06 Document"`
	Message *FIToFIPaymentCancellationRequestV06 `xml:"FIToFIPmtCxlReq"`
}

func (d *Document05600106) AddMessage() *FIToFIPaymentCancellationRequestV06

type Document05700102 ¶

type Document05700102 struct {
	XMLName xml.Name                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.057.001.02 Document"`
	Message *NotificationToReceiveV02 `xml:"NtfctnToRcv"`
}

func (d *Document05700102) AddMessage() *NotificationToReceiveV02

type Document05700103 ¶

type Document05700103 struct {
	XMLName xml.Name                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.057.001.03 Document"`
	Message *NotificationToReceiveV03 `xml:"NtfctnToRcv"`
}

func (d *Document05700103) AddMessage() *NotificationToReceiveV03

type Document05700104 ¶

type Document05700104 struct {
	XMLName xml.Name                  `xml:"urn:iso:std:iso:20022:tech:xsd:camt.057.001.04 Document"`
	Message *NotificationToReceiveV04 `xml:"NtfctnToRcv"`
}

func (d *Document05700104) AddMessage() *NotificationToReceiveV04

type Document05700105 ¶