Release Version 4.50.0 (January 27, 2026)

Check configuration changes and apply them in the application.yaml if the default configuration has been overridden there

Check if the release contains migrations. Migrations can affect deployment and downtime.

Use GET /i18n/export/{fileName} to download files with current i18n properties. Check if the downloaded file is correct.

The migration is required to migrate transaction history data from the legacy BusinessProcessHistory MongoDB collection to the new business_process collection.

Key changes:

• Relocates process record classes to new sdk.finance.transaction.record.* package structure

• Converts epoch milliseconds timestamps to ISO 8601 format (OffsetDateTime compatibility)

• Consolidates type-specific fields (exchange, bank, cash desk, gate, invoice, merchant, monthly fee records)

• Creates indexes for query performance on the new collection

Usage:
mongosh "mongodb://user:pass@host:27017/db?authSource=admin" migrate_business_process_history.js

File migrate_business_process_history.js is included in the release.

Verify permission changes and assign or remove required permissions if they have been overridden

Add new properties from the I18n properties changes to the downloaded i18n properties file and add translation for them if needed.

Use POST /i18n/import to upload and apply previously downloaded i18n file with added new properties.

If any hardcoded keys are used to retrieve values from locale bundles, make sure to update the keys with the code. prefix.

New column resource created in i18n_property table. Default value core set to new column. Keys from key column of i18n_property table updated with added prefix core. to existing keys. Values of name_bundle_key, icon_bundle_key and description_bundle_key in gate_product_def table updated with core. prefix.

Сreated PostgreSQL table for the transactional outbox pattern to support reliable event delivery.

Key changes:

• New business_process_outbox table with columns: id, business_process_id, version

• Index on business_process_id for efficient outbox polling

Smart Card → In-System Card Renaming (core module)

• Updated SMART_CARD references to IN_SYSTEM_CARD in environment variables

Smart Card → In-System Card Renaming (merchant module)

• Updated payment_instrument values in tx_payment_def table

Created org_prof_kyc_def table to store KYC (Know Your Customer) definition records for organization profiles. The table tracks sanction status per profile with audit support via editaction_id reference to history tracking.

Added kyc_def_id column to org_prof_profile_base table, establishing a link between organization profiles and their KYC definitions.

Introduced OpenSanctions integration schema with three tables:

• open_sanctions_data_sync_record — tracks synchronization events with external sanctions data

• open_sanctions_entity — stores sanctioned entity details (names, aliases, addresses, identifiers, etc.)

• open_sanctions_match — links users to matched sanction entities with match scores for screening purposes

Added field external_integration to customer_verification_provider_def table

Added field external_integration to gate_provider_account_def table

New tables are created: customer_verification_provider, customer_verification_provider_def, customer_verification_item_settings, customer_verification_item_settings_def.

New entity CustomerVerificationProvider (customer_verification_provider, customer_verification_provider_def) will be used to store data based on system configuration which include: Verification provider name, supported organizaition types, supported verification item types, is the provider currently Active in the system, has external integration or not.

New entity CustomerVerificationItemSettings (customer_verification_item_settings, customer_verification_item_settings_def) will be used for storing data related to verification item settings like it’s type of the verification item, verification provider, organization type code, verification item group, boolean value if the item is required for KYC verification.

The following APIs are deprecated:

• POST /profiles/{userId}/reset-identification-requests/{reqId}/approve

• POST /profiles/{userId}/reset-identification-requests/{reqId}/decline

API PATCH /organizations/{organizationId}/identification-request/{requestId} should be used instead

Feature

Description

Benefits

Added ability for compliance to view, approve/decline the reset identification request for the company.

To make changes to the already approved company, the user must send a reset identification request. When the request is approved, statuses are changed in the following way, which allows for making changes:

More flexible management of the company’s information.

Added ability for service users to manage companies (UI changes)

• close company if all accounts are closed

• delete company with None status

