Skip to main content

Cbe - v9.193

This page contains the following releases for v9.193:

v9.193​

Release Dates

  • Sandbox: 18.08.2026

Features​

Lending​

Introduced COVER_DUE_AMOUNT Allocation Type for Revolving Credit Overpayments​

We added the COVER_DUE_AMOUNT auto-allocation option for Revolving Credit accounts to provide better control over overpayment routing.

When this allocation strategy is selected on an account, any repayment funds that exceed the current total due amount will be automatically routed to and stored within the account's CreditBalance.

Migrate existing accounts to new credit balance functionality​

Added a new private API that updates all existing accounts with the new credit balance functionality when the Credit Balance is enabled on an existing product

Option to Include Payment Holiday Accrued Interest in Loan Payoff Calculations​

We introduced a new configuration option that allows lenders to include interest accrued during an active payment holiday directly within final loan payoff calculations.

Previous Behavior: Previously, when a loan account was paid off during an active payment holiday, any interest accrued during that holiday period was omitted from the payoff interest balance. Because the system prevented the application of payment holiday interest while the holiday was active, this accrued interest remained completely unaccounted for at the time of payoff.

New Behavior: A new option is now available within the payoff dialog in the user interface and via the API. When enabled, the system automatically triggers a dedicated payment holiday interest application transaction during the payoff sequence—even if the payoff occurs while the holiday period is still active. This ensures that all outstanding accrued interest is fully recognized and collected.

Deposits​

Resolved Concurrent Activation Race Conditions on Deposit Accounts​

We resolved a database race condition where multiple concurrent activation requests (activateDepositAccount) targeting the same deposit account could simultaneously bypass state validation. This issue resulted in duplicated side effects across the system, including redundant activity log entries, repeated notifications, and mismatched client holder state updates.

To eliminate this race condition, the system now enforces a pessimistic locking strategy during the activation workflow:

  • Row-Level Locking: A new lockAndActivateSavingsAccount method in the ActivateSavingsAccountService leverages the SavingsAccountDbLockService to acquire a row-level database lock (SELECT ... FOR UPDATE) before running the activation sequence.
  • Explicit Failure Handling: Any concurrent requests arriving for an account that is already active or currently undergoing activation will now be explicitly rejected with an InvalidStateTransitionException instead of processing a silent, duplicate success.

System Impact: Standard, single-request account activations are entirely unaffected. This update safeguards data integrity against rapid UI double-clicks or high-concurrency automated API operations.

Overdraft Limit Change Transactions Extended to Dormant Accounts​

We have enhanced transaction logging to ensure that modifying the overdraft limit on an account in a DORMANT state now correctly generates and displays an OVERDRAFT_LIMIT_CHANGED transaction record.

This update extends standard limit-change auditing to dormant accounts, ensuring a consistent history and a complete audit trail for financial profile modifications across all account lifecycle states.

Courtesy Pay Account Enablement Modification Activity UI Display​

Added Courtesy Pay enable/disable activity tracking across Dashboard, Client, and Account levels.

Groundwork for upcoming features​

  • Dynamic Interest account appraisals and interest application capabilities.

Islamic Banking​

Additional work​

  • Non-customer-facing design work for Murabaha contract specifications.

Improvements​

Data​

AI skill auditor​

Enhanced AI-powered skill auditing capabilities for mortgage processing workflows.

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.

Groundwork for upcoming features​

  • Ledger data archival infrastructure including foreign amount co-archival, observability, security, performance, and compliance requirements.

Additional work​

  • Non-customer-facing configuration updates and internal documentation.

Bug fixes​

Lending​

Resolved Custom Repayment Failures on Balloon Loans with Graced Installments​

We fixed an issue where attempting to log a custom repayment on a balloon-payment loan would fail with a NullPointerException (NPE) under specific scheduling conditions.

The Issue: The crash occurred on balloon-payment loans that featured graced installments at disbursement. Specifically, after a borrower successfully paid off all interest associated with the non-grace installments, the system would fail to process any subsequent custom repayment transactions, blocking further payment logging.

The Fix: The repayment allocation engine has been corrected to properly handle the internal evaluation of installment components once non-grace interest balances are fully cleared. These custom repayments now complete successfully, ensuring accurate schedule updates and uninterrupted account management.

Fixed UI Loan Account Creation Failures Involving Products with "Fee Included in PMT"​

We fixed a user interface issue where attempting to create a loan account failed when switching between loan products with different fee structures.

The Issue:

When navigating or switching between loan products—specifically moving from a product with Fee Included in PMT (Payment) enabled to one without it—subsequent loan account creation attempts in the UI would fail.

The Fix: The form state management has been corrected so that the FeeRate value is completely cleared whenever the panel is hidden. Users can now create consecutive loan accounts across different product configurations without encountering UI submission errors.

Resolved Interest Recalculation Errors Following Rate Changes on Loans with Same-Day Prepayments​

We resolved an interest calculation issue on Dynamic Term Loans utilizing the Declining Balance Discounted interest method.

Previously, if a principal prepayment was processed on the same day as account disbursement and was subsequently followed by an interest rate change, the recalculation engine would ignore the prior prepayment. This caused interest to be erroneously calculated against the full original principal rather than the actual reduced balance, leading to significant interest overstatements (potentially up to 10× the correct amount).

The system now accurately accounts for all historical principal prepayments when recalculating interest after a rate change, ensuring correct interest accruals moving forward.

Resolved "Invalid Amount" Failures During Loan Payoffs​

We fixed an issue where the Pay Off Loan dialog rejected the exact payoff balance it calculated and displayed on-screen, causing the account closure process to fail.

The Issue: When attempting to close a loan account, the system would frequently throw an InvalidReduceAmountForAccountException (invalid amount error) despite the operator entering the precise balance shown in the interface. To bypass this error and successfully close the account, users were forced to perform manual adjustments to the interest balance prior to executing the payoff.

The Fix: The validation logic within the loan closure workflow has been corrected. The system now accurately reconciles and accepts the displayed current balance directly, allowing users to process payoffs seamlessly without requiring manual financial workarounds.

Fixed Principal Allocation for P2P Loan Repayment Adjustments​

We resolved an issue in Peer-to-Peer (P2P) lending workflows where adjusting a loan repayment resulted in an incorrect allocation of principal across multiple funders.

The Issue: When a repayment transaction on a P2P loan was adjusted (reversed and re-applied), the system mishandled the redistribution of the principal components among the investors or funders backing the loan. This led to an inaccurate financial state where funder account balances became misaligned following the adjustment process.

The Fix: The P2P repayment adjustment engine has been corrected to ensure that principal amounts are accurately tracked and proportionally redistributed across all participating funders whenever a repayment adjustment occurs.

Resolved Excess Payment Errors on Loans with Extended Principal Grace Periods​

We resolved an issue where executing an early repayment on loan accounts configured with more than 1,000 principal grace installments incorrectly triggered an Excess Payment allocation error.

This failure occurred because an internal evaluation safety guard incorrectly tracked loop progression across exceptionally long schedule structures. The iteration logic has been optimized to accurately assess active loop progress, ensuring that extended grace-period schedules process repayment allocations smoothly.

Fixed Grace Installment Calculations for Offset-Enabled Loans​

We resolved an issue in the new Interest Rate Change (IRC) processor where offset-enabled loan accounts could generate inaccurate schedule structures following a partial pre-disbursement transfer.

The Issue: When managing offset-enabled loans, if a portion of the loan amount was transferred to the linked offset account prior to final disbursement, the schedule generation logic faltered. The resulting repayment schedule incorrectly featured graced installments that failed to align with the account's actual, real-time outstanding balance.

