Documentation ¶
Index ¶
- type AccountReportingRequestV02
- type AccountReportingRequestV03
- type AdditionalPaymentInformation
- 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
- 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
- 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
- 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
- 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
- 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 BankServicesBillingStatementV02
- type BankToCustomerAccountReportV01
- type BankToCustomerAccountReportV02
- type BankToCustomerAccountReportV03
- type BankToCustomerAccountReportV04
- type BankToCustomerAccountReportV05
- type BankToCustomerAccountReportV06
- type BankToCustomerDebitCreditNotificationV01
- type BankToCustomerDebitCreditNotificationV02
- type BankToCustomerDebitCreditNotificationV03
- type BankToCustomerDebitCreditNotificationV04
- type BankToCustomerDebitCreditNotificationV05
- type BankToCustomerDebitCreditNotificationV06
- type BankToCustomerStatementV01
- type BankToCustomerStatementV02
- type BankToCustomerStatementV03
- type BankToCustomerStatementV04
- type BankToCustomerStatementV05
- type BankToCustomerStatementV06
- type CancelCaseAssignment
- type CancelCaseAssignmentV02
- type CancelCaseAssignmentV03
- type CaseStatusReport
- type CaseStatusReportRequest
- type CaseStatusReportRequestV02
- type CaseStatusReportRequestV03
- type CaseStatusReportV03
- type CaseStatusReportV04
- 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 ClaimNonReceiptV03
- type ClaimNonReceiptV04
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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 DebitAuthorisationResponseV02
- type DebitAuthorisationResponseV03
- 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 Document00800201
- type Document02600101
- type Document02600103
- type Document02600104
- type Document02600105
- type Document02700101
- type Document02700103
- type Document02700104
- type Document02700105
- type Document02800101
- type Document02800103
- type Document02800104
- type Document02800105
- type Document02800106
- type Document02800107
- type Document02900101
- type Document02900103
- type Document02900104
- type Document02900105
- type Document02900106
- type Document02900107
- type Document03000101
- type Document03000103
- type Document03000104
- type Document03100101
- type Document03100103
- type Document03100104
- type Document03200101
- type Document03200102
- type Document03200103
- type Document03300101
- type Document03300103
- type Document03300104
- type Document03400103
- type Document03400104
- type Document03500102
- type Document03500103
- type Document03600101
- type Document03600102
- type Document03600103
- type Document03700101
- type Document03700103
- type Document03700104
- type Document03700105
- type Document03800101
- type Document03800102
- type Document03800103
- type Document03900101
- type Document03900103
- type Document03900104
- type Document04000102
- type Document04000103
- type Document04000104
- type Document04100102
- type Document04100103
- type Document04100104
- type Document04200102
- type Document04200103
- type Document04200104
- type Document04300102
- type Document04300103
- type Document04300104
- type Document04400101
- type Document04400102
- type Document04400103
- type Document04500101
- type Document04500102
- type Document04500103
- type Document05200101
- type Document05200102
- type Document05200103
- type Document05200104
- type Document05200105
- type Document05200106
- type Document05300101
- type Document05300102
- type Document05300103
- type Document05300104
- type Document05300105
- type Document05300106
- type Document05400101
- type Document05400102
- type Document05400103
- type Document05400104
- type Document05400105
- type Document05400106
- type Document05500101
- type Document05500102
- type Document05500103
- type Document05500104
- type Document05500105
- type Document05500106
- type Document05600101
- type Document05600102
- type Document05600103
- type Document05600104
- type Document05600105
- type Document05600106
- type Document05700102
- type Document05700103
- type Document05700104
- type Document05700105
- type Document05800102
- type Document05800103
- type Document05800104
- type Document05800105
- type Document05900102
- type Document05900103
- type Document05900104
- type Document05900105
- type Document06000102
- type Document06000103
- type Document06100102
- type Document06200103
- type Document06300102
- type Document08600101
- type Document08600102
- type Document08700101
- type Document08700102
- type Document08700104
- type Document08800101
- type DuplicateV03
- type DuplicateV04
- type FIToFIPaymentCancellationRequestV01
- func (f *FIToFIPaymentCancellationRequestV01) AddAssignment() *iso20022.CaseAssignment2
- func (f *FIToFIPaymentCancellationRequestV01) AddCase() *iso20022.Case2
- func (f *FIToFIPaymentCancellationRequestV01) AddControlData() *iso20022.ControlData1
- func (f *FIToFIPaymentCancellationRequestV01) AddUnderlying() *iso20022.UnderlyingTransaction2
- type FIToFIPaymentCancellationRequestV02
- func (f *FIToFIPaymentCancellationRequestV02) AddAssignment() *iso20022.CaseAssignment3
- func (f *FIToFIPaymentCancellationRequestV02) AddCase() *iso20022.Case3
- func (f *FIToFIPaymentCancellationRequestV02) AddControlData() *iso20022.ControlData1
- func (f *FIToFIPaymentCancellationRequestV02) AddSupplementaryData() *iso20022.SupplementaryData1
- func (f *FIToFIPaymentCancellationRequestV02) AddUnderlying() *iso20022.UnderlyingTransaction5
- type FIToFIPaymentCancellationRequestV03
- func (f *FIToFIPaymentCancellationRequestV03) AddAssignment() *iso20022.CaseAssignment3
- func (f *FIToFIPaymentCancellationRequestV03) AddCase() *iso20022.Case3
- func (f *FIToFIPaymentCancellationRequestV03) AddControlData() *iso20022.ControlData1
- func (f *FIToFIPaymentCancellationRequestV03) AddSupplementaryData() *iso20022.SupplementaryData1
- func (f *FIToFIPaymentCancellationRequestV03) AddUnderlying() *iso20022.UnderlyingTransaction8
- type FIToFIPaymentCancellationRequestV04
- func (f *FIToFIPaymentCancellationRequestV04) AddAssignment() *iso20022.CaseAssignment3
- func (f *FIToFIPaymentCancellationRequestV04) AddCase() *iso20022.Case3
- func (f *FIToFIPaymentCancellationRequestV04) AddControlData() *iso20022.ControlData1
- func (f *FIToFIPaymentCancellationRequestV04) AddSupplementaryData() *iso20022.SupplementaryData1
- func (f *FIToFIPaymentCancellationRequestV04) AddUnderlying() *iso20022.UnderlyingTransaction10
- type FIToFIPaymentCancellationRequestV05
- func (f *FIToFIPaymentCancellationRequestV05) AddAssignment() *iso20022.CaseAssignment3
- func (f *FIToFIPaymentCancellationRequestV05) AddCase() *iso20022.Case3
- func (f *FIToFIPaymentCancellationRequestV05) AddControlData() *iso20022.ControlData1
- func (f *FIToFIPaymentCancellationRequestV05) AddSupplementaryData() *iso20022.SupplementaryData1
- func (f *FIToFIPaymentCancellationRequestV05) AddUnderlying() *iso20022.UnderlyingTransaction13
- type FIToFIPaymentCancellationRequestV06
- func (f *FIToFIPaymentCancellationRequestV06) AddAssignment() *iso20022.CaseAssignment3
- func (f *FIToFIPaymentCancellationRequestV06) AddCase() *iso20022.Case3
- func (f *FIToFIPaymentCancellationRequestV06) AddControlData() *iso20022.ControlData1
- func (f *FIToFIPaymentCancellationRequestV06) AddSupplementaryData() *iso20022.SupplementaryData1
- func (f *FIToFIPaymentCancellationRequestV06) AddUnderlying() *iso20022.UnderlyingTransaction16
- type FundConfirmedCashForecastReportCancellationV01
- func (f *FundConfirmedCashForecastReportCancellationV01) AddCashForecastReportToBeCancelled() *iso20022.FundConfirmedCashForecastReport1
- func (f *FundConfirmedCashForecastReportCancellationV01) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportCancellationV01) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportCancellationV01) AddRelatedReference() *iso20022.AdditionalReference3
- type FundConfirmedCashForecastReportCancellationV02
- func (f *FundConfirmedCashForecastReportCancellationV02) AddCashForecastReportToBeCancelled() *iso20022.FundConfirmedCashForecastReport2
- func (f *FundConfirmedCashForecastReportCancellationV02) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundConfirmedCashForecastReportCancellationV02) AddMessagePagination() *iso20022.Pagination
- func (f *FundConfirmedCashForecastReportCancellationV02) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportCancellationV02) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportCancellationV02) AddRelatedReference() *iso20022.AdditionalReference3
- type FundConfirmedCashForecastReportCancellationV03
- func (f *FundConfirmedCashForecastReportCancellationV03) AddCashForecastReportToBeCancelled() *iso20022.FundConfirmedCashForecastReport3
- func (f *FundConfirmedCashForecastReportCancellationV03) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundConfirmedCashForecastReportCancellationV03) AddMessagePagination() *iso20022.Pagination
- func (f *FundConfirmedCashForecastReportCancellationV03) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportCancellationV03) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportCancellationV03) AddRelatedReference() *iso20022.AdditionalReference3
- type FundConfirmedCashForecastReportV02
- func (f *FundConfirmedCashForecastReportV02) AddExtension() *iso20022.Extension1
- func (f *FundConfirmedCashForecastReportV02) AddFundCashForecastDetails() *iso20022.FundCashForecast1
- func (f *FundConfirmedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
- type FundConfirmedCashForecastReportV03
- func (f *FundConfirmedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundConfirmedCashForecastReportV03) AddExtension() *iso20022.Extension1
- func (f *FundConfirmedCashForecastReportV03) AddFundCashForecastDetails() *iso20022.FundCashForecast3
- func (f *FundConfirmedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundConfirmedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
- func (f *FundConfirmedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
- type FundConfirmedCashForecastReportV04
- func (f *FundConfirmedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundConfirmedCashForecastReportV04) AddExtension() *iso20022.Extension1
- func (f *FundConfirmedCashForecastReportV04) AddFundCashForecastDetails() *iso20022.FundCashForecast7
- func (f *FundConfirmedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund2
- func (f *FundConfirmedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundConfirmedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
- func (f *FundConfirmedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundConfirmedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedConfirmedCashForecastReportCancellationV01
- func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddCashForecastReportToBeCancelled() *iso20022.FundDetailedConfirmedCashForecastReport1
- func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedConfirmedCashForecastReportCancellationV02
- func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddCashForecastReportToBeCancelled() *iso20022.FundDetailedConfirmedCashForecastReport2
- func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddMessagePagination() *iso20022.Pagination
- func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedConfirmedCashForecastReportCancellationV03
- func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddCashForecastReportToBeCancelled() *iso20022.FundDetailedConfirmedCashForecastReport3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddMessagePagination() *iso20022.Pagination
- func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedConfirmedCashForecastReportV02
- func (f *FundDetailedConfirmedCashForecastReportV02) AddExtension() *iso20022.Extension1
- func (f *FundDetailedConfirmedCashForecastReportV02) AddFundCashForecastDetails() *iso20022.FundCashForecast2
- func (f *FundDetailedConfirmedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedConfirmedCashForecastReportV03
- func (f *FundDetailedConfirmedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundDetailedConfirmedCashForecastReportV03) AddExtension() *iso20022.Extension1
- func (f *FundDetailedConfirmedCashForecastReportV03) AddFundCashForecastDetails() *iso20022.FundCashForecast4
- func (f *FundDetailedConfirmedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundDetailedConfirmedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
- func (f *FundDetailedConfirmedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedConfirmedCashForecastReportV04
- func (f *FundDetailedConfirmedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundDetailedConfirmedCashForecastReportV04) AddExtension() *iso20022.Extension1
- func (f *FundDetailedConfirmedCashForecastReportV04) AddFundCashForecastDetails() *iso20022.FundCashForecast6
- func (f *FundDetailedConfirmedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund4
- func (f *FundDetailedConfirmedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundDetailedConfirmedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
- func (f *FundDetailedConfirmedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedConfirmedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedEstimatedCashForecastReportV02
- func (f *FundDetailedEstimatedCashForecastReportV02) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast2
- func (f *FundDetailedEstimatedCashForecastReportV02) AddExtension() *iso20022.Extension1
- func (f *FundDetailedEstimatedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedEstimatedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedEstimatedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedEstimatedCashForecastReportV03
- func (f *FundDetailedEstimatedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundDetailedEstimatedCashForecastReportV03) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast4
- func (f *FundDetailedEstimatedCashForecastReportV03) AddExtension() *iso20022.Extension1
- func (f *FundDetailedEstimatedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundDetailedEstimatedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
- func (f *FundDetailedEstimatedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedEstimatedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedEstimatedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
- type FundDetailedEstimatedCashForecastReportV04
- func (f *FundDetailedEstimatedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundDetailedEstimatedCashForecastReportV04) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast5
- func (f *FundDetailedEstimatedCashForecastReportV04) AddExtension() *iso20022.Extension1
- func (f *FundDetailedEstimatedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund3
- func (f *FundDetailedEstimatedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundDetailedEstimatedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
- func (f *FundDetailedEstimatedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundDetailedEstimatedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundDetailedEstimatedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
- type FundEstimatedCashForecastReportV02
- func (f *FundEstimatedCashForecastReportV02) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast1
- func (f *FundEstimatedCashForecastReportV02) AddExtension() *iso20022.Extension1
- func (f *FundEstimatedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundEstimatedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundEstimatedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
- type FundEstimatedCashForecastReportV03
- func (f *FundEstimatedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundEstimatedCashForecastReportV03) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast3
- func (f *FundEstimatedCashForecastReportV03) AddExtension() *iso20022.Extension1
- func (f *FundEstimatedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundEstimatedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
- func (f *FundEstimatedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundEstimatedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundEstimatedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
- type FundEstimatedCashForecastReportV04
- func (f *FundEstimatedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
- func (f *FundEstimatedCashForecastReportV04) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast6
- func (f *FundEstimatedCashForecastReportV04) AddExtension() *iso20022.Extension1
- func (f *FundEstimatedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund1
- func (f *FundEstimatedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
- func (f *FundEstimatedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
- func (f *FundEstimatedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
- func (f *FundEstimatedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
- func (f *FundEstimatedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
- type NetReportV01
- func (n *NetReportV01) AddNetObligation() *iso20022.NetObligation1
- func (n *NetReportV01) AddNetReportData() *iso20022.NetReportData1
- func (n *NetReportV01) AddNetServiceCounterpartyIdentification() *iso20022.PartyIdentification73Choice
- func (n *NetReportV01) AddNetServiceParticipantIdentification() *iso20022.PartyIdentification73Choice
- func (n *NetReportV01) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationOfCaseAssignment
- func (n *NotificationOfCaseAssignment) AddAssignment() *iso20022.CaseAssignment
- func (n *NotificationOfCaseAssignment) AddCase() *iso20022.Case
- func (n *NotificationOfCaseAssignment) AddHeader() *iso20022.ReportHeader
- func (n *NotificationOfCaseAssignment) AddNotification() *iso20022.CaseForwardingNotification
- type NotificationOfCaseAssignmentV03
- func (n *NotificationOfCaseAssignmentV03) AddAssignment() *iso20022.CaseAssignment2
- func (n *NotificationOfCaseAssignmentV03) AddCase() *iso20022.Case2
- func (n *NotificationOfCaseAssignmentV03) AddHeader() *iso20022.ReportHeader2
- func (n *NotificationOfCaseAssignmentV03) AddNotification() *iso20022.CaseForwardingNotification3
- type NotificationOfCaseAssignmentV04
- func (n *NotificationOfCaseAssignmentV04) AddAssignment() *iso20022.CaseAssignment3
- func (n *NotificationOfCaseAssignmentV04) AddCase() *iso20022.Case3
- func (n *NotificationOfCaseAssignmentV04) AddHeader() *iso20022.ReportHeader4
- func (n *NotificationOfCaseAssignmentV04) AddNotification() *iso20022.CaseForwardingNotification3
- func (n *NotificationOfCaseAssignmentV04) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveCancellationAdviceV02
- type NotificationToReceiveCancellationAdviceV03
- func (n *NotificationToReceiveCancellationAdviceV03) AddGroupHeader() *iso20022.GroupHeader59
- func (n *NotificationToReceiveCancellationAdviceV03) AddOriginalNotification() *iso20022.OriginalNotification6
- func (n *NotificationToReceiveCancellationAdviceV03) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveCancellationAdviceV04
- func (n *NotificationToReceiveCancellationAdviceV04) AddGroupHeader() *iso20022.GroupHeader59
- func (n *NotificationToReceiveCancellationAdviceV04) AddOriginalNotification() *iso20022.OriginalNotification8
- func (n *NotificationToReceiveCancellationAdviceV04) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveCancellationAdviceV05
- func (n *NotificationToReceiveCancellationAdviceV05) AddGroupHeader() *iso20022.GroupHeader59
- func (n *NotificationToReceiveCancellationAdviceV05) AddOriginalNotification() *iso20022.OriginalNotification10
- func (n *NotificationToReceiveCancellationAdviceV05) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveStatusReportV02
- type NotificationToReceiveStatusReportV03
- func (n *NotificationToReceiveStatusReportV03) AddGroupHeader() *iso20022.GroupHeader60
- func (n *NotificationToReceiveStatusReportV03) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification5
- func (n *NotificationToReceiveStatusReportV03) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveStatusReportV04
- func (n *NotificationToReceiveStatusReportV04) AddGroupHeader() *iso20022.GroupHeader60
- func (n *NotificationToReceiveStatusReportV04) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification7
- func (n *NotificationToReceiveStatusReportV04) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveStatusReportV05
- func (n *NotificationToReceiveStatusReportV05) AddGroupHeader() *iso20022.GroupHeader60
- func (n *NotificationToReceiveStatusReportV05) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification9
- func (n *NotificationToReceiveStatusReportV05) AddSupplementaryData() *iso20022.SupplementaryData1
- type NotificationToReceiveV02
- type NotificationToReceiveV03
- type NotificationToReceiveV04
- type NotificationToReceiveV05
- type PayInCallV02
- type PayInEventAcknowledgementV02
- func (p *PayInEventAcknowledgementV02) AddAcknowledgementDetails() *iso20022.AcknowledgementDetails1Choice
- func (p *PayInEventAcknowledgementV02) AddSupplementaryData() *iso20022.SupplementaryData1
- func (p *PayInEventAcknowledgementV02) SetMessageIdentification(value string)
- func (p *PayInEventAcknowledgementV02) SetSettlementSessionIdentifier(value string)
- type PayInScheduleV03
- func (p *PayInScheduleV03) AddPartyIdentification() *iso20022.PartyIdentification73Choice
- func (p *PayInScheduleV03) AddPayInFactors() *iso20022.PayInFactors1
- func (p *PayInScheduleV03) AddPayInScheduleItem() *iso20022.PayInScheduleItems1
- func (p *PayInScheduleV03) AddPayInScheduleLongBalance() *iso20022.BalanceStatus2
- func (p *PayInScheduleV03) AddReportData() *iso20022.ReportData4
- func (p *PayInScheduleV03) AddSupplementaryData() *iso20022.SupplementaryData1
- type ProprietaryFormatInvestigationV02
- type ProprietaryFormatInvestigationV03
- func (p *ProprietaryFormatInvestigationV03) AddAssignment() *iso20022.CaseAssignment3
- func (p *ProprietaryFormatInvestigationV03) AddCase() *iso20022.Case3
- func (p *ProprietaryFormatInvestigationV03) AddProprietaryData() *iso20022.ProprietaryData4
- func (p *ProprietaryFormatInvestigationV03) AddSupplementaryData() *iso20022.SupplementaryData1
- type RejectCaseAssignment
- type RejectInvestigationV03
- type RejectInvestigationV04
- func (r *RejectInvestigationV04) AddAssignment() *iso20022.CaseAssignment3
- func (r *RejectInvestigationV04) AddCase() *iso20022.Case3
- func (r *RejectInvestigationV04) AddJustification() *iso20022.InvestigationRejectionJustification1
- func (r *RejectInvestigationV04) AddSupplementaryData() *iso20022.SupplementaryData1
- type RequestForDuplicateInstruction
- type RequestForDuplicateV03
- type RequestForDuplicateV04
- type RequestToCancelPayment
- func (r *RequestToCancelPayment) AddAssignment() *iso20022.CaseAssignment
- func (r *RequestToCancelPayment) AddCase() *iso20022.Case
- func (r *RequestToCancelPayment) AddJustification() *iso20022.DebitAuthorisationDetails
- func (r *RequestToCancelPayment) AddUnderlying() *iso20022.PaymentInstructionExtract
- type RequestToModifyPayment
- type RequestToModifyPaymentV01
- func (r *RequestToModifyPaymentV01) AddAssignment() *iso20022.CaseAssignment3
- func (r *RequestToModifyPaymentV01) AddCase() *iso20022.Case3
- func (r *RequestToModifyPaymentV01) AddModification() *iso20022.RequestedModification3
- func (r *RequestToModifyPaymentV01) AddSupplementaryData() *iso20022.SupplementaryData1
- func (r *RequestToModifyPaymentV01) AddUnderlying() *iso20022.UnderlyingTransaction2Choice
- type RequestToModifyPaymentV02
- func (r *RequestToModifyPaymentV02) AddAssignment() *iso20022.CaseAssignment3
- func (r *RequestToModifyPaymentV02) AddCase() *iso20022.Case3
- func (r *RequestToModifyPaymentV02) AddModification() *iso20022.RequestedModification4
- func (r *RequestToModifyPaymentV02) AddSupplementaryData() *iso20022.SupplementaryData1
- func (r *RequestToModifyPaymentV02) AddUnderlying() *iso20022.UnderlyingTransaction2Choice
- type RequestToModifyPaymentV04
- func (r *RequestToModifyPaymentV04) AddAssignment() *iso20022.CaseAssignment3
- func (r *RequestToModifyPaymentV04) AddCase() *iso20022.Case3
- func (r *RequestToModifyPaymentV04) AddModification() *iso20022.RequestedModification6
- func (r *RequestToModifyPaymentV04) AddSupplementaryData() *iso20022.SupplementaryData1
- func (r *RequestToModifyPaymentV04) AddUnderlying() *iso20022.UnderlyingTransaction3Choice
- type ResolutionOfInvestigation
- func (r *ResolutionOfInvestigation) AddAssignment() *iso20022.CaseAssignment
- func (r *ResolutionOfInvestigation) AddCorrectionTransaction() *iso20022.PaymentInstructionExtract
- func (r *ResolutionOfInvestigation) AddResolvedCase() *iso20022.Case
- func (r *ResolutionOfInvestigation) AddStatus() *iso20022.InvestigationStatusChoice
- type ResolutionOfInvestigationV03
- func (r *ResolutionOfInvestigationV03) AddAssignment() *iso20022.CaseAssignment2
- func (r *ResolutionOfInvestigationV03) AddCancellationDetails() *iso20022.UnderlyingTransaction3
- func (r *ResolutionOfInvestigationV03) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
- func (r *ResolutionOfInvestigationV03) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
- func (r *ResolutionOfInvestigationV03) AddResolvedCase() *iso20022.Case2
- func (r *ResolutionOfInvestigationV03) AddStatementDetails() *iso20022.StatementResolutionEntry1
- func (r *ResolutionOfInvestigationV03) AddStatus() *iso20022.InvestigationStatus2Choice
- type ResolutionOfInvestigationV04
- func (r *ResolutionOfInvestigationV04) AddAssignment() *iso20022.CaseAssignment3
- func (r *ResolutionOfInvestigationV04) AddCancellationDetails() *iso20022.UnderlyingTransaction4
- func (r *ResolutionOfInvestigationV04) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
- func (r *ResolutionOfInvestigationV04) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
- func (r *ResolutionOfInvestigationV04) AddResolvedCase() *iso20022.Case3
- func (r *ResolutionOfInvestigationV04) AddStatementDetails() *iso20022.StatementResolutionEntry2
- func (r *ResolutionOfInvestigationV04) AddStatus() *iso20022.InvestigationStatus3Choice
- func (r *ResolutionOfInvestigationV04) AddSupplementaryData() *iso20022.SupplementaryData1
- type ResolutionOfInvestigationV05
- func (r *ResolutionOfInvestigationV05) AddAssignment() *iso20022.CaseAssignment3
- func (r *ResolutionOfInvestigationV05) AddCancellationDetails() *iso20022.UnderlyingTransaction9
- func (r *ResolutionOfInvestigationV05) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
- func (r *ResolutionOfInvestigationV05) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
- func (r *ResolutionOfInvestigationV05) AddResolvedCase() *iso20022.Case3
- func (r *ResolutionOfInvestigationV05) AddStatementDetails() *iso20022.StatementResolutionEntry2
- func (r *ResolutionOfInvestigationV05) AddStatus() *iso20022.InvestigationStatus3Choice
- func (r *ResolutionOfInvestigationV05) AddSupplementaryData() *iso20022.SupplementaryData1
- type ResolutionOfInvestigationV06
- func (r *ResolutionOfInvestigationV06) AddAssignment() *iso20022.CaseAssignment3
- func (r *ResolutionOfInvestigationV06) AddCancellationDetails() *iso20022.UnderlyingTransaction14
- func (r *ResolutionOfInvestigationV06) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
- func (r *ResolutionOfInvestigationV06) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
- func (r *ResolutionOfInvestigationV06) AddResolvedCase() *iso20022.Case3
- func (r *ResolutionOfInvestigationV06) AddStatementDetails() *iso20022.StatementResolutionEntry2
- func (r *ResolutionOfInvestigationV06) AddStatus() *iso20022.InvestigationStatus3Choice
- func (r *ResolutionOfInvestigationV06) AddSupplementaryData() *iso20022.SupplementaryData1
- type ResolutionOfInvestigationV07
- func (r *ResolutionOfInvestigationV07) AddAssignment() *iso20022.CaseAssignment3
- func (r *ResolutionOfInvestigationV07) AddCancellationDetails() *iso20022.UnderlyingTransaction17
- func (r *ResolutionOfInvestigationV07) AddCorrectionTransaction() *iso20022.CorrectiveTransaction2Choice
- func (r *ResolutionOfInvestigationV07) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
- func (r *ResolutionOfInvestigationV07) AddResolvedCase() *iso20022.Case3
- func (r *ResolutionOfInvestigationV07) AddStatementDetails() *iso20022.StatementResolutionEntry2
- func (r *ResolutionOfInvestigationV07) AddStatus() *iso20022.InvestigationStatus3Choice
- func (r *ResolutionOfInvestigationV07) AddSupplementaryData() *iso20022.SupplementaryData1
- type UnableToApply
- type UnableToApplyV03
- type UnableToApplyV04
- func (u *UnableToApplyV04) AddAssignment() *iso20022.CaseAssignment3
- func (u *UnableToApplyV04) AddCase() *iso20022.Case3
- func (u *UnableToApplyV04) AddJustification() *iso20022.UnableToApplyJustification2Choice
- func (u *UnableToApplyV04) AddSupplementaryData() *iso20022.SupplementaryData1
- func (u *UnableToApplyV04) AddUnderlying() *iso20022.UnderlyingTransaction2Choice
- type UnableToApplyV05
- func (u *UnableToApplyV05) AddAssignment() *iso20022.CaseAssignment3
- func (u *UnableToApplyV05) AddCase() *iso20022.Case3
- func (u *UnableToApplyV05) AddJustification() *iso20022.UnableToApplyJustification3Choice
- func (u *UnableToApplyV05) AddSupplementaryData() *iso20022.SupplementaryData1
- func (u *UnableToApplyV05) AddUnderlying() *iso20022.UnderlyingTransaction3Choice
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
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 (*AccountReportingRequestV02) AddGroupHeader ¶
func (a *AccountReportingRequestV02) AddGroupHeader() *iso20022.GroupHeader43
func (*AccountReportingRequestV02) AddReportingRequest ¶
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 (*AccountReportingRequestV03) AddGroupHeader ¶
func (a *AccountReportingRequestV03) AddGroupHeader() *iso20022.GroupHeader59
func (*AccountReportingRequestV03) AddReportingRequest ¶
func (a *AccountReportingRequestV03) AddReportingRequest() *iso20022.ReportingRequest3
func (*AccountReportingRequestV03) AddSupplementaryData ¶
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 (*AdditionalPaymentInformation) AddAssignment ¶
func (a *AdditionalPaymentInformation) AddAssignment() *iso20022.CaseAssignment
func (*AdditionalPaymentInformation) AddCase ¶
func (a *AdditionalPaymentInformation) AddCase() *iso20022.Case
func (*AdditionalPaymentInformation) AddInformation ¶
func (a *AdditionalPaymentInformation) AddInformation() *iso20022.PaymentComplementaryInformation
func (*AdditionalPaymentInformation) AddUnderlying ¶
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 (*AdditionalPaymentInformationV03) AddAssignment ¶
func (a *AdditionalPaymentInformationV03) AddAssignment() *iso20022.CaseAssignment2
func (*AdditionalPaymentInformationV03) AddCase ¶
func (a *AdditionalPaymentInformationV03) AddCase() *iso20022.Case2
func (*AdditionalPaymentInformationV03) AddInformation ¶
func (a *AdditionalPaymentInformationV03) AddInformation() *iso20022.PaymentComplementaryInformation2
func (*AdditionalPaymentInformationV03) AddUnderlying ¶
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 (*AdditionalPaymentInformationV04) AddAssignment ¶
func (a *AdditionalPaymentInformationV04) AddAssignment() *iso20022.CaseAssignment3
func (*AdditionalPaymentInformationV04) AddCase ¶
func (a *AdditionalPaymentInformationV04) AddCase() *iso20022.Case3
func (*AdditionalPaymentInformationV04) AddInformation ¶
func (a *AdditionalPaymentInformationV04) AddInformation() *iso20022.PaymentComplementaryInformation3
func (*AdditionalPaymentInformationV04) AddSupplementaryData ¶
func (a *AdditionalPaymentInformationV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*AdditionalPaymentInformationV04) AddUnderlying ¶
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 (*AdditionalPaymentInformationV05) AddAssignment ¶
func (a *AdditionalPaymentInformationV05) AddAssignment() *iso20022.CaseAssignment3
func (*AdditionalPaymentInformationV05) AddCase ¶
func (a *AdditionalPaymentInformationV05) AddCase() *iso20022.Case3
func (*AdditionalPaymentInformationV05) AddInformation ¶
func (a *AdditionalPaymentInformationV05) AddInformation() *iso20022.PaymentComplementaryInformation4
func (*AdditionalPaymentInformationV05) AddSupplementaryData ¶
func (a *AdditionalPaymentInformationV05) AddSupplementaryData() *iso20022.SupplementaryData1
func (*AdditionalPaymentInformationV05) AddUnderlying ¶
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 (*AdditionalPaymentInformationV06) AddAssignment ¶
func (a *AdditionalPaymentInformationV06) AddAssignment() *iso20022.CaseAssignment3
func (*AdditionalPaymentInformationV06) AddCase ¶
func (a *AdditionalPaymentInformationV06) AddCase() *iso20022.Case3
func (*AdditionalPaymentInformationV06) AddInformation ¶
func (a *AdditionalPaymentInformationV06) AddInformation() *iso20022.PaymentComplementaryInformation5
func (*AdditionalPaymentInformationV06) AddSupplementaryData ¶
func (a *AdditionalPaymentInformationV06) AddSupplementaryData() *iso20022.SupplementaryData1
func (*AdditionalPaymentInformationV06) AddUnderlying ¶
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 (*AdditionalPaymentInformationV07) AddAssignment ¶
func (a *AdditionalPaymentInformationV07) AddAssignment() *iso20022.CaseAssignment3
func (*AdditionalPaymentInformationV07) AddCase ¶
func (a *AdditionalPaymentInformationV07) AddCase() *iso20022.Case3
func (*AdditionalPaymentInformationV07) AddInformation ¶
func (a *AdditionalPaymentInformationV07) AddInformation() *iso20022.PaymentComplementaryInformation6
func (*AdditionalPaymentInformationV07) AddSupplementaryData ¶
func (a *AdditionalPaymentInformationV07) AddSupplementaryData() *iso20022.SupplementaryData1
func (*AdditionalPaymentInformationV07) AddUnderlying ¶
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 (*BankServicesBillingStatementV01) AddBillingStatementGroup ¶
func (b *BankServicesBillingStatementV01) AddBillingStatementGroup() *iso20022.StatementGroup1
func (*BankServicesBillingStatementV01) AddReportHeader ¶
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 (*BankServicesBillingStatementV02) AddBillingStatementGroup ¶
func (b *BankServicesBillingStatementV02) AddBillingStatementGroup() *iso20022.StatementGroup2
func (*BankServicesBillingStatementV02) AddReportHeader ¶
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 (*BankToCustomerAccountReportV01) AddGroupHeader ¶
func (b *BankToCustomerAccountReportV01) AddGroupHeader() *iso20022.GroupHeader23
func (*BankToCustomerAccountReportV01) AddReport ¶
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 (*BankToCustomerAccountReportV02) AddGroupHeader ¶
func (b *BankToCustomerAccountReportV02) AddGroupHeader() *iso20022.GroupHeader42
func (*BankToCustomerAccountReportV02) AddReport ¶
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 (*BankToCustomerAccountReportV03) AddGroupHeader ¶
func (b *BankToCustomerAccountReportV03) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerAccountReportV03) AddReport ¶
func (b *BankToCustomerAccountReportV03) AddReport() *iso20022.AccountReport12
func (*BankToCustomerAccountReportV03) AddSupplementaryData ¶
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 (*BankToCustomerAccountReportV04) AddGroupHeader ¶
func (b *BankToCustomerAccountReportV04) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerAccountReportV04) AddReport ¶
func (b *BankToCustomerAccountReportV04) AddReport() *iso20022.AccountReport16
func (*BankToCustomerAccountReportV04) AddSupplementaryData ¶
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 (*BankToCustomerAccountReportV05) AddGroupHeader ¶
func (b *BankToCustomerAccountReportV05) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerAccountReportV05) AddReport ¶
func (b *BankToCustomerAccountReportV05) AddReport() *iso20022.AccountReport18
func (*BankToCustomerAccountReportV05) AddSupplementaryData ¶
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 (*BankToCustomerAccountReportV06) AddGroupHeader ¶
func (b *BankToCustomerAccountReportV06) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerAccountReportV06) AddReport ¶
func (b *BankToCustomerAccountReportV06) AddReport() *iso20022.AccountReport19
func (*BankToCustomerAccountReportV06) AddSupplementaryData ¶
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 (*BankToCustomerDebitCreditNotificationV01) AddGroupHeader ¶
func (b *BankToCustomerDebitCreditNotificationV01) AddGroupHeader() *iso20022.GroupHeader23
func (*BankToCustomerDebitCreditNotificationV01) AddNotification ¶
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 (*BankToCustomerDebitCreditNotificationV02) AddGroupHeader ¶
func (b *BankToCustomerDebitCreditNotificationV02) AddGroupHeader() *iso20022.GroupHeader42
func (*BankToCustomerDebitCreditNotificationV02) AddNotification ¶
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 (*BankToCustomerDebitCreditNotificationV03) AddGroupHeader ¶
func (b *BankToCustomerDebitCreditNotificationV03) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerDebitCreditNotificationV03) AddNotification ¶
func (b *BankToCustomerDebitCreditNotificationV03) AddNotification() *iso20022.AccountNotification5
func (*BankToCustomerDebitCreditNotificationV03) AddSupplementaryData ¶
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 (*BankToCustomerDebitCreditNotificationV04) AddGroupHeader ¶
func (b *BankToCustomerDebitCreditNotificationV04) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerDebitCreditNotificationV04) AddNotification ¶
func (b *BankToCustomerDebitCreditNotificationV04) AddNotification() *iso20022.AccountNotification7
func (*BankToCustomerDebitCreditNotificationV04) AddSupplementaryData ¶
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 (*BankToCustomerDebitCreditNotificationV05) AddGroupHeader ¶
func (b *BankToCustomerDebitCreditNotificationV05) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerDebitCreditNotificationV05) AddNotification ¶
func (b *BankToCustomerDebitCreditNotificationV05) AddNotification() *iso20022.AccountNotification11
func (*BankToCustomerDebitCreditNotificationV05) AddSupplementaryData ¶
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 (*BankToCustomerDebitCreditNotificationV06) AddGroupHeader ¶
func (b *BankToCustomerDebitCreditNotificationV06) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerDebitCreditNotificationV06) AddNotification ¶
func (b *BankToCustomerDebitCreditNotificationV06) AddNotification() *iso20022.AccountNotification12
func (*BankToCustomerDebitCreditNotificationV06) AddSupplementaryData ¶
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 (*BankToCustomerStatementV01) AddGroupHeader ¶
func (b *BankToCustomerStatementV01) AddGroupHeader() *iso20022.GroupHeader23
func (*BankToCustomerStatementV01) AddStatement ¶
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 (*BankToCustomerStatementV02) AddGroupHeader ¶
func (b *BankToCustomerStatementV02) AddGroupHeader() *iso20022.GroupHeader42
func (*BankToCustomerStatementV02) AddStatement ¶
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 (*BankToCustomerStatementV03) AddGroupHeader ¶
func (b *BankToCustomerStatementV03) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerStatementV03) AddStatement ¶
func (b *BankToCustomerStatementV03) AddStatement() *iso20022.AccountStatement3
func (*BankToCustomerStatementV03) AddSupplementaryData ¶
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 (*BankToCustomerStatementV04) AddGroupHeader ¶
func (b *BankToCustomerStatementV04) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerStatementV04) AddStatement ¶
func (b *BankToCustomerStatementV04) AddStatement() *iso20022.AccountStatement4
func (*BankToCustomerStatementV04) AddSupplementaryData ¶
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 (*BankToCustomerStatementV05) AddGroupHeader ¶
func (b *BankToCustomerStatementV05) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerStatementV05) AddStatement ¶
func (b *BankToCustomerStatementV05) AddStatement() *iso20022.AccountStatement5
func (*BankToCustomerStatementV05) AddSupplementaryData ¶
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 (*BankToCustomerStatementV06) AddGroupHeader ¶
func (b *BankToCustomerStatementV06) AddGroupHeader() *iso20022.GroupHeader58
func (*BankToCustomerStatementV06) AddStatement ¶
func (b *BankToCustomerStatementV06) AddStatement() *iso20022.AccountStatement6
func (*BankToCustomerStatementV06) AddSupplementaryData ¶
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 (*CancelCaseAssignment) AddAssignment ¶
func (c *CancelCaseAssignment) AddAssignment() *iso20022.CaseAssignment
func (*CancelCaseAssignment) AddCase ¶
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 (*CancelCaseAssignmentV02) AddAssignment ¶
func (c *CancelCaseAssignmentV02) AddAssignment() *iso20022.CaseAssignment2
func (*CancelCaseAssignmentV02) AddCase ¶
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 (*CancelCaseAssignmentV03) AddAssignment ¶
func (c *CancelCaseAssignmentV03) AddAssignment() *iso20022.CaseAssignment3
func (*CancelCaseAssignmentV03) AddCase ¶
func (c *CancelCaseAssignmentV03) AddCase() *iso20022.Case3
func (*CancelCaseAssignmentV03) AddSupplementaryData ¶
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 (*CaseStatusReport) AddCase ¶
func (c *CaseStatusReport) AddCase() *iso20022.Case
func (*CaseStatusReport) AddHeader ¶
func (c *CaseStatusReport) AddHeader() *iso20022.ReportHeader
func (*CaseStatusReport) AddNewAssignment ¶
func (c *CaseStatusReport) AddNewAssignment() *iso20022.CaseAssignment
func (*CaseStatusReport) AddStatus ¶
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 (*CaseStatusReportRequest) AddCase ¶
func (c *CaseStatusReportRequest) AddCase() *iso20022.Case
func (*CaseStatusReportRequest) AddRequestHeader ¶
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 (*CaseStatusReportRequestV02) AddCase ¶
func (c *CaseStatusReportRequestV02) AddCase() *iso20022.Case2
func (*CaseStatusReportRequestV02) AddRequestHeader ¶
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 (*CaseStatusReportRequestV03) AddCase ¶
func (c *CaseStatusReportRequestV03) AddCase() *iso20022.Case3
func (*CaseStatusReportRequestV03) AddRequestHeader ¶
func (c *CaseStatusReportRequestV03) AddRequestHeader() *iso20022.ReportHeader4
func (*CaseStatusReportRequestV03) AddSupplementaryData ¶
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 (*CaseStatusReportV03) AddCase ¶
func (c *CaseStatusReportV03) AddCase() *iso20022.Case2
func (*CaseStatusReportV03) AddHeader ¶
func (c *CaseStatusReportV03) AddHeader() *iso20022.ReportHeader2
func (*CaseStatusReportV03) AddNewAssignment ¶
func (c *CaseStatusReportV03) AddNewAssignment() *iso20022.CaseAssignment2
func (*CaseStatusReportV03) AddStatus ¶
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 (*CaseStatusReportV04) AddCase ¶
func (c *CaseStatusReportV04) AddCase() *iso20022.Case3
func (*CaseStatusReportV04) AddHeader ¶
func (c *CaseStatusReportV04) AddHeader() *iso20022.ReportHeader4
func (*CaseStatusReportV04) AddNewAssignment ¶
func (c *CaseStatusReportV04) AddNewAssignment() *iso20022.CaseAssignment3
func (*CaseStatusReportV04) AddStatus ¶
func (c *CaseStatusReportV04) AddStatus() *iso20022.CaseStatus2
func (*CaseStatusReportV04) AddSupplementaryData ¶
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 (*ClaimNonReceipt) AddAssignment ¶
func (c *ClaimNonReceipt) AddAssignment() *iso20022.CaseAssignment
func (*ClaimNonReceipt) AddCase ¶
func (c *ClaimNonReceipt) AddCase() *iso20022.Case
func (*ClaimNonReceipt) AddMissingCover ¶
func (c *ClaimNonReceipt) AddMissingCover() *iso20022.MissingCover
func (*ClaimNonReceipt) AddUnderlying ¶
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 (*ClaimNonReceiptV03) AddAssignment ¶
func (c *ClaimNonReceiptV03) AddAssignment() *iso20022.CaseAssignment2
func (*ClaimNonReceiptV03) AddCase ¶
func (c *ClaimNonReceiptV03) AddCase() *iso20022.Case2
func (*ClaimNonReceiptV03) AddCoverDetails ¶
func (c *ClaimNonReceiptV03) AddCoverDetails() *iso20022.MissingCover2
func (*ClaimNonReceiptV03) AddUnderlying ¶
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 (*ClaimNonReceiptV04) AddAssignment ¶
func (c *ClaimNonReceiptV04) AddAssignment() *iso20022.CaseAssignment3
func (*ClaimNonReceiptV04) AddCase ¶
func (c *ClaimNonReceiptV04) AddCase() *iso20022.Case3
func (*ClaimNonReceiptV04) AddCoverDetails ¶
func (c *ClaimNonReceiptV04) AddCoverDetails() *iso20022.MissingCover3
func (*ClaimNonReceiptV04) AddSupplementaryData ¶
func (c *ClaimNonReceiptV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*ClaimNonReceiptV04) AddUnderlying ¶
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 (*ClaimNonReceiptV05) AddAssignment ¶
func (c *ClaimNonReceiptV05) AddAssignment() *iso20022.CaseAssignment3
func (*ClaimNonReceiptV05) AddCase ¶
func (c *ClaimNonReceiptV05) AddCase() *iso20022.Case3
func (*ClaimNonReceiptV05) AddCoverDetails ¶
func (c *ClaimNonReceiptV05) AddCoverDetails() *iso20022.MissingCover3
func (*ClaimNonReceiptV05) AddSupplementaryData ¶
func (c *ClaimNonReceiptV05) AddSupplementaryData() *iso20022.SupplementaryData1
func (*ClaimNonReceiptV05) AddUnderlying ¶
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 (*CustomerPaymentCancellationRequestV01) AddAssignment ¶
func (c *CustomerPaymentCancellationRequestV01) AddAssignment() *iso20022.CaseAssignment2
func (*CustomerPaymentCancellationRequestV01) AddCase ¶
func (c *CustomerPaymentCancellationRequestV01) AddCase() *iso20022.Case2
func (*CustomerPaymentCancellationRequestV01) AddControlData ¶
func (c *CustomerPaymentCancellationRequestV01) AddControlData() *iso20022.ControlData1
func (*CustomerPaymentCancellationRequestV01) AddUnderlying ¶
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 (*CustomerPaymentCancellationRequestV02) AddAssignment ¶
func (c *CustomerPaymentCancellationRequestV02) AddAssignment() *iso20022.CaseAssignment3
func (*CustomerPaymentCancellationRequestV02) AddCase ¶
func (c *CustomerPaymentCancellationRequestV02) AddCase() *iso20022.Case3
func (*CustomerPaymentCancellationRequestV02) AddControlData ¶
func (c *CustomerPaymentCancellationRequestV02) AddControlData() *iso20022.ControlData1
func (*CustomerPaymentCancellationRequestV02) AddSupplementaryData ¶
func (c *CustomerPaymentCancellationRequestV02) AddSupplementaryData() *iso20022.SupplementaryData1
func (*CustomerPaymentCancellationRequestV02) AddUnderlying ¶
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 (*CustomerPaymentCancellationRequestV03) AddAssignment ¶
func (c *CustomerPaymentCancellationRequestV03) AddAssignment() *iso20022.CaseAssignment3
func (*CustomerPaymentCancellationRequestV03) AddCase ¶
func (c *CustomerPaymentCancellationRequestV03) AddCase() *iso20022.Case3
func (*CustomerPaymentCancellationRequestV03) AddControlData ¶
func (c *CustomerPaymentCancellationRequestV03) AddControlData() *iso20022.ControlData1
func (*CustomerPaymentCancellationRequestV03) AddSupplementaryData ¶
func (c *CustomerPaymentCancellationRequestV03) AddSupplementaryData() *iso20022.SupplementaryData1
func (*CustomerPaymentCancellationRequestV03) AddUnderlying ¶
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 (*CustomerPaymentCancellationRequestV04) AddAssignment ¶
func (c *CustomerPaymentCancellationRequestV04) AddAssignment() *iso20022.CaseAssignment3
func (*CustomerPaymentCancellationRequestV04) AddCase ¶
func (c *CustomerPaymentCancellationRequestV04) AddCase() *iso20022.Case3
func (*CustomerPaymentCancellationRequestV04) AddControlData ¶
func (c *CustomerPaymentCancellationRequestV04) AddControlData() *iso20022.ControlData1
func (*CustomerPaymentCancellationRequestV04) AddSupplementaryData ¶
func (c *CustomerPaymentCancellationRequestV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*CustomerPaymentCancellationRequestV04) AddUnderlying ¶
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 (*CustomerPaymentCancellationRequestV05) AddAssignment ¶
func (c *CustomerPaymentCancellationRequestV05) AddAssignment() *iso20022.CaseAssignment3
func (*CustomerPaymentCancellationRequestV05) AddCase ¶
func (c *CustomerPaymentCancellationRequestV05) AddCase() *iso20022.Case3
func (*CustomerPaymentCancellationRequestV05) AddControlData ¶
func (c *CustomerPaymentCancellationRequestV05) AddControlData() *iso20022.ControlData1
func (*CustomerPaymentCancellationRequestV05) AddSupplementaryData ¶
func (c *CustomerPaymentCancellationRequestV05) AddSupplementaryData() *iso20022.SupplementaryData1
func (*CustomerPaymentCancellationRequestV05) AddUnderlying ¶
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 (*CustomerPaymentCancellationRequestV06) AddAssignment ¶
func (c *CustomerPaymentCancellationRequestV06) AddAssignment() *iso20022.CaseAssignment3
func (*CustomerPaymentCancellationRequestV06) AddCase ¶
func (c *CustomerPaymentCancellationRequestV06) AddCase() *iso20022.Case3
func (*CustomerPaymentCancellationRequestV06) AddControlData ¶
func (c *CustomerPaymentCancellationRequestV06) AddControlData() *iso20022.ControlData1
func (*CustomerPaymentCancellationRequestV06) AddSupplementaryData ¶
func (c *CustomerPaymentCancellationRequestV06) AddSupplementaryData() *iso20022.SupplementaryData1
func (*CustomerPaymentCancellationRequestV06) AddUnderlying ¶
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 (*DebitAuthorisationRequest) AddAssignment ¶
func (d *DebitAuthorisationRequest) AddAssignment() *iso20022.CaseAssignment
func (*DebitAuthorisationRequest) AddCase ¶
func (d *DebitAuthorisationRequest) AddCase() *iso20022.Case
func (*DebitAuthorisationRequest) AddDetail ¶
func (d *DebitAuthorisationRequest) AddDetail() *iso20022.DebitAuthorisationDetails
func (*DebitAuthorisationRequest) AddUnderlying ¶
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 (*DebitAuthorisationRequestV03) AddAssignment ¶
func (d *DebitAuthorisationRequestV03) AddAssignment() *iso20022.CaseAssignment2
func (*DebitAuthorisationRequestV03) AddCase ¶
func (d *DebitAuthorisationRequestV03) AddCase() *iso20022.Case2
func (*DebitAuthorisationRequestV03) AddDetail ¶
func (d *DebitAuthorisationRequestV03) AddDetail() *iso20022.DebitAuthorisationDetails3
func (*DebitAuthorisationRequestV03) AddUnderlying ¶
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 (*DebitAuthorisationRequestV04) AddAssignment ¶
func (d *DebitAuthorisationRequestV04) AddAssignment() *iso20022.CaseAssignment3
func (*DebitAuthorisationRequestV04) AddCase ¶
func (d *DebitAuthorisationRequestV04) AddCase() *iso20022.Case3
func (*DebitAuthorisationRequestV04) AddDetail ¶
func (d *DebitAuthorisationRequestV04) AddDetail() *iso20022.DebitAuthorisation1
func (*DebitAuthorisationRequestV04) AddSupplementaryData ¶
func (d *DebitAuthorisationRequestV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*DebitAuthorisationRequestV04) AddUnderlying ¶
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 (*DebitAuthorisationRequestV05) AddAssignment ¶
func (d *DebitAuthorisationRequestV05) AddAssignment() *iso20022.CaseAssignment3
func (*DebitAuthorisationRequestV05) AddCase ¶
func (d *DebitAuthorisationRequestV05) AddCase() *iso20022.Case3
func (*DebitAuthorisationRequestV05) AddDetail ¶
func (d *DebitAuthorisationRequestV05) AddDetail() *iso20022.DebitAuthorisation2
func (*DebitAuthorisationRequestV05) AddSupplementaryData ¶
func (d *DebitAuthorisationRequestV05) AddSupplementaryData() *iso20022.SupplementaryData1
func (*DebitAuthorisationRequestV05) AddUnderlying ¶
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 (*DebitAuthorisationResponse) AddAssignment ¶
func (d *DebitAuthorisationResponse) AddAssignment() *iso20022.CaseAssignment
func (*DebitAuthorisationResponse) AddCase ¶
func (d *DebitAuthorisationResponse) AddCase() *iso20022.Case
func (*DebitAuthorisationResponse) AddConfirmation ¶
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 (*DebitAuthorisationResponseV02) AddAssignment ¶
func (d *DebitAuthorisationResponseV02) AddAssignment() *iso20022.CaseAssignment2
func (*DebitAuthorisationResponseV02) AddCase ¶
func (d *DebitAuthorisationResponseV02) AddCase() *iso20022.Case2
func (*DebitAuthorisationResponseV02) AddConfirmation ¶
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 (*DebitAuthorisationResponseV03) AddAssignment ¶
func (d *DebitAuthorisationResponseV03) AddAssignment() *iso20022.CaseAssignment3
func (*DebitAuthorisationResponseV03) AddCase ¶
func (d *DebitAuthorisationResponseV03) AddCase() *iso20022.Case3
func (*DebitAuthorisationResponseV03) AddConfirmation ¶
func (d *DebitAuthorisationResponseV03) AddConfirmation() *iso20022.DebitAuthorisationConfirmation2
func (*DebitAuthorisationResponseV03) AddSupplementaryData ¶
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 (*Document00700201) AddMessage ¶
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 (*Document00800201) AddMessage ¶
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 (*Document02600101) AddMessage ¶
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 (*Document02600103) AddMessage ¶
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 (*Document02600104) AddMessage ¶
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 (*Document02600105) AddMessage ¶
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 (*Document02700101) AddMessage ¶
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 (*Document02700103) AddMessage ¶
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 (*Document02700104) AddMessage ¶
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 (*Document02700105) AddMessage ¶
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 (*Document02800101) AddMessage ¶
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 (*Document02800103) AddMessage ¶
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 (*Document02800104) AddMessage ¶
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 (*Document02800105) AddMessage ¶
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 (*Document02800106) AddMessage ¶
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 (*Document02800107) AddMessage ¶
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 (*Document02900101) AddMessage ¶
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 (*Document02900103) AddMessage ¶
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 (*Document02900104) AddMessage ¶
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 (*Document02900105) AddMessage ¶
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 (*Document02900106) AddMessage ¶
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 (*Document02900107) AddMessage ¶
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 (*Document03000101) AddMessage ¶
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 (*Document03000103) AddMessage ¶
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 (*Document03000104) AddMessage ¶
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 (*Document03100101) AddMessage ¶
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 (*Document03100103) AddMessage ¶
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 (*Document03100104) AddMessage ¶
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 (*Document03200101) AddMessage ¶
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 (*Document03200102) AddMessage ¶
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 (*Document03200103) AddMessage ¶
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 (*Document03300101) AddMessage ¶
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 (*Document03300103) AddMessage ¶
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 (*Document03300104) AddMessage ¶
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 (*Document03400103) AddMessage ¶
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 (*Document03400104) AddMessage ¶
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 (*Document03500102) AddMessage ¶
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 (*Document03500103) AddMessage ¶
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 (*Document03600101) AddMessage ¶
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 (*Document03600102) AddMessage ¶
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 (*Document03600103) AddMessage ¶
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 (*Document03700101) AddMessage ¶
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 (*Document03700103) AddMessage ¶
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 (*Document03700104) AddMessage ¶
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 (*Document03700105) AddMessage ¶
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 (*Document03800101) AddMessage ¶
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 (*Document03800102) AddMessage ¶
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 (*Document03800103) AddMessage ¶
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 (*Document03900101) AddMessage ¶
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 (*Document03900103) AddMessage ¶
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 (*Document03900104) AddMessage ¶
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 (*Document04000102) AddMessage ¶
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 (*Document04000103) AddMessage ¶
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 (*Document04000104) AddMessage ¶
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 (*Document04100102) AddMessage ¶
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 (*Document04100103) AddMessage ¶
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 (*Document04100104) AddMessage ¶
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 (*Document04200102) AddMessage ¶
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 (*Document04200103) AddMessage ¶
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 (*Document04200104) AddMessage ¶
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 (*Document04300102) AddMessage ¶
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 (*Document04300103) AddMessage ¶
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 (*Document04300104) AddMessage ¶
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 (*Document04400101) AddMessage ¶
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 (*Document04400102) AddMessage ¶
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 (*Document04400103) AddMessage ¶
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 (*Document04500101) AddMessage ¶
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 (*Document04500102) AddMessage ¶
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 (*Document04500103) AddMessage ¶
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 (*Document05200101) AddMessage ¶
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 (*Document05200102) AddMessage ¶
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 (*Document05200103) AddMessage ¶
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 (*Document05200104) AddMessage ¶
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 (*Document05200105) AddMessage ¶
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 (*Document05200106) AddMessage ¶
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 (*Document05300101) AddMessage ¶
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 (*Document05300102) AddMessage ¶
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 (*Document05300103) AddMessage ¶
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 (*Document05300104) AddMessage ¶
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 (*Document05300105) AddMessage ¶
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 (*Document05300106) AddMessage ¶
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 (*Document05400101) AddMessage ¶
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 (*Document05400102) AddMessage ¶
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 (*Document05400103) AddMessage ¶
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 (*Document05400104) AddMessage ¶
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 (*Document05400105) AddMessage ¶
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 (*Document05400106) AddMessage ¶
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 (*Document05500101) AddMessage ¶
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 (*Document05500102) AddMessage ¶
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 (*Document05500103) AddMessage ¶
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 (*Document05500104) AddMessage ¶
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 (*Document05500105) AddMessage ¶
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 (*Document05500106) AddMessage ¶
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 (*Document05600101) AddMessage ¶
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 (*Document05600102) AddMessage ¶
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 (*Document05600103) AddMessage ¶
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 (*Document05600104) AddMessage ¶
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 (*Document05600105) AddMessage ¶
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 (*Document05600106) AddMessage ¶
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 (*Document05700102) AddMessage ¶
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 (*Document05700103) AddMessage ¶
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 (*Document05700104) AddMessage ¶
func (d *Document05700104) AddMessage() *NotificationToReceiveV04
type Document05700105 ¶
type Document05700105 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.057.001.05 Document"` Message *NotificationToReceiveV05 `xml:"NtfctnToRcv"` }
func (*Document05700105) AddMessage ¶
func (d *Document05700105) AddMessage() *NotificationToReceiveV05
type Document05800102 ¶
type Document05800102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.058.001.02 Document"` Message *NotificationToReceiveCancellationAdviceV02 `xml:"NtfctnToRcvCxlAdvc"` }
func (*Document05800102) AddMessage ¶
func (d *Document05800102) AddMessage() *NotificationToReceiveCancellationAdviceV02
type Document05800103 ¶
type Document05800103 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.058.001.03 Document"` Message *NotificationToReceiveCancellationAdviceV03 `xml:"NtfctnToRcvCxlAdvc"` }
func (*Document05800103) AddMessage ¶
func (d *Document05800103) AddMessage() *NotificationToReceiveCancellationAdviceV03
type Document05800104 ¶
type Document05800104 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.058.001.04 Document"` Message *NotificationToReceiveCancellationAdviceV04 `xml:"NtfctnToRcvCxlAdvc"` }
func (*Document05800104) AddMessage ¶
func (d *Document05800104) AddMessage() *NotificationToReceiveCancellationAdviceV04
type Document05800105 ¶
type Document05800105 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.058.001.05 Document"` Message *NotificationToReceiveCancellationAdviceV05 `xml:"NtfctnToRcvCxlAdvc"` }
func (*Document05800105) AddMessage ¶
func (d *Document05800105) AddMessage() *NotificationToReceiveCancellationAdviceV05
type Document05900102 ¶
type Document05900102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.059.001.02 Document"` Message *NotificationToReceiveStatusReportV02 `xml:"NtfctnToRcvStsRpt"` }
func (*Document05900102) AddMessage ¶
func (d *Document05900102) AddMessage() *NotificationToReceiveStatusReportV02
type Document05900103 ¶
type Document05900103 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.059.001.03 Document"` Message *NotificationToReceiveStatusReportV03 `xml:"NtfctnToRcvStsRpt"` }
func (*Document05900103) AddMessage ¶
func (d *Document05900103) AddMessage() *NotificationToReceiveStatusReportV03
type Document05900104 ¶
type Document05900104 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.059.001.04 Document"` Message *NotificationToReceiveStatusReportV04 `xml:"NtfctnToRcvStsRpt"` }
func (*Document05900104) AddMessage ¶
func (d *Document05900104) AddMessage() *NotificationToReceiveStatusReportV04
type Document05900105 ¶
type Document05900105 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.059.001.05 Document"` Message *NotificationToReceiveStatusReportV05 `xml:"NtfctnToRcvStsRpt"` }
func (*Document05900105) AddMessage ¶
func (d *Document05900105) AddMessage() *NotificationToReceiveStatusReportV05
type Document06000102 ¶
type Document06000102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.060.001.02 Document"` Message *AccountReportingRequestV02 `xml:"AcctRptgReq"` }
func (*Document06000102) AddMessage ¶
func (d *Document06000102) AddMessage() *AccountReportingRequestV02
type Document06000103 ¶
type Document06000103 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.060.001.03 Document"` Message *AccountReportingRequestV03 `xml:"AcctRptgReq"` }
func (*Document06000103) AddMessage ¶
func (d *Document06000103) AddMessage() *AccountReportingRequestV03
type Document06100102 ¶
type Document06100102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.061.001.02 Document"` Message *PayInCallV02 `xml:"PayInCall"` }
func (*Document06100102) AddMessage ¶
func (d *Document06100102) AddMessage() *PayInCallV02
type Document06200103 ¶
type Document06200103 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.062.001.03 Document"` Message *PayInScheduleV03 `xml:"PayInSchdl"` }
func (*Document06200103) AddMessage ¶
func (d *Document06200103) AddMessage() *PayInScheduleV03
type Document06300102 ¶
type Document06300102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.063.001.02 Document"` Message *PayInEventAcknowledgementV02 `xml:"PayInEvtAck"` }
func (*Document06300102) AddMessage ¶
func (d *Document06300102) AddMessage() *PayInEventAcknowledgementV02
type Document08600101 ¶
type Document08600101 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.086.001.01 Document"` Message *BankServicesBillingStatementV01 `xml:"BkSvcsBllgStmt"` }
func (*Document08600101) AddMessage ¶
func (d *Document08600101) AddMessage() *BankServicesBillingStatementV01
type Document08600102 ¶
type Document08600102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.086.001.02 Document"` Message *BankServicesBillingStatementV02 `xml:"BkSvcsBllgStmt"` }
func (*Document08600102) AddMessage ¶
func (d *Document08600102) AddMessage() *BankServicesBillingStatementV02
type Document08700101 ¶
type Document08700101 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.087.001.01 Document"` Message *RequestToModifyPaymentV01 `xml:"ReqToModfyPmt"` }
func (*Document08700101) AddMessage ¶
func (d *Document08700101) AddMessage() *RequestToModifyPaymentV01
type Document08700102 ¶
type Document08700102 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.087.001.02 Document"` Message *RequestToModifyPaymentV02 `xml:"ReqToModfyPmt"` }
func (*Document08700102) AddMessage ¶
func (d *Document08700102) AddMessage() *RequestToModifyPaymentV02
type Document08700104 ¶
type Document08700104 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.087.001.04 Document"` Message *RequestToModifyPaymentV04 `xml:"ReqToModfyPmt"` }
func (*Document08700104) AddMessage ¶
func (d *Document08700104) AddMessage() *RequestToModifyPaymentV04
type Document08800101 ¶
type Document08800101 struct { XMLName xml.Name `xml:"urn:iso:std:iso:20022:tech:xsd:camt.088.001.01 Document"` Message *NetReportV01 `xml:"NetRpt"` }
func (*Document08800101) AddMessage ¶
func (d *Document08800101) AddMessage() *NetReportV01
type DuplicateV03 ¶
type DuplicateV03 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"` // Duplicate of a previously sent message. Duplicate *iso20022.ProprietaryData4 `xml:"Dplct"` }
Scope The Duplicate message is used by financial institutions, with their own offices, and/or with other financial institutions with which they have established bilateral agreements. It allows to exchange duplicate payment instructions. Usage This message must be sent in response to a Request For Duplicate message. The Duplicate Data element must contain a well formed XML document. This means XML special characters such as '<' must be used in a way that is consistent with XML well-formedness criteria.
func (*DuplicateV03) AddAssignment ¶
func (d *DuplicateV03) AddAssignment() *iso20022.CaseAssignment2
func (*DuplicateV03) AddCase ¶
func (d *DuplicateV03) AddCase() *iso20022.Case2
func (*DuplicateV03) AddDuplicate ¶
func (d *DuplicateV03) AddDuplicate() *iso20022.ProprietaryData4
type DuplicateV04 ¶
type DuplicateV04 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"` // Duplicate of a previously sent message. Duplicate *iso20022.ProprietaryData4 `xml:"Dplct"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Duplicate message is used by financial institutions, with their own offices, and/or with other financial institutions with which they have established bilateral agreements. It allows to exchange duplicate payment instructions. Usage This message must be sent in response to a Request For Duplicate message. The Duplicate Data element must contain a well formed XML document. This means XML special characters such as '<' must be used in a way that is consistent with XML well-formedness criteria.
func (*DuplicateV04) AddAssignment ¶
func (d *DuplicateV04) AddAssignment() *iso20022.CaseAssignment3
func (*DuplicateV04) AddCase ¶
func (d *DuplicateV04) AddCase() *iso20022.Case3
func (*DuplicateV04) AddDuplicate ¶
func (d *DuplicateV04) AddDuplicate() *iso20022.ProprietaryData4
func (*DuplicateV04) AddSupplementaryData ¶
func (d *DuplicateV04) AddSupplementaryData() *iso20022.SupplementaryData1
type FIToFIPaymentCancellationRequestV01 ¶
type FIToFIPaymentCancellationRequestV01 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.UnderlyingTransaction2 `xml:"Undrlyg"` }
Scope The FIToFI 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 FIToFI Payment Cancellation Request message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer). Usage The FIToFI 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 FIToFI 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 FIToFI Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The FIToFI 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 FIToFI Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'.
func (*FIToFIPaymentCancellationRequestV01) AddAssignment ¶
func (f *FIToFIPaymentCancellationRequestV01) AddAssignment() *iso20022.CaseAssignment2
func (*FIToFIPaymentCancellationRequestV01) AddCase ¶
func (f *FIToFIPaymentCancellationRequestV01) AddCase() *iso20022.Case2
func (*FIToFIPaymentCancellationRequestV01) AddControlData ¶
func (f *FIToFIPaymentCancellationRequestV01) AddControlData() *iso20022.ControlData1
func (*FIToFIPaymentCancellationRequestV01) AddUnderlying ¶
func (f *FIToFIPaymentCancellationRequestV01) AddUnderlying() *iso20022.UnderlyingTransaction2
type FIToFIPaymentCancellationRequestV02 ¶
type FIToFIPaymentCancellationRequestV02 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.UnderlyingTransaction5 `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 FIToFI 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 FIToFI Payment Cancellation Request message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer). Usage The FIToFI 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 FIToFI 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 FIToFI Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The FIToFI 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 FIToFI Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The FIToFI Payment Cancellation Request message has the following main characteristics: Case Identification: 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 FIToFI 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 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 or transaction present in the cancellation request: For each group or transaction, 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. Cancellation of a cover payment: The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately. Cancellation request initiators: 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 (*FIToFIPaymentCancellationRequestV02) AddAssignment ¶
func (f *FIToFIPaymentCancellationRequestV02) AddAssignment() *iso20022.CaseAssignment3
func (*FIToFIPaymentCancellationRequestV02) AddCase ¶
func (f *FIToFIPaymentCancellationRequestV02) AddCase() *iso20022.Case3
func (*FIToFIPaymentCancellationRequestV02) AddControlData ¶
func (f *FIToFIPaymentCancellationRequestV02) AddControlData() *iso20022.ControlData1
func (*FIToFIPaymentCancellationRequestV02) AddSupplementaryData ¶
func (f *FIToFIPaymentCancellationRequestV02) AddSupplementaryData() *iso20022.SupplementaryData1
func (*FIToFIPaymentCancellationRequestV02) AddUnderlying ¶
func (f *FIToFIPaymentCancellationRequestV02) AddUnderlying() *iso20022.UnderlyingTransaction5
type FIToFIPaymentCancellationRequestV03 ¶
type FIToFIPaymentCancellationRequestV03 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.UnderlyingTransaction8 `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 FIToFI 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 FIToFI Payment Cancellation Request message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer). Usage The FIToFI 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 FIToFI 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 FIToFI Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The FIToFI 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 FIToFI Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The FIToFI Payment Cancellation Request message has the following main characteristics: Case Identification: 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 FIToFI 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 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 or transaction present in the cancellation request: For each group or transaction, 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. Cancellation of a cover payment: The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately. Cancellation request initiators: 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 (*FIToFIPaymentCancellationRequestV03) AddAssignment ¶
func (f *FIToFIPaymentCancellationRequestV03) AddAssignment() *iso20022.CaseAssignment3
func (*FIToFIPaymentCancellationRequestV03) AddCase ¶
func (f *FIToFIPaymentCancellationRequestV03) AddCase() *iso20022.Case3
func (*FIToFIPaymentCancellationRequestV03) AddControlData ¶
func (f *FIToFIPaymentCancellationRequestV03) AddControlData() *iso20022.ControlData1
func (*FIToFIPaymentCancellationRequestV03) AddSupplementaryData ¶
func (f *FIToFIPaymentCancellationRequestV03) AddSupplementaryData() *iso20022.SupplementaryData1
func (*FIToFIPaymentCancellationRequestV03) AddUnderlying ¶
func (f *FIToFIPaymentCancellationRequestV03) AddUnderlying() *iso20022.UnderlyingTransaction8
type FIToFIPaymentCancellationRequestV04 ¶
type FIToFIPaymentCancellationRequestV04 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.UnderlyingTransaction10 `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 FIToFI 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 FIToFI Payment Cancellation Request message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer). Usage The FIToFI 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 FIToFI 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 FIToFI Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The FIToFI 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 FIToFI Payment Cancellation Request message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The FIToFI Payment Cancellation Request message has the following main characteristics: Case Identification: 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 FIToFI 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 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 or transaction present in the cancellation request: For each group or transaction, 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. Cancellation of a cover payment: The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately. Cancellation request initiators: 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 (*FIToFIPaymentCancellationRequestV04) AddAssignment ¶
func (f *FIToFIPaymentCancellationRequestV04) AddAssignment() *iso20022.CaseAssignment3
func (*FIToFIPaymentCancellationRequestV04) AddCase ¶
func (f *FIToFIPaymentCancellationRequestV04) AddCase() *iso20022.Case3
func (*FIToFIPaymentCancellationRequestV04) AddControlData ¶
func (f *FIToFIPaymentCancellationRequestV04) AddControlData() *iso20022.ControlData1
func (*FIToFIPaymentCancellationRequestV04) AddSupplementaryData ¶
func (f *FIToFIPaymentCancellationRequestV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*FIToFIPaymentCancellationRequestV04) AddUnderlying ¶
func (f *FIToFIPaymentCancellationRequestV04) AddUnderlying() *iso20022.UnderlyingTransaction10
type FIToFIPaymentCancellationRequestV05 ¶
type FIToFIPaymentCancellationRequestV05 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.UnderlyingTransaction13 `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 FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer). Usage The FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest 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 FIToFI Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The FIToFIPaymentCancellationRequest message has the following main characteristics: Case Identification: 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 FIToFIPaymentCancellationRequest 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 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 or transaction present in the cancellation request: For each group or transaction, 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. Cancellation of a cover payment: The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately. Cancellation request initiators: 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 (*FIToFIPaymentCancellationRequestV05) AddAssignment ¶
func (f *FIToFIPaymentCancellationRequestV05) AddAssignment() *iso20022.CaseAssignment3
func (*FIToFIPaymentCancellationRequestV05) AddCase ¶
func (f *FIToFIPaymentCancellationRequestV05) AddCase() *iso20022.Case3
func (*FIToFIPaymentCancellationRequestV05) AddControlData ¶
func (f *FIToFIPaymentCancellationRequestV05) AddControlData() *iso20022.ControlData1
func (*FIToFIPaymentCancellationRequestV05) AddSupplementaryData ¶
func (f *FIToFIPaymentCancellationRequestV05) AddSupplementaryData() *iso20022.SupplementaryData1
func (*FIToFIPaymentCancellationRequestV05) AddUnderlying ¶
func (f *FIToFIPaymentCancellationRequestV05) AddUnderlying() *iso20022.UnderlyingTransaction13
type FIToFIPaymentCancellationRequestV06 ¶
type FIToFIPaymentCancellationRequestV06 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.UnderlyingTransaction16 `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 FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message is exchanged between the instructing agent and the instructed agent to request the cancellation of a interbank payment message previously sent (such as FIToFICustomerCreditTransfer, FIToFICustomerDirectDebit or FinancialInstitutionCreditTransfer).
The FIToFIPaymentCancellationRequest supports for both the request for cancellation (the instructed agent - or assignee - has not yet processed and forwarded the payment instruction) as well as the request for refund (payment has been fully processed already by the instructed agent - or assignee).
Usage The FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest 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 FIToFI Payment Cancellation Request message case may lead to a Debit Authorisation Request message sent to the creditor by its account servicing institution. The FIToFIPaymentCancellationRequest 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 FIToFIPaymentCancellationRequest message and the element ReopenCaseIndication is set to 'Yes' or 'true'. The FIToFIPaymentCancellationRequest message has the following main characteristics: Case Identification: 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 FIToFIPaymentCancellationRequest message the case 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 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 or transaction present in the cancellation request: For each group or transaction, 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. Cancellation of a cover payment: The cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately. Cancellation request initiators: 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 (*FIToFIPaymentCancellationRequestV06) AddAssignment ¶
func (f *FIToFIPaymentCancellationRequestV06) AddAssignment() *iso20022.CaseAssignment3
func (*FIToFIPaymentCancellationRequestV06) AddCase ¶
func (f *FIToFIPaymentCancellationRequestV06) AddCase() *iso20022.Case3
func (*FIToFIPaymentCancellationRequestV06) AddControlData ¶
func (f *FIToFIPaymentCancellationRequestV06) AddControlData() *iso20022.ControlData1
func (*FIToFIPaymentCancellationRequestV06) AddSupplementaryData ¶
func (f *FIToFIPaymentCancellationRequestV06) AddSupplementaryData() *iso20022.SupplementaryData1
func (*FIToFIPaymentCancellationRequestV06) AddUnderlying ¶
func (f *FIToFIPaymentCancellationRequestV06) AddUnderlying() *iso20022.UnderlyingTransaction16
type FundConfirmedCashForecastReportCancellationV01 ¶
type FundConfirmedCashForecastReportCancellationV01 struct { // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference *iso20022.AdditionalReference3 `xml:"PrvsRef"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // The FundDetailedConfirmedCashForecastReport to be cancelled. CashForecastReportToBeCancelled *iso20022.FundConfirmedCashForecastReport1 `xml:"CshFcstRptToBeCanc,omitempty"` }
Scope The FundConfirmedCashForecastReportCancellation message is sent by a report provider, such as a transfer agent or a designated agent of the fund, to a report user, such as an investment manager, a fund accountant or any other interested party. This message is used to cancel a previously sent FundConfirmedCashForecastReport message. Usage The FundConfirmedCashForecastReportCancellation message is used to cancel an entire FundConfirmedCashForecastReport message that was previously sent by the report provider. This message must contain the reference of the message to be cancelled. This message may also contain details of the message to be cancelled, but this is not recommended.
func (*FundConfirmedCashForecastReportCancellationV01) AddCashForecastReportToBeCancelled ¶
func (f *FundConfirmedCashForecastReportCancellationV01) AddCashForecastReportToBeCancelled() *iso20022.FundConfirmedCashForecastReport1
func (*FundConfirmedCashForecastReportCancellationV01) AddPoolReference ¶
func (f *FundConfirmedCashForecastReportCancellationV01) AddPoolReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportCancellationV01) AddPreviousReference ¶
func (f *FundConfirmedCashForecastReportCancellationV01) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportCancellationV01) AddRelatedReference ¶
func (f *FundConfirmedCashForecastReportCancellationV01) AddRelatedReference() *iso20022.AdditionalReference3
type FundConfirmedCashForecastReportCancellationV02 ¶
type FundConfirmedCashForecastReportCancellationV02 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference *iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // The FundDetailedConfirmedCashForecastReport to be cancelled. CashForecastReportToBeCancelled *iso20022.FundConfirmedCashForecastReport2 `xml:"CshFcstRptToBeCanc,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundConfirmedCashForecastReportCancellation message to the report user, such as an investment manager, to cancel a previously sent FundConfirmedCashForecastReport message. Usage The FundConfirmedCashForecastReportCancellation message is used to cancel an entire FundConfirmedCashForecastReport message that was previously sent by the report provider. This message must contain reference to the of the message being cancelled. This message may also contain details of the message to be cancelled, but this is not recommended.
func (*FundConfirmedCashForecastReportCancellationV02) AddCashForecastReportToBeCancelled ¶
func (f *FundConfirmedCashForecastReportCancellationV02) AddCashForecastReportToBeCancelled() *iso20022.FundConfirmedCashForecastReport2
func (*FundConfirmedCashForecastReportCancellationV02) AddMessageIdentification ¶
func (f *FundConfirmedCashForecastReportCancellationV02) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundConfirmedCashForecastReportCancellationV02) AddMessagePagination ¶
func (f *FundConfirmedCashForecastReportCancellationV02) AddMessagePagination() *iso20022.Pagination
func (*FundConfirmedCashForecastReportCancellationV02) AddPoolReference ¶
func (f *FundConfirmedCashForecastReportCancellationV02) AddPoolReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportCancellationV02) AddPreviousReference ¶
func (f *FundConfirmedCashForecastReportCancellationV02) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportCancellationV02) AddRelatedReference ¶
func (f *FundConfirmedCashForecastReportCancellationV02) AddRelatedReference() *iso20022.AdditionalReference3
type FundConfirmedCashForecastReportCancellationV03 ¶
type FundConfirmedCashForecastReportCancellationV03 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference *iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // The FundDetailedConfirmedCashForecastReport to be cancelled. CashForecastReportToBeCancelled *iso20022.FundConfirmedCashForecastReport3 `xml:"CshFcstRptToBeCanc,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundConfirmedCashForecastReportCancellation message to the report user, such as an investment manager or pricing agent, to cancel a previously sent FundConfirmedCashForecastReport message. Usage The FundConfirmedCashForecastReportCancellation message is used to cancel an entire FundConfirmedCashForecastReport message that was previously sent by the report provider. This message must contain reference to the of the message being cancelled. This message may also contain details of the message to be cancelled, but this is not recommended.
func (*FundConfirmedCashForecastReportCancellationV03) AddCashForecastReportToBeCancelled ¶
func (f *FundConfirmedCashForecastReportCancellationV03) AddCashForecastReportToBeCancelled() *iso20022.FundConfirmedCashForecastReport3
func (*FundConfirmedCashForecastReportCancellationV03) AddMessageIdentification ¶
func (f *FundConfirmedCashForecastReportCancellationV03) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundConfirmedCashForecastReportCancellationV03) AddMessagePagination ¶
func (f *FundConfirmedCashForecastReportCancellationV03) AddMessagePagination() *iso20022.Pagination
func (*FundConfirmedCashForecastReportCancellationV03) AddPoolReference ¶
func (f *FundConfirmedCashForecastReportCancellationV03) AddPoolReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportCancellationV03) AddPreviousReference ¶
func (f *FundConfirmedCashForecastReportCancellationV03) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportCancellationV03) AddRelatedReference ¶
func (f *FundConfirmedCashForecastReportCancellationV03) AddRelatedReference() *iso20022.AdditionalReference3
type FundConfirmedCashForecastReportV02 ¶
type FundConfirmedCashForecastReportV02 struct { // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Information related to the cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switches to/from a specified investment fund. // // FundCashForecastDetails []*iso20022.FundCashForecast1 `xml:"FndCshFcstDtls"` // Additional information that cannot be captured in the structured elements and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope The FundConfirmedCashForecastReport message is sent by a report provider, such as a transfer agent or a designated agent of the fund, to a report user, such as an investment manager, a fund accountant or any other interested party. This message is used to report the confirmed cash incomings and outgoings of one or more investment funds, on one or more trade dates. These cash movements may result from, for example, redemption, subscription, switch transactions or dividends. Usage The FundConfirmedCashForecastReport message is used to provide definitive cash movements, that is it is sent after the cut-off time and/or the price valuation of the fund.
func (*FundConfirmedCashForecastReportV02) AddExtension ¶
func (f *FundConfirmedCashForecastReportV02) AddExtension() *iso20022.Extension1
func (*FundConfirmedCashForecastReportV02) AddFundCashForecastDetails ¶
func (f *FundConfirmedCashForecastReportV02) AddFundCashForecastDetails() *iso20022.FundCashForecast1
func (*FundConfirmedCashForecastReportV02) AddPoolReference ¶
func (f *FundConfirmedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportV02) AddPreviousReference ¶
func (f *FundConfirmedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportV02) AddRelatedReference ¶
func (f *FundConfirmedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
type FundConfirmedCashForecastReportV03 ¶
type FundConfirmedCashForecastReportV03 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information related to the cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switches to/from a specified investment fund. FundCashForecastDetails []*iso20022.FundCashForecast3 `xml:"FndCshFcstDtls"` // Estimated net cash as a result of the cash-in and cash-out flows. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that cannot be captured in the structured elements and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundConfirmedCashForecastReport message to the report user, such as an investment manager, to report the confirmed cash incomings and outgoings of one or more investment funds on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundConfirmedCashForecastReport is used to report definitive cash movements, that is it is sent after the cut-off time and/or the price valuation of the fund. This message contains incoming and outgoing cash flows that are confirmed, i.e., the price has been applied. If the price is not yet definitive, then the FundEstimatedCashForecastReport message must be used. This message allows the report provider to report cash movements in or out of a fund, but does not allow the Sender to categorise these movements, for example by country, or to give details of the underlying orders, commission or charges. If the report provider wishes to give detailed information related to cash movements, then the FundDetailedConfirmedCashForecastReport message must be used.
func (*FundConfirmedCashForecastReportV03) AddConsolidatedNetCashForecast ¶
func (f *FundConfirmedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundConfirmedCashForecastReportV03) AddExtension ¶
func (f *FundConfirmedCashForecastReportV03) AddExtension() *iso20022.Extension1
func (*FundConfirmedCashForecastReportV03) AddFundCashForecastDetails ¶
func (f *FundConfirmedCashForecastReportV03) AddFundCashForecastDetails() *iso20022.FundCashForecast3
func (*FundConfirmedCashForecastReportV03) AddMessageIdentification ¶
func (f *FundConfirmedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundConfirmedCashForecastReportV03) AddMessagePagination ¶
func (f *FundConfirmedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
func (*FundConfirmedCashForecastReportV03) AddPoolReference ¶
func (f *FundConfirmedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportV03) AddPreviousReference ¶
func (f *FundConfirmedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportV03) AddRelatedReference ¶
func (f *FundConfirmedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
type FundConfirmedCashForecastReportV04 ¶
type FundConfirmedCashForecastReportV04 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information about the fund/sub fund when the report either specifies cash flow for the fund/sub fund or for a share class of the fund/sub fund. FundOrSubFundDetails []*iso20022.Fund2 `xml:"FndOrSubFndDtls,omitempty"` // Information related to the cash-in and cash-out flows for a specific trade date as a result of transactions in shares in an investment fund, for example, subscriptions, redemptions or switches. FundCashForecastDetails []*iso20022.FundCashForecast7 `xml:"FndCshFcstDtls,omitempty"` // Estimated net cash as a result of the cash-in and cash-out flows. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that cannot be captured in the structured elements and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundConfirmedCashForecastReport message to the report user, such as an investment manager or pricing agent, to report the confirmed cash incomings and outgoings of one or more share classes of an investment fund on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundConfirmedCashForecastReport is used to report definitive cash movements, that is it is sent after the cut-off time and/or the price valuation of the fund. This message contains incoming and outgoing cash flows that are confirmed, that is, the price has been applied. If the price is not yet definitive, then the FundEstimatedCashForecastReport message must be used. The message structure allows for the following uses: - to provide cash in and cash out amounts for a fund/sub fund (a FundOrSubFundDetails sequence is used), - to provide cash in and cash out amounts for a fund/sub fund and one or more share classes (FundOrSubFundDetails sequence and one or more FundCashForecastDetails sequences are used), - to provide cash in and cash out amounts for one or more share classes (one or more FundCashForecastDetails sequences are used). - to provide cash in and cash out amounts for more than one fund/sub fund, and more than one share classes (two or more FundOrSubFundDetails sequences and two or more FundCashForecastDetails sequences and used); however, it should be noted that, in this usage, there is no way to determine which share class belongs to which fund/sub fund from the message content itself, which may not be desirable and the use of this kind of combination should be bilaterally agreed. This message allows the report provider to report cash movements in or out of a fund, but does not allow the Sender to categorise these movements, for example by country, or to give details of the underlying orders, commission or charges. If the report provider wishes to give detailed information related to cash movements, then the FundDetailedConfirmedCashForecastReport message must be used.
func (*FundConfirmedCashForecastReportV04) AddConsolidatedNetCashForecast ¶
func (f *FundConfirmedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundConfirmedCashForecastReportV04) AddExtension ¶
func (f *FundConfirmedCashForecastReportV04) AddExtension() *iso20022.Extension1
func (*FundConfirmedCashForecastReportV04) AddFundCashForecastDetails ¶
func (f *FundConfirmedCashForecastReportV04) AddFundCashForecastDetails() *iso20022.FundCashForecast7
func (*FundConfirmedCashForecastReportV04) AddFundOrSubFundDetails ¶
func (f *FundConfirmedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund2
func (*FundConfirmedCashForecastReportV04) AddMessageIdentification ¶
func (f *FundConfirmedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundConfirmedCashForecastReportV04) AddMessagePagination ¶
func (f *FundConfirmedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
func (*FundConfirmedCashForecastReportV04) AddPoolReference ¶
func (f *FundConfirmedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportV04) AddPreviousReference ¶
func (f *FundConfirmedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundConfirmedCashForecastReportV04) AddRelatedReference ¶
func (f *FundConfirmedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedConfirmedCashForecastReportCancellationV01 ¶
type FundDetailedConfirmedCashForecastReportCancellationV01 struct { // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference *iso20022.AdditionalReference3 `xml:"PrvsRef"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // The FundDetailedConfirmedCashForecastReport to be cancelled. CashForecastReportToBeCancelled *iso20022.FundDetailedConfirmedCashForecastReport1 `xml:"CshFcstRptToBeCanc,omitempty"` }
Scope The FundDetailedConfirmedCashForecastReportCancellation message is sent by a report provider, such as a transfer agent or a designated agent of the fund, to a report user, such as an investment manager, a fund accountant or any other interested party. This message is used to cancel a previously sent FundDetailedConfirmedCashForecastReport message. Usage The FundDetailedConfirmedCashForecastReportCancellation message is used to cancel an entire FundDetailedConfirmedCashForecastReport message that was previously sent by the report provider. This message must contain the reference of the message to be cancelled. This message may also contain details of the message to be cancelled, but this is not recommended.
func (*FundDetailedConfirmedCashForecastReportCancellationV01) AddCashForecastReportToBeCancelled ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddCashForecastReportToBeCancelled() *iso20022.FundDetailedConfirmedCashForecastReport1
func (*FundDetailedConfirmedCashForecastReportCancellationV01) AddPoolReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportCancellationV01) AddPreviousReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportCancellationV01) AddRelatedReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV01) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedConfirmedCashForecastReportCancellationV02 ¶
type FundDetailedConfirmedCashForecastReportCancellationV02 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference *iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // The FundDetailedConfirmedCashForecastReport to be cancelled. CashForecastReportToBeCancelled *iso20022.FundDetailedConfirmedCashForecastReport2 `xml:"CshFcstRptToBeCanc,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundDetailedConfirmedCashForecastReportCancellation messages to the report user, such as an investment manager, fund accountant or any other interested party, to cancel a previously sent FundDetailedConfirmedCashForecastReport. Usage The FundDetailedConfirmedCashForecastReportCancellation message is used to cancel an entire FundDetailedConfirmedCashForecastReport message that was previously sent. This message must contain the reference of the message to be cancelled. This message may also contain details of the message to be cancelled, but this is not recommended.
func (*FundDetailedConfirmedCashForecastReportCancellationV02) AddCashForecastReportToBeCancelled ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddCashForecastReportToBeCancelled() *iso20022.FundDetailedConfirmedCashForecastReport2
func (*FundDetailedConfirmedCashForecastReportCancellationV02) AddMessageIdentification ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundDetailedConfirmedCashForecastReportCancellationV02) AddMessagePagination ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddMessagePagination() *iso20022.Pagination
func (*FundDetailedConfirmedCashForecastReportCancellationV02) AddPoolReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportCancellationV02) AddPreviousReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportCancellationV02) AddRelatedReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV02) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedConfirmedCashForecastReportCancellationV03 ¶
type FundDetailedConfirmedCashForecastReportCancellationV03 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference *iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // The FundDetailedConfirmedCashForecastReport to be cancelled. CashForecastReportToBeCancelled *iso20022.FundDetailedConfirmedCashForecastReport3 `xml:"CshFcstRptToBeCanc,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundDetailedConfirmedCashForecastReportCancellation messages to the report user, such as an investment manager, fund accountant or any other interested party, to cancel a previously sent FundDetailedConfirmedCashForecastReport. Usage The FundDetailedConfirmedCashForecastReportCancellation message is used to cancel an entire FundDetailedConfirmedCashForecastReport message that was previously sent. This message must contain the reference of the message to be cancelled. This message may also contain details of the message to be cancelled, but this is not recommended.
func (*FundDetailedConfirmedCashForecastReportCancellationV03) AddCashForecastReportToBeCancelled ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddCashForecastReportToBeCancelled() *iso20022.FundDetailedConfirmedCashForecastReport3
func (*FundDetailedConfirmedCashForecastReportCancellationV03) AddMessageIdentification ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundDetailedConfirmedCashForecastReportCancellationV03) AddMessagePagination ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddMessagePagination() *iso20022.Pagination
func (*FundDetailedConfirmedCashForecastReportCancellationV03) AddPoolReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportCancellationV03) AddPreviousReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportCancellationV03) AddRelatedReference ¶
func (f *FundDetailedConfirmedCashForecastReportCancellationV03) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedConfirmedCashForecastReportV02 ¶
type FundDetailedConfirmedCashForecastReportV02 struct { // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Information related to the cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switches to/from a specified investment fund. The information provided is sorted by pre-defined criteria such as country, institution, currency or user defined criteria. FundCashForecastDetails []*iso20022.FundCashForecast2 `xml:"FndCshFcstDtls"` // Additional information that cannot be captured in the structured elements and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope The FundDetailedConfirmedCashForecastReport message is sent by a report provider, such as a transfer agent or a designated agent of the fund, to a report user, such as an investment manager, a fund accountant or any other interested party. This message is used to report confirmed cash incomings and outgoings, sorted by country, institution or some other criteria defined by the user. This message can be used to report the confirmed cash movements of one or more investment funds, on one or more trade dates. These cash movements may result from, for example, redemption, subscription, switch transactions or dividends. Usage The FundDetailedConfirmedCashForecastReport is used to provide definitive cash movements, i.e., it is sent after the cut-off time and/or the price valuation of the fund.
func (*FundDetailedConfirmedCashForecastReportV02) AddExtension ¶
func (f *FundDetailedConfirmedCashForecastReportV02) AddExtension() *iso20022.Extension1
func (*FundDetailedConfirmedCashForecastReportV02) AddFundCashForecastDetails ¶
func (f *FundDetailedConfirmedCashForecastReportV02) AddFundCashForecastDetails() *iso20022.FundCashForecast2
func (*FundDetailedConfirmedCashForecastReportV02) AddPoolReference ¶
func (f *FundDetailedConfirmedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportV02) AddPreviousReference ¶
func (f *FundDetailedConfirmedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportV02) AddRelatedReference ¶
func (f *FundDetailedConfirmedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedConfirmedCashForecastReportV03 ¶
type FundDetailedConfirmedCashForecastReportV03 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information related to the cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switches to/from a specified investment fund. The information provided is sorted by pre-defined criteria such as country, institution, currency or user defined criteria. FundCashForecastDetails []*iso20022.FundCashForecast4 `xml:"FndCshFcstDtls"` // Net cash as a result of the cash-in and cash-out flows specified in the fund cash forecast details. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that cannot be captured in the structured elements and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundDetailedConfirmedCashForecastReport message to the report user, such as an investment manager, to report the confirmed cash incomings and outgoings, sorted by country, institution name or other criteria defined by the user of one or more investment funds on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundDetailedConfirmedCashForecastReport is used to provide definitive cash movements, i.e., it is sent after the cut-off time and/or the price valuation of the fund. If the price is not yet definitive, then the FundDetailedEstimatedCashForecastReport message must be used. The FundDetailedConfirmedCashForecastReport message is used to report cash movements in or out of a fund, organised by party, such as fund management company, country, currency or by some other criteria defined by the report provider. If the report is used to given the cash-in and cash-out for a party, then additional criteria, such as currency and country, can be specified. In addition, the underlying transaction type for the cash-in or cash-out movement can be specified, as well as information about the cash movement's underlying orders, such as commission and charges.
func (*FundDetailedConfirmedCashForecastReportV03) AddConsolidatedNetCashForecast ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundDetailedConfirmedCashForecastReportV03) AddExtension ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddExtension() *iso20022.Extension1
func (*FundDetailedConfirmedCashForecastReportV03) AddFundCashForecastDetails ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddFundCashForecastDetails() *iso20022.FundCashForecast4
func (*FundDetailedConfirmedCashForecastReportV03) AddMessageIdentification ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundDetailedConfirmedCashForecastReportV03) AddMessagePagination ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
func (*FundDetailedConfirmedCashForecastReportV03) AddPoolReference ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportV03) AddPreviousReference ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportV03) AddRelatedReference ¶
func (f *FundDetailedConfirmedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedConfirmedCashForecastReportV04 ¶
type FundDetailedConfirmedCashForecastReportV04 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information about the fund/sub fund when the report either specifies cash flow for the fund/sub fund or for a share class of the fund/sub fund. FundOrSubFundDetails *iso20022.Fund4 `xml:"FndOrSubFndDtls,omitempty"` // Information related to the cash-in and cash-out flows for a specific trade date as a result of transactions in shares in an investment fund, for example, subscriptions, redemptions or switches. The information provided is sorted by pre-defined criteria such as country, institution, currency or user defined criteria. FundCashForecastDetails []*iso20022.FundCashForecast6 `xml:"FndCshFcstDtls"` // Net cash as a result of the cash-in and cash-out flows specified in the fund cash forecast details. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that cannot be captured in the structured elements and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundDetailedConfirmedCashForecastReport message to the report user, such as an investment manager or pricing agent, to report the confirmed cash incomings and outgoings, sorted by country, institution name or other criteria defined by the user of one or more share classes of an investment fund on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundDetailedConfirmedCashForecastReport is used to provide definitive cash movements, that is, it is sent after the cut-off time and/or the price valuation of the fund. If the price is not yet definitive, then the FundDetailedEstimatedCashForecastReport message must be used. The message structure allows for the following uses: - to provide cash in and cash out amounts for a fund/sub fund and one or more share classes (a FundOrSubFundDetails sequence and one or FundCashForecastDetails sequences are used), - to provide cash in and cash out amounts for one or more share classes (one or more FundCashForecastDetails sequences are used). If the report is to provide cash in and cash out for a fund/sub fund only and not for one or more share classes, then the FundConfirmedCashForecastReport message must be used. The FundDetailedConfirmedCashForecastReport message is used to report cash movements in or out of a fund, organised by party, such as fund management company, country, currency or by some other criteria defined by the report provider. If the report is used to given the cash-in and cash-out for a party, then additional criteria, such as currency and country, can be specified. In addition, the underlying transaction type for the cash-in or cash-out movement can be specified, as well as information about the cash movement's underlying orders, such as commission and charges.
func (*FundDetailedConfirmedCashForecastReportV04) AddConsolidatedNetCashForecast ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundDetailedConfirmedCashForecastReportV04) AddExtension ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddExtension() *iso20022.Extension1
func (*FundDetailedConfirmedCashForecastReportV04) AddFundCashForecastDetails ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddFundCashForecastDetails() *iso20022.FundCashForecast6
func (*FundDetailedConfirmedCashForecastReportV04) AddFundOrSubFundDetails ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund4
func (*FundDetailedConfirmedCashForecastReportV04) AddMessageIdentification ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundDetailedConfirmedCashForecastReportV04) AddMessagePagination ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
func (*FundDetailedConfirmedCashForecastReportV04) AddPoolReference ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportV04) AddPreviousReference ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedConfirmedCashForecastReportV04) AddRelatedReference ¶
func (f *FundDetailedConfirmedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedEstimatedCashForecastReportV02 ¶
type FundDetailedEstimatedCashForecastReportV02 struct { // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Information related to the estimated cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switches to/from a specified investment fund. The information provided is sorted by pre-defined criteria such as country, institution, currency or user defined criteria. // // EstimatedFundCashForecastDetails []*iso20022.EstimatedFundCashForecast2 `xml:"EstmtdFndCshFcstDtls"` // Additional information that can not be captured in the structured fields and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope The FundDetailedEstimatedCashForecastReport message is sent by a report provider, such as a transfer agent or a designated agent of the fund, to a report user, such as an investment manager, a fund accountant or any other interested party. This message is used to report estimated cash incomings and outgoings, sorted by country, institution or some other criteria defined by the user. This message can be used to report the estimated cash movements of one or more investment funds, on one or more trade dates. These cash movements may result from, for example, redemption, subscription, switch transactions or dividends. Usage The FundDetailedEstimatedCashForecastReport is used to provide definitive cash movements, i.e., it is sent prior to the cutoff time and/or the price valuation of the fund.
func (*FundDetailedEstimatedCashForecastReportV02) AddEstimatedFundCashForecastDetails ¶
func (f *FundDetailedEstimatedCashForecastReportV02) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast2
func (*FundDetailedEstimatedCashForecastReportV02) AddExtension ¶
func (f *FundDetailedEstimatedCashForecastReportV02) AddExtension() *iso20022.Extension1
func (*FundDetailedEstimatedCashForecastReportV02) AddPoolReference ¶
func (f *FundDetailedEstimatedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedEstimatedCashForecastReportV02) AddPreviousReference ¶
func (f *FundDetailedEstimatedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedEstimatedCashForecastReportV02) AddRelatedReference ¶
func (f *FundDetailedEstimatedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedEstimatedCashForecastReportV03 ¶
type FundDetailedEstimatedCashForecastReportV03 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information related to the estimated cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switches to/from a specified investment fund. The information provided is sorted by pre-defined criteria such as country, institution, currency or user defined criteria. EstimatedFundCashForecastDetails []*iso20022.EstimatedFundCashForecast4 `xml:"EstmtdFndCshFcstDtls"` // Estimated net cash as a result of the cash-in and cash-out flows specified in the fund cash forecast details. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that can not be captured in the structured fields and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundDetailedEstimatedCashForecastReport message to the report user, such as an investment manager, to report the estimated cash incomings and outgoings, sorted by country, institution name or other criteria defined by the user of one or more investment funds on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundDetailedEstimatedCashForecastReport is used to provide estimated cash movements, i.e., it is sent prior to the cut-off time and/or the price valuation of the fund. If the price is definitive, then the FundDetailedConfirmedCashForecastReport message must be used. The FundDetailedEstimatedCashForecastReport message is used to report cash movements in or out of a fund, organised by party, such as fund management company, country, currency or by some other criteria defined by the report provider. If the report is used to give the cash-in and cash-out for a party, then additional criteria, such as currency and country, can be specified. In addition, the underlying transaction type for the cash-in or cash-out movement can be specified, as well as information about the cash movement's underlying orders, such as commission and charges.
func (*FundDetailedEstimatedCashForecastReportV03) AddConsolidatedNetCashForecast ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundDetailedEstimatedCashForecastReportV03) AddEstimatedFundCashForecastDetails ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast4
func (*FundDetailedEstimatedCashForecastReportV03) AddExtension ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddExtension() *iso20022.Extension1
func (*FundDetailedEstimatedCashForecastReportV03) AddMessageIdentification ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundDetailedEstimatedCashForecastReportV03) AddMessagePagination ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
func (*FundDetailedEstimatedCashForecastReportV03) AddPoolReference ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedEstimatedCashForecastReportV03) AddPreviousReference ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedEstimatedCashForecastReportV03) AddRelatedReference ¶
func (f *FundDetailedEstimatedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
type FundDetailedEstimatedCashForecastReportV04 ¶
type FundDetailedEstimatedCashForecastReportV04 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information about the fund/sub fund when the report either specifies cash flow for the fund/sub fund or for a share class of the fund/sub fund. FundOrSubFundDetails *iso20022.Fund3 `xml:"FndOrSubFndDtls,omitempty"` // Information related to the estimated cash-in and cash-out flows for a specific trade date as a result of transactions in shares in an investment fund, for example, subscriptions, redemptions or switches. The information provided is sorted by pre-defined criteria such as country, institution, currency or user defined criteria. EstimatedFundCashForecastDetails []*iso20022.EstimatedFundCashForecast5 `xml:"EstmtdFndCshFcstDtls"` // Estimated net cash as a result of the cash-in and cash-out flows specified in the fund cash forecast details. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that can not be captured in the structured fields and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundDetailedEstimatedCashForecastReport message to the report user, such as an investment manager or pricing agent, to report the estimated cash incomings and outgoings, sorted by country, institution name or other criteria defined by the user of one or more share classes of an investment fund on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundDetailedEstimatedCashForecastReport is used to provide estimated cash movements, that is, it is sent prior to the cut-off time and/or the price valuation of the fund. The message contains incoming and outgoing cash flows that are estimated, that is, the price has not been applied. If the price is definitive, then the FundDetailedConfirmedCashForecastReport message must be used. The message structure allows for the following uses: - to provide cash in and cash out amounts for a fund/sub fund and one or more share classes (a FundOrSubFundDetails sequence and one or more EstimatedFundCashForecastDetails sequences are used), - to provide cash in and cash out amounts for one or more share classes (one or more EstimatedFundCashForecastDetails sequences are used). If the report is to provide estimated cash in and cash out for a fund/sub fund only and not for one or more share classes, then the FundEstimatedCashForecastReport message must be used. The FundDetailedEstimatedCashForecastReport message is used to report cash movements in or out of a fund, organised by party, such as fund management company, country, currency or by some other criteria defined by the report provider. If the report is used to give the cash-in and cash-out for a party, then additional criteria, such as currency and country, can be specified. In addition, the underlying transaction type for the cash-in or cash-out movement can be specified, as well as information about the cash movement's underlying orders, such as commission and charges.
func (*FundDetailedEstimatedCashForecastReportV04) AddConsolidatedNetCashForecast ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundDetailedEstimatedCashForecastReportV04) AddEstimatedFundCashForecastDetails ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast5
func (*FundDetailedEstimatedCashForecastReportV04) AddExtension ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddExtension() *iso20022.Extension1
func (*FundDetailedEstimatedCashForecastReportV04) AddFundOrSubFundDetails ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund3
func (*FundDetailedEstimatedCashForecastReportV04) AddMessageIdentification ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundDetailedEstimatedCashForecastReportV04) AddMessagePagination ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
func (*FundDetailedEstimatedCashForecastReportV04) AddPoolReference ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
func (*FundDetailedEstimatedCashForecastReportV04) AddPreviousReference ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundDetailedEstimatedCashForecastReportV04) AddRelatedReference ¶
func (f *FundDetailedEstimatedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
type FundEstimatedCashForecastReportV02 ¶
type FundEstimatedCashForecastReportV02 struct { // Collective reference identifying a set of messages. PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Information related to the estimated cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switch to/from a specified investment fund. EstimatedFundCashForecastDetails []*iso20022.EstimatedFundCashForecast1 `xml:"EstmtdFndCshFcstDtls"` // Additional information that can not be captured in the structured fields and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope The FundEstimatedCashForecastReport message is sent by a report provider, such as a transfer agent or a designated agent of the fund, to a report user, such as an investment manager, a fund accountant or any other interested party. This message is used to report the estimated cash incomings and outgoings of one or more investment funds, on one or more trade dates. These cash movements may result from, for example, redemption, subscription, switch transactions or dividends. Usage The FundEstimatedCashForecastReport message is used to report estimated cash movements, i.e., it is sent prior to the cutoff time and/or the price valuation of the fund.
func (*FundEstimatedCashForecastReportV02) AddEstimatedFundCashForecastDetails ¶
func (f *FundEstimatedCashForecastReportV02) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast1
func (*FundEstimatedCashForecastReportV02) AddExtension ¶
func (f *FundEstimatedCashForecastReportV02) AddExtension() *iso20022.Extension1
func (*FundEstimatedCashForecastReportV02) AddPoolReference ¶
func (f *FundEstimatedCashForecastReportV02) AddPoolReference() *iso20022.AdditionalReference3
func (*FundEstimatedCashForecastReportV02) AddPreviousReference ¶
func (f *FundEstimatedCashForecastReportV02) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundEstimatedCashForecastReportV02) AddRelatedReference ¶
func (f *FundEstimatedCashForecastReportV02) AddRelatedReference() *iso20022.AdditionalReference3
type FundEstimatedCashForecastReportV03 ¶
type FundEstimatedCashForecastReportV03 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information related to the estimated cash-in and cash-out flows for a specific trade date as a result of investment fund transactions, for example, subscriptions, redemptions or switch to/from a specified investment fund. EstimatedFundCashForecastDetails []*iso20022.EstimatedFundCashForecast3 `xml:"EstmtdFndCshFcstDtls"` // Estimated net cash as a result of the cash-in and cash-out flows. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that can not be captured in the structured fields and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundEstimatedCashForecastReport message to the report user, such as an investment manager, to report the estimated cash incomings and outgoings of one or more investment funds on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundEstimatedCashForecastReport is used to report estimated cash movements, i.e., it is sent prior to the cut-off time and/or the price valuation of the fund. The FundEstimatedCashForecastReport contains incoming and outgoing cash flows that are estimated, i.e., the price has not been applied. If the price is definitive, then the FundConfirmedCashForecastReport message must be used. This message allows the report provider to report estimated cash movements in or out of a fund, but does not allow the Sender to categorise these movements, for example by country, or to give details of the underlying orders, commission or charges. If the report provider wishes to give detailed information related to estimated cash movements, then the FundDetailedEstimatedCashForecastReport message must be used.
func (*FundEstimatedCashForecastReportV03) AddConsolidatedNetCashForecast ¶
func (f *FundEstimatedCashForecastReportV03) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundEstimatedCashForecastReportV03) AddEstimatedFundCashForecastDetails ¶
func (f *FundEstimatedCashForecastReportV03) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast3
func (*FundEstimatedCashForecastReportV03) AddExtension ¶
func (f *FundEstimatedCashForecastReportV03) AddExtension() *iso20022.Extension1
func (*FundEstimatedCashForecastReportV03) AddMessageIdentification ¶
func (f *FundEstimatedCashForecastReportV03) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundEstimatedCashForecastReportV03) AddMessagePagination ¶
func (f *FundEstimatedCashForecastReportV03) AddMessagePagination() *iso20022.Pagination
func (*FundEstimatedCashForecastReportV03) AddPoolReference ¶
func (f *FundEstimatedCashForecastReportV03) AddPoolReference() *iso20022.AdditionalReference3
func (*FundEstimatedCashForecastReportV03) AddPreviousReference ¶
func (f *FundEstimatedCashForecastReportV03) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundEstimatedCashForecastReportV03) AddRelatedReference ¶
func (f *FundEstimatedCashForecastReportV03) AddRelatedReference() *iso20022.AdditionalReference3
type FundEstimatedCashForecastReportV04 ¶
type FundEstimatedCashForecastReportV04 struct { // Identifies the message. MessageIdentification *iso20022.MessageIdentification1 `xml:"MsgId"` // Collective reference identifying a set of messages PoolReference *iso20022.AdditionalReference3 `xml:"PoolRef,omitempty"` // Reference to a linked message that was previously sent. PreviousReference []*iso20022.AdditionalReference3 `xml:"PrvsRef,omitempty"` // Reference to a linked message that was previously received. RelatedReference []*iso20022.AdditionalReference3 `xml:"RltdRef,omitempty"` // Pagination of the message. MessagePagination *iso20022.Pagination `xml:"MsgPgntn"` // Information about the fund/sub fund when the report either specifies cash flow for the fund/sub fund or for a share class of the fund/sub fund. FundOrSubFundDetails []*iso20022.Fund1 `xml:"FndOrSubFndDtls,omitempty"` // Information related to the estimated cash-in and cash-out flows for a specific trade date as a result of transactions in shares in an investment fund, for example, subscriptions, redemptions or switches. EstimatedFundCashForecastDetails []*iso20022.EstimatedFundCashForecast6 `xml:"EstmtdFndCshFcstDtls,omitempty"` // Estimated net cash as a result of the cash-in and cash-out flows. ConsolidatedNetCashForecast *iso20022.NetCashForecast3 `xml:"CnsltdNetCshFcst,omitempty"` // Additional information that can not be captured in the structured fields and/or any other specific block. Extension []*iso20022.Extension1 `xml:"Xtnsn,omitempty"` }
Scope A report provider, such as a transfer agent, sends the FundEstimatedCashForecastReport message to the report user, such as an investment manager or pricing agent, to report the estimated cash incomings and outgoings of one or more share classes of an investment fund on one or more trade dates. The cash movements may result from, for example, redemption, subscription, switch transactions or reinvestment of dividends. Usage The FundEstimatedCashForecastReport is used to report estimated cash movements, that is, it is sent prior to the cut-off time and/or the price valuation of the fund. The message contains incoming and outgoing cash flows that are estimated, that is, the price has not been applied. If the price is definitive, then the FundConfirmedCashForecastReport message must be used. The message structure allows for the following uses: - to provide cash in and cash out amounts for a fund/sub fund (FundOrSubFundDetails sequence is used), - to provide cash in and cash out amounts for a fund/sub fund and one or more share classes (a FundOrSubFundDetails sequence and one or more EstimatedFundCashForecastDetails sequences are used), - to provide cash in and cash out amounts for one or more share classes (one or more EstimatedFundCashForecastDetails sequences are used). - to provide cash in and cash out amounts for more than one fund/sub fund, and more than one share classes (two or more FundOrSubFundDetails sequences and two or more EstimatedFundCashForecastDetails sequences and used); however, it should be noted that, in this usage, there is no way to determine which share class belongs to which fund/sub fund from the message content itself, which may not be desirable and the use of this kind of combination should be bilaterally agreed. This message allows the report provider to report estimated cash movements in or out of a fund, but does not allow the Sender to categorise these movements, for example by country, or to give details of the underlying orders, commission or charges. If the report provider wishes to give detailed information related to estimated cash movements, then the FundDetailedEstimatedCashForecastReport message must be used.
func (*FundEstimatedCashForecastReportV04) AddConsolidatedNetCashForecast ¶
func (f *FundEstimatedCashForecastReportV04) AddConsolidatedNetCashForecast() *iso20022.NetCashForecast3
func (*FundEstimatedCashForecastReportV04) AddEstimatedFundCashForecastDetails ¶
func (f *FundEstimatedCashForecastReportV04) AddEstimatedFundCashForecastDetails() *iso20022.EstimatedFundCashForecast6
func (*FundEstimatedCashForecastReportV04) AddExtension ¶
func (f *FundEstimatedCashForecastReportV04) AddExtension() *iso20022.Extension1
func (*FundEstimatedCashForecastReportV04) AddFundOrSubFundDetails ¶
func (f *FundEstimatedCashForecastReportV04) AddFundOrSubFundDetails() *iso20022.Fund1
func (*FundEstimatedCashForecastReportV04) AddMessageIdentification ¶
func (f *FundEstimatedCashForecastReportV04) AddMessageIdentification() *iso20022.MessageIdentification1
func (*FundEstimatedCashForecastReportV04) AddMessagePagination ¶
func (f *FundEstimatedCashForecastReportV04) AddMessagePagination() *iso20022.Pagination
func (*FundEstimatedCashForecastReportV04) AddPoolReference ¶
func (f *FundEstimatedCashForecastReportV04) AddPoolReference() *iso20022.AdditionalReference3
func (*FundEstimatedCashForecastReportV04) AddPreviousReference ¶
func (f *FundEstimatedCashForecastReportV04) AddPreviousReference() *iso20022.AdditionalReference3
func (*FundEstimatedCashForecastReportV04) AddRelatedReference ¶
func (f *FundEstimatedCashForecastReportV04) AddRelatedReference() *iso20022.AdditionalReference3
type NetReportV01 ¶
type NetReportV01 struct { // Specifies the meta data associated with the net report. NetReportData *iso20022.NetReportData1 `xml:"NetRptData"` // Describes the participant receiving the net report. NetServiceParticipantIdentification *iso20022.PartyIdentification73Choice `xml:"NetSvcPtcptId"` // Describes the counterparty participant involved in (all of) the obligations of the report. NetServiceCounterpartyIdentification *iso20022.PartyIdentification73Choice `xml:"NetSvcCtrPtyId,omitempty"` // Provides the amount, direct parties or netting groups involved in the obligation. NetObligation []*iso20022.NetObligation1 `xml:"NetOblgtn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
The Net Report message is sent to a participant by a central system to provide details of the of the bi-lateral payment obligations, calculated by the central system per currency.
func (*NetReportV01) AddNetObligation ¶
func (n *NetReportV01) AddNetObligation() *iso20022.NetObligation1
func (*NetReportV01) AddNetReportData ¶
func (n *NetReportV01) AddNetReportData() *iso20022.NetReportData1
func (*NetReportV01) AddNetServiceCounterpartyIdentification ¶
func (n *NetReportV01) AddNetServiceCounterpartyIdentification() *iso20022.PartyIdentification73Choice
func (*NetReportV01) AddNetServiceParticipantIdentification ¶
func (n *NetReportV01) AddNetServiceParticipantIdentification() *iso20022.PartyIdentification73Choice
func (*NetReportV01) AddSupplementaryData ¶
func (n *NetReportV01) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationOfCaseAssignment ¶
type NotificationOfCaseAssignment struct { // Specifies generic information about the notification. // The receiver of a notification is necessarily the party which assigned the case to the sender. Header *iso20022.ReportHeader `xml:"Hdr"` // Identifies the case. Case *iso20022.Case `xml:"Case"` // Identifies the current assignment of the case. // // The Assigner must be the emitter of the notification. // The Assignee must be another Party in the payment chain. Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Information about the type of action taken. Notification *iso20022.CaseForwardingNotification `xml:"Ntfctn"` }
Scope The Notification Of Case Assignment message is sent by a case assignee to a case creator/case assigner. This message is used to inform the case assigner that: - the assignee is reassigning the case to the next agent in the transaction processing chain for further action - the assignee will work on the case himself, without re-assigning it to another party, and therefore indicating that the re-assignment has reached its end-point Usage The Notification Of Case Assignment message is used to notify the case creator or case assigner of further action undertaken by the case assignee in a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Notification Of Case Assignment message - covers one and only one case at a time. If the case assignee needs to inform a case creator or case assigner about several cases, then multiple Notification Of Case Assignment messages must be sent - except in the case where it is used to indicate that an agent is doing the correction himself, this message must be forwarded by all subsequent case assigner(s) until it reaches the case creator - must not be used in place of a Resolution Of Investigation or a Case Status Report message.
func (*NotificationOfCaseAssignment) AddAssignment ¶
func (n *NotificationOfCaseAssignment) AddAssignment() *iso20022.CaseAssignment
func (*NotificationOfCaseAssignment) AddCase ¶
func (n *NotificationOfCaseAssignment) AddCase() *iso20022.Case
func (*NotificationOfCaseAssignment) AddHeader ¶
func (n *NotificationOfCaseAssignment) AddHeader() *iso20022.ReportHeader
func (*NotificationOfCaseAssignment) AddNotification ¶
func (n *NotificationOfCaseAssignment) AddNotification() *iso20022.CaseForwardingNotification
type NotificationOfCaseAssignmentV03 ¶
type NotificationOfCaseAssignmentV03 struct { // Specifies generic information about the notification. // The receiver of a notification must be the party which assigned the case to the sender. Header *iso20022.ReportHeader2 `xml:"Hdr"` // Identifies the investigation case. Case *iso20022.Case2 `xml:"Case"` // 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"` // Information about the type of action taken. Notification *iso20022.CaseForwardingNotification3 `xml:"Ntfctn"` }
Scope The Notification Of Case Assignment message is sent by a case assignee to a case creator/case assigner. This message is used to inform the case assigner that: - the assignee is reassigning the case to the next agent in the transaction processing chain for further action - the assignee will work on the case himself, without re-assigning it to another party, and therefore indicating that the re-assignment has reached its end-point Usage The Notification Of Case Assignment message is used to notify the case creator or case assigner of further action undertaken by the case assignee in a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Notification Of Case Assignment message - covers one and only one case at a time. If the case assignee needs to inform a case creator or case assigner about several cases, then multiple Notification Of Case Assignment messages must be sent - except in the case where it is used to indicate that an agent is doing the correction himself, this message must be forwarded by all subsequent case assigner(s) until it reaches the case creator - must not be used in place of a Resolution Of Investigation or a Case Status Report message When the assignee does not reassign the case to another party (that is responding with a Notification Of Case Assignment message with notification MINE - The case is processed by the assignee), the case assignment should contain the case assignment elements as received in the original query.
func (*NotificationOfCaseAssignmentV03) AddAssignment ¶
func (n *NotificationOfCaseAssignmentV03) AddAssignment() *iso20022.CaseAssignment2
func (*NotificationOfCaseAssignmentV03) AddCase ¶
func (n *NotificationOfCaseAssignmentV03) AddCase() *iso20022.Case2
func (*NotificationOfCaseAssignmentV03) AddHeader ¶
func (n *NotificationOfCaseAssignmentV03) AddHeader() *iso20022.ReportHeader2
func (*NotificationOfCaseAssignmentV03) AddNotification ¶
func (n *NotificationOfCaseAssignmentV03) AddNotification() *iso20022.CaseForwardingNotification3
type NotificationOfCaseAssignmentV04 ¶
type NotificationOfCaseAssignmentV04 struct { // Specifies generic information about the notification. // The receiver of a notification must be the party which assigned the case to the sender. Header *iso20022.ReportHeader4 `xml:"Hdr"` // Identifies the investigation case. Case *iso20022.Case3 `xml:"Case"` // 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"` // Information about the type of action taken. Notification *iso20022.CaseForwardingNotification3 `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 Notification Of Case Assignment message is sent by a case assignee to a case creator/case assigner. This message is used to inform the case assigner that: - the assignee is reassigning the case to the next agent in the transaction processing chain for further action - the assignee will work on the case himself, without re-assigning it to another party, and therefore indicating that the re-assignment has reached its end-point Usage The Notification Of Case Assignment message is used to notify the case creator or case assigner of further action undertaken by the case assignee in a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Notification Of Case Assignment message - covers one and only one case at a time. If the case assignee needs to inform a case creator or case assigner about several cases, then multiple Notification Of Case Assignment messages must be sent - except in the case where it is used to indicate that an agent is doing the correction himself, this message must be forwarded by all subsequent case assigner(s) until it reaches the case creator - must not be used in place of a Resolution Of Investigation or a Case Status Report message When the assignee does not reassign the case to another party (that is responding with a Notification Of Case Assignment message with notification MINE - The case is processed by the assignee), the case assignment should contain the case assignment elements as received in the original query.
func (*NotificationOfCaseAssignmentV04) AddAssignment ¶
func (n *NotificationOfCaseAssignmentV04) AddAssignment() *iso20022.CaseAssignment3
func (*NotificationOfCaseAssignmentV04) AddCase ¶
func (n *NotificationOfCaseAssignmentV04) AddCase() *iso20022.Case3
func (*NotificationOfCaseAssignmentV04) AddHeader ¶
func (n *NotificationOfCaseAssignmentV04) AddHeader() *iso20022.ReportHeader4
func (*NotificationOfCaseAssignmentV04) AddNotification ¶
func (n *NotificationOfCaseAssignmentV04) AddNotification() *iso20022.CaseForwardingNotification3
func (*NotificationOfCaseAssignmentV04) AddSupplementaryData ¶
func (n *NotificationOfCaseAssignmentV04) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveCancellationAdviceV02 ¶
type NotificationToReceiveCancellationAdviceV02 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader43 `xml:"GrpHdr"` // Set of elements used to identify the original notification, to which the cancellation advice refers. OriginalNotification *iso20022.OriginalNotification4 `xml:"OrgnlNtfctn"` }
Scope The NotificationToReceiveCancellationAdvice message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is used to advise the account servicing institution about the cancellation of one or more notifications in a previous NotificationToReceive message. Usage The NotificationToReceiveCancellationAdvice message is used to advise the account servicing institution that the funds are no longer expected. The message can be used in either a direct or a relay scenario.
func (*NotificationToReceiveCancellationAdviceV02) AddGroupHeader ¶
func (n *NotificationToReceiveCancellationAdviceV02) AddGroupHeader() *iso20022.GroupHeader43
func (*NotificationToReceiveCancellationAdviceV02) AddOriginalNotification ¶
func (n *NotificationToReceiveCancellationAdviceV02) AddOriginalNotification() *iso20022.OriginalNotification4
type NotificationToReceiveCancellationAdviceV03 ¶
type NotificationToReceiveCancellationAdviceV03 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader59 `xml:"GrpHdr"` // Set of elements used to identify the original notification, to which the cancellation advice refers. OriginalNotification *iso20022.OriginalNotification6 `xml:"OrgnlNtfctn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The NotificationToReceiveCancellationAdvice message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is used to advise the account servicing institution about the cancellation of one or more notifications in a previous NotificationToReceive message. Usage The NotificationToReceiveCancellationAdvice message is used to advise the account servicing institution that the funds are no longer expected. The message can be used in either a direct or a relay scenario.
func (*NotificationToReceiveCancellationAdviceV03) AddGroupHeader ¶
func (n *NotificationToReceiveCancellationAdviceV03) AddGroupHeader() *iso20022.GroupHeader59
func (*NotificationToReceiveCancellationAdviceV03) AddOriginalNotification ¶
func (n *NotificationToReceiveCancellationAdviceV03) AddOriginalNotification() *iso20022.OriginalNotification6
func (*NotificationToReceiveCancellationAdviceV03) AddSupplementaryData ¶
func (n *NotificationToReceiveCancellationAdviceV03) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveCancellationAdviceV04 ¶
type NotificationToReceiveCancellationAdviceV04 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader59 `xml:"GrpHdr"` // Set of elements used to identify the original notification, to which the cancellation advice refers. OriginalNotification *iso20022.OriginalNotification8 `xml:"OrgnlNtfctn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The NotificationToReceiveCancellationAdvice message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is used to advise the account servicing institution about the cancellation of one or more notifications in a previous NotificationToReceive message. Usage The NotificationToReceiveCancellationAdvice message is used to advise the account servicing institution that the funds are no longer expected. The message can be used in either a direct or a relay scenario.
func (*NotificationToReceiveCancellationAdviceV04) AddGroupHeader ¶
func (n *NotificationToReceiveCancellationAdviceV04) AddGroupHeader() *iso20022.GroupHeader59
func (*NotificationToReceiveCancellationAdviceV04) AddOriginalNotification ¶
func (n *NotificationToReceiveCancellationAdviceV04) AddOriginalNotification() *iso20022.OriginalNotification8
func (*NotificationToReceiveCancellationAdviceV04) AddSupplementaryData ¶
func (n *NotificationToReceiveCancellationAdviceV04) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveCancellationAdviceV05 ¶
type NotificationToReceiveCancellationAdviceV05 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader59 `xml:"GrpHdr"` // Set of elements used to identify the original notification, to which the cancellation advice refers. OriginalNotification *iso20022.OriginalNotification10 `xml:"OrgnlNtfctn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The NotificationToReceiveCancellationAdvice message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is used to advise the account servicing institution about the cancellation of one or more notifications in a previous NotificationToReceive message. Usage The NotificationToReceiveCancellationAdvice message is used to advise the account servicing institution that the funds are no longer expected. The message can be used in either a direct or a relay scenario.
func (*NotificationToReceiveCancellationAdviceV05) AddGroupHeader ¶
func (n *NotificationToReceiveCancellationAdviceV05) AddGroupHeader() *iso20022.GroupHeader59
func (*NotificationToReceiveCancellationAdviceV05) AddOriginalNotification ¶
func (n *NotificationToReceiveCancellationAdviceV05) AddOriginalNotification() *iso20022.OriginalNotification10
func (*NotificationToReceiveCancellationAdviceV05) AddSupplementaryData ¶
func (n *NotificationToReceiveCancellationAdviceV05) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveStatusReportV02 ¶
type NotificationToReceiveStatusReportV02 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader44 `xml:"GrpHdr"` // Set of elements used to identify the original notification and to provide the status. OriginalNotificationAndStatus *iso20022.OriginalNotification3 `xml:"OrgnlNtfctnAndSts"` }
Scope The NotificationToReceiveStatusReport message is sent by an account servicing institution to an account owner or to a party acting on the account owner's behalf. It is used to notify the account owner about the status of one or more expected payments that were advised in a previous NotificationToReceive message. Usage The NotificationToReceiveStatusReport message is sent in response to a NotificationToReceive message and can be used in either a direct or a relay scenario. It is used to advise the account owner of receipt of the funds as expected. It is also used to notify the account owner of non-receipt of funds or of discrepancies in the funds received.
func (*NotificationToReceiveStatusReportV02) AddGroupHeader ¶
func (n *NotificationToReceiveStatusReportV02) AddGroupHeader() *iso20022.GroupHeader44
func (*NotificationToReceiveStatusReportV02) AddOriginalNotificationAndStatus ¶
func (n *NotificationToReceiveStatusReportV02) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification3
type NotificationToReceiveStatusReportV03 ¶
type NotificationToReceiveStatusReportV03 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader60 `xml:"GrpHdr"` // Set of elements used to identify the original notification and to provide the status. OriginalNotificationAndStatus *iso20022.OriginalNotification5 `xml:"OrgnlNtfctnAndSts"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The NotificationToReceiveStatusReport message is sent by an account servicing institution to an account owner or to a party acting on the account owner's behalf. It is used to notify the account owner about the status of one or more expected payments that were advised in a previous NotificationToReceive message. Usage The NotificationToReceiveStatusReport message is sent in response to a NotificationToReceive message and can be used in either a direct or a relay scenario. It is used to advise the account owner of receipt of the funds as expected. It is also used to notify the account owner of non-receipt of funds or of discrepancies in the funds received.
func (*NotificationToReceiveStatusReportV03) AddGroupHeader ¶
func (n *NotificationToReceiveStatusReportV03) AddGroupHeader() *iso20022.GroupHeader60
func (*NotificationToReceiveStatusReportV03) AddOriginalNotificationAndStatus ¶
func (n *NotificationToReceiveStatusReportV03) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification5
func (*NotificationToReceiveStatusReportV03) AddSupplementaryData ¶
func (n *NotificationToReceiveStatusReportV03) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveStatusReportV04 ¶
type NotificationToReceiveStatusReportV04 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader60 `xml:"GrpHdr"` // Set of elements used to identify the original notification and to provide the status. OriginalNotificationAndStatus *iso20022.OriginalNotification7 `xml:"OrgnlNtfctnAndSts"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The NotificationToReceiveStatusReport message is sent by an account servicing institution to an account owner or to a party acting on the account owner's behalf. It is used to notify the account owner about the status of one or more expected payments that were advised in a previous NotificationToReceive message. Usage The NotificationToReceiveStatusReport message is sent in response to a NotificationToReceive message and can be used in either a direct or a relay scenario. It is used to advise the account owner of receipt of the funds as expected. It is also used to notify the account owner of non-receipt of funds or of discrepancies in the funds received.
func (*NotificationToReceiveStatusReportV04) AddGroupHeader ¶
func (n *NotificationToReceiveStatusReportV04) AddGroupHeader() *iso20022.GroupHeader60
func (*NotificationToReceiveStatusReportV04) AddOriginalNotificationAndStatus ¶
func (n *NotificationToReceiveStatusReportV04) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification7
func (*NotificationToReceiveStatusReportV04) AddSupplementaryData ¶
func (n *NotificationToReceiveStatusReportV04) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveStatusReportV05 ¶
type NotificationToReceiveStatusReportV05 struct { // Set of elements used to provide further details on the message. GroupHeader *iso20022.GroupHeader60 `xml:"GrpHdr"` // Set of elements used to identify the original notification and to provide the status. OriginalNotificationAndStatus *iso20022.OriginalNotification9 `xml:"OrgnlNtfctnAndSts"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The NotificationToReceiveStatusReport message is sent by an account servicing institution to an account owner or to a party acting on the account owner's behalf. It is used to notify the account owner about the status of one or more expected payments that were advised in a previous NotificationToReceive message. Usage The NotificationToReceiveStatusReport message is sent in response to a NotificationToReceive message and can be used in either a direct or a relay scenario. It is used to advise the account owner of receipt of the funds as expected. It is also used to notify the account owner of non-receipt of funds or of discrepancies in the funds received.
func (*NotificationToReceiveStatusReportV05) AddGroupHeader ¶
func (n *NotificationToReceiveStatusReportV05) AddGroupHeader() *iso20022.GroupHeader60
func (*NotificationToReceiveStatusReportV05) AddOriginalNotificationAndStatus ¶
func (n *NotificationToReceiveStatusReportV05) AddOriginalNotificationAndStatus() *iso20022.OriginalNotification9
func (*NotificationToReceiveStatusReportV05) AddSupplementaryData ¶
func (n *NotificationToReceiveStatusReportV05) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveV02 ¶
type NotificationToReceiveV02 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 account notification. Notification *iso20022.AccountNotification4 `xml:"Ntfctn"` }
Scope The NotificationToReceive message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is an advance notice that the account servicing institution will receive funds to be credited to the account of the account owner. Usage The NotificationToReceive 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 (*NotificationToReceiveV02) AddGroupHeader ¶
func (n *NotificationToReceiveV02) AddGroupHeader() *iso20022.GroupHeader43
func (*NotificationToReceiveV02) AddNotification ¶
func (n *NotificationToReceiveV02) AddNotification() *iso20022.AccountNotification4
type NotificationToReceiveV03 ¶
type NotificationToReceiveV03 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 account notification. Notification *iso20022.AccountNotification6 `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 NotificationToReceive message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is an advance notice that the account servicing institution will receive funds to be credited to the account of the account owner. Usage The NotificationToReceive 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 (*NotificationToReceiveV03) AddGroupHeader ¶
func (n *NotificationToReceiveV03) AddGroupHeader() *iso20022.GroupHeader59
func (*NotificationToReceiveV03) AddNotification ¶
func (n *NotificationToReceiveV03) AddNotification() *iso20022.AccountNotification6
func (*NotificationToReceiveV03) AddSupplementaryData ¶
func (n *NotificationToReceiveV03) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveV04 ¶
type NotificationToReceiveV04 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 account notification. Notification *iso20022.AccountNotification10 `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 NotificationToReceive message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is an advance notice that the account servicing institution will receive funds to be credited to the account of the account owner. Usage The NotificationToReceive 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 (*NotificationToReceiveV04) AddGroupHeader ¶
func (n *NotificationToReceiveV04) AddGroupHeader() *iso20022.GroupHeader59
func (*NotificationToReceiveV04) AddNotification ¶
func (n *NotificationToReceiveV04) AddNotification() *iso20022.AccountNotification10
func (*NotificationToReceiveV04) AddSupplementaryData ¶
func (n *NotificationToReceiveV04) AddSupplementaryData() *iso20022.SupplementaryData1
type NotificationToReceiveV05 ¶
type NotificationToReceiveV05 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 account notification. Notification *iso20022.AccountNotification13 `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 NotificationToReceive message is sent by an account owner or by a party acting on the account owner's behalf to one of the account owner's account servicing institutions. It is an advance notice that the account servicing institution will receive funds to be credited to the account of the account owner. Usage The NotificationToReceive 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 (*NotificationToReceiveV05) AddGroupHeader ¶
func (n *NotificationToReceiveV05) AddGroupHeader() *iso20022.GroupHeader59
func (*NotificationToReceiveV05) AddNotification ¶
func (n *NotificationToReceiveV05) AddNotification() *iso20022.AccountNotification13
func (*NotificationToReceiveV05) AddSupplementaryData ¶
func (n *NotificationToReceiveV05) AddSupplementaryData() *iso20022.SupplementaryData1
type PayInCallV02 ¶
type PayInCallV02 struct { // Party for which the PayInCall is generated. PartyIdentification *iso20022.PartyIdentification73Choice `xml:"PtyId"` // Contains the report generation information and the report items. ReportData *iso20022.ReportData5 `xml:"RptData"` // To indicate the requested CLS Settlement Session that the related trade is part of. SettlementSessionIdentifier *iso20022.Exact4AlphaNumericText `xml:"SttlmSsnIdr,omitempty"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
The PayInCall message is sent by a central settlement system to request additional funding from a settlement member impacted by a failure situation.
func (*PayInCallV02) AddPartyIdentification ¶
func (p *PayInCallV02) AddPartyIdentification() *iso20022.PartyIdentification73Choice
func (*PayInCallV02) AddReportData ¶
func (p *PayInCallV02) AddReportData() *iso20022.ReportData5
func (*PayInCallV02) AddSupplementaryData ¶
func (p *PayInCallV02) AddSupplementaryData() *iso20022.SupplementaryData1
func (*PayInCallV02) SetSettlementSessionIdentifier ¶
func (p *PayInCallV02) SetSettlementSessionIdentifier(value string)
type PayInEventAcknowledgementV02 ¶
type PayInEventAcknowledgementV02 struct { // Unique and unambiguous identifier for the message, as assigned by the sender. MessageIdentification *iso20022.Max35Text `xml:"MsgId"` // To indicate the requested CLS Settlement Session that the related trade is part of. SettlementSessionIdentifier *iso20022.Exact4AlphaNumericText `xml:"SttlmSsnIdr,omitempty"` // Details of the pay in schedule or pay in call being acknowledged . AcknowledgementDetails *iso20022.AcknowledgementDetails1Choice `xml:"AckDtls"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
The PayInEventAcknowledgement message is sent by a participant of a central system to the central system to confirm a PayInSchedule or a PayInCall has been received.
func (*PayInEventAcknowledgementV02) AddAcknowledgementDetails ¶
func (p *PayInEventAcknowledgementV02) AddAcknowledgementDetails() *iso20022.AcknowledgementDetails1Choice
func (*PayInEventAcknowledgementV02) AddSupplementaryData ¶
func (p *PayInEventAcknowledgementV02) AddSupplementaryData() *iso20022.SupplementaryData1
func (*PayInEventAcknowledgementV02) SetMessageIdentification ¶
func (p *PayInEventAcknowledgementV02) SetMessageIdentification(value string)
func (*PayInEventAcknowledgementV02) SetSettlementSessionIdentifier ¶
func (p *PayInEventAcknowledgementV02) SetSettlementSessionIdentifier(value string)
type PayInScheduleV03 ¶
type PayInScheduleV03 struct { // Party for which the pay-in schedule is generated. PartyIdentification *iso20022.PartyIdentification73Choice `xml:"PtyId"` // General information applicable to the report. ReportData *iso20022.ReportData4 `xml:"RptData"` // Projected net position for all currencies, projected long for the value date. PayInScheduleLongBalance []*iso20022.BalanceStatus2 `xml:"PayInSchdlLngBal,omitempty"` // Currency and total amount to be paid in by the corresponding deadline. PayInScheduleItem []*iso20022.PayInScheduleItems1 `xml:"PayInSchdlItm,omitempty"` // Factors used in the calculation of the pay-in schedule. PayInFactors *iso20022.PayInFactors1 `xml:"PayInFctrs,omitempty"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
The PayInSchedule message is sent by a central settlement system to the participant to provide notification of a series of timed payments scheduled for each currency at the time and date of the schedule generation. The central settlement system may send information about how the timed payments have been calculated.
func (*PayInScheduleV03) AddPartyIdentification ¶
func (p *PayInScheduleV03) AddPartyIdentification() *iso20022.PartyIdentification73Choice
func (*PayInScheduleV03) AddPayInFactors ¶
func (p *PayInScheduleV03) AddPayInFactors() *iso20022.PayInFactors1
func (*PayInScheduleV03) AddPayInScheduleItem ¶
func (p *PayInScheduleV03) AddPayInScheduleItem() *iso20022.PayInScheduleItems1
func (*PayInScheduleV03) AddPayInScheduleLongBalance ¶
func (p *PayInScheduleV03) AddPayInScheduleLongBalance() *iso20022.BalanceStatus2
func (*PayInScheduleV03) AddReportData ¶
func (p *PayInScheduleV03) AddReportData() *iso20022.ReportData4
func (*PayInScheduleV03) AddSupplementaryData ¶
func (p *PayInScheduleV03) AddSupplementaryData() *iso20022.SupplementaryData1
type ProprietaryFormatInvestigationV02 ¶
type ProprietaryFormatInvestigationV02 struct { // Identifies the assignment of an investigation case from an assigner to an assignee. // Usage Rule: 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"` // Proprietary information. ProprietaryData *iso20022.ProprietaryData4 `xml:"PrtryData"` }
Scope The Proprietary Format Investigation message type is used by financial institutions, with their own offices, and/or with other financial institutions with which they have established bilateral agreements. Usage The user should ensure that an existing standard message cannot be used before using the proprietary message. As defined in the scope, this ProprietaryFormatInvestigation message may only be used when bilaterally agreed. It is used as an envelope for a non standard message and provides means to manage an exception or investigation which falls outside the scope or capability of any other formatted message.
func (*ProprietaryFormatInvestigationV02) AddAssignment ¶
func (p *ProprietaryFormatInvestigationV02) AddAssignment() *iso20022.CaseAssignment2
func (*ProprietaryFormatInvestigationV02) AddCase ¶
func (p *ProprietaryFormatInvestigationV02) AddCase() *iso20022.Case2
func (*ProprietaryFormatInvestigationV02) AddProprietaryData ¶
func (p *ProprietaryFormatInvestigationV02) AddProprietaryData() *iso20022.ProprietaryData4
type ProprietaryFormatInvestigationV03 ¶
type ProprietaryFormatInvestigationV03 struct { // Identifies the assignment of an investigation case from an assigner to an assignee. // Usage Rule: 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"` // Proprietary information. ProprietaryData *iso20022.ProprietaryData4 `xml:"PrtryData"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Proprietary Format Investigation message type is used by financial institutions, with their own offices, and/or with other financial institutions with which they have established bilateral agreements. Usage The user should ensure that an existing standard message cannot be used before using the proprietary message. As defined in the scope, this ProprietaryFormatInvestigation message may only be used when bilaterally agreed. It is used as an envelope for a non standard message and provides means to manage an exception or investigation which falls outside the scope or capability of any other formatted message. The ProprietaryData element must contain a well formed XML document. This means XML special characters such as '<' must be used in a way that is consistent with XML well-formedness criteria.
func (*ProprietaryFormatInvestigationV03) AddAssignment ¶
func (p *ProprietaryFormatInvestigationV03) AddAssignment() *iso20022.CaseAssignment3
func (*ProprietaryFormatInvestigationV03) AddCase ¶
func (p *ProprietaryFormatInvestigationV03) AddCase() *iso20022.Case3
func (*ProprietaryFormatInvestigationV03) AddProprietaryData ¶
func (p *ProprietaryFormatInvestigationV03) AddProprietaryData() *iso20022.ProprietaryData4
func (*ProprietaryFormatInvestigationV03) AddSupplementaryData ¶
func (p *ProprietaryFormatInvestigationV03) AddSupplementaryData() *iso20022.SupplementaryData1
type RejectCaseAssignment ¶
type RejectCaseAssignment struct { // Identifies the assignment. Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Identifies the case. Case *iso20022.Case `xml:"Case"` // Specifies the reason for not accepting a Case. Justification *iso20022.CaseAssignmentRejectionJustification `xml:"Justfn"` }
Scope The Reject Case Assignment message is sent by a case assignee to a case creator or case assigner to reject a case given to him. Usage The Reject Case Assignment message is used to notify the case creator or case assigner the rejection of an assignment by the case assignee in a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case Rejecting a case assignment occurs when the case assignee is unable to trace the original payment instruction or when the case assignee is unable, or does not have authority, to process the assigned case. The Reject Case Assignment message covers one and only one case at a time. If the case assignee needs to reject several case assignments, then multiple Reject Case Assignment messages must be sent. The Reject Case Assignment message must be forwarded by all subsequent case assignee(s) until it reaches the case assigner. The Reject Case Assignment message must not be used in place of a Resolution Of Investigation or Case Status Report message.
func (*RejectCaseAssignment) AddAssignment ¶
func (r *RejectCaseAssignment) AddAssignment() *iso20022.CaseAssignment
func (*RejectCaseAssignment) AddCase ¶
func (r *RejectCaseAssignment) AddCase() *iso20022.Case
func (*RejectCaseAssignment) AddJustification ¶
func (r *RejectCaseAssignment) AddJustification() *iso20022.CaseAssignmentRejectionJustification
type RejectInvestigationV03 ¶
type RejectInvestigationV03 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"` // Specifies the reason for the rejection of an investigation. Justification *iso20022.InvestigationRejectionJustification1 `xml:"Justfn"` }
Scope The Reject Investigation message is sent by a case assignee to a case creator or case assigner to reject a case given to him. Usage The Reject Investigation message is used to notify the case creator or case assigner the rejection of an assignment by the case assignee in a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case Rejecting a case assignment occurs when: - the case assignee is unable to trace the original payment instruction - the case assignee is unable, or does not have authority, to process the assigned case (indicate "You have by-passed a party", - the case assignee has received a non expected message, and rejects the message with a wrong message indicator - the case assignee has not yet received the Resolution Of Investigation message and the case has already been reopened - the case assignee has rejects an non-cash related query The Reject Investigation message covers one and only one case at a time. If the case assignee needs to reject several case assignments, then multiple Reject Investigation messages must be sent. The Reject Investigation message must be forwarded by all subsequent case assignee(s) until it reaches the case assigner and must not be used in place of a Resolution Of Investigation or Case Status Report message.
func (*RejectInvestigationV03) AddAssignment ¶
func (r *RejectInvestigationV03) AddAssignment() *iso20022.CaseAssignment2
func (*RejectInvestigationV03) AddCase ¶
func (r *RejectInvestigationV03) AddCase() *iso20022.Case2
func (*RejectInvestigationV03) AddJustification ¶
func (r *RejectInvestigationV03) AddJustification() *iso20022.InvestigationRejectionJustification1
type RejectInvestigationV04 ¶
type RejectInvestigationV04 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"` // Specifies the reason for the rejection of an investigation. Justification *iso20022.InvestigationRejectionJustification1 `xml:"Justfn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Reject Investigation message is sent by a case assignee to a case creator or case assigner to reject a case given to him. Usage The Reject Investigation message is used to notify the case creator or case assigner the rejection of an assignment by the case assignee in a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case Rejecting a case assignment occurs when: - the case assignee is unable to trace the original payment instruction - the case assignee is unable, or does not have authority, to process the assigned case (indicate "You have by-passed a party", - the case assignee has received a non expected message, and rejects the message with a wrong message indicator - the case assignee has not yet received the Resolution Of Investigation message and the case has already been reopened - the case assignee has rejects an non-cash related query The Reject Investigation message covers one and only one case at a time. If the case assignee needs to reject several case assignments, then multiple Reject Investigation messages must be sent. The Reject Investigation message must be forwarded by all subsequent case assignee(s) until it reaches the case assigner and must not be used in place of a Resolution Of Investigation or Case Status Report message.
func (*RejectInvestigationV04) AddAssignment ¶
func (r *RejectInvestigationV04) AddAssignment() *iso20022.CaseAssignment3
func (*RejectInvestigationV04) AddCase ¶
func (r *RejectInvestigationV04) AddCase() *iso20022.Case3
func (*RejectInvestigationV04) AddJustification ¶
func (r *RejectInvestigationV04) AddJustification() *iso20022.InvestigationRejectionJustification1
func (*RejectInvestigationV04) AddSupplementaryData ¶
func (r *RejectInvestigationV04) AddSupplementaryData() *iso20022.SupplementaryData1
type RequestForDuplicateInstruction ¶
type RequestForDuplicateInstruction struct { // Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Case *iso20022.Case `xml:"Case"` }
Scope The Request For Duplicate message is sent by the case assignee to the case creator or case assigner. This message is used to request a copy of the original payment instruction considered in the case. Usage The Request For Duplicate message: - must be answered with a Duplicate message - must be used when a case assignee requests a copy of the original payment instruction. This occurs, for example, when the case assignee cannot trace the payment instruction based on the elements mentioned in the case assignment message - covers one and only one instruction at a time. If several payment instruction copies are needed by the case assignee, then multiple Request For Duplicate messages must be sent - must be used exclusively between the case assignee and its case creator/case assigner
func (*RequestForDuplicateInstruction) AddAssignment ¶
func (r *RequestForDuplicateInstruction) AddAssignment() *iso20022.CaseAssignment
func (*RequestForDuplicateInstruction) AddCase ¶
func (r *RequestForDuplicateInstruction) AddCase() *iso20022.Case
type RequestForDuplicateV03 ¶
type RequestForDuplicateV03 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 Request For Duplicate message is sent by the case assignee to the case creator or case assigner. This message is used to request a copy of the original payment instruction considered in the case. Usage The Request For Duplicate message: - must be answered with a Duplicate message - must be used when a case assignee requests a copy of the original payment instruction. This occurs, for example, when the case assignee cannot trace the payment instruction based on the elements mentioned in the case assignment message - covers one and only one instruction at a time. If several payment instruction copies are needed by the case assignee, then multiple Request For Duplicate messages must be sent - must be used exclusively between the case assignee and its case creator/case assigner
func (*RequestForDuplicateV03) AddAssignment ¶
func (r *RequestForDuplicateV03) AddAssignment() *iso20022.CaseAssignment2
func (*RequestForDuplicateV03) AddCase ¶
func (r *RequestForDuplicateV03) AddCase() *iso20022.Case2
type RequestForDuplicateV04 ¶
type RequestForDuplicateV04 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 Request For Duplicate message is sent by the case assignee to the case creator or case assigner. This message is used to request a copy of the original payment instruction considered in the case. Usage The Request For Duplicate message: - must be answered with a Duplicate message - must be used when a case assignee requests a copy of the original payment instruction. This occurs, for example, when the case assignee cannot trace the payment instruction based on the elements mentioned in the case assignment message - covers one and only one instruction at a time. If several payment instruction copies are needed by the case assignee, then multiple Request For Duplicate messages must be sent - must be used exclusively between the case assignee and its case creator/case assigner
func (*RequestForDuplicateV04) AddAssignment ¶
func (r *RequestForDuplicateV04) AddAssignment() *iso20022.CaseAssignment3
func (*RequestForDuplicateV04) AddCase ¶
func (r *RequestForDuplicateV04) AddCase() *iso20022.Case3
func (*RequestForDuplicateV04) AddSupplementaryData ¶
func (r *RequestForDuplicateV04) AddSupplementaryData() *iso20022.SupplementaryData1
type RequestToCancelPayment ¶
type RequestToCancelPayment struct { // Identifies the assignment of a case from an assigner to an assignee. Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Identifies the case. Case *iso20022.Case `xml:"Case"` // Identifies the payment instruction to be cancelled. Underlying *iso20022.PaymentInstructionExtract `xml:"Undrlyg"` // Defines the reason for requesting the cancellation. Justification *iso20022.DebitAuthorisationDetails `xml:"Justfn"` }
Scope The Request To Cancel Payment 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. Usage The Request To Cancel Payment 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 Case Assignment 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 Request To Cancel Payment message concerns one and only one original payment instruction at a time. If several original payment instructions need to be cancelled, then multiple Request To Cancel Payment messages must be sent. 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 request to cancel payment case may end with a Debit Authorisation Request message sent to the creditor by its account servicing institution. The Request To Cancel Payment 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 Request To Modify Payment message and the element ReopenCaseIndication is set to 'Yes' or 'true'.
func (*RequestToCancelPayment) AddAssignment ¶
func (r *RequestToCancelPayment) AddAssignment() *iso20022.CaseAssignment
func (*RequestToCancelPayment) AddCase ¶
func (r *RequestToCancelPayment) AddCase() *iso20022.Case
func (*RequestToCancelPayment) AddJustification ¶
func (r *RequestToCancelPayment) AddJustification() *iso20022.DebitAuthorisationDetails
func (*RequestToCancelPayment) AddUnderlying ¶
func (r *RequestToCancelPayment) AddUnderlying() *iso20022.PaymentInstructionExtract
type RequestToModifyPayment ¶
type RequestToModifyPayment struct { // Identifies the assignment. Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Identifies the case. Case *iso20022.Case `xml:"Case"` // Identifies the Payment Transaction to modify. Underlying *iso20022.PaymentInstructionExtract `xml:"Undrlyg"` // Modification *iso20022.RequestedModification `xml:"Mod"` }
Scope The Request To Modify Payment message is sent by a case creator/case assigner to a case assignee. This message is used to request the modification of characteristics of an original payment instruction. Usage The Request To Modify Payment message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested modification - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested modification but fails to do so (too late, irrevocable instruction, one requested element cannot be modified, ...) - Reject Case Assignment message when the case assignee is unable or not authorised to perform the requested modification - 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. The Request To Modify Payment message covers one and only one original instruction at a time. If several original payment instructions need to be modified, then multiple Request To Modify Payment messages must be sent. The Request To Modify Payment message can be sent to request the modification of one or several elements of the original payment instruction. If many elements need to be modified, it is recommended to cancel the original payment instruction and initiate a new one. The Request To Modify Payment must be processed on an all or nothing basis. If one of the elements to be modified cannot be altered, the assignment must be rejected in full by means of a negative Resolution Of Investigation message. (See section on Resolution Of Investigation for more details.) The Request To Modify Payment message must never be sent to request the modification of the currency of the original payment instruction. If the currency is wrong, use Request To Cancel Payment message to cancel it and issue and a new payment instruction. The Request To Modify Payment message may be forwarded to subsequent case assignee(s). When a Request To Modify Payment message is used to decrease the amount of the original payment instruction, the modification will trigger a return of funds from the case assignee to the case creator. The assignee may indicate, within the Resolution Of Investigation message, the amount to be returned, the date it is or will be returned and the channel through which the return will be done. The Request To Modify Payment message must never be sent to request the increase of the amount of the original payment instruction. To increase the amount in a payment, the debtor can do one of the following: - Cancel the first payment using a Request To Cancel Payment message and make a new payment with a higher and correct amount. - Simply send a second payment with the supplementary amount. Depending on the requested modification(s) and the processing stage of the original payment instruction, the processing of a request to modify payment case may end with one of the following: - an Additional Payment Information message sent to the creditor of the original payment instruction - a Debit Authorisation Request message sent to the creditor of the original payment instruction - a Request To Cancel Payment message sent to a subsequent case assignee The Request To Modify Payment message can be sent to correct characteristics of an original payment instruction following receipt of an Unable To Apply message. In this scenario, the case identification will remain the same. The RequestToModifyPayment message has the following main characteristics: The case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s). Lowering the amount of an original payment instruction for which cover is provided by a separate instruction will systematically mean the modification of the whole transaction, including the cover. The case assignee performing the amount modification must initiate the return of funds in excess to the case creator. The modification of the agent's or agents' information on an original payment instruction for which cover is provided by a separate instruction will systematically mean the whole transaction is modified, i.e., the cover is executed through the agent(s) mentioned in the Request To Modify Payment message. The cover payment must not be modified separately. The modification of a payment instruction can be initiated by either the debtor or any subsequent agent in the payment processing chain. The case creator provides the information to be modified in line with agreements made with the case assignee. If the case assignee needs in turn to assign the case to a subsequent case assignee, the requested modification(s) must be in line with the agreement made with the next case assignee and a Notification Of Case Assignment message must be sent to the case assigner. Otherwise, the request to modify payment case must be rejected (by means of a negative Resolution Of Investigation message).
func (*RequestToModifyPayment) AddAssignment ¶
func (r *RequestToModifyPayment) AddAssignment() *iso20022.CaseAssignment
func (*RequestToModifyPayment) AddCase ¶
func (r *RequestToModifyPayment) AddCase() *iso20022.Case
func (*RequestToModifyPayment) AddModification ¶
func (r *RequestToModifyPayment) AddModification() *iso20022.RequestedModification
func (*RequestToModifyPayment) AddUnderlying ¶
func (r *RequestToModifyPayment) AddUnderlying() *iso20022.PaymentInstructionExtract
type RequestToModifyPaymentV01 ¶
type RequestToModifyPaymentV01 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 transaction to be modified. Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"` // Identifies the list of modifications requested. Modification *iso20022.RequestedModification3 `xml:"Mod"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Request To Modify Payment message is sent by a case creator/case assigner to a case assignee. This message is used to request the modification of characteristics of an original payment instruction. Usage The Request To Modify Payment message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested modification - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested modification but fails to do so (too late, irrevocable instruction, one requested element cannot be modified, ...) - Reject Case Assignment message when the case assignee is unable or not authorised to perform the requested modification - 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. The Request To Modify Payment message covers one and only one original instruction at a time. If several original payment instructions need to be modified, then multiple Request To Modify Payment messages must be sent. The Request To Modify Payment message can be sent to request the modification of one or several elements of the original payment instruction. If many elements need to be modified, it is recommended to cancel the original payment instruction and initiate a new one. The Request To Modify Payment must be processed on an all or nothing basis. If one of the elements to be modified cannot be altered, the assignment must be rejected in full by means of a negative Resolution Of Investigation message. (See section on Resolution Of Investigation for more details.) The Request To Modify Payment message must never be sent to request the modification of the currency of the original payment instruction. If the currency is wrong, use Request To Cancel Payment message to cancel it and issue and a new payment instruction. The Request To Modify Payment message may be forwarded to subsequent case assignee(s). When a Request To Modify Payment message is used to decrease the amount of the original payment instruction, the modification will trigger a return of funds from the case assignee to the case creator. The assignee may indicate, within the Resolution Of Investigation message, the amount to be returned, the date it is or will be returned and the channel through which the return will be done. The Request To Modify Payment message must never be sent to request the increase of the amount of the original payment instruction. To increase the amount in a payment, the debtor can do one of the following: - Cancel the first payment using a Request To Cancel Payment message and make a new payment with a higher and correct amount. - Simply send a second payment with the supplementary amount. Depending on the requested modification(s) and the processing stage of the original payment instruction, the processing of a request to modify payment case may end with one of the following: - an Additional Payment Information message sent to the creditor of the original payment instruction - a Debit Authorisation Request message sent to the creditor of the original payment instruction - a Request To Cancel Payment message sent to a subsequent case assignee The Request To Modify Payment message can be sent to correct characteristics of an original payment instruction following receipt of an Unable To Apply message. In this scenario, the case identification will remain the same. The RequestToModifyPayment message has the following main characteristics: The case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s). Lowering the amount of an original payment instruction for which cover is provided by a separate instruction will systematically mean the modification of the whole transaction, including the cover. The case assignee performing the amount modification must initiate the return of funds in excess to the case creator. The modification of the agent's or agents' information on an original payment instruction for which cover is provided by a separate instruction will systematically mean the whole transaction is modified, i.e., the cover is executed through the agent(s) mentioned in the Request To Modify Payment message. The cover payment must not be modified separately. The modification of a payment instruction can be initiated by either the debtor or any subsequent agent in the payment processing chain. The case creator provides the information to be modified in line with agreements made with the case assignee. If the case assignee needs in turn to assign the case to a subsequent case assignee, the requested modification(s) must be in line with the agreement made with the next case assignee and a Notification Of Case Assignment message must be sent to the case assigner. Otherwise, the request to modify payment case must be rejected (by means of a negative Resolution Of Investigation message).
func (*RequestToModifyPaymentV01) AddAssignment ¶
func (r *RequestToModifyPaymentV01) AddAssignment() *iso20022.CaseAssignment3
func (*RequestToModifyPaymentV01) AddCase ¶
func (r *RequestToModifyPaymentV01) AddCase() *iso20022.Case3
func (*RequestToModifyPaymentV01) AddModification ¶
func (r *RequestToModifyPaymentV01) AddModification() *iso20022.RequestedModification3
func (*RequestToModifyPaymentV01) AddSupplementaryData ¶
func (r *RequestToModifyPaymentV01) AddSupplementaryData() *iso20022.SupplementaryData1
func (*RequestToModifyPaymentV01) AddUnderlying ¶
func (r *RequestToModifyPaymentV01) AddUnderlying() *iso20022.UnderlyingTransaction2Choice
type RequestToModifyPaymentV02 ¶
type RequestToModifyPaymentV02 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 transaction to be modified. Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"` // Identifies the list of modifications requested. Modification *iso20022.RequestedModification4 `xml:"Mod"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Request To Modify Payment message is sent by a case creator/case assigner to a case assignee. This message is used to request the modification of characteristics of an original payment instruction. Usage The Request To Modify Payment message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested modification - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested modification but fails to do so (too late, irrevocable instruction, one requested element cannot be modified, ...) - Reject Case Assignment message when the case assignee is unable or not authorised to perform the requested modification - 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. The Request To Modify Payment message covers one and only one original instruction at a time. If several original payment instructions need to be modified, then multiple Request To Modify Payment messages must be sent. The Request To Modify Payment message can be sent to request the modification of one or several elements of the original payment instruction. If many elements need to be modified, it is recommended to cancel the original payment instruction and initiate a new one. The Request To Modify Payment must be processed on an all or nothing basis. If one of the elements to be modified cannot be altered, the assignment must be rejected in full by means of a negative Resolution Of Investigation message. (See section on Resolution Of Investigation for more details.) The Request To Modify Payment message must never be sent to request the modification of the currency of the original payment instruction. If the currency is wrong, use Request To Cancel Payment message to cancel it and issue and a new payment instruction. The Request To Modify Payment message may be forwarded to subsequent case assignee(s). When a Request To Modify Payment message is used to decrease the amount of the original payment instruction, the modification will trigger a return of funds from the case assignee to the case creator. The assignee may indicate, within the Resolution Of Investigation message, the amount to be returned, the date it is or will be returned and the channel through which the return will be done. The Request To Modify Payment message must never be sent to request the increase of the amount of the original payment instruction. To increase the amount in a payment, the debtor can do one of the following: - Cancel the first payment using a Request To Cancel Payment message and make a new payment with a higher and correct amount. - Simply send a second payment with the supplementary amount. Depending on the requested modification(s) and the processing stage of the original payment instruction, the processing of a request to modify payment case may end with one of the following: - an Additional Payment Information message sent to the creditor of the original payment instruction - a Debit Authorisation Request message sent to the creditor of the original payment instruction - a Request To Cancel Payment message sent to a subsequent case assignee The Request To Modify Payment message can be sent to correct characteristics of an original payment instruction following receipt of an Unable To Apply message. In this scenario, the case identification will remain the same. The RequestToModifyPayment message has the following main characteristics: The case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s). Lowering the amount of an original payment instruction for which cover is provided by a separate instruction will systematically mean the modification of the whole transaction, including the cover. The case assignee performing the amount modification must initiate the return of funds in excess to the case creator. The modification of the agent's or agents' information on an original payment instruction for which cover is provided by a separate instruction will systematically mean the whole transaction is modified, i.e., the cover is executed through the agent(s) mentioned in the Request To Modify Payment message. The cover payment must not be modified separately. The modification of a payment instruction can be initiated by either the debtor or any subsequent agent in the payment processing chain. The case creator provides the information to be modified in line with agreements made with the case assignee. If the case assignee needs in turn to assign the case to a subsequent case assignee, the requested modification(s) must be in line with the agreement made with the next case assignee and a Notification Of Case Assignment message must be sent to the case assigner. Otherwise, the request to modify payment case must be rejected (by means of a negative Resolution Of Investigation message).
func (*RequestToModifyPaymentV02) AddAssignment ¶
func (r *RequestToModifyPaymentV02) AddAssignment() *iso20022.CaseAssignment3
func (*RequestToModifyPaymentV02) AddCase ¶
func (r *RequestToModifyPaymentV02) AddCase() *iso20022.Case3
func (*RequestToModifyPaymentV02) AddModification ¶
func (r *RequestToModifyPaymentV02) AddModification() *iso20022.RequestedModification4
func (*RequestToModifyPaymentV02) AddSupplementaryData ¶
func (r *RequestToModifyPaymentV02) AddSupplementaryData() *iso20022.SupplementaryData1
func (*RequestToModifyPaymentV02) AddUnderlying ¶
func (r *RequestToModifyPaymentV02) AddUnderlying() *iso20022.UnderlyingTransaction2Choice
type RequestToModifyPaymentV04 ¶
type RequestToModifyPaymentV04 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 transaction to be modified. Underlying *iso20022.UnderlyingTransaction3Choice `xml:"Undrlyg"` // Identifies the list of modifications requested. Modification *iso20022.RequestedModification6 `xml:"Mod"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The RequestToModifyPayment message is sent by a case creator/case assigner to a case assignee. This message is used to request the modification of characteristics of an original payment instruction. Usage The RequestToModifyPayment message must be answered with a: - Resolution Of Investigation message with a positive final outcome when the case assignee can perform the requested modification - Resolution Of Investigation message with a negative final outcome when the case assignee may perform the requested modification but fails to do so (too late, irrevocable instruction, one requested element cannot be modified, ...) - Reject Case Assignment message when the case assignee is unable or not authorised to perform the requested modification - 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. The Request To Modify Payment message covers one and only one original instruction at a time. If several original payment instructions need to be modified, then multiple Request To Modify Payment messages must be sent. The Request To Modify Payment message can be sent to request the modification of one or several elements of the original payment instruction. If many elements need to be modified, it is recommended to cancel the original payment instruction and initiate a new one. The Request To Modify Payment must be processed on an all or nothing basis. If one of the elements to be modified cannot be altered, the assignment must be rejected in full by means of a negative Resolution Of Investigation message. (See section on Resolution Of Investigation for more details.) The Request To Modify Payment message must never be sent to request the modification of the currency of the original payment instruction. If the currency is wrong, use Request To Cancel Payment message to cancel it and issue and a new payment instruction. The Request To Modify Payment message may be forwarded to subsequent case assignee(s). When a Request To Modify Payment message is used to decrease the amount of the original payment instruction, the modification will trigger a return of funds from the case assignee to the case creator. The assignee may indicate, within the Resolution Of Investigation message, the amount to be returned, the date it is or will be returned and the channel through which the return will be done. The Request To Modify Payment message must never be sent to request the increase of the amount of the original payment instruction. To increase the amount in a payment, the debtor can do one of the following: - Cancel the first payment using a Request To Cancel Payment message and make a new payment with a higher and correct amount. - Simply send a second payment with the supplementary amount. Depending on the requested modification(s) and the processing stage of the original payment instruction, the processing of a request to modify payment case may end with one of the following: - an Additional Payment Information message sent to the creditor of the original payment instruction - a Debit Authorisation Request message sent to the creditor of the original payment instruction - a Request To Cancel Payment message sent to a subsequent case assignee The Request To Modify Payment message can be sent to correct characteristics of an original payment instruction following receipt of an Unable To Apply message. In this scenario, the case identification will remain the same. The RequestToModifyPayment message has the following main characteristics: The case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s). Lowering the amount of an original payment instruction for which cover is provided by a separate instruction will systematically mean the modification of the whole transaction, including the cover. The case assignee performing the amount modification must initiate the return of funds in excess to the case creator. The modification of the agent's or agents' information on an original payment instruction for which cover is provided by a separate instruction will systematically mean the whole transaction is modified, i.e., the cover is executed through the agent(s) mentioned in the Request To Modify Payment message. The cover payment must not be modified separately. The modification of a payment instruction can be initiated by either the debtor or any subsequent agent in the payment processing chain. The case creator provides the information to be modified in line with agreements made with the case assignee. If the case assignee needs in turn to assign the case to a subsequent case assignee, the requested modification(s) must be in line with the agreement made with the next case assignee and a Notification Of Case Assignment message must be sent to the case assigner. Otherwise, the request to modify payment case must be rejected (by means of a negative Resolution Of Investigation message).
func (*RequestToModifyPaymentV04) AddAssignment ¶
func (r *RequestToModifyPaymentV04) AddAssignment() *iso20022.CaseAssignment3
func (*RequestToModifyPaymentV04) AddCase ¶
func (r *RequestToModifyPaymentV04) AddCase() *iso20022.Case3
func (*RequestToModifyPaymentV04) AddModification ¶
func (r *RequestToModifyPaymentV04) AddModification() *iso20022.RequestedModification6
func (*RequestToModifyPaymentV04) AddSupplementaryData ¶
func (r *RequestToModifyPaymentV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*RequestToModifyPaymentV04) AddUnderlying ¶
func (r *RequestToModifyPaymentV04) AddUnderlying() *iso20022.UnderlyingTransaction3Choice
type ResolutionOfInvestigation ¶
type ResolutionOfInvestigation struct { // Note: the Assigner must be the sender of this confirmation and the Assignee must be the receiver. Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Identifies a resolved case. ResolvedCase *iso20022.Case `xml:"RslvdCase"` // Indicates the status of the investigation. Status *iso20022.InvestigationStatusChoice `xml:"Sts,omitempty"` // References a transaction intitiated to fix the case under investigation. CorrectionTransaction *iso20022.PaymentInstructionExtract `xml:"CrrctnTx,omitempty"` }
Scope The Resolution Of Investigation message is sent by a case assignee to a case creator/case assigner. This message is used to inform of the resolution of a case, and optionally provides details about . - the corrective action undertaken by the case assignee - information on the return where applicable Usage The Resolution Of Investigation message is used by the case assignee to inform a case creator or case assigner about the resolution of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Resolution Of Investigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several Resolution Of Investigation messages must be sent. The Resolution Of Investigation message provides: - the final outcome of the case, whether positive or negative - optionally, the details of the corrective action undertaken by the case assignee and the information of the return Whenever a payment instruction has been generated to solve the case under investigation, the optional CorrectionTransaction component present in the message must be completed. Whenever the action of modifying or cancelling a payment results in funds being returned, an investigating agent may attached some details in this message. These details facilitates the account reconciliations at the initiating bank and the intermediaries. It must be stressed that returning of funds is outside the scope of this Exceptions and Investigation service. The features given here is only meant to transmit the information of returns when it is available. The Resolution Of Investigation message must - be forwarded by all subsequent case assignee(s) until it reaches the case creator - not be used in place of a Reject Case Assignment or Case Status Report or Notification Of Case Assignment message. Take note of an exceptional rule that allows the use of Resolution Of Investigation in lieu of a Case Status Report. Case Status Report is a response-message to a Case Status Report Request. The latter which is sent when the assigner has waited too long (by his standard) for an answer. However it may happen that when the Request arrives, the investigating agent has just obtained a resolution. In such a situation, it would be redundant to send a Case Status Report when then followed immediately by a Resolution Of Investigation. It is therefore quite acceptable for the investigating agent, the assignee, to skip the Case Status Report and send the Resolution Of Investigation message directly.
func (*ResolutionOfInvestigation) AddAssignment ¶
func (r *ResolutionOfInvestigation) AddAssignment() *iso20022.CaseAssignment
func (*ResolutionOfInvestigation) AddCorrectionTransaction ¶
func (r *ResolutionOfInvestigation) AddCorrectionTransaction() *iso20022.PaymentInstructionExtract
func (*ResolutionOfInvestigation) AddResolvedCase ¶
func (r *ResolutionOfInvestigation) AddResolvedCase() *iso20022.Case
func (*ResolutionOfInvestigation) AddStatus ¶
func (r *ResolutionOfInvestigation) AddStatus() *iso20022.InvestigationStatusChoice
type ResolutionOfInvestigationV03 ¶
type ResolutionOfInvestigationV03 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 a resolved case. ResolvedCase *iso20022.Case2 `xml:"RslvdCase,omitempty"` // Indicates the status of the investigation. Status *iso20022.InvestigationStatus2Choice `xml:"Sts"` // Specifies the details of the underlying transactions being cancelled. CancellationDetails []*iso20022.UnderlyingTransaction3 `xml:"CxlDtls,omitempty"` // Details on the underlying statement entry. StatementDetails *iso20022.StatementResolutionEntry1 `xml:"StmtDtls,omitempty"` // References a transaction initiated to fix the case under investigation. CorrectionTransaction *iso20022.CorrectiveTransaction1Choice `xml:"CrrctnTx,omitempty"` // Reference of a return or a reversal initiated to fix the case under investigation as part of the resolution. ResolutionRelatedInformation *iso20022.ResolutionInformation1 `xml:"RsltnRltdInf,omitempty"` }
Scope The Resolution Of Investigation message is sent by a case assignee to a case creator/case assigner. This message is used to inform of the resolution of a case, and optionally provides details about . - the corrective action undertaken by the case assignee - information on the return where applicable Usage The Resolution Of Investigation message is used by the case assignee to inform a case creator or case assigner about the resolution of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Resolution Of Investigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several Resolution Of Investigation messages must be sent. The Resolution Of Investigation message provides: - the final outcome of the case, whether positive or negative - optionally, the details of the corrective action undertaken by the case assignee and the information of the return Whenever a payment instruction has been generated to solve the case under investigation following a claim non receipt or an unable to apply, the optional CorrectionTransaction component present in the message must be completed. Whenever the action of modifying or cancelling a payment results in funds being returned or reversed, an investigating agent may provide the details in the resolution related investigation component, to identify the return or reversal transaction. These details will facilitate the account reconciliations at the initiating bank and the intermediaries. It must be stressed that the return or reversal of funds is outside the scope of this Exceptions and Investigation service. The features given here is only meant to transmit the information of return or reversal when it is available through the resolution of the case. The Resolution Of Investigation message must: - be forwarded by all subsequent case assignee(s) until it reaches the case creator - not be used in place of a Reject Case Assignment or Case Status Report or Notification Of Case Assignment message Take note of an exceptional rule that allows the use of Resolution Of Investigation in lieu of a Case Status Report. Case Status Report is a response-message to a Case Status Report Request. The latter which is sent when the assigner has reached its own time-out threshold to receive a response. However it may happen that when the Request arrives, the investigating agent has just obtained a resolution. In such a situation, it would be redundant to send a Case Status Report when then followed immediately by a Resolution Of Investigation. It is therefore quite acceptable for the investigating agent, the assignee, to skip the Case Status Report and send the Resolution Of Investigation message directly. The Resolution Of Investigation message should be the sole message to respond to a cancellation request. Details of the underlying transactions and the related statuses for which the cancellation request has been issued may be provided in the Cancellation Details component.
func (*ResolutionOfInvestigationV03) AddAssignment ¶
func (r *ResolutionOfInvestigationV03) AddAssignment() *iso20022.CaseAssignment2
func (*ResolutionOfInvestigationV03) AddCancellationDetails ¶
func (r *ResolutionOfInvestigationV03) AddCancellationDetails() *iso20022.UnderlyingTransaction3
func (*ResolutionOfInvestigationV03) AddCorrectionTransaction ¶
func (r *ResolutionOfInvestigationV03) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
func (*ResolutionOfInvestigationV03) AddResolutionRelatedInformation ¶
func (r *ResolutionOfInvestigationV03) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
func (*ResolutionOfInvestigationV03) AddResolvedCase ¶
func (r *ResolutionOfInvestigationV03) AddResolvedCase() *iso20022.Case2
func (*ResolutionOfInvestigationV03) AddStatementDetails ¶
func (r *ResolutionOfInvestigationV03) AddStatementDetails() *iso20022.StatementResolutionEntry1
func (*ResolutionOfInvestigationV03) AddStatus ¶
func (r *ResolutionOfInvestigationV03) AddStatus() *iso20022.InvestigationStatus2Choice
type ResolutionOfInvestigationV04 ¶
type ResolutionOfInvestigationV04 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 a resolved case. ResolvedCase *iso20022.Case3 `xml:"RslvdCase,omitempty"` // Indicates the status of the investigation. Status *iso20022.InvestigationStatus3Choice `xml:"Sts"` // Specifies the details of the underlying transactions being cancelled. CancellationDetails []*iso20022.UnderlyingTransaction4 `xml:"CxlDtls,omitempty"` // Details on the underlying statement entry. StatementDetails *iso20022.StatementResolutionEntry2 `xml:"StmtDtls,omitempty"` // References a transaction initiated to fix the case under investigation. CorrectionTransaction *iso20022.CorrectiveTransaction1Choice `xml:"CrrctnTx,omitempty"` // Reference of a return or a reversal initiated to fix the case under investigation as part of the resolution. ResolutionRelatedInformation *iso20022.ResolutionInformation1 `xml:"RsltnRltdInf,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 Resolution Of Investigation message is sent by a case assignee to a case creator/case assigner. This message is used to inform of the resolution of a case, and optionally provides details about . - the corrective action undertaken by the case assignee - information on the return where applicable Usage The Resolution Of Investigation message is used by the case assignee to inform a case creator or case assigner about the resolution of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Resolution Of Investigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several Resolution Of Investigation messages must be sent. The Resolution Of Investigation message provides: - the final outcome of the case, whether positive or negative - optionally, the details of the corrective action undertaken by the case assignee and the information of the return Whenever a payment instruction has been generated to solve the case under investigation following a claim non receipt or an unable to apply, the optional CorrectionTransaction component present in the message must be completed. Whenever the action of modifying or cancelling a payment results in funds being returned or reversed, an investigating agent may provide the details in the resolution related investigation component, to identify the return or reversal transaction. These details will facilitate the account reconciliations at the initiating bank and the intermediaries. It must be stressed that the return or reversal of funds is outside the scope of this Exceptions and Investigation service. The features given here is only meant to transmit the information of return or reversal when it is available through the resolution of the case. The Resolution Of Investigation message must: - be forwarded by all subsequent case assignee(s) until it reaches the case creator - not be used in place of a Reject Case Assignment or Case Status Report or Notification Of Case Assignment message Take note of an exceptional rule that allows the use of Resolution Of Investigation in lieu of a Case Status Report. Case Status Report is a response-message to a Case Status Report Request. The latter which is sent when the assigner has reached its own time-out threshold to receive a response. However it may happen that when the Request arrives, the investigating agent has just obtained a resolution. In such a situation, it would be redundant to send a Case Status Report when then followed immediately by a Resolution Of Investigation. It is therefore quite acceptable for the investigating agent, the assignee, to skip the Case Status Report and send the Resolution Of Investigation message directly. The Resolution Of Investigation message should be the sole message to respond to a cancellation request. Details of the underlying transactions and the related statuses for which the cancellation request has been issued may be provided in the Cancellation Details component.
func (*ResolutionOfInvestigationV04) AddAssignment ¶
func (r *ResolutionOfInvestigationV04) AddAssignment() *iso20022.CaseAssignment3
func (*ResolutionOfInvestigationV04) AddCancellationDetails ¶
func (r *ResolutionOfInvestigationV04) AddCancellationDetails() *iso20022.UnderlyingTransaction4
func (*ResolutionOfInvestigationV04) AddCorrectionTransaction ¶
func (r *ResolutionOfInvestigationV04) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
func (*ResolutionOfInvestigationV04) AddResolutionRelatedInformation ¶
func (r *ResolutionOfInvestigationV04) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
func (*ResolutionOfInvestigationV04) AddResolvedCase ¶
func (r *ResolutionOfInvestigationV04) AddResolvedCase() *iso20022.Case3
func (*ResolutionOfInvestigationV04) AddStatementDetails ¶
func (r *ResolutionOfInvestigationV04) AddStatementDetails() *iso20022.StatementResolutionEntry2
func (*ResolutionOfInvestigationV04) AddStatus ¶
func (r *ResolutionOfInvestigationV04) AddStatus() *iso20022.InvestigationStatus3Choice
func (*ResolutionOfInvestigationV04) AddSupplementaryData ¶
func (r *ResolutionOfInvestigationV04) AddSupplementaryData() *iso20022.SupplementaryData1
type ResolutionOfInvestigationV05 ¶
type ResolutionOfInvestigationV05 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 a resolved case. ResolvedCase *iso20022.Case3 `xml:"RslvdCase,omitempty"` // Indicates the status of the investigation. Status *iso20022.InvestigationStatus3Choice `xml:"Sts"` // Specifies the details of the underlying transactions being cancelled. CancellationDetails []*iso20022.UnderlyingTransaction9 `xml:"CxlDtls,omitempty"` // Details on the underlying statement entry. StatementDetails *iso20022.StatementResolutionEntry2 `xml:"StmtDtls,omitempty"` // References a transaction initiated to fix the case under investigation. CorrectionTransaction *iso20022.CorrectiveTransaction1Choice `xml:"CrrctnTx,omitempty"` // Reference of a return or a reversal initiated to fix the case under investigation as part of the resolution. ResolutionRelatedInformation *iso20022.ResolutionInformation1 `xml:"RsltnRltdInf,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 Resolution Of Investigation message is sent by a case assignee to a case creator/case assigner. This message is used to inform of the resolution of a case, and optionally provides details about . - the corrective action undertaken by the case assignee - information on the return where applicable Usage The Resolution Of Investigation message is used by the case assignee to inform a case creator or case assigner about the resolution of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The Resolution Of Investigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several Resolution Of Investigation messages must be sent. The Resolution Of Investigation message provides: - the final outcome of the case, whether positive or negative - optionally, the details of the corrective action undertaken by the case assignee and the information of the return Whenever a payment instruction has been generated to solve the case under investigation following a claim non receipt or an unable to apply, the optional CorrectionTransaction component present in the message must be completed. Whenever the action of modifying or cancelling a payment results in funds being returned or reversed, an investigating agent may provide the details in the resolution related investigation component, to identify the return or reversal transaction. These details will facilitate the account reconciliations at the initiating bank and the intermediaries. It must be stressed that the return or reversal of funds is outside the scope of this Exceptions and Investigation service. The features given here is only meant to transmit the information of return or reversal when it is available through the resolution of the case. The Resolution Of Investigation message must: - be forwarded by all subsequent case assignee(s) until it reaches the case creator - not be used in place of a Reject Case Assignment or Case Status Report or Notification Of Case Assignment message Take note of an exceptional rule that allows the use of Resolution Of Investigation in lieu of a Case Status Report. Case Status Report is a response-message to a Case Status Report Request. The latter which is sent when the assigner has reached its own time-out threshold to receive a response. However it may happen that when the Request arrives, the investigating agent has just obtained a resolution. In such a situation, it would be redundant to send a Case Status Report when then followed immediately by a Resolution Of Investigation. It is therefore quite acceptable for the investigating agent, the assignee, to skip the Case Status Report and send the Resolution Of Investigation message directly. The Resolution Of Investigation message should be the sole message to respond to a cancellation request. Details of the underlying transactions and the related statuses for which the cancellation request has been issued may be provided in the Cancellation Details component.
func (*ResolutionOfInvestigationV05) AddAssignment ¶
func (r *ResolutionOfInvestigationV05) AddAssignment() *iso20022.CaseAssignment3
func (*ResolutionOfInvestigationV05) AddCancellationDetails ¶
func (r *ResolutionOfInvestigationV05) AddCancellationDetails() *iso20022.UnderlyingTransaction9
func (*ResolutionOfInvestigationV05) AddCorrectionTransaction ¶
func (r *ResolutionOfInvestigationV05) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
func (*ResolutionOfInvestigationV05) AddResolutionRelatedInformation ¶
func (r *ResolutionOfInvestigationV05) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
func (*ResolutionOfInvestigationV05) AddResolvedCase ¶
func (r *ResolutionOfInvestigationV05) AddResolvedCase() *iso20022.Case3
func (*ResolutionOfInvestigationV05) AddStatementDetails ¶
func (r *ResolutionOfInvestigationV05) AddStatementDetails() *iso20022.StatementResolutionEntry2
func (*ResolutionOfInvestigationV05) AddStatus ¶
func (r *ResolutionOfInvestigationV05) AddStatus() *iso20022.InvestigationStatus3Choice
func (*ResolutionOfInvestigationV05) AddSupplementaryData ¶
func (r *ResolutionOfInvestigationV05) AddSupplementaryData() *iso20022.SupplementaryData1
type ResolutionOfInvestigationV06 ¶
type ResolutionOfInvestigationV06 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 a resolved case. ResolvedCase *iso20022.Case3 `xml:"RslvdCase,omitempty"` // Indicates the status of the investigation. Status *iso20022.InvestigationStatus3Choice `xml:"Sts"` // Specifies the details of the underlying transactions being cancelled. CancellationDetails []*iso20022.UnderlyingTransaction14 `xml:"CxlDtls,omitempty"` // Details on the underlying statement entry. StatementDetails *iso20022.StatementResolutionEntry2 `xml:"StmtDtls,omitempty"` // References a transaction initiated to fix the case under investigation. CorrectionTransaction *iso20022.CorrectiveTransaction1Choice `xml:"CrrctnTx,omitempty"` // Reference of a return or a reversal initiated to fix the case under investigation as part of the resolution. ResolutionRelatedInformation *iso20022.ResolutionInformation1 `xml:"RsltnRltdInf,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 ResolutionOfInvestigation message is sent by a case assignee to a case creator/case assigner. This message is used to inform of the resolution of a case, and optionally provides details about . - the corrective action undertaken by the case assignee - information on the return where applicable Usage The ResolutionOfInvestigation message is used by the case assignee to inform a case creator or case assigner about the resolution of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The ResolutionOfInvestigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several Resolution Of Investigation messages must be sent. The ResolutionOfInvestigation message provides: - the final outcome of the case, whether positive or negative - optionally, the details of the corrective action undertaken by the case assignee and the information of the return Whenever a payment instruction has been generated to solve the case under investigation following a claim non receipt or an unable to apply, the optional CorrectionTransaction component present in the message must be completed. Whenever the action of modifying or cancelling a payment results in funds being returned or reversed, an investigating agent may provide the details in the resolution related investigation component, to identify the return or reversal transaction. These details will facilitate the account reconciliations at the initiating bank and the intermediaries. It must be stressed that the return or reversal of funds is outside the scope of this Exceptions and Investigation service. The features given here is only meant to transmit the information of return or reversal when it is available through the resolution of the case. The ResolutionOfInvestigation message must: - be forwarded by all subsequent case assignee(s) until it reaches the case creator - not be used in place of a RejectCaseAssignment or CaseStatusReport or NotificationOfCaseAssignment message Take note of an exceptional rule that allows the use of ResolutionOfInvestigation in lieu of a CaseStatusReport. CaseStatusReport is a response-message to a CaseStatusReportRequest. The latter which is sent when the assigner has reached its own time-out threshold to receive a response. However it may happen that when the request arrives, the investigating agent has just obtained a resolution. In such a situation, it would be redundant to send a CaseStatusReport when then followed immediately by a ResolutionOfInvestigation. It is therefore quite acceptable for the investigating agent, the assignee, to skip the Case Status Report and send the ResolutionOfInvestigation message directly. The ResolutionOfInvestigation message should be the sole message to respond to a cancellation request. Details of the underlying transactions and the related statuses for which the cancellation request has been issued may be provided in the CancellationDetails component.
func (*ResolutionOfInvestigationV06) AddAssignment ¶
func (r *ResolutionOfInvestigationV06) AddAssignment() *iso20022.CaseAssignment3
func (*ResolutionOfInvestigationV06) AddCancellationDetails ¶
func (r *ResolutionOfInvestigationV06) AddCancellationDetails() *iso20022.UnderlyingTransaction14
func (*ResolutionOfInvestigationV06) AddCorrectionTransaction ¶
func (r *ResolutionOfInvestigationV06) AddCorrectionTransaction() *iso20022.CorrectiveTransaction1Choice
func (*ResolutionOfInvestigationV06) AddResolutionRelatedInformation ¶
func (r *ResolutionOfInvestigationV06) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
func (*ResolutionOfInvestigationV06) AddResolvedCase ¶
func (r *ResolutionOfInvestigationV06) AddResolvedCase() *iso20022.Case3
func (*ResolutionOfInvestigationV06) AddStatementDetails ¶
func (r *ResolutionOfInvestigationV06) AddStatementDetails() *iso20022.StatementResolutionEntry2
func (*ResolutionOfInvestigationV06) AddStatus ¶
func (r *ResolutionOfInvestigationV06) AddStatus() *iso20022.InvestigationStatus3Choice
func (*ResolutionOfInvestigationV06) AddSupplementaryData ¶
func (r *ResolutionOfInvestigationV06) AddSupplementaryData() *iso20022.SupplementaryData1
type ResolutionOfInvestigationV07 ¶
type ResolutionOfInvestigationV07 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 a resolved case. ResolvedCase *iso20022.Case3 `xml:"RslvdCase,omitempty"` // Indicates the status of the investigation. Status *iso20022.InvestigationStatus3Choice `xml:"Sts"` // Specifies the details of the underlying transactions being cancelled. CancellationDetails []*iso20022.UnderlyingTransaction17 `xml:"CxlDtls,omitempty"` // Details on the underlying statement entry. StatementDetails *iso20022.StatementResolutionEntry2 `xml:"StmtDtls,omitempty"` // References a transaction initiated to fix the case under investigation. CorrectionTransaction *iso20022.CorrectiveTransaction2Choice `xml:"CrrctnTx,omitempty"` // Reference of a return or a reversal initiated to fix the case under investigation as part of the resolution. ResolutionRelatedInformation *iso20022.ResolutionInformation1 `xml:"RsltnRltdInf,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 ResolutionOfInvestigation message is sent by a case assignee to a case creator/case assigner. This message is used to inform of the resolution of a case, and optionally provides details about . - the corrective action undertaken by the case assignee - information on the return where applicable Usage The ResolutionOfInvestigation message is used by the case assignee to inform a case creator or case assigner about the resolution of a: - request to cancel payment case - request to modify payment case - unable to apply case - claim non receipt case The ResolutionOfInvestigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several Resolution Of Investigation messages must be sent. The ResolutionOfInvestigation message provides: - the final outcome of the case, whether positive or negative - optionally, the details of the corrective action undertaken by the case assignee and the information of the return Whenever a payment instruction has been generated to solve the case under investigation following a claim non receipt or an unable to apply, the optional CorrectionTransaction component present in the message must be completed. Whenever the action of modifying or cancelling a payment results in funds being returned or reversed, an investigating agent may provide the details in the resolution related investigation component, to identify the return or reversal transaction. These details will facilitate the account reconciliations at the initiating bank and the intermediaries. It must be stressed that the return or reversal of funds is outside the scope of this Exceptions and Investigation service. The features given here is only meant to transmit the information of return or reversal when it is available through the resolution of the case. The ResolutionOfInvestigation message must: - be forwarded by all subsequent case assignee(s) until it reaches the case creator - not be used in place of a RejectCaseAssignment or CaseStatusReport or NotificationOfCaseAssignment message Take note of an exceptional rule that allows the use of ResolutionOfInvestigation in lieu of a CaseStatusReport. CaseStatusReport is a response-message to a CaseStatusReportRequest. The latter which is sent when the assigner has reached its own time-out threshold to receive a response. However it may happen that when the request arrives, the investigating agent has just obtained a resolution. In such a situation, it would be redundant to send a CaseStatusReport when then followed immediately by a ResolutionOfInvestigation. It is therefore quite acceptable for the investigating agent, the assignee, to skip the Case Status Report and send the ResolutionOfInvestigation message directly. The ResolutionOfInvestigation message should be the sole message to respond to a cancellation request. Details of the underlying transactions and the related statuses for which the cancellation request has been issued may be provided in the CancellationDetails component.
func (*ResolutionOfInvestigationV07) AddAssignment ¶
func (r *ResolutionOfInvestigationV07) AddAssignment() *iso20022.CaseAssignment3
func (*ResolutionOfInvestigationV07) AddCancellationDetails ¶
func (r *ResolutionOfInvestigationV07) AddCancellationDetails() *iso20022.UnderlyingTransaction17
func (*ResolutionOfInvestigationV07) AddCorrectionTransaction ¶
func (r *ResolutionOfInvestigationV07) AddCorrectionTransaction() *iso20022.CorrectiveTransaction2Choice
func (*ResolutionOfInvestigationV07) AddResolutionRelatedInformation ¶
func (r *ResolutionOfInvestigationV07) AddResolutionRelatedInformation() *iso20022.ResolutionInformation1
func (*ResolutionOfInvestigationV07) AddResolvedCase ¶
func (r *ResolutionOfInvestigationV07) AddResolvedCase() *iso20022.Case3
func (*ResolutionOfInvestigationV07) AddStatementDetails ¶
func (r *ResolutionOfInvestigationV07) AddStatementDetails() *iso20022.StatementResolutionEntry2
func (*ResolutionOfInvestigationV07) AddStatus ¶
func (r *ResolutionOfInvestigationV07) AddStatus() *iso20022.InvestigationStatus3Choice
func (*ResolutionOfInvestigationV07) AddSupplementaryData ¶
func (r *ResolutionOfInvestigationV07) AddSupplementaryData() *iso20022.SupplementaryData1
type UnableToApply ¶
type UnableToApply struct { // Identifies the assignment. Assignment *iso20022.CaseAssignment `xml:"Assgnmt"` // Identifies the case. Case *iso20022.Case `xml:"Case"` // References the Payment Instruction that a Party is unable to execute or unable to reconcile. Underlying *iso20022.PaymentInstructionExtract `xml:"Undrlyg"` // Explains the reason why unable to apply. Justification *iso20022.UnableToApplyJustificationChoice `xml:"Justfn"` }
Scope The Unable To Apply message is sent by a case creator or a case assigner to a case assignee. This message is used to initiate an investigation of a payment instruction that cannot be executed or reconciled. Usage The Unable To Apply case occurs in two situations: - an agent cannot execute the payment instruction due to missing or incorrect information - a creditor cannot reconcile the payment entry as it is received unexpectedly, or missing or incorrect information prevents reconciliation The Unable To Apply message: - always follows the reverse route of the original payment instruction - must be forwarded to the preceding agents in the payment processing chain, where appropriate - covers one and only one payment instruction (or payment entry) at a time; if several payment instructions cannot be executed or several payment entries cannot be reconciled, then multiple Unable To Apply messages must be sent. Depending on what stage the payment is and what has been done to it, for example incorrect routing, errors/omissions when processing the instruction or even the absence of any error, the unable to apply case may lead to a: - Additional Payment Information message, sent to the case creator/case assigner, if a truncation or omission in a payment instruction prevented reconciliation. - 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 entails a new corrected payment instruction being issued). Prior to sending the payment cancellation request, the agent should first send a resolution indicating that a cancellation will follow (CWFW). - 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. Prior to sending the modify payment request, the agent should first send a resolution indicating that a modification will follow (MWFW). - Debit Authorisation Request message, sent to the case creator/case assigner, if the payment instruction has reached an incorrect creditor.
func (*UnableToApply) AddAssignment ¶
func (u *UnableToApply) AddAssignment() *iso20022.CaseAssignment
func (*UnableToApply) AddCase ¶
func (u *UnableToApply) AddCase() *iso20022.Case
func (*UnableToApply) AddJustification ¶
func (u *UnableToApply) AddJustification() *iso20022.UnableToApplyJustificationChoice
func (*UnableToApply) AddUnderlying ¶
func (u *UnableToApply) AddUnderlying() *iso20022.PaymentInstructionExtract
type UnableToApplyV03 ¶
type UnableToApplyV03 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"` // References the payment instruction or statement entry that a party is unable to execute or unable to reconcile. Underlying *iso20022.UnderlyingTransaction1Choice `xml:"Undrlyg"` // Explains the reason why the case creator is unable to apply the instruction. Justification *iso20022.UnableToApplyJustification2Choice `xml:"Justfn"` }
Scope The Unable To Apply message is sent by a case creator or a case assigner to a case assignee. This message is used to initiate an investigation of a payment instruction that cannot be executed or reconciled. Usage The Unable To Apply case occurs in two situations: - an agent cannot execute the payment instruction due to missing or incorrect information - a creditor cannot reconcile the payment entry as it is received unexpectedly, or missing or incorrect information prevents reconciliation The Unable To Apply message - always follows the reverse route of the original payment instruction - must be forwarded to the preceding agents in the payment processing chain, where appropriate - covers one and only one payment instruction (or payment entry) at a time; if several payment instructions cannot be executed or several payment entries cannot be reconciled, then multiple Unable To Apply messages must be sent. Depending on what stage the payment is and what has been done to it, for example incorrect routing, errors/omissions when processing the instruction or even the absence of any error, the unable to apply case may lead to a: - Additional Payment Information message, sent to the case creator/case assigner, if a truncation or omission in a payment instruction prevented reconciliation. - 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 entails a new corrected payment instruction being issued). Prior to sending the payment cancellation request, the agent should first send a resolution indicating that a cancellation will follow (CWFW). - 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. Prior to sending the modify payment request, the agent should first send a resolution indicating that a modification will follow (MWFW). - Debit Authorisation Request message, sent to the case creator/case assigner, if the payment instruction has reached an incorrect creditor. The UnableToApply message has the following main characteristics: - Case Identification and Reason Code: The case creator (the instructed party/creditor of a payment instruction) assigns a unique case identification and optionally the reason code for the Unable To Apply message. This information will be passed unchanged to all subsequent case assignees. - Underlying Payment Instruction Identification: The case creator specifies the identification of the underlying 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). - Unable To Apply Justification: The Unable To Apply Justification element allows the assigner to indicate whether a specific element causes the unable to apply situation (incorrect element and/or mismatched element can be listed) or whether any supplementary information needs to be forwarded.
func (*UnableToApplyV03) AddAssignment ¶
func (u *UnableToApplyV03) AddAssignment() *iso20022.CaseAssignment2
func (*UnableToApplyV03) AddCase ¶
func (u *UnableToApplyV03) AddCase() *iso20022.Case2
func (*UnableToApplyV03) AddJustification ¶
func (u *UnableToApplyV03) AddJustification() *iso20022.UnableToApplyJustification2Choice
func (*UnableToApplyV03) AddUnderlying ¶
func (u *UnableToApplyV03) AddUnderlying() *iso20022.UnderlyingTransaction1Choice
type UnableToApplyV04 ¶
type UnableToApplyV04 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"` // References the payment instruction or statement entry that a party is unable to execute or unable to reconcile. Underlying *iso20022.UnderlyingTransaction2Choice `xml:"Undrlyg"` // Explains the reason why the case creator is unable to apply the instruction. Justification *iso20022.UnableToApplyJustification2Choice `xml:"Justfn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Unable To Apply message is sent by a case creator or a case assigner to a case assignee. This message is used to initiate an investigation of a payment instruction that cannot be executed or reconciled. Usage The Unable To Apply case occurs in two situations: - an agent cannot execute the payment instruction due to missing or incorrect information - a creditor cannot reconcile the payment entry as it is received unexpectedly, or missing or incorrect information prevents reconciliation The Unable To Apply message - always follows the reverse route of the original payment instruction - must be forwarded to the preceding agents in the payment processing chain, where appropriate - covers one and only one payment instruction (or payment entry) at a time; if several payment instructions cannot be executed or several payment entries cannot be reconciled, then multiple Unable To Apply messages must be sent. Depending on what stage the payment is and what has been done to it, for example incorrect routing, errors/omissions when processing the instruction or even the absence of any error, the unable to apply case may lead to a: - Additional Payment Information message, sent to the case creator/case assigner, if a truncation or omission in a payment instruction prevented reconciliation. - 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 entails a new corrected payment instruction being issued). Prior to sending the payment cancellation request, the agent should first send a resolution indicating that a cancellation will follow (CWFW). - 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. Prior to sending the modify payment request, the agent should first send a resolution indicating that a modification will follow (MWFW). - Debit Authorisation Request message, sent to the case creator/case assigner, if the payment instruction has reached an incorrect creditor. The UnableToApply message has the following main characteristics: The case creator (the instructed party/creditor of a payment instruction) assigns a unique case identification and optionally the reason code for the Unable To Apply message. This information will be passed unchanged to all subsequent case assignees. The case creator specifies the identification of the underlying 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). The Unable To Apply Justification element allows the assigner to indicate whether a specific element causes the unable to apply situation (incorrect element and/or mismatched element can be listed) or whether any supplementary information needs to be forwarded.
func (*UnableToApplyV04) AddAssignment ¶
func (u *UnableToApplyV04) AddAssignment() *iso20022.CaseAssignment3
func (*UnableToApplyV04) AddCase ¶
func (u *UnableToApplyV04) AddCase() *iso20022.Case3
func (*UnableToApplyV04) AddJustification ¶
func (u *UnableToApplyV04) AddJustification() *iso20022.UnableToApplyJustification2Choice
func (*UnableToApplyV04) AddSupplementaryData ¶
func (u *UnableToApplyV04) AddSupplementaryData() *iso20022.SupplementaryData1
func (*UnableToApplyV04) AddUnderlying ¶
func (u *UnableToApplyV04) AddUnderlying() *iso20022.UnderlyingTransaction2Choice
type UnableToApplyV05 ¶
type UnableToApplyV05 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"` // References the payment instruction or statement entry that a party is unable to execute or unable to reconcile. Underlying *iso20022.UnderlyingTransaction3Choice `xml:"Undrlyg"` // Explains the reason why the case creator is unable to apply the instruction. Justification *iso20022.UnableToApplyJustification3Choice `xml:"Justfn"` // Additional information that cannot be captured in the structured elements and/or any other specific block. SupplementaryData []*iso20022.SupplementaryData1 `xml:"SplmtryData,omitempty"` }
Scope The Unable To Apply message is sent by a case creator or a case assigner to a case assignee. This message is used to initiate an investigation of a payment instruction that cannot be executed or reconciled. Usage The Unable To Apply case occurs in two situations: - an agent cannot execute the payment instruction due to missing or incorrect information - a creditor cannot reconcile the payment entry as it is received unexpectedly, or missing or incorrect information prevents reconciliation The Unable To Apply message - always follows the reverse route of the original payment instruction - must be forwarded to the preceding agents in the payment processing chain, where appropriate - covers one and only one payment instruction (or payment entry) at a time; if several payment instructions cannot be executed or several payment entries cannot be reconciled, then multiple Unable To Apply messages must be sent. Depending on what stage the payment is and what has been done to it, for example incorrect routing, errors/omissions when processing the instruction or even the absence of any error, the unable to apply case may lead to a: - Additional Payment Information message, sent to the case creator/case assigner, if a truncation or omission in a payment instruction prevented reconciliation. - 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 entails a new corrected payment instruction being issued). Prior to sending the payment cancellation request, the agent should first send a resolution indicating that a cancellation will follow (CWFW). - 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. Prior to sending the modify payment request, the agent should first send a resolution indicating that a modification will follow (MWFW). - Debit Authorisation Request message, sent to the case creator/case assigner, if the payment instruction has reached an incorrect creditor. The UnableToApply message has the following main characteristics: The case creator (the instructed party/creditor of a payment instruction) assigns a unique case identification and optionally the reason code for the Unable To Apply message. This information will be passed unchanged to all subsequent case assignees. The case creator specifies the identification of the underlying 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). The Unable To Apply Justification element allows the assigner to indicate whether a specific element causes the unable to apply situation (incorrect element and/or mismatched element can be listed) or whether any supplementary information needs to be forwarded.
func (*UnableToApplyV05) AddAssignment ¶
func (u *UnableToApplyV05) AddAssignment() *iso20022.CaseAssignment3
func (*UnableToApplyV05) AddCase ¶
func (u *UnableToApplyV05) AddCase() *iso20022.Case3
func (*UnableToApplyV05) AddJustification ¶
func (u *UnableToApplyV05) AddJustification() *iso20022.UnableToApplyJustification3Choice
func (*UnableToApplyV05) AddSupplementaryData ¶
func (u *UnableToApplyV05) AddSupplementaryData() *iso20022.SupplementaryData1
func (*UnableToApplyV05) AddUnderlying ¶
func (u *UnableToApplyV05) AddUnderlying() *iso20022.UnderlyingTransaction3Choice
Source Files ¶
- AccountReportingRequestV02.go
- AccountReportingRequestV03.go
- AdditionalPaymentInformation.go
- AdditionalPaymentInformationV03.go
- AdditionalPaymentInformationV04.go
- AdditionalPaymentInformationV05.go
- AdditionalPaymentInformationV06.go
- AdditionalPaymentInformationV07.go
- BankServicesBillingStatementV01.go
- BankServicesBillingStatementV02.go
- BankToCustomerAccountReportV01.go
- BankToCustomerAccountReportV02.go
- BankToCustomerAccountReportV03.go
- BankToCustomerAccountReportV04.go
- BankToCustomerAccountReportV05.go
- BankToCustomerAccountReportV06.go
- BankToCustomerDebitCreditNotificationV01.go
- BankToCustomerDebitCreditNotificationV02.go
- BankToCustomerDebitCreditNotificationV03.go
- BankToCustomerDebitCreditNotificationV04.go
- BankToCustomerDebitCreditNotificationV05.go
- BankToCustomerDebitCreditNotificationV06.go
- BankToCustomerStatementV01.go
- BankToCustomerStatementV02.go
- BankToCustomerStatementV03.go
- BankToCustomerStatementV04.go
- BankToCustomerStatementV05.go
- BankToCustomerStatementV06.go
- CancelCaseAssignment.go
- CancelCaseAssignmentV02.go
- CancelCaseAssignmentV03.go
- CaseStatusReport.go
- CaseStatusReportRequest.go
- CaseStatusReportRequestV02.go
- CaseStatusReportRequestV03.go
- CaseStatusReportV03.go
- CaseStatusReportV04.go
- ClaimNonReceipt.go
- ClaimNonReceiptV03.go
- ClaimNonReceiptV04.go
- ClaimNonReceiptV05.go
- CustomerPaymentCancellationRequestV01.go
- CustomerPaymentCancellationRequestV02.go
- CustomerPaymentCancellationRequestV03.go
- CustomerPaymentCancellationRequestV04.go
- CustomerPaymentCancellationRequestV05.go
- CustomerPaymentCancellationRequestV06.go
- DebitAuthorisationRequest.go
- DebitAuthorisationRequestV03.go
- DebitAuthorisationRequestV04.go
- DebitAuthorisationRequestV05.go
- DebitAuthorisationResponse.go
- DebitAuthorisationResponseV02.go
- DebitAuthorisationResponseV03.go
- DuplicateV03.go
- DuplicateV04.go
- FIToFIPaymentCancellationRequestV01.go
- FIToFIPaymentCancellationRequestV02.go
- FIToFIPaymentCancellationRequestV03.go
- FIToFIPaymentCancellationRequestV04.go
- FIToFIPaymentCancellationRequestV05.go
- FIToFIPaymentCancellationRequestV06.go
- FundConfirmedCashForecastReportCancellationV01.go
- FundConfirmedCashForecastReportCancellationV02.go
- FundConfirmedCashForecastReportCancellationV03.go
- FundConfirmedCashForecastReportV02.go
- FundConfirmedCashForecastReportV03.go
- FundConfirmedCashForecastReportV04.go
- FundDetailedConfirmedCashForecastReportCancellationV01.go
- FundDetailedConfirmedCashForecastReportCancellationV02.go
- FundDetailedConfirmedCashForecastReportCancellationV03.go
- FundDetailedConfirmedCashForecastReportV02.go
- FundDetailedConfirmedCashForecastReportV03.go
- FundDetailedConfirmedCashForecastReportV04.go
- FundDetailedEstimatedCashForecastReportV02.go
- FundDetailedEstimatedCashForecastReportV03.go
- FundDetailedEstimatedCashForecastReportV04.go
- FundEstimatedCashForecastReportV02.go
- FundEstimatedCashForecastReportV03.go
- FundEstimatedCashForecastReportV04.go
- NetReportV01.go
- NotificationOfCaseAssignment.go
- NotificationOfCaseAssignmentV03.go
- NotificationOfCaseAssignmentV04.go
- NotificationToReceiveCancellationAdviceV02.go
- NotificationToReceiveCancellationAdviceV03.go
- NotificationToReceiveCancellationAdviceV04.go
- NotificationToReceiveCancellationAdviceV05.go
- NotificationToReceiveStatusReportV02.go
- NotificationToReceiveStatusReportV03.go
- NotificationToReceiveStatusReportV04.go
- NotificationToReceiveStatusReportV05.go
- NotificationToReceiveV02.go
- NotificationToReceiveV03.go
- NotificationToReceiveV04.go
- NotificationToReceiveV05.go
- PayInCallV02.go
- PayInEventAcknowledgementV02.go
- PayInScheduleV03.go
- ProprietaryFormatInvestigationV02.go
- ProprietaryFormatInvestigationV03.go
- RejectCaseAssignment.go
- RejectInvestigationV03.go
- RejectInvestigationV04.go
- RequestForDuplicateInstruction.go
- RequestForDuplicateV03.go
- RequestForDuplicateV04.go
- RequestToCancelPayment.go
- RequestToModifyPayment.go
- RequestToModifyPaymentV01.go
- RequestToModifyPaymentV02.go
- RequestToModifyPaymentV04.go
- ResolutionOfInvestigation.go
- ResolutionOfInvestigationV03.go
- ResolutionOfInvestigationV04.go
- ResolutionOfInvestigationV05.go
- ResolutionOfInvestigationV06.go
- ResolutionOfInvestigationV07.go
- UnableToApply.go
- UnableToApplyV03.go
- UnableToApplyV04.go
- UnableToApplyV05.go