Cbe - v9.192
This page contains the following releases for v9.192:
v9.192
Release Dates
- Sandbox: 19.08.2026
Features
Developer
New Management APIs for Process Instance Recovery
We have introduced new operational endpoints and granular permissions (CANCEL_PROCESS_INSTANCE, EDIT_PROCESS_INSTANCE_VARIABLES) to recover stalled process instances without direct database access. These tools enable administrators to resolve blocked workflows by terminating instances or repairing variables directly via the API.
New endpoints:
POST /api/processinstances/{id}:cancel: Terminate a running instance; this operation is idempotent.PUT /api/processinstances/{id}/variables/{name}: Repair a single process-scoped variable to move tokens parked at gateways.POST /api/processinstances/{id}/variables: Perform an atomic, multi-variable write that short-circuits on any validation failure.
Note: Variable types in the history API now use a standardized uppercase format (e.g., INTEGER), ensuring that read and write paths are consistent for developers.
New Orchestration permissions for Process Orchestration APIs
We have introduced seven new specific permissions for Process Orchestration APIs, enabling granular access control and a strict "maker-checker" separation of duties for the process-definition lifecycle. These permissions replace the previous global administrator requirement and are available for both standard users and API consumers.
Breaking Change: Access is no longer automatically granted via the general "ADMIN" permission. To maintain integration continuity, you must explicitly assign the relevant new Orchestration permissions (View, Deploy, Approve, Manage, and Execute) to your roles or API consumers. Users with full administrator status (isAdministrator=true) remain unaffected.
Improved Process Orchestration performance
Process context loading is now skipped when no process is configured for an extension point, improving system performance.
Lending
Introduction of fee tracking for Fixed Term loans
Introduced detailed tracking of specific fee types and tax amounts (Inclusive/Exclusive) per installment.
Notifications
New Webhook Notification for Holiday Synchronization Completion
Introduced a new HOLIDAY_SYNC_COMPLETED webhook event under the Administrative target type. This allows system administrators to receive automated alerts after global or branch-specific holiday updates are processed without needing to link the notification to specific client or loan accounts. This provides the following benefits:
- Detailed Synchronization Metadata: Webhook payloads now include critical diagnostic information, such as the Process ID, Sync Status (Success/Failure), and a Failure Summary where applicable.
- Improved Integration Reliability: For failed synchronizations, a machine-readable FAILED_ACCOUNT_LIST (JSON array) is included in the payload to allow external systems to automate retry or reporting workflows.
- Process Integrity: The notification system is architecturally isolated, ensuring that synchronization updates remain stable and performant even if notification delivery is delayed.
Deposits
Advanced Configuration Controls for Next-Generation Deposit Backdating
We have introduced a dual-layered gating framework to safely control and deploy next-generation backdating capabilities across deposit products and accounts. This structure ensures precise operational control and eliminates partial activation risks by automatically falling back to legacy backdating behavior if either gate is inactive.
Configuration Layers:
- Tenant-Level Master Gate (
DEPOSITS_NEXT_GEN_BACKDATING): Serves as the global environment switch. This feature must be enabled before any product-specific options can be configured, and it safely activates the new optimized code paths across all deposit services. - Product-Level Opt-In (
deposits_next_gen_backdating): Provides a granular, irrevocable configuration option at the individual product level. It is verified before performing horizontal balance changes and only takes effect when the tenant-level master gate is active.
Improvements
Deposits
Courtesy Pay Product Feature API enhancements
Updated the Courtesy Pay Product Feature API to automatically create Dynamic Balance configurations and preserve existing settings during product setup.
Improved deposit balance validation flexibility
Disabled the opening balance validation for product types globally by default, providing more flexibility in account setup across all tenants.
Sync Wio sandbox feature toggles with production
Aligned several savings/deposit ordering and background-job feature toggles on the Wio sandbox environment (wiodefiqa) with what is already enabled in production (wiodefiprod), so sandbox behavior matches prod for these features.
Validation of Shadow Balance Tracking with Historical Exchange Rates
Verified that shadow balance tracking (specifically for Mexican deposit limits in MXV/UDIS) correctly utilizes historical exchange rates for backdated transactions. Confirmed that the system follows a fallback strategy of using the latest available rate on or before the transaction date.
Groundwork for upcoming features
- Enhanced deposit validation controls for backdated deposits in customer and internal sandbox environments.
Additional work
- Internal deposits infrastructure changes.
Bug fixes
Lending
Fixed EOD failures on loan accounts with IRC and redraw transactions
Resolved an issue where End-of-Day processing could fail with an error for certain loan accounts after the enableOptimizedRsvPayloadSerialization feature toggle was enabled, due to the read path falling back to the old deserialization. Affected accounts will now process through EOD successfully without requiring a workaround.
Enhanced Reliability and Visibility for Human-Task Workflows
We resolved a defect to ensure human-task completion is invoked exactly once, standardizing data propagation via {taskDefKey}_reply variables, and improved the Tasks inbox interface by resolving missing names for linked accounts and journal entries.
Resolved Repayment Failures Caused by Tax Rounding Discrepancies on Dynamic Term Loans
We resolved an issue where posting a repayment mid-installment on Dynamic Term Loans using Declining Balance Equal Instalment (DBEI) caused subsequent repayments to fail.
When an intervening transaction split an installment period into intervals, the system rounded the withholding tax for each sub-period independently. The sum of these rounded fragments could differ slightly from the true total tax, leaving a residual balance stranded in the schedule. The system now accumulates all intervals before executing a single-pass tax calculation, aligning it with the standard interest application mechanism.
Configuration Note: This corrected calculation logic is gated behind the fixTaxOnInterestRounding feature. Once enabled, it natively covers all Dynamic Term Loan configurations.
Corrected Interest Calculations for Loan Accounts with High Offset Balances
We resolved an issue on loan accounts linked with an offset savings account where interest due on future installments was incorrectly calculated as a negative value.
This bug occurred when the savings account balance exceeded the outstanding loan principal, causing the calculated effective outstanding principal to drop below zero without being restricted. The system now correctly clamps the minimum effective principal to zero under these conditions, ensuring that the affected installments accurately reflect an interest due amount of 0.00.
Note: This adjustment applies exclusively to accounts with linked offset or redraw capabilities; standard loan account behavior remains unchanged.
Fix Fee Prepayment allocation on zero principal due installment
A fee prepayment made for an installment with zero grace principal amount is now corrected to allocate the payment properly on the installment marking it as PAID.
Improved Repayment Allocation for Complex Fee Scenarios on Dynamic Term Loans
We resolved an allocation defect (UnableToAllocateException) that caused repayments to fail on Dynamic Term Loans when an account carried both a capitalized disbursement fee and a post-maturity manual fee.
The updated allocation logic calculates unlinked fee states directly from the outstanding fee balance (account.feesBalance) rather than historical payments. This adjustment prevents unallocatable leftover funds, ensures tax-on-fees scales precisely for partial repayments, and natively supports fee reductions (FEES_DUE_REDUCED).
Configuration Note: This corrected behavior is gated behind the FIX_FEE_PAYMENT_FROM_ACCOUNT_FEE_BALANCE feature toggle (disabled by default) to preserve legacy allocation tracking for tenants who have not opted in.
Resolved Account and Schedule Inconsistencies Caused by Concurrent Transactions
We resolved a class of concurrency issues where multiple API transactions processed on the same loan account within milliseconds of each other could cause race conditions. These races led to data discrepancies between the account schedule and the transaction ledger, triggering disruptive errors such as ExcessPaymentException during concurrent repayments, schedule corruption, or ACCOUNT_BALANCE_OUTSIDE_CONSTRAINTS during fee applications.
To eliminate these conflicts, the system now acquires a pessimistic lock on the LoanAccount database row during key orchestration events—including repayments, manual fees, planned-fee applications, redraw repayments, withdrawal redraws, and payments made. This ensures that overlapping transactions on a single account serialize cleanly and execute sequentially.
Configuration Note: This sequential processing behavior is gated behind the LOCK_LOAN_ACCOUNT_FOR_TRANSACTIONS feature.
Interest incorrectly applied on payment holiday due dates for Dynamic Term Loans
Resolved an issue where a small amount of regular interest could be applied on a due date marked as a payment holiday for Dynamic Term Loan accounts. This occurred when accumulated interest rounding residuals were applied during EOD processing. Interest application on payment holiday dates is now correctly skipped.
Overpayments on loan accounts with planned fees were incorrectly allocated across installments
When making an overpayment on a loan account that had planned fees configured, the excess amount was incorrectly allocated to fees on the next installment instead of being fully applied to the current installment being paid.
Corrected Repayment Schedules for Overpaid Dynamic Term Loans During Grace Periods
We resolved an edge case where large prepayments on loan accounts configured with Reduce Number of Installments (RNI) caused incorrect due amounts to appear during grace periods. This issue occurred when an overpayment significantly dropped the scheduled installment amount (PMT) below the remaining principal balance.
This fix has also been extended to broader Dynamic Term Loan (DTL) configurations using Declining Balance Equal Instalment (DBEI) loans where similar payment-to-principal imbalances could occur.
Configuration Note: For broader DTL and DBEI configurations outside of the specific RNI scenario, this updated schedule behavior is gated behind a feature toggle to protect existing account calculations.
Custom repayments now apply penalties to the oldest outstanding amount first
When a repayment is entered that combined an interest amount and a penalty amount across different months, Mambu would apply the penalty to the most recent installment with a penalty due — even if there was an older, unpaid penalty on an earlier installment. As a result, the older penalty stayed (or was only partially) paid, while a newer one was cleared. This behaved differently from a standard repayment, which always paid older amounts first.
With this feature toggle, the penalty portion of a combined custom repayment is allocated to the oldest installment with an outstanding penalty first, matching the order used for standard repayments.
Undo Close and Undo Write Off loan account actions now work correctly in the UI
Resolved an issue where the Undo Close and Undo Write Off actions on loan accounts failed with an unexpected error when performed through the UI. The loan account remained in the Closed state instead of returning to Active. These operations now complete successfully via the UI. Actions performed through the API were not affected by this issue.
Added accountState filter to credit arrangement accounts API
Added an optional accountState query parameter to the GET /creditarrangements/{creditArrangementId}/accounts endpoint. Clients can now filter linked loan and deposit accounts by state (e.g. ACTIVE, CLOSED). When the filter is omitted, all accounts are returned as before.
Fixed negative journal entries for exclusive fee taxes during inter-branch transfers.
Resolved an issue where changing a loan's branch resulted in negative journal entry amounts for exclusive taxes applied to fees. The system now correctly logs these inter-branch transfer entries with positive amounts and the appropriate Credit or Debit entry type.
Aligned Configuration-as-Code Mappings for Loan Product Principal Payment Settings
We resolved an issue where exporting and re-importing a loan product configuration via the Configuration-as-Code (CasC) API could unintentionally modify the product's underlying principal payment settings.
Previously, during a configuration round-trip (GET followed by PUT), the system would inject and persist unauthorized default fields—such as principalPaymentMethod and includeInterestInFloorAmount—even if they were not part of the original product configuration.
The Configuration-as-Code endpoint has been corrected to ensure payload consistency. Re-importing an exported configuration file now preserves the exact state of the loan product without introducing unintended default settings.
Prepayments are now accepted for locked Fixed Term Loan account payment due fees
Resolved an issue on Fixed Term Loan accounts with Horizontal payment allocation and Payment-Due fees applied on due dates, where prepayments were rejected with an excess-payment error after interest was locked. Prepayments are now accepted and the relevant payment-due fees are applied to the targeted future installments as part of the repayment.
Notifications
Resolved "Set Notifications" Dialog Crashes on Client and Group Pages
We resolved an issue where attempting to open or save the Set Notifications dialog on Client and Group pages triggered a SerializationException, causing the interface to fail or crash.
The root cause stemmed from the notification filter model, which utilized EnumSet types that were incompatible with Google Web Toolkit (GWT) serialization protocols. The underlying data structures have been corrected to ensure full compatibility, allowing users to configure and save notification settings seamlessly.
Deposits
Fix: Savings product description now displays correctly with special characters and JSON content
The savings product overview page now correctly displays descriptions containing special characters, HTML markup, or JSON content. Previously, characters such as quotes and angle brackets were shown as HTML entities (e.g. " instead of ", <div> instead of a rendered element), making JSON-formatted descriptions unreadable. This was caused by a display-layer regression introduced in a prior fix (DO-1217). The description is now rendered using a safe HTML whitelist approach that strips XSS payloads (script tags, event handlers) while correctly displaying the intended content.
Target Validation Enforcement for Deposit Account Withdrawal Limits
We resolved a validation issue where editing unrelated fields (such as custom fields) on an existing deposit account would fail if the account's maximum withdrawal limit was higher than the product's current limit.
The system now only enforces product-level maximum withdrawal constraints when the account's maximum withdrawal limit field itself is explicitly modified. This ensures that routine data updates to existing accounts can proceed smoothly without being blocked by subsequent changes made to the overarching product configuration.
URL-Safe Character Validation for New Deposit Account and Product IDs
To ensure API compatibility and alignment with technical specifications, deposit account IDs and product ID patterns now enforce strict validation to reject characters that are unsafe in URL paths (such as spaces, parentheses, and emojis).
Allowed Characters:
- Alphanumeric characters (
A-Z,a-z,0-9) - Hyphens (
-) - Underscores (
_)
Compatibility Note: This character validation is applied exclusively at the time of product or account creation. Existing data and configurations containing legacy formatting remain unaffected and will continue to function normally.
Validation Error Enforced for Zero-Amount Manual Interest Applications
We resolved an issue where manually applying interest to a deposit account with a net-zero accrued amount (after rounding) incorrectly returned an HTTP 200 OK success response without actually generating a transaction in the ledger.
The API now correctly validates the request before responding. When the rounded net of all accrued interest components is zero, the system rejects the operation and returns a dedicated error with code ACCOUNT_HAS_NO_ACCRUED_INTEREST instead of processing a silent success.
Resolved Search API Failures Across Daylight Saving Time Transitions
We resolved an issue where search queries using a BETWEEN filter on core date fields (creationDate, transactionDate, lastModifiedDate) returned an HTTP 500 error when the requested date range spanned a Daylight Saving Time (DST) transition.
The failure occurred because timezone offset changes during the transition caused the system to incorrectly invert the date boundaries (making the calculated start date occur after the end date). The conversion logic has been corrected, ensuring searches across DST boundaries execute successfully and return accurate records.
Interest incorrectly recalculated from account activation after product payment date propagation
When the interest payment dates of a savings product were updated and propagated to existing accounts, the end-of-day process incorrectly recalculated interest from the account's activation date using the current interest rate — ignoring any intermediate rate changes recorded on the account.
After this fix, interest is calculated correctly based on the account's rate history. When product changes are propagated, the EoD process respects the valueDate of each rate change and applies interest only from the date each rate was introduced.
Affected configuration: Savings products with Fixed Date or Tiered interest rate and interest paid on fixed dates.
Resolved End-of-Day Interest Application Failures from Invalid Accrual Values
We resolved an issue where invalid values within the imported interest accrual custom field caused End-of-Day (EOD) processing to fail. When a negative or non-numeric amount was provided, the system unexpectedly attempted to route the transaction as an overdraft. This triggered a missing OVERDRAFT_PORTFOLIO_CONTROL accounting resource error on products that do not support overdrafts.
To prevent this, strict data validation is now enforced at write time, blocking malformed or negative inputs before they can disrupt downstream batch jobs.
Configuration Note: This write-time validation applies when the
IMPORTED_INTEREST_ACCRUALfeature toggle is enabled.
Enforced Range Limits for Incremental ID Patterns on Deposit Products
We resolved an integer overflow issue where configuring an INCREMENTAL_NUMBER identifier pattern (idPattern) on a deposit product with a value greater than 2,147,483,647 (Integer.MAX_VALUE) would silently overflow to 0 and bypass validation. This bug resulted in the malformed pattern being incorrectly saved in the database.
The validation engine (DepositProductConfigurationNewAccountSettingsValidator) now strictly enforces the intended operational range of [0, 2,000,000,000]. Any configuration attempts containing values outside this range will be rejected immediately with error code 8814.
Resolved UI Editing Failures for Deposit Accounts with Indexed Overdraft Settings
We resolved an issue in the user interface where updating a deposit account configured with indexed overdraft interest rate settings (INDEX_INTEREST_SOURCE) would fail with a validation error.
This bug was triggered if the underlying product's interest rate review period parameters (InterestRateReviewCount or InterestRateReviewUnit) were modified after the account's creation. While API v2 modifications remained unaffected, the UI validation logic has been corrected to ensure accounts can now be updated via the interface as expected.
Auto-settlement now uses available balance when 'USE_OVERDRAFT_ON_LINKED_TRANSFER' is enabled
When the 'USE_OVERDRAFT_ON_LINKED_TRANSFER' feature toggle is enabled, auto-settlements from linked deposit accounts now correctly consider the authorised overdraft limit as part of the available balance. Previously, settlement attempts would fail for accounts with a debit balance even when the account had sufficient available balance within the authorised overdraft limit.
Clients and Groups
Preserved Group Memberships on Client Branch Updates in UI
An issue in the client management interface has been resolved to ensure that updating a client's assigned branch no longer inadvertently clears their existing group memberships. The UI now correctly aligns with API behavior, automatically preserving all group assignments when a branch change is saved while maintaining the option to manually manage groups at any time.
v9.192.9
Release Date: 22.08.2026
This release contains the following:
- Internal maintenance improvements to transaction processing reliability by addressing card reversal handling mechanisms.
v9.192.8
Release Date: 19.08.2026
This release contains the following:
- Internal maintenance improvements to API documentation system reliability.
v9.192.7
Release Date: 19.08.2026
This release contains the following:
- Internal maintenance improvements to platform stability and test reliability.
v9.192.6
Release Date: 19.08.2026
Improvements
Data
Disabled opening balance validation for certain product types
Removed the default validation that prevented opening balances for specific product types, giving tenants more flexibility in account setup configurations.
Sync Wio sandbox feature toggles with production
Aligned several savings/deposit ordering and background-job feature toggles on the Wio sandbox environment (wiodefiqa) with what is already enabled in production (wiodefiprod), so sandbox behavior matches prod for these features.
Enhanced deposit balance validation for backdated transactions
Enabled maximum deposit balance validation for backdated deposits across customer and internal sandbox environments to ensure data integrity.
v9.192.5
Release Date: 19.08.2026
Improvements
Data
Disabled opening balance validation for certain product types
Removed the default validation that prevented opening balances for specific product types, giving tenants more flexibility in account setup configurations.
Sync Wio sandbox feature toggles with production
Aligned several savings/deposit ordering and background-job feature toggles on the Wio sandbox environment (wiodefiqa) with what is already enabled in production (wiodefiprod), so sandbox behavior matches prod for these features.
Enhanced deposit balance validation for backdated transactions
Enabled maximum deposit balance validation for backdated deposits across customer and internal sandbox environments to ensure data integrity.
v9.192.4
Release Date: 19.08.2026
Improvements
Data
Disabled opening balance validation for certain product types
Removed the default validation that prevented opening balances for specific product types, giving tenants more flexibility in account setup configurations.
Sync Wio sandbox feature toggles with production
Aligned several savings/deposit ordering and background-job feature toggles on the Wio sandbox environment (wiodefiqa) with what is already enabled in production (wiodefiprod), so sandbox behavior matches prod for these features.
Enhanced deposit balance validation for backdated transactions
Enabled maximum deposit balance validation for backdated deposits across customer and internal sandbox environments to ensure data integrity.
v9.192.3
Release Date: 19.08.2026
Improvements
Data
Disabled opening balance validation for certain product types
Removed the default validation that prevented opening balances for specific product types, giving tenants more flexibility in account setup configurations.
Sync Wio sandbox feature toggles with production
Aligned several savings/deposit ordering and background-job feature toggles on the Wio sandbox environment (wiodefiqa) with what is already enabled in production (wiodefiprod), so sandbox behavior matches prod for these features.
Enhanced deposit balance validation for backdated transactions
Enabled maximum deposit balance validation for backdated deposits in customer and internal sandbox environments to ensure data consistency.
v9.192.2
Release Date: 19.08.2026
Improvements
Data
Disabled opening balance validation for certain product types
Removed the default validation that prevented opening balances for specific product types, giving tenants more flexibility in account setup configurations.
Sync Wio sandbox feature toggles with production
Aligned several savings/deposit ordering and background-job feature toggles on the Wio sandbox environment (wiodefiqa) with what is already enabled in production (wiodefiprod), so sandbox behavior matches prod for these features.
Enhanced deposit balance validation for backdated transactions
Enabled maximum deposit balance validation for backdated deposits across customer and internal sandbox environments to ensure data integrity.
Bug fixes
Lending
Resolved Repayment Failures Following Prepayments on Loans with Initial Payment Holidays
We resolved an issue where processing a large prepayment on a loan account configured with a payment holiday on its first installment caused subsequent repayment transactions to fail.
The underlying schedule recalculation logic has been corrected to ensure that large principal reductions during an active payment holiday map cleanly to future periods. Affected accounts will now seamlessly accept and process all subsequent repayments as expected.
Notifications
Resolved "Set Notifications" Dialog Crashes on Client and Group Pages
We resolved an issue where attempting to open or save the Set Notifications dialog on Client and Group pages triggered a SerializationException, causing the interface to fail or crash.
The root cause stemmed from the notification filter model, which utilized EnumSet types that were incompatible with Google Web Toolkit (GWT) serialization protocols. The underlying data structures have been corrected to ensure full compatibility, allowing users to configure and save notification settings seamlessly.
Data
Resolved Validation Failures When Removing Grouped Custom Field Sets
We resolved an issue where saving an entity (such as a client, group, account, branch, or user) would fail with a misleading "required custom fields without a value" validation error after a user removed an instance of a grouped custom field set that contained required fields.
The system now correctly processes the deletion of a grouped custom field set instance, allowing the overarching entity to save successfully without triggering false-positive validation checks for the fields within the removed set.
Validation Note: This fix applies strictly to grouped custom field set instances that can be added or deleted as collections. Single (non-grouped) required custom fields cannot be cleared and will continue to enforce standard mandatory-value validation.
v9.192.1
Release Date: 19.08.2026
Improvements
Data
Additional work
- Non-customer-facing configuration and feature toggle updates.
For more information, see Mambu Release Cycle.