Optional Modules - Changes & Fixes

This page covers the optional module changes and fixes provided in IPF Release 2025.3.0

Scheme Packs

Deprecated Changes

  • Previous character replacer configuration is deprecated, please follow the updated documentation for defining configuration (PAY-15636)

    • Deprecated configuration will no longer be supported starting from the 2026.3.0 release

Please see Migration Steps for more details

Breaking Changes

  • Character replacer method to replace parts of the message removed (PAY-15636)

  • BDD test integrity checks fixed for TechnicalResponses and ValidateSchemeRuleResponses (PAY-15277)

  • All references to ValidateSchemeRulesResponseSender in scheme packs should be replaced with ValidateSchemeRulesResponseSender<ValidateSchemeRulesResponse> or ValidateSchemeRulesResponseSender<ValidateDirectDebitSchemeRulesResponse> (in case of direct debit) (PAY-15332)

  • All references to ValidateSchemeRules in scheme packs should be replaced with ValidateSchemeRules<CANONICAL, ValidationResponse> (PAY-15332)

  • All references to ValidateDDSchemeRules<CANONICAL> in scheme packs should be replaced with ValidateSchemeRules<CANONICAL, ValidationDDResponse> (PAY-15332)

  • Any class such as <SchemeName>ValidateSchemeRules that implements ValidateSchemeRules should be replaced with a concrete bean. Each overloaded method in ValidateSchemeRules must have a dedicated implementation for its corresponding CANONICAL type. Each concrete bean should implement ValidateSchemeRules<CANONICAL, ValidationResponse> (PAY-15332)

Please see Migration Steps for more details

New

  • ValidateSchemeRuleResponse now automatically includes the key "ValidatedIsoType" in its customBusinessData metadata. This identifies which ISO 20022 message type was validated. The CSMClientValidationResponseAdapter and CSMDDClientValidationResponseAdapter default handleSchemeRulesResponse() method now automatically routes to new ISO type-specific handler methods for you to implement based on the response metadata. If you previously implemented the handleSchemeRulesResponse() and don’t wish to migrate to the new default routing no change is required. You can retain your existing implementation without changes (PAY-15060, PAY-15075)

You must keep your CSM client and CSM service versions in sync to ensure the new default handleSchemeRulesResponse() routing works correctly. If your client is upgraded but the service is running an older version, the metadata will be missing from responses, causing the method to fail.

  • A new lookup table character replacer is available. See Character Replacement for further details. (PAY-15636)

CSM Instant Scheme Packs

Changed

  • On a duplicate pacs.004 received csm-service does not send a pacs.002 (PAY-15331)

SEPA CT CSM

New

  • Configuration to disable the scheduling of implicit End-Of-Day (EOD) pacs.002. See eod jobs for further details. (PAY-15290)

Fixed

  • Removed pluralisation of offending tags in validation failures. For example, "XT33 CdtTrfTxInf RmtInf Strds" will now be "XT33 CdtTrfTxInf RmtInf Strd" (PAY-14756)

  • When receiving a CVF file 'Full File Reject' (denoted by the FileRjctRsn field not being 'A00' or 'A01') a System Event of type FileRejected will be raised and the 'submit' flow will remain in a passivated 'Waiting for Scheme Responses' state. (PAY-15290)

  • Produced ICF and IQF files are generated with a STEP2 scheme compliant file name (PAY-15716, PAY-15742).

Changed

Breaking Changes

  • The following system events have been relocated to sepa-common with their package updated (PAY-14419)

    • BulkCommandFailed

    • ReceiveFromSchemeExtensionPointFailed

    • SendingSchemeResponseFailed

    • SendToSchemeExtensionPointFailed

    • SendToSchemeExtensionPointSuccess

Please see Migration Steps for more details

SEPA DD CSM