• manage company members

• manage company contract.

Service users can manage companies on the UI.

More convenient company management.

Added ability to customise the list of mandatory fields required for KYC in the Individual profile at the system level (API changes).

Added APIs to manage the list of mandatory fields required for KYC for Individual user.

More flexible platform management.

Added ability to configure a custom KYC provider with external integration enabled (platform configuration changes).

An administrator or DevOps engineer configures a custom KYC provider in the SDK.finance platform and defines whether this provider uses an external integration.
This configuration determines whether marking the organisation as ready for review should trigger outbound webhooks.

More flexible platform management and the ability to use external integration in the middleware.

Added ability to specify that external integration is enabled for the custom gate provider (API changes).

An administrator creates a custom gate provider in the SDK.finance platform and defines whether this provider uses an external integration.
This configuration determines whether the initiation of a top-up or withdrawal triggers outbound webhooks.

More flexible platform management and the ability to use external integration in the middleware.

Added ability to enable Fireblocks integration at the currency level (UI change)

If Fireblocks integration is enabled, Fireblocks will be used to open an account in this currency and to perform top-up and withdrawal.

Fireblocks integration enables operating with cryptocurrency.

Feature

Description

Added the ability to create and delete bundle keys.

Added APIs to update and delete bundle key

Added prefix to the bundle keys to separate resources.

core. prefix was added to all existing bundle keys

OpenSanctions integrations changed to improve performance and to remove NodeRed usage

Sanctions Database Management

Maintain an up-to-date local copy of global sanctions lists to ensure compliance with international regulations and avoid doing business with sanctioned individuals or entities.

• Automatic Updates: The system automatically synchronizes with OpenSanctions (a global sanctions aggregator) multiple times per day, ensuring your organization always screens against the latest sanctions
  data

• Coverage: Consolidates sanctions lists from multiple authorities (UN, US OFAC, EU, UK, etc.) into a single screening database

• Efficiency: Uses incremental updates to minimize data transfer and processing time – only new changes are downloaded after initial setup

Customer Screening Process

Systematically screen all customers against sanctions lists to identify potential matches and prevent prohibited transactions.

• Automated Batch Screening:

  • All existing customers are automatically re-screened daily

  • Any customer whose data changes is flagged for immediate re-screening

Status of individual profile is changed to pending by calling API POST /v1/organizations/{organizationId}/review-request instaed of when the first profile document is uploaded.

Pending status means that the Individual profile is ready for compliance review and is changed now by the user when all required information is specified and all required documents are uploaded.

OTP confirmation screen for self-registration is shown only when OTP is sent.

New parameter requiresConfirmation (boolean true/false) added to response:

POST:

response body example:

Added information about allowed transaction types for reconciliation in CFO -> Reconciliation -> Files -> Upload file popup

Added information message on UI

Added tooltip text for mismatch with type ‘Transaction not found’ in CFO -> Reconciliation (Transaction) -> Reconciliation details

Added information message on UI

When reset identification is approved status is changed to None for Individual

Reset identification for companies and individual users works in the same way: when reset identification is approved status is changed to None (previously it was Pending for individual)

New APIs are used to work with the Individual profile:

• Get organization profile GET /organizations/{organizationId}/profile

• Update organization profile PATCH /organizations/{organizationId}/profile

Removed the ability to specify filters in the Export Transactions sidebar and used the same filters as were chosen in the Transactions list.

Used new API to manage user-level notifications:

• POST /notification-settings

• GET /notification-settings?userId={ID}

instead of

• GET ​​/profiles​/{userId}

• PATCH ​/profiles​/{userId}​/security-settings

Changed APIs usage:

GET /users/{userId}

GET /organizations/{organizationId}/profile

Changed API usage:

GET /kyc-providers

Updated

POST /reports

API accepts the same list of filters as POST /transactions/view

The following filterType values are supported:

• TransactionFilter

• TransactionStatementFilter