The Fix: The IRC processor has been corrected to accurately factor in partial loan-amount transfers to linked offset accounts before disbursement. The system now evaluates the true initial outstanding balance seamlessly, ensuring the engine generates correct repayment schedules and proper installment structures.

Corrected Pay-Off Preview Calculations for Loans Within Arrears Tolerance​

We resolved an issue where the loan pay-off preview API erroneously included a late-payment penalty for accounts with overdue amounts that fell within the configured arrears tolerance.

The calculation engine now correctly evaluates the account's arrears status against the product's tolerance thresholds before applying any late penalties. This ensures that pay-off preview quotes accurately reflect the true outstanding balance for loans that are not technically considered in arrears.

Fixed repayment failure on dynamic term loans with interest-only installments and custom repayment allocation​

Fixed a bug where repayments and schedule recalculations failed with an allocation error on dynamic term loans that had interest-only installments (zero principal due) and custom repayment allocation enabled. The allocation engine incorrectly selected interest-only future installments as principal allocation targets, distorting the loan schedule and causing subsequent repayment and schedule recalculation operations to fail. The fix ensures only installments that can absorb each component of a repayment are considered as allocation targets.

Fixed incorrect principal schedule for Optimized Payments when Interest Rate Change is applied after midnight on a schedule due date​

Fixed a bug in Optimized Payments (DECLINING_BALANCE_DISCOUNTED) where rolling back an Interest Rate Change after midnight on a schedule due date caused the following installment's principal to be calculated incorrectly as if the rate was still 0%. The fix ensures the affected installment is correctly identified and recomputed with the reinstated interest rate.

Deposits​

Normalized Decimal Formatting for Deposit Account Balance API Responses​

We resolved an API response formatting issue where monetary balance fields returned by the GET /api/deposits/{accountId}?detailsLevel=FULL endpoint were displayed using an internal 10-decimal storage format (e.g., -550.0000000000) instead of the standard normalized decimal format (e.g., -550.00).

Affected Fields Include:

  • totalBalance
  • availableBalance
  • overdraftAmount
  • overdraftLimit

This formatting adjustment is managed via the TEN_DECIMALS_BACKWARDS_COMPATIBILITY_APIV2_RESPONSE feature toggle, which is enabled by default across all tenants.

Note: Zero values are unaffected and will continue to render simply as 0. This update is strictly a presentation correction for API consumers; no underlying financial values, ledger entries, or database balances are altered.

Fixed incorrect balance storage in bulk deposit operations under concurrent load​

Fixed a race condition in bulk deposit processing where, under concurrent load, deposit transactions could be stored with the pre-deposit account balance instead of the correct post-deposit value. Affected accounts would show no balance change from the deposit, and no GL journal entries would be generated for the transaction. The fix ensures each deposit flushes its balance update to the database before the next deposit reads the account state, eliminating the stale-read window.

Enforced Read-Only Restrictions for Overdraft Interest Field on Active Deposit Products​

We resolved a user interface issue on Current Account deposit products where the Overdraft Interest Calculation Balance field incorrectly appeared editable even after accounts had been associated with the product.

Previously, if a user attempted to modify this field on a product that had one or more linked accounts (including accounts in a Pending Approval state), the interface would silently discard the changes upon saving. The system would fail to save the product updates without displaying any error message, leading to operational confusion.

The field is now correctly rendered as read-only as soon as any account is linked to the overarching product, eliminating the risk of silent save failures and aligning the interface with standard product modification rules.

Savings product form now warns when overdraft is enabled but interest is not paid into the account​

When configuring a savings product with 'Allow overdrafts' enabled but 'Apply interest to account' not selected, the product setup form now displays a warning banner with the following wording:

`

Overdraft interest will not accrue: 'Allow overdrafts' is enabled but interest is not applied to the account.

`

This prevents silent misconfigurations where accounts created under the product would not accumulate overdraft interest despite overdraft being enabled. This is a display-only change to the product administration UI — no impact on account calculations, transaction processing, or existing accounts.

v9.193.11​

Release Date: 29.08.2026

This release contains the following:

  • Internal maintenance improvements to transaction processing stability within the core banking engine.

v9.193.10​

Release Date: 21.08.2026

This release contains the following:

  • Internal maintenance improvements to transaction processing reliability by addressing card reversal handling mechanisms.

v9.193.9​

Release Date: 20.08.2026

Bug fixes​

Lending​

Fixed Branch Reassignment Failures for Loans with Partially-Paid Taxable Fees​

We resolved an issue where reassigning a dynamic loan account with partially-paid taxable fees to a different branch failed with an InvalidAmountException.

The Issue: Reassigning a dynamic loan account containing an outstanding or partially-paid taxable fee caused defects in the system's tax calculation logic. This generated invalid negative journal entries that were subsequently rejected, causing the branch reassignment process to fail.

The Fix: The tax computation logic used during branch transfers has been corrected. Branch reassignments now complete successfully regardless of fee payment status, and the resulting BRANCH_CHANGED transaction accurately records all corresponding fee and tax values.

v9.193.8​

Release Date: 18.08.2026

Bug fixes​

Lending​

Installment fee tax calculation now handles split payments correctly​

We resolved an issue where settling taxable fees across multiple payments on Dynamic Term Loans could leave a 1-cent tax residual. The fee tax calculation engine now handles split fee repayments cleanly without leaving rounding residuals, ensuring installments balance to zero across principal, fee, and tax components when fully settled.

v9.193.7​

Release Date: 18.08.2026

Bug fixes​

Lending​

Fixed Incorrect Graced Installments Following Repayments on Multiple Late Installments​

We resolved an issue where making a single repayment to settle multiple late installments on Dynamic Term Loans could leave trailing installments incorrectly marked as graced.

The Issue: When a single repayment was applied to cover multiple overdue installments on Dynamic Term Loans configured with Declining Balance Equal Installments and Reduce Number of Installments (RNI), the schedule recomputation engine miscalculated the remaining term. This resulted in incorrect graced installments being generated at the end of the repayment schedule.

The Fix: The schedule recomputation logic has been updated to accurately process single payments covering multiple late installments. Dynamic Term Loans now recalculate repayment schedules cleanly without producing unintended graced installments.

v9.193.6​

Release Date: 18.08.2026

Improvements​

Data​

Additional work​

  • Backend-only configuration changes.

v9.193.5​

Release Date: 18.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.193.4​

Release Date: 18.08.2026

Improvements​

Data​

Disable opening balance validation by default​

The validateOpeningBalanceNotApplicableForProductType validation is now disabled by default across all tenants, providing more flexibility in deposit product configuration.

Exempt Birmingham Bank from opening-balance product-type validation​

birminghambank and birminghambank2 are now exempted from the VALIDATE_OPENING_BALANCE_NOT_APPLICABLE_FOR_PRODUCT_TYPE validation introduced in DO-944, restoring the ability to set opening balance fields on non-FIXED_DEPOSIT deposit products (e.g. SAVINGS_PLAN) for these two tenants only.

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.

Enable backdated deposit balance validation for sandboxes​

The VALIDATE_MAX_DEPOSIT_BALANCE_FOR_BACKDATED_DEPOSITS validation is now enabled for customer and internal sandbox environments.

v9.193.3​

Release Date: 18.08.2026

Improvements​

Data​

Additional work​

  • Internal feature toggle and configuration updates across sandbox environments.

v9.193.2​

Release Date: 18.08.2026

Improvements​

Data​

Additional work​

  • Internal feature toggle and validation configuration updates.

v9.193.1​

Release Date: 18.08.2026

Improvements​

Data​

Additional work​

  • Internal feature toggle and validation rule configuration updates.

For more information, see Mambu Release Cycle.

Last updated on