Table of content

• Improvements
  • Counterparty management via API
    • Counterparty approval
    • Counterparty grouping
  • Payment file character sanitization

Improvements

Version 6.6.1 extends the FinologeeBKO API with counterparty lifecycle management and introduces automatic character sanitization for payment file processing.

Counterparty management via API

The FinologeeBKO API now supports approving and grouping counterparties, allowing external systems to manage the full counterparty lifecycle without manual intervention in the back-office interface.

This enables organizations that manage counterparties in their own systems to keep FinologeeBKO in sync automatically, with approval status and group membership reflecting decisions made upstream rather than requiring back-office intervention at each step.

Counterparty approval

After creating a non-approved counterparty via API — which performs IBAN and BIC validation — the external system can approve the counterparty through a dedicated API call.

Counterparty grouping

External systems can now assign counterparties to groups via the FinologeeBKO API. This allows organizations managing counterparties programmatically to maintain the same organizational structure in FinologeeBKO that they use in their own platforms.

Payment file character sanitization

When processing pain.001 and MT101 payment files, FinologeeBKO now automatically replaces unsupported characters before submission. This sanitization follows the same character substitution rules applied by the Multiline payment platform, ensuring compatibility without requiring file corrections on the sender's side.

Users submitting payment files that contain special or non-standard characters no longer need to pre-process their files manually. The platform handles the substitution transparently, reducing file rejection rates and simplifying the payment submission workflow.

Table of content

• Improvements
  • Payment settlement channel selection
  • Rebranding to FinologeeBKO

Improvements

Version 6.6.0 introduces payment settlement channel selection, giving users explicit control over how payments are routed, and completes the rebranding of the platform from LYNKS to FinologeeBKO.

Payment settlement channel selection

When creating a payment, users can now select a settlement channel — Normal, Instant, or Urgent — to control how the payment is routed to the bank. This replaces the previous NORMAL/URGENT toggle with three clearly defined options that reflect the actual processing rail: standard SEPA clearing, SEPA Instant, BACS, CHAPS, FPS, or other bank-specific channels depending on the initiating bank, currency, and payment category. The platform displays relevant context for each option, including indicative cost and speed, so users can make an informed choice.

On the back end, the selected channel determines the payment instruction fields sent to the bank, such as order type, service level, or local instrument codes. Channel configuration is bank-specific and maintained at the configuration level without requiring a release. Backwards compatibility is preserved, meaning existing payment flows continue to work without changes for tenants whose banks do not yet use the new channel selection logic.

Rebranding to FinologeeBKO

The platform formerly known as LYNKS is now named Finologee Banking Orchestrator, branded as FinologeeBKO. This update applies across the web application, mobile apps, authentication pages, domain names, and system-generated emails. The new application domain and email domain (@bko.finologee.com) are in place, with backward-compatible redirects maintained so that existing client configurations and whitelisted domains continue to function.

The mobile app is published under the FinologeeBKO name in the App Store, with updated logos and labels throughout. LYNKSDrive is renamed to FinologeeDRIVE. Tenants access the same features and workflows; the rebranding is limited to visual identity and naming.

Table of content

• Improvements
  • Authentication method onboarding flow
  • Peppol invoice receiving
  • Swift messaging API migration
  • Default signature requirements

Improvements

Version 6.5.0 introduces a revised authentication method onboarding flow, Peppol invoice receiving support, Swift Messaging API connectivity, and expanded signature requirement coverage.

Authentication method onboarding flow

To use LuxTrust or the FinologeeBKO mobile app for authentication and signature, users will have to go through an onboarding process to confirm that they are legitimately using that account. We have now revised the onboarding process to better support the user.

When an administrator enables an authentication method, the user receives an email with instructions to onboard their account to the application, followed by a second email including a one-time password or a verification link. The authentication method only becomes active once the user enters the code or follows the link and completes the verification process.

Peppol invoice receiving

The platform now supports receiving electronic invoices through the Peppol network. Incoming invoices are routed using the configured Peppol identifiers and are made available through the API, FinologeeDRIVE, and SFTP.

This extends FinologeeBKO invoicing capabilities to cover the full Peppol receive workflow, enabling organisations to accept standardised e-invoices from counterparties registered on the Peppol network without manual file handling in accordance with Directive 2014/55/EU of the European Parliament on e-invoicing.

Swift messaging API migration

Bank connectivity for SWIFT-connected banks has been upgraded to the Swift Messaging API from the legacy file-based system, improving communication with the SWIFT network and enabling both Interact and FinPlus services for direct, synchronous communication following ISO20022 standards.

This migration eliminates file parsing overhead and establishes a direct API connection for banks that support Swift Interact, improving reliability and reducing processing steps for payment submission and statement retrieval.

Default signature requirements

Signature requirements now apply by default to cover gaps in signatory rule configurations. Where no specific signatory rule is defined for a payment or operation, the platform enforces a default signature requirement to ensure authorisation controls remain in place.

A default signature requirement can be defined by the system administrator as 'Gap fallback rule'.

This prevents scenarios where payments or operations could proceed without the appropriate number of signatures or be automatically rejected due to missing rule coverage, strengthening the overall authorisation framework across all payment types.

Table of content

• Improvements and small enhancements

Improvements and small enhancements

We've made several technical fixes and enhancements to improve system reliability and data accuracy:

• External API: Restored missing transaction information in CAMT-based statements (remittance information and information to account owner) and added support for exchange rates, original amounts and currencies in statement transaction entries for foreign exchange validation
• Bank connectivity: Resolved SWIFT MT101 validation issues for foreign exchange payments and added support for CAMT.052.001.02 statement format
• Webhooks: Standardized content-type headers to application/json for better integration reliability
• Reconciliation: Fixed matching algorithm to correctly handle transactions with identical amounts and counterparties but different remittance information

Table of content

• Functional improvements
  • Multi-currency account support for FX payments
• UI and UX improvements and small enhancements

Functional improvements

Multi-currency account support for FX payments

The platform now supports foreign exchange payments from multi-currency accounts through enhanced MT101 file generation and bulk payment upload capabilities. Users can specify which currency line to use when making FX payments from accounts that maintain multiple currencies under the same IBAN.

Bulk payment uploads via CSV, Excel and pain.001 files support two additional optional fields: Ordering Party Account Currency and Ordering Party BIC. These fields enable unique identification of ordering accounts when multiple currency lines or BIC codes share the same IBAN. The platform validates ordering accounts using IBAN, BIC and currency parameters together, ensuring users can create bulk payments from multi-currency accounts with precise control over which account line processes each payment.

UI and UX improvements and small enhancements

The platform includes stability improvements for bulk payment processing and signatory rule management. Large payment file processing now uses atomic write operations to prevent file corruption during simultaneous read and write operations. Signatory rule gap calculation has been corrected to display all missing rule combinations on the first calculation. Various refinements enhance overall system reliability.

Table of content

• Functional improvements
  • Immediate payment submission
  • Enhanced payment reconciliation
  • Flexible approval workflow
  • Permission editing
• UI and UX improvements and small enhancements

Functional improvements

Immediate payment submission

Authorised SEPA payments are now sent directly to the bank without waiting for batch processing windows, eliminating cut-off time delays.

The system automatically adjusts weekend and holiday execution dates to the next banking day, ensuring prompt submission while respecting banking calendars.

Enhanced payment reconciliation

The platform now processes pain.002 status report files (ISO 20022 standard) to provide intermediate payment status updates before final settlement. Banks send these files to confirm receipt, acceptance, or rejection of payment instructions.

When a bank accepts a payment, the status updates to "Executed." Rejected payments display as "Not executed" with the rejection reason. This real-time feedback enables users to monitor payment progress and address issues before end-of-day settlement for all payment types.

Flexible approval workflow

Tenant settings approvals now require one or two signatures based on who made changes, maintaining the four-eyes principle. When a single administrator makes all changes, a second administrator must approve. When multiple administrators contribute changes, the system accepts one signature from an uninvolved administrator or two signatures from contributors.

The platform displays which administrators contributed with changes and shows approval requirements through contextual warnings and confirmation dialogs. The audit log records all approval actions for complete authorisation history.

Permission editing

Administrators can now edit user and user group permissions directly without deleting and recreating entries. The edit interface allows adjustments to permission scopes, parameter values and access levels on user details and user groups details pages.

This eliminates the previous workflow where administrators had to identify, delete and manually recreate entire permission structures for each modification.

UI and UX improvements and small enhancements

The platform's bank connectivity has been migrated to the EBICS API standard, improving reliability and performance of bank communication channels. Various refinements enhance overall system stability and user experience.

Table of content

• Functional improvements
  • Counterparty groups management
• Improvements and small enhancements

Functional improvements

Counterparty groups management

In addition to the previous release, version 6.3.1 introduces counterparty group management in the user interface. This enhancement gives users greater flexibility to organize counterparties in groups either during the creation process or at a later stage. A review step has also been added to manage the removal or addition of counterparties within existing or new groups.

Counterparty group management further strengthens granular permission controls for user access and signatory rules, building on features delivered in earlier releases.

Improvements and small enhancements

Small generic improvements have been made to improve the performance and the user experience on the application.

Table of content

• Functional improvements
  • Tenant settings approval
• Improvements and small enhancements

Functional improvements

Tenant settings approval

Managing tenant settings—such as the signatory matrix and user management—is essential for daily operations. To enhance security and control, we have introduced the Tenant Settings Approval feature.

This feature adds an extra layer of security by requiring a second person to review and approve any changes before they take effect in the FinologeeBKO application. This helps minimize risk by ensuring all administrator actions are double-checked.

You can request to enable this feature in your environment by contacting Finologee's customer support. Further details on this feature will be soon available in the FinologeeBKO user guide.

Improvements and small enhancements

We’ve made several small updates to improve performance and user experience, including:

• Enhanced validations
• Naming for signatory rules
• A smoother onboarding process in the FinologeeBKO mobile app
• Faster data loading and display

Bug fixes:

Resolved a bug that prevented transactions between ordering party accounts from being correctly reconciled.

Table of content

• Functional improvements
  • Depositary oversight workflow
  • Counterparty permission scoping
  • Auto-approve and auto-reject signatory rules
• UI and UX improvements and small enhancements

Functional improvements

Depositary oversight workflow

A new oversight workflow has been introduced to support depositaries, enabling payment instructions initiated in a different tenant to be approved or rejected. This functionality allows for a clear separation of duties and facilitates compliance in scenarios where payment initiation and oversight are handled by distinct entities. Learn more here.

Counterparty permission scoping

A new counterparty scoping feature is now available, enabling administrators to control which counterparties are visible to each user. The functionality mirrors the existing scoping logic for ordering party accounts, and now extends segregation of access to include target (counterparty) accounts as well as source accounts. The enhanced control improves data confidentiality and supports more precise user access configurations across the platform.

Auto-approve and auto-reject signatory rules

The signatory rule framework has been extended to cover payment flows that don’t require user signatures. Payments can now be automatically approved or rejected based on predefined rule logic. This enhancement streamlines the processing of small payments and ensures that every payment is subject to governance controls and auditability, even if no specific business case supports them.

UI and UX improvements and small enhancements

Various refinements across the platform to ensure a more intuitive and user-friendly interface. Enhancements included a thorough review of labels, pagination and more.