New

  • Add canonical schema validation for ValidateCollectAndSettleSchemeRulesRequest and CollectAndSettleRequest (PAY-15023)

  • Add pacs003 validation rule to mandate debtor postal address country code if payment involves a non-EEA country (PAY-15098)

  • Add new configuration options for enabling or disabling pacs003 validation rule to mandate debtor postal address country code if payment involves a non-EEA country. The default values are:

    • ipf.csm.sepa-dd.validation.pacs003.non-eea-debtor-address-validation-outbound.enabled = false

  • Add pacs003 validation rule to verify the debtor postal address must be either structured, hybrid or unstructured (PAY-11648)

  • Add new configuration options for enabling or disabling pacs003 validation rule to verify the debtor postal address must be either structured, hybrid or unstructured. The default values are:

    • ipf.csm.sepa-dd.validation.pacs003.debtor-address-structural-validation-outbound.enabled = false

  • Add new configuration options for enabling or disabling pacs003 validation rule to verify the creditor postal address must be either structured, hybrid or unstructured. The default values are:

    • ipf.csm.sepa-dd.validation.pacs003.creditor-address-structural-validation-outbound.enabled = false

  • Enabled Debulker schema validation for DVF and RSF files. (PAY-14837)

  • Added camt056 support (PAY-15649)

    • Direct Debit API now supports ExecuteDDCancellationRequest and ExecuteDDCancellationResponse for additional details see API and Request Processing

    • Direct Debit Validation API now supports ValidateDDCancellationSchemeRulesRequest for additional details see API and Validations

    • IDF File Production now supports camt056

    • DVF Response processing supports camt056

  • Added pacs007 support (PAY-15649)

    • Direct Debit API now supports ExecuteDDReversalRequest and ExecuteDDReversalResponse for additional details see API and Request Processing

    • Direct Debit Validation API now supports ValidateDDReversalSchemeRulesRequest for additional details see API and Validations

    • IDF File Production now supports pacs007

    • DVF Response processing supports pacs007

    • RSF Response processing supports pacs007

Fixed

  • Component processing of a DVF/RSF file will now resume after an application crash (PAY-14419)

  • Unable to process ValidateCollectAndSettleSchemeRulesRequest if scheme schema validation error (PAY-15023)

  • Remove failed transactions from bulking and raise RegisterBulkCorrelationFailed system event if saving to the correlation store fails (PAY-14833)

  • Validation now correctly rejects pacs003 requests containing more than 2 postal address lines for debtor or creditor (PAY-15049)

  • For flow validations, resume running validations on the remaining transactions even if the first one failed, so we can submit successful transactions to the bulker correctly (PAY-14884)

  • Produced IDF files are generated with a STEP2 scheme compliant file name (PAY-15741).

Changed

  • Updated to the latest XSD Schemas for the October 2025 release:

    • Pacs003 (PAY-14682)

    • Pacs002S2 (PAY-14683)

Breaking Changes

  • Pacs002 message processing for RSF and DVF is now contained in a subflow (PAY-14419)

  • The technical.enabled parameter now serves as a single toggle for enabling/disabling direct debit technical responses (see configuration changes below)

    • Kafka Topic Default Value change from COLLECTANDSETTLE_TECHNICAL_RESPONSE to DIRECTDEBIT_TECHNICAL_RESPONSE

    • JMS Queue Default Value change from collectandsettle.technical.response to directdebit.technical.response

  • Direct Debit queues/topics are now per direction and role only (i.e. DD creditor-to-csm/DD csm-to-creditor), as opposed to per direction, role and message type (PAY-15358/PAY-15434/PAY-15360/PAY-15550)

    • Topic names and configuration keys to override them have changed. See transport reference for further details

The configuration below shows the change in configuration to enable/disable the various DD connectors:

Before:
csm {
  direct-debit {
    collect-and-settle {
      creditor.enabled = true
      technical.enabled = true
    }
  }
}
After:
csm {
  direct-debit {
    creditor.enabled = true
    technical.enabled = true
  }
}

Please see Migration Steps for more details

TIPS CSM

Breaking Changes

  • The default character replacement has been updated to use the EPC217-08 SEPA Conversion Table (PAY-15584)

    • Caveat: Multi-character replacements from the table will be replaced by .

    • Please see Migration Steps on how to maintain the legacy behaviour

SEPA VFG Simulator

New

  • Added support for Camt.056 transactions during Direct Debit DVF file generation (PAY-15371)

  • Added support for Pacs.007 transactions during Direct Debit DVF and RSF file generation (PAY-15372)

Fixed

  • The simulator expects ICF, IQF and IDF file names to match the scheme compliant format in order to produce the corresponding verification files (PAY-15716, PAY-15741, PAY-15742).

SIC CSM Simulator

Changed

  • Using non SpeL expressions in additionalInfo to enhance generated data is deprecated and will be removed in a future release (PAY-14008)

TIPS CSM Simulator

Changed

  • When setting additionalInfo, you can now use SpEL to enhance the generated data (PAY-14008)

  • Using non SpeL expressions in additionalInfo to enhance generated data is deprecated and will be removed in a future release (PAY-14008)

IPF Metrics Processor

New

Updated configuration structure to support versioned pds mappings in IPF Metrics Processor.

To support IPF data versioning, the metrics processor configuration has been enhanced to handle multiple versions of a PDS object across various releases, accommodating possible schema changes.

NOTE

While PDS versioning is not currently supported in IPF, these changes are in preparation for its eventual integration. Further documentation will be provided once versioning is fully supported.
This change is backwards compatible, allowing users to continue using the existing configuration without requiring immediate migration to the new format.

The following is an example configuration for some metrics labels:

ipf.business-metrics-processor.payment-metrics {
  labels {
    csm {
      pds-type = "Csm",
      path = "/value"
    }
    currency {
      pds-type = CurrencyPdsType
      path = "/amt/pmtAmt/ccy"
    }
    local-instrument {
      pds-type = InstrumentPdsType
      path = "/prcgInstrs/lclInstrm/prtry"
    }
  }
}

To migrate to the new configuration, the following changes are required:

  • Replace the labels key with versioned-labels

  • Each key within versioned-labels (E.g. csm, currency, local-instrument etc.) now holds an array of objects rather than a single object.

Below is the updated version of the example configuration:

ipf.business-metrics-processor.payment-metrics {
  versioned-labels {
    csm = [
      {
        pds-type = "Csm",
        path = "/value"
      }
    ]
    currency = [
      {
        pds-type = CurrencyPdsType
        path = "/amt/pmtAmt/ccy"
      }
    ]
    local-instrument = [
      {
        pds-type = InstrumentPdsType
        path = "/prcgInstrs/lclInstrm/prtry"
      }
    ]
  }
}

Query ODS using Inquiry

In some cases, the metrics processor queries ODS (Operational Data Store) database to retrieve any missing data such as events and PDS (Processing Data Structures) objects. This has been done using a direct connection to the ODS MongoDB collections. It is now possible to configure the metrics processor to utilise ODS Inquiry to retrieve this necessary data.

This functionality is optionally configurable. If desired, add the following to your IPF Metrics Processor configuration:

ods.inquiry.client {
  version = 3
  // Only the process object and pds object connectors are required
  process-objects.enabled = true
  pds-objects.enabled = true

  // Replace with your deployed ODS Inquiry host and port
  http.client {
    host = "ods-inquiry-host"
    port = 8080
  }
}

We recommended that you move to using this ODS client configuration for the metrics processor as it will become the default in the future; at which point, ods.http.client.host and ods.http.client.port will be required configuration for an instance of IPF Metrics Processor.

An instance of ODS Inquiry is required within your deployment for these new connectors to work.

Verification of Payee (VoP)

VoP Requester

Deprecated Kafka Headers

  • The following headers are now deprecated (PAY-15687) and will be removed in IPF Release 2025.4.0:

    • requestId

    • processingEntity

  • The equivalent replacement headers to be used going forward are:

    • ipf_processing_context_client_request_id

    • ipf_processing_context_processing_entity

VoP Responder

New

  • Country Filtering

    • Added functionality to filter VoP requests based on requesting agent BIC country code and an optional regulatory date. Returns a NOAP (Not Applicable) response if any of these checks are not met.

    • Country Filtering is disabled by default, so no migration steps are needed for responder to continue working

    • Please see VoP Responder for more details

Deprecated Kafka Headers

  • The following headers are now deprecated (PAY-15687) and will be removed in IPF Release 2025.4.0:

    • requestId

    • processingEntity

  • The equivalent replacement headers to be used going forward are:

    • ipf_processing_context_client_request_id

    • ipf_processing_context_processing_entity

Payment Notification Service

Breaking Changes

As part of making the Notification Service data version agnostic, some domain classes have changed which may require a migration for client-specific implementations of the notification service. See the migration notes for additional details.