Release Notes - Medium and Minor Releases

RPAA: Client Data Access Restrictions

To comply with RPAA standards, the system now restricts IBM operational users from viewing client PII while still enabling effective issue/ query investigation and resolution.

Key Updates:

• Default Data Masking for Client Support Users

According to contract agreements, Client Support users may not be permitted to access full client data by default. Client Support users will no longer be able to view sensitive client data (e.g., transaction amounts, account numbers, account names etc.). They will continue to have access to non-PII information such as transaction status and processing flow, ensuring production issues can be investigated without exposing sensitive data.

• Optional Full Data Access via Customer Authorization

In exceptional cases where full data visibility is required for investigation, customers may grant explicit access to Client Support users. Full data visibility can also be revoked after an issue investigation. This is managed through a new Data Access Control page, which is not enabled by default to users. Please contact to IBM operational team to request access to this feature.

For detailed information, please refer to the Data Access Control page.

• “Add” button available in File/ Transaction queue or details

A new “Add” action has been introduced in the dashboard to support issue investigation scenarios where Operational users do not have full client data access. This feature allows authorized users to grant Operational access to specific transactions or files on an as-needed basis, enabling more efficient and targeted investigations while maintaining appropriate data access controls. “Add” action is not enabled by default to users. Please contact to IBM operational team to request access to this feature.

For detailed information, please refer to the Transaction , Inbound files , Outbound files pages.

Revamped User Roles and Access Scopes

As part of ongoing access management cleanup, certain configuration-related responsibilities have been consolidated into existing roles to reduce duplication and simplify role management. This consolidation ensures users continue to manage configurations through a single, clearly defined role. There is no impact to supported functionality. Users who previously managed these configurations retain access through the appropriate consolidated role, providing a more streamlined and maintainable role model.

Python Version Upgrade

The platform runtime has been upgraded from Python 3.9 to Python 3.12 as part of ongoing platform modernization and due to Python 3.9 reaching end of life in lambda. This upgrade ensures continued support for security updates, improves performance and stability, and maintains compatibility with supported cloud infrastructure.

This change is internal to the platform and does not impact existing user workflows or require any client action. As a standard best practice, clients are encouraged to perform UAT regression testing to confirm that no issues are observed in their specific environments.

Notification Category Display Improvement

The notification category label has been updated to improve clarity during notification setup. Where notifications were previously displayed with a category of “Undefined”, they are now shown as “Dispatcher”. This change provides clearer context when creating email or file-based notifications and helps ensure notification settings are easier to understand and configure. No client action is required.

Financial Message File Notifications

Support has been added for file-based notifications on financial message flows, allowing users to receive alerts when a financial message file enters a failed state. This enhancement improves visibility into file processing outcomes and helps teams respond more quickly to issues during financial message exchange. Notification configuration is available through both the user interface and APIs. No client action is required unless clients wish to enable this feature.

Enhanced Platform Monitoring and Alerting

Platform monitoring has been enhanced with additional alert coverage to improve detection of critical errors and anomalies. This update strengthens real-time visibility into platform health and supports faster identification and response to operational issues. Enhancements include as below,

• Automated Alarms: New automated alerts were added to improve monitoring of system health, including storage levels, performance indicators, and response times. These alerts are active in both primary and disaster‑recovery regions and are integrated with EPS ALARM for timely notification.

• Standardized DB Alarms: A standardized set of database health and performance alerts is now in place across all environments. These alerts have been fully tested and are integrated with EPS ALARM to ensure immediate visibility into issues.

• Automated Layer Publishing: Automation was implemented to securely update and publish new versions of the Lambda Insights monitoring layer. This ensures consistent availability of the latest monitoring capabilities while reducing manual effort.

• Healthcheck Notifications: AWS Health Notifications were enhanced to include alerts for Account‑Specific Issues, providing complete coverage of health notifications across both UAT and Production environments.

• Script and AMI Fix for Antivirus Scan: A startup issue affecting the antivirus scanning service was resolved through updates to initialization logic, enabling reliable service operation and consistent log generation across production systems.

• Antivirus Scan Monitoring Enhancement: Enhanced monitoring was added for AVScan EC2 instances, including new ClamAV‑specific alerts for disk usage and container availability. CloudWatch alarm configurations were also improved to correctly handle dynamic EC2 instance IDs, ensuring accurate alarm state transitions when instances are replaced.

As a result, the Operations team can be alerted in a timely manner when issues occur, enabling faster remediation. These enhancements are internal to the platform and do not impact user workflows or require any client action.

Transaction Search - Message User Reference Added

Transaction search has been enhanced to support searching by Message User Reference (MUR), also referred to as User Reference. This field is now indexed and searchable through both the API and the user interface. This enhancement improves traceability and investigation workflows by allowing users to locate transactions using external or client-provided references, supporting both English and French labels.

Data Access Control - Entity Type Filtering

The Data Access Control has been enhanced to support filtering by entity type (Files or Transactions), allowing transactions and files to be retrieved independently. This enhancement supports the Data Access Control page in the Administration section and ensures existing behavior remains unchanged when the filter is not applied, while improving flexibility and efficiency when managing access to transactions versus files.

Improved "Add Access" Modal to Data Access Control page

The Add Accessmodal has been enhanced to provide a clearer and more consistent user experience across the platform. The modal now dynamically reflects whether transactions or files are being added, based on the originating screen. A selection counter has been added to show how many items have been selected before granting access, making the process more intuitive

Error While Approving Transaction

An issue was identified where an error could occur during transaction approval if the transaction status was changed outside the approval flow (for example, via backend updates), leading to inconsistent approval behavior. This issue has been resolved. The system now correctly handles approval attempts in such scenarios and logs the appropriate outcome without causing approval failures.

Not Able to Edit Data Archive Period During Organization Edit

The system now allows users to edit the data archive and live retention periods after an organization has been created, providing greater flexibility in managing data retention settings.

Unauthorized Error on Transaction Details & Transaction Import Page

A regression issue was resolved where users were incorrectly receiving an "access unauthorized" error when navigating to the Transaction Import page by removing ruleset in Import screen & Transaction Details page. This impacted both Client Support and regular users.The Transaction Details page now loads correctly for authorized users, restoring expected access and ensuring uninterrupted investigation and support workflows.

Service Error During Diagnostic Audit Creation with TTL

An issue was identified where a service error occurred when creating a diagnostic audit that included the TTL field. This error was triggered during diagnostic creation in the service layer, preventing the audit from being successfully created.

The issue has been resolved to ensure diagnostic audits can be created successfully when the TTL field is provided, restoring expected behavior during diagnostic audit processing.

Legacy Unicity Check Removal

As part of ongoing platform modernization, the legacy unicity check has been removed. The previously used unicity logic and related configuration have been fully retired.

Going forward, the system relies on the new unicity mechanism for file processing, ensuring consistent behavior and alignment with the platform’s supported architecture (primary and DR region). New unicity calculation could avoid receiving or sending files just in case we switch to DR. This change does not require any client action and has no impact on existing workflows.

Additional User Profile Fields

New security-related fields have been added to the User Profile page. These additions provide greater visibility into the user activity history. The newly added fields include:

• Last Session Login
• Last Session IP Address

For detailed information, please refer to the User Profile page.

Revamped User Roles and Access Scopes

To better align user roles with their intended permissions and actions, we have revamped the roles and their associated scopes, ensuring that each role has the appropriate access level and capabilities. These updates enhance both security and role clarity across the system.

For more information, please refer to the Default role specifications.

Transaction Search Clearer Routing Information

To improve clarity around routing details, the Transaction Search results have been updated to display Instructing Agent BIC and Instructed Agent BIC columns. The Operation Type column has been removed, and the columns have been reordered to provide a more logical layout. These changes deliver a more consistent view for payment investigations and reconciliation. This update applies only to Transaction Search in this release; the Transaction List screen will be aligned in the next release.

For more information, please refer to the Transaction Search page.

User Roles Improved Interface Alignment

Building on the previous release revamp of user roles and scopes, this release introduces further refinements to how roles are reflected in the user interface. Clients may notice changes in the menu and home page, where certain links are now hidden if they are not relevant to the user’s assigned role. For example, a user without configuration permissions will no longer see the payment processing configuration screens (Flows, channels), since access to those actions is not part of their role. Importantly, no rights have been removed; users can still perform the same actions as before. The update simply removes non-actionable links, reducing clutter and ensuring the interface reflects each role’s intended capabilities.

For clients wishing to expand access, the full list of available roles and their descriptions is available in the Default Role Specifications page.

File Processing with Non-UTF8 Characters

A new global configuration is available to ensure files containing non-UTF8 characters can still be processed. When this configuration is activated, any non-UTF8 characters are automatically dropped from the file instead of causing it to fail. By default, the configuration is not enabled; clients who need it may request activation. This helps avoid disruptions when exchanging files from external sources.

Extended Support for Fractional Seconds in CreDtTm Field

The system aligns with CBPRPlus guidelines from SWIFT, where the CreDtTm (Creation Date Time) field follows the format: YYYY-MM-DDThh:mm:ss.sss+/-hh:mm, with three fractional seconds (sss) recommended.

Although CBPRPlus suggests 3 fractional digits, SWIFT systems accept more. To ensure flexibility and compatibility, the database column size for the CreDtTm field has been increased to support up to 255 characters, accommodating extended fractional seconds and other valid formats.

MQ Connectivity Status in UI

An issue affecting the MQ inbound connectors has been resolved. Previously, the connectivity status (enabled/disabled) was not accurately reflected in the user interface, which limited the ability of operational teams to investigate incidents. With this fix, the UI now correctly displays the real status of each connector, allowing operational teams to act immediately and reduce the risk of payment processing disruption.

If the system cannot connect to a queue after three retries, the MQ connection is automatically disabled to avoid repeated errors and allow operations to address the issue quickly.

Business Day Check Source Update

As previously communicated, the system now leverages the SWIFTRef Business Day Calendar for all business day validations. The previously used Copp Clark external calendar has been deprecated. Going forward, all validations will rely exclusively on the SWIFTRef calendar to ensure full alignment with industry standards.

Extended Storage for Rejection Reasons

To improve transparency and support more effective troubleshooting, the character limit for status rejection reasons has been increased. This enhancement ensures that full exception messages generated by validation or mapping failures in our message transformation tool are now captured in full, without truncation.

• The database now supports up to 2048 characters for status rejection reasons.
• All existing data remains preserved after this update.
• The platform UI has been updated to display longer messages where applicable.
• PDF reports will show a summarized version of rejection reasons, limited to 150 characters for clarity. Please refer to the Bug Fixes / Misaligned Rows in Reports for Long State Reasons Section.

For more information on how to access Inbound File and Transaction State Information from UI, please refer to the following links: Inbound File Details, Outbound File Details and Transaction Details.

Improved File Upload Security and Validation

The API file upload process has been enhanced for better security and user feedback. It now validates the file type and size upfront (only XML, plain text, JSON, and CSV under 150 MiB are allowed) and rejects invalid files with clear error messages. All files are scanned for viruses before storage, and users are promptly notified with error messages of any upload issues in the UI. These updates improve protection and transparency when uploading payment files.

For more information on how to upload an Inbound File from UI, please refer to the following link: Inbound File Import.

SWIFTRef Portfolio Evolution – Calendar migration

In alignment with the SWIFT Portfolio Evolution, the product has been enhanced to integrate with the SWIFTRef Calendar for business day validation, including holiday and weekend checks. The existing integration with Copp Clark is planned for full decommissioning in an upcoming release.

The SWIFTRef Calendar provides a list of banking holidays per country or financial centre. The adoption of this file further enhances the accuracy and standardization of holiday referencing across payment flows.

Key Benefits:

• Compliance with SWIFT standards and ISO 20022 guidelines.
• Access to richer, centralized holiday data directly from the SWIFTRef portfolio.
• Improved accuracy in business day checks, reducing payment rejections and manual intervention.

This change applies only to payment flows that use Business Day validation within their Date Configuration settings. All other flows remain unaffected.

For more information on Business Day check, please refer to the following link: Date Configurations.

Improved Duplicate File Handling

Enhancements have been made to strengthen the platform’s ability to detect and manage duplicate files, improving overall reliability and operational efficiency. These improvements ensure consistent behavior across both Primary and Disaster Recovery regions, supporting seamless operation during failover scenarios.

For more information on actions available if a duplicate file is detected, please refer to the following link: Inbound File Failed.

Improved Time Zone Accuracy in Client Communications

Missing File Type and Category After Correction

An issue was resolved where the File Type and Category fields were incorrectly left blank after an inbound file was corrected and re-approved after failure. This issue occurred only for inbound files that failed due to an exception within the dispatcher mechanism responsible for identifying the appropriate payment processing flow.

• Previously, when a user corrected a failed file and another user approved it, the file appeared in the File Queue and Audit History without its File Type and Category.
• This issue has now been resolved. The platform will correctly retain and display the File Type and Category after file correction and approval.

This fix ensures consistent file metadata visibility across audit trails and processing queues.

For more information on how to access Inbound File Lists from UI, please refer to the following link: Inbound File.

Misaligned Rows in Reports for Long State Reasons

An issue was resolved where records in the generated report became misaligned when the State Reason exceeded 365 characters for failed transactions.

• Previously, long rejection reasons caused incorrect row formatting, resulting in data being misplaced in the report.
• To prevent this, the State Reason is now truncated to 150 characters in the report, ensuring proper alignment and consistent formatting across all rows.

This fix ensures accurate and reliable reporting, even when detailed error messages are present.

For more information on how to configure Reports, please refer to the following link: Reports.

Incorrect Debtor Enrichment with IBAN and OrgID

An enrichment logic issue related to incoming pacs.008 messages using SWIFTRef has been corrected:

• Previously, when both the Debtor IBAN and OrgID were present, the system incorrectly enriched the Debtor entity instead of only enriching the Debtor Agent as intended.
• Now, the enrichment process correctly uses the Debtor IBAN to enrich only the Debtor Agent, while preserving the original Debtor information provided in the message.

This fix ensures compliance with expected enrichment behavior and maintains data integrity for ISO 20022 messages. This issue has already been hotfixed in UAT and PROD.

File Search enhancement on filter

To enhance the file search experience, the "Transformation Only" cartridge type has been added to the File Type filter, available when "Inbound" is selected under File Direction.

This fix ensures that all relevant transformation mapping types, such as Passthrough and One Transformation, are accurately reflected in search results.

For more information about the File Search capabilities, please refer to the following link: File Search.

Removal of JMS Metadata from MQ Messages

As part of the recent Java-based MQ connectivity implementation, the platform's MQ connectors began using a JMS-compliant Java client to send messages to MQ queues, which results in the inclusion of JMS headers such as the MQRFH2 structure. These headers, which contain metadata like message type and destination details included in the DataPDU/MessageProperty, are standard when using JMS with IBM MQ and do not impact the payment processing. However, not all downstream systems require or expect this information. To improve compatibility, the implementation is updated to remove these headers, restoring consistency with the prior implementation.

Python-Based MQ Component

Following the successful rollout of the Java-based MQ connectivity in last month’s release, we have now fully deprecated the legacy Python-based MQ component.

• As of May 31st, 2025, all environments are using the new Java-based MQ connectors, which leverage IBM-supported libraries and JKS (Java KeyStore) for secure authentication.
• The deprecated Python component is no longer maintained or active in the production environment.

This deprecation ensures continued compatibility, long-term maintainability, and improved performance for all MQ integrations.

Removal of Legacy Audit Log Page

To ensure stricter control over sensitive information, the Administration - Event page has been removed from the platform. This page previously displayed audit information that could include client financial data and was accessible to client users without the appropriate financial message access.

This update is a proactive security measure and does not impact core platform functionality or access to authorized financial data views. All associated links, backend logic, and API definitions have been fully removed to ensure consistent and compliant access management.

Removal of the AFT dashboard

The AFT Dashboard has been removed from the system UI, as it is no longer in use by any clients. This change is part of our ongoing effort to streamline and simplify the user interface. As a result, under the Messaging tab, only WIRE dashboard components will now be displayed.

In line with SWIFT's guidance, SwiftRef will undergo a transformation to align with ISO 20022 standards. The migration to the new SwiftRef directory (Identifiers directory) is suggested to be done by the end of 2025.

The updated SWIFTRef enrichment using the Identifiers Directory will be available in UAT starting the week of June 16, and is scheduled for production release on July 26. We recommend completing your testing within this one-month window.

Reference: SwiftRef 2.0 Migration

To enhance our transaction details page with ISO 20022 compatibility, we have introduced new settlement and payment information fields based on the ISO 20022 standard. These include:

• Settlement Method
• Sequence Type
• Category Purpose
• Local Instrument
• Clearing System

This improvement means users no longer need to inspect the full MX file content to retrieve key information. The transaction details page now surfaces these relevant fields directly, offering a clearer, faster view of essential payment data at a glance.

Reference: Transactions

Our MQ connectors, originally built in Python, are being migrated to Java to leverage IBM MQ Java libraries, developed and maintained by IBM, to ensure better compatibility, long-term support, and improved performance.

What’s Changing?

To support this migration, we will be transitioning your current MQ connectivity from using KDB (Key Database) to JKS (Java KeyStore), which is required by our new Java-based components.

Our IPC Operational team will perform the update of the application as well as each existing MQ configuration and conduct internal connectivity testing in UAT environment on May 20th. However, we strongly recommend that you also perform minimal testing to ensure your end-to-end payment processing continues to function as expected. The IPC Operational team is planning to apply the same changes on May 31st. If you have any questions or concerns, feel free to reach out.

The SWIFT Standard Release 2025 documentation is available. Do not hesitate to contact the IPC team if you have any questions.

To allow flexibility of changes between transaction status, in To Approve status, there are Approve, Reject and Correct (newly added) buttons. When user clicks Reject - the payment will go to Rejected status. User will not be able to process the transaction again. When user clicks To Correct - the transaction will go to To correct status. User could correct the fields in the transaction.

Reference: Transaction - Approval

To help maintain data accuracy and reduce the risk of errors, flows now offer a new option to always require manual approval for every file manually edited by a user.

Reference: Flow

Already available for Payments and PSR categories, users can now configure notifications for multiple statuses associated with the category Financial Message.

Reference: Notifications

The File Format, Message ID, and Original File Creation Date for both Inbound and Outbound files will be now included into the file email notifications. This update provides users with quick access to key file details.

For reports sent by email, a new option is configurable to prevent the email from being sent if the report is empty, or conversely, to send an email containing an empty report as an attachment.

Reference: Reports

To allow flexibility of changes between transaction status, in Hold status, there are Release, Reject and Correct (newly added) buttons. When user clicks Reject - the payment will go to Rejected status. User will not be able to process the transaction again. When user clicks To Correct - the transaction will go to To correct status. User could correct the fields in the transaction.

Reference: Transaction - Release

To align with IBM acquisition, we are going to update the Domain Name for the platform. Starting from Aug 27th for UAT and Sep 7th for Production, we will be having a new domain name to access IPC Wire Services.

Ability to now execute file validation to meet regulatory compliance for Passthrough files. This update enhances the validation process, ensuring accurate and efficient handling of payment files.

References: Cartridges and Flows

Configuration Manager users can now set channels to always remain open. Ensuring seamless operation and system adaptability for channels that never close.

Reference: Channels

Report Manager users can now configure reports to avoid generation if the content is empty. If configured, automatic reports won't generate if all types are empty, logging a warning instead. Alternatively, reports can be configured to generate even if empty, with all pages showing empty messages. This update offers greater control, ensuring reports are only generated when necessary.

Reference: Reports

Report manager users can now set report generation intervals every 5, 10, 15, or 30 minutes, and every 1, 2, or 3 hours throughout the day. This update also allows the configuration of up to 12 fixed schedules for report generation, providing greater flexibility and precision in configuring automatic reports.

Reference: Reports

Flow managers can now add a file approval step for Payment Status Reports (PSR) and Financial Messages received from SWIFT or other networks. This update enhances flow management by allowing the inclusion of approval steps for new categories.

Reference: Flows

Channels now support transaction debulking with three options: Always, Never, or Scheduled. The "Always" option sends completed transactions immediately, leaving out those needing correction. The "Scheduled" option allows setting specific times and dates to send completed transactions, even if some are still incomplete. The "Never" option ensures all transactions from the same inbound file are sent together. Transactions requiring manual intervention remain processed until resolved, ensuring smooth outbound processing.

Reference: Channels

To ensure straight through processing, transactions without changes manually by an user can go smoothly without approval. Correction Approval allows users to approve the transaction only when a transaction is being updated by an user. Level of approval can also be configured.

Transaction approvers can now easily see changes applied to transactions awaiting correction approval. This update allows approvers to view old values in red and new values in green within the transaction approval modal, similar to the user approval modal. This improvement simplifies the review process, making it easier to identify and approve necessary corrections.

Reference: Flows

Users can now easily search for Passthrough messages from File Search using file format or transaction reference. This update enhances search functionality by adding new fields to the UI. This enhancement improves search efficiency, allowing users to quickly locate specific Passthrough messages.

Reference: File Search

File approval limit has been removed from the user and client support user interfaces. This change simplifies the configuration process, ensuring a more straightforward setup for users.

Reference: User management

User reports can now retrieve all users created under an organization, including both approved and unapproved users. This update enhances visibility by including inactive users in reports. This enhancement provides a comprehensive view of all users, ensuring better management and oversight of user status within the organization.

Reference: User management

To manage the access in the organization configured in IPC Wire, we have enabled a IP whitelist feature. User can configure a list of IP from which users would be able to connect under Client Organization.

Reference: Organization management

To better handle the sequence that is used in External Provider, we have added a new logic to calculate the sequence in different type of external provider. One example is that file naming with a specific sequence can be used in output connectivity external provider.

Reference: Sequences

The platform now offers enhanced report management capabilities, allowing users to configure custom reports based on specific criteria without manual database configuration. This update aims to streamline the integration of customer-specific reports with their internal systems.

Reference: Reports

The system now supports processing Pacs.002 messages to determine payment status and trigger Trck.001 messages when necessary. This update enhances the payment tracking system by updating the tracker with the latest payment statuses.

To better distinguish the transactions require processing or a passthrough, we have added a new category called - Financial Message. This category is a transaction that only require a passthrough. It would be shown in Dashboard filter, File search category and Import category.

References: Live Board and File Search

This enhancement is to allow clients to have a single transformation or no transformation for a payment. There are market needs - (1) to transform a message (from MT to MX or MX to MT) or (2) just send out the message to next system as a passthrough in IPC Wire (no transformation). With the configuration of Flow, users could easily achieve the above.

Reference: Flows

This enhancement is facilitated through the introduction of a new "INBOUND" keyword, which allows users to seamlessly incorporate the name of the inbound file into the outbound file name pattern within the outbound integration configurations.

Reference: Output Connectivities

In our most recent enhancement, we've significantly improved the report management experience for users. Recognizing the need for a more efficient and user-friendly approach to managing and resending old reports, we've introduced a new screen dedicated to report generation.

This update features two main components:

Report Configuration Tab: Integrates the existing report configuration content, now housed within a newly designed tab for streamlined access and management.

Generated Reports Tab: A fresh addition to the report screen, this tab is specifically for viewing reports that have been previously generated.

Reference: Reports

In our recent update, we've revamped the default filename format in our product, transitioning from "EPS__OUT__{%Y-%m-%d}__{uuid}.txt" to "IPCWS_{%Y%m%d%H%M%S}_{uuid}.txt". This change reflects our rebranding from EPS to IPC, enhancing file naming precision by including a detailed timestamp.

Reference: Output Connectivities

We're excited to introduce a new external provider Transaction Enrichment and Customer Information Enrichment. This feature allows for the seamless enrichment of payment transactions such as debtor and creditor addresses, alongside the Unique End-to-end Transaction Reference (UETR).

Reference: External Providers

Users will now find a new filter dropdown on the Wire Dashboard. This feature offers the options "All," "Payment," and "PSR," allowing users to tailor the dashboard view according to their specific needs. The functionality will be available upon request.

Reference: Live Board

Notifications can now be automatically sent when files of specific formats are received. This update allows users to customize alerts for particular file types, improving focus and efficiency in managing important notifications. It's a streamlined way to ensure you never miss critical arrivals, enhancing productivity and workflow management.

Reference: Notifications

For now, the system allows users to include the additional information of a payment in the Report type.

Reference: Reports

To enhance the flexibility in determining the channel, here we introduced a channel rule configuration. This allows users to pick up different determination parameters as a rule trigger and hence to pick up a channel associated with a transaction.

Reference: Rules

For customer credit transfer received & corresponding cover payment received, the system is now able to match both payments together. If a customer credit transfer that requires a cover payment is received in the system first, the payment will stay in the “Pending Cover” queue.

This feature is not available by default. If you are interested in using these new capabilities, please contact the IBM Payments Center.

To align with the IBM acquisition, the system logo and naming will be updated in the platform and user guide.

According to the Payment Canada requirements, timezone would need to be included in the Creation Date & Creation Date Time. To align with that, instead of using UTC in the payments, we would update the Creation Date & Creation Date Time to the original time & timezone we received from the payment or the timezone configured in Channel.

Reference: Channels

To calculate the correct time for each organization with the correct timezone, we introduce the capability to configure the timezone in user, organization, channel, and report levels. The organization’s daily limit or FX quote will be configured based on the organization’s timezone. For the payment-related & business hours of a channel, it will be configured based on the channel timezone. It is suggested to use the same timezone within an organization.

References: User Profile, Organization management, Reports, Channels and Transaction - WIRE Creation

To allow more flexibility in the outbound file generation, we introduced the configuration of multiple fixed schedules on the channel configuration.

The options available to determine the Header ID/Group ID and Transaction ID for the outbound file generation are now configurable using a drop-down to simplify the choice and add more clarity.

Reference: Channels

The support email used to generate notification to the customer is now ipc-ws-support@wwpdl.vnet.ibm.com to align with the product name: IPC - Wire Services.

After a rule is updated, the user would need to click regenerate in the ruleset to reload all rules contained in the rule set with any last change. To be more efficient, we have introduced a bulk regeneration button for rulesets. With one click, all the rules in the rulesets will be refreshed to the latest configurations.

Reference: Rule Set

With the yearly update in regulatory requirements on Standard Release from SWIFT, our solution is complying with the standard SSR2023 and it is now live in production.

To fit the market and users' needs, we have introduced a new product feature: Cover Generation - Nostro & SSI enrichment. The system can identify whether the payment would require an instructing reimbursement agent or instructed reimbursement agent by looking up Nostro Data that the organization configured or the SSI Directory provided by SWIFT. The user could configure whether the enrichment to overridden in the payment.

This feature is not available by default. If you are interested in using these new capabilities, please contact the IBM Payments Center.

Reference: Cover Generation - Nostro and SSI Enrichments

To fit the market and users' needs, we have introduced a new product feature: Manual Cancellation. The system would be able to cancel a transaction with one click from a user. The user could pick the cancellation code to state the cancelation reason and send the cancellation request to the next correspondent. When there is a response received, the system would be able to link it with the request and transaction requested to be canceled. Hence, the system would update the transaction status according to the response answered.

This feature is not available by default. If you are interested in using these new capabilities, please contact the IBM Payments Center.

Reference: Manual Cancellation

Product Improvements

To be more efficient in managing the rules, we have introduced a button to bulk delete the rules instead of deleting them one by one.

Reference: Rules

To fit the market and users' needs, we have introduced a new product feature - Cover Generation. The system would be able to identify whether your payment would require a cover generation and generate a cover payment automatically. What’s more, you could manually create a cover payment if needed.

This feature is not available by default. If you are interested in using these new capabilities, please contact the IBM Payments Center.

To allow flexibility in the separation of roles, we have introduced a new scope - fraud:display. The intercepted Transactions queue can only be seen with this new scope associated with a user.

Reference: Role management

On the Notifications page, users can set up a file or email generation once the transaction/file reaches a specific state. Given that we are allowing more notification types in the future, we have set up a filter for users to easily select a specific type.

Reference: Notifications

With organizational structure, some resources can be shared from parent organizations to the child organizations, e.g., Roles, Cartridges, and Rules. For Rules, there are 2 types – (1) created by System or (2) created by organizations. To differentiate between system or organization-associated rules and to share the rules with child organizations easily, we introduced in the product a new Product Rule management.

What are Product Rules?

1. Product Rules are system-created and common use.

2. Product Rules will be created once you create a new organization.

3. Product Rules will be carried forward to all parent & child organizations.

4. Product Rules cannot be created or edited by normal users.

5. Product Rules can be assigned to the Parent Organization when Client Support users create the organization.

How would you know if this is a Product Rule?

On the Rules page:

• Organization equals SYSTEM means it is a Product Rule. It cannot be edited by normal users.

• Organization equals Organization Name means it is created by the user at level 1.

Reference: Rules

SSR2023 version is available to be used in UAT. Please reach out to your support user for more details.

Reference: SWIFT Standard Release 2023

With organization structure, some resources can be shared from parent organizations to the child organizations, e.g., Roles, Cartridges, and Rules. For Cartridges, there are 2 types – (1) created by System or (2) created by organizations. To differentiate between system or organization-associated cartridges and to share the cartridges with organizations easily, we introduced in the product a new Product Cartridge management.

What are Product Cartridges?

1. Product Cartridges are system-created and common use.

2. Product Cartridges will be created once you create a new organization.

3. Product Cartridge will be carried forward to all parent and child organizations.

4. Product Cartridges cannot be created or edited by normal users.

5. Product Cartridge can be assigned to the Parent Organization when Client Support users create the organization.

How would you know if this is a Product Cartridge?

On the Cartridges page:

• Organization equals SYSTEM means it is a Product Cartridge. It cannot be edited by normal users.

• Organization equals Organization Name means it is created by the user at level 1.

Reference: Cartridges

To be more comprehensive of rule usage with fields related to numbers, there are 4 more comparators available in Rule setup. They are:

• greater than (Number)

• lesser or equal to (Number)

• length greater than (Number)

• length lesser or equal to (Number)

Moreover, there is a long list of parameters in Rule parameters/comparators. A new filter list is available on the product so that users can search easily for the parameters they want.

Reference: Rules

To allow flexibility in utilizing the date configuration, users could select multiple currencies in Source Currency Code and Destination Currency Code in one date configuration instead of setting up multiple date configurations.

Reference: Date configurations

To be more comprehensive of rule usage with Reference Data (with type Custom List), there are 4 more comparators available in Rule set up. They are:

1. starts with (Reference Data list)

2. not starts with (Reference Data list)

3. ends with (Reference Data list)

4. not ends with (Reference Data list)

For example, a Reference Data Custom List as below -

The rule is If Payment Type ends with (Reference Data list) “1”, then only the first “example_1” will be selected.

Reference: Rules

To be more efficient in setting up the SWIFT Test Mode configuration, users can now just enable/ disable the SWIFT Test Mode from Level 1 Organization and the same settings will be shared with the children organizations.

Reference: Organization management

To allow flexibility in utilizing the channels and to better manage the number of channels, users could select multiple currencies in channel determination parameters in one channel instead of setting up multiple channels.

Reference: Channels

In the Organization creation/edition screen, we can specify a list of organization identifications, such as national ID, BIC, and originator ID. To be comprehensive in Rules set up, the organization identifications are now available to be reused in Rule parameters. Users could now select Rule Trigger (equal or not equal to organization identification) or Consequence (copy the value from) to a specific organization identification.

Reference: Rules

To allow flexibility for users to manage their organizations, users with organization manager roles and access to level 1 organizations could now edit level 1 organizations without the client support manager’s help. Users could still edit the organizations which are under level 1 organization.

Reference: Organization management

To be more comprehensive in Rules setup, intermediary agents 2-5 are now available as an option to be picked up from Rule triggers and consequences.

Reference: Rules

The IPC- Wire Services product would have a major release every 6 months. To communicate the significant changes ahead of time, we have published a major release note which introduced the high-level functionalities that users might expect 3 months later. Please note that these major changes are not available by default. If you are interested in using these new capabilities, please contact the IBM Payments Center.

Product Improvements

To provide a better user experience in configuring the channel, business hours configuration will be available in the Channel setup screen now. Users can now configure the channel & business hours with the start of the day, end of the day & timezone in one go instead of hovering around 2 pages. Moreover, users will be able to do a bulk postponement on multiple channel business hours.

Reference: Channels

To display the external provider better in other dependency screens, an external provider description is now mandatory. Notes - Existing external providers with blank descriptions will not be impacted.

Reference: External Providers

To be more efficient in creating the rules, users can now duplicate the rule. Rule description, type, trigger, and consequences will be copied. The user would need to give a new rule name.

To be more organized in showing several rule triggers & consequences, there is a minor update in the display of Rule creation, edition & view screen.

Reference: Rules

To be more specific on the cartridge category and ensure the user is picking the correct direction for a cartridge in creation/edition screens, some new validations are available - When the user selects Category as Dispatcher or PSR, the Type drop-down would show Inbound only; When the user selects Category as Notification, Type drop-down would show Outbound only.

To bring convenience for users in creating a transaction manually, we would have more choices to pre-fill a transaction in the “Create a Transaction” screen going forward. Therefore, we have grouped the Pre-filled Options with a drop-down at the top instead of having a long list.

Once the user selects a choice from the Pre-filled Options drop-down, a related required field will pop up right next to it. For example - when a user picks “Apply a Template”, an existing Template drop-down would be shown on the right for users to pick a Template.

To better differentiate & manage the external provider, we introduced a new Network option in External Provider creation & edition screens. With the Network option, users can pick whether the External Provider is for Wire or AFT.

Reference: External Providers

With organization structure, some resources can be shared from parent organizations to the child organizations, e.g., Roles, Cartridges, and Rules. For Roles, there are 2 types – (1) created by System or (2) created by organizations. To differentiate between system or organization-associated Roles and to share the roles with organizations easily, we introduced in the product a new Default Role management.

What are Default Roles?

1. Default Roles are system roles that consist of basic scopes.

2. Default Roles will be created once you create a new organization.

3. Default Roles will be carried forward to all parent and child organizations.

4. Default Roles cannot be created or edited by normal users.

5. Default Roles can be assigned to the users.

How would you know if this is a Default Role?

On the Role page:

• Organization equals SYSTEM means it is a Default Role. It cannot be edited by normal users.

• Organization equals Organization Name means it is created by the user at the organization level.

Reference: Role management

To allow greater flexibility and precision in searching a transaction in AFT and Wire, a new capability is available to allow users to search for words or phrases that match a specific pattern rather than an exact phrasing when searching with the below references:

• Transaction Reference & Transaction Related Reference for Wire

• Originator’s Cross Reference Number & Transaction ID for AFT

References: File Search and Transactions Search.

In Rule Trigger, there is an option for users to choose References as a rule condition. To ensure users are given a correct reference name to do a comparison, a new reference drop-down is available while keeping the existing capability to fill in reference names manually. Going forward, users can pick the reference name in the drop-down or fill in the reference name manually if needed.

Reference: Rules

To better present the timestamp and avoid any confusion with the timezone in the Transaction/File history page, the audit timestamp is now displayed using the user’s default time zone and a tooltip specifying UTC is available too.

To allow our users to better understand the status of each report generated under the live board, we have added the title with the status.

How to generate the report for transaction/file status details?

In the transactions/files status details screens, click CSV/PDF/Print for your preference to generate the report. Status has been added to the Report title.

Reference: Reports

To allow better customization of report generation, for a medium such as email or output connectivity, automatic End-of-month report generation is now available. Users could specify the time they want the report to be generated as the end of the month.

Reference: Reports

To provide a better search experience on Wire/AFT Transaction & File Search, the product has enabled search based on All organizations.

For transaction search, the User could pick the search criteria with

(1) All organizations OR a specific organization

(2) External providers depending on the organization selected

For file search, the User could pick the search criteria with

(1) All organizations OR a specific organization

To provide a better search experience on Wire/AFT Transaction Search, the search criteria would not be erased when there is a change in the organization. Therefore, a user could save time by re-entering the fields again.

Reference: File Search

To improve the input connectivity management, a new status (Enabled/Disabled) is now available on configuration management screens.

For SFTP & MQ input connectivity only:

To optimize the usage of input connectivity, if there is a connection error that occurs with the SFTP & MQ server, the input connectivity will be disabled automatically. A user is now able to reactivate the disabled input connectivity from the configuration screen.

To allow better customization of report generation, automatic daily/weekly/monthly report generation is now available on the product. Users could specify the:

• Frequency (daily/weekly/monthly)

• Schedule (hours, minutes, days)

• Medium (email/output connectivity/download)

Reference: Reports