• PaymentTransactionFilter

• GateMerchantPaymentTransactionFilter

• GateTransactionFilter

• BusinessUserTransactionReportFilter

GET /reports

Removed functionality:

• Sorting by createdAt

• Filtering by name

• Filtering by lastReport

• Filtering by description

New organisation status SanctionStatus was introduced.

Any endpoint returning OrganizationShortDto will now include this field.
e.g:

New parameter requiresConfirmation (boolean true/false) added to response:

POST /registration

POST /gate-providers

• Request body (CreateGateProviderReq) now includes externalIntegration.

• Response (ShortGateProviderDtoNoGate) now includes externalIntegration.

GET /gate-providers

Response (ViewGateProvidersResp) contains GateProviderDto which now includes externalIntegration

PATCH /gate-providers/{gateProviderId}

• Request body (CreateGateProviderReq) now includes externalIntegration.

• Response (ShortGateProviderDto) now includes externalIntegration.

PATCH /gate-providers/{gateProviderId}/link

Response (ShortGateProviderDto) now includes externalIntegration

GET /users/{userId}

GET /organizations/{organizationId}/profile

Response extended with new fields

Added

POST /i18n

DELETE /i18n/{key}

PATCH /organizations/{organizationId}/identification-request/{requestId}

GET /kyc-settings/verification-items

PATCH /kyc-settings/verification-items/{verificationItemId}

DELETE /kyc-settings/verification-items/{verificationItemId}

Deprecated/Deleted

POST /profiles/{userId}/reset-identification-requests/{reqId}/approve

POST /profiles/{userId}/reset-identification-requests/{reqId}/decline

Added

core. prefix was added to all existing bundle keys

OpenSanctions Configuration Properties

• open-sanctions.url

url: https://data.opensanctions.org/datasets/
Base API endpoint for OpenSanctions data services. Used to fetch index files, delta updates, and CSV downloads.

• open-sanctions.dataset

dataset: sanctions
Selects which OpenSanctions dataset to use. Options: sanctions (sanctioned entities), PEPs (politically exposed persons), crime (criminal watchlists).

• open-sanctions.filename

filename: targets.simple.csv
CSV file name for full database downloads. The “simple” format contains core fields only (name, ID, dates) vs. the full format with all metadata.

• open-sanctions.cron.sanctions-check

sanctions-check: 0 0 2 * * *
Schedule for screening all users. Runs daily at 2:00 AM. Checks existing customers against the sanctions database for new matches.

• open-sanctions.cron.database-update

database-update: 0 0 */6 * * *
Schedule for syncing sanctions data. Runs every 6 hours (00:00, 06:00, 12:00, 18:00). Downloads the latest changes from OpenSanctions.

Added flag to KYC providers configuration:

Configuration properties removed:

• compliance.document-verification.provider-name

• compliance.document-verification.sumsub-is-enabled

New configuration properties introduced:

compliance.document-verification.active-provider-name:MANUAL

or COMPLIANCE_DOCUMENT_VERIFICATION_ACTIVE_PROVIDER_NAME
default value: MANUAL
posible values: MANUAL/SUMSUB/OPEN_SANCTIONS/COMPLY_ADVANTAGE

Configuration property structure changed for:

compliance.document-verification.providers
It’s a list of verification providers; each of them must contain the following required nodes:
– name Provider name. Ex: MANUAL/SUMSUB/OPEN_SANCTIONS/COMPLY_ADVANTAGE
– organization-types List of supported organization types. e.g.: individual, business, shareholder
– verification-item-types List of supported verification item types. e.g.: USER_ID, FIRST_NAME_PLAIN, LAST_NAME_PLAIN, DATE_OF_BIRTH, ORGANIZATION_TYPE, CREDENTIAL, COUNTRY, ZIPCODE, REGION
– external-integration Boolean value define if verification provider has external integration e.g.: true/false

Default configuration properties: