Skip to main content

Cbe - v9.196

This page contains the following releases for v9.196:

v9.196​

Release Dates

  • Sandbox: 11.11.2026

Features​

Lending​

Apply accrued penalties on demand for Dynamic Term Loans​

The Apply Accrued Penalties option in the More menu now covers Dynamic Term Loans that use the Outstanding Principal penalty method with Declining Balance Discounted interest. It is available at any point in the loan lifecycle, including after maturity, and the application date can be backdated to any date not earlier than the last applied penalty transaction.

Deposits​

Overdraft limit recorded on more deposit transactions​

On deposit products using next-gen backdating, seizure, withdrawal, and fee-applied transactions now record the account's current overdraft limit in the overdraftLimit field (API v2). Accounts without an overdraft limit keep the field empty.

Past-dated deposits refused where interest cannot be recalculated​

On API v2, a past-dated deposit on a next-gen backdating product with a tiered or index interest rate and no dynamic interest configuration on the value date is now refused with HTTP 400 (INVALID_BACKDATED_TRANSACTION). Previously it was accepted without interest being recalculated from the value date.

Cash inflow configuration validated on activation​

Activating a deposit product or deposit account now checks the product's cash inflow configuration. If it is invalid, for example because the funds source is missing, activation is refused and the response explains why. The GraphQL product activation mutation now reports refusals caused by any deposit product feature as an INVALID_PRODUCT_FEATURE_PARAMS user error.

Consistent balances and rules for backdated postings​

On products using next-gen backdating, a backdated deposit, loan disbursement, reversal, or profit posting now updates the stored balance of every later transaction. Later deposits are re-checked against their transaction channel and, for fixed deposits, the maximum opening balance. A posting that would break these rules is refused with the usual error (for example INVALID_AMOUNT) before anything is saved.

Linked sent and received legs for same-day deposit transfers​

Same-day transfers made with POST /api/deposits/{depositAccountId}/transfer-transactions between accounts whose products have opted into the deposits_transfers_reversal product feature now post a linked TRANSFER_SENT and TRANSFER_RECEIVED transaction, together or not at all. The payer's funds are used first, then its authorised overdraft, and never technical overdraft. The API v2 transaction type enum gains TRANSFER_SENT, TRANSFER_RECEIVED, REVERSAL_TRANSFER_SENT, and REVERSAL_TRANSFER_RECEIVED, and concurrent transfers between the same accounts may return 409 CONCURRENT_ACCOUNT_ACTIVITY.

Backdated transfers post as transfer legs​

A backdated transfer between opted-in deposit accounts now posts TRANSFER_SENT and TRANSFER_RECEIVED legs at the value date, and both accounts' later history is replayed. The transfer is refused, with nothing written, if the payer cannot pay at the value date and on every later day of its replayed history.

Transfers involving opted-in products restricted to the new transfer model​

Transfers between an opted-in product and a product that is not opted in are now refused on every channel with TRANSFER_BETWEEN_MIXED_PRODUCTS, naming the account that is not opted in. Transfers between two opted-in products through legacy channels (API v1, the UI, bulk operations) are refused with TRANSFER_CANT_BE_MADE and must use the transfer-transactions endpoint instead.

Reverse deposit transfers​

Transfers between deposit accounts on products opted into transfer reversal can now be reversed through POST /deposits/transactions/{id}:adjust on either leg. The payer is restored at the original value date, and the beneficiary is debited from funds and then authorised overdraft. If the beneficiary cannot pay, the whole reversal is refused and nothing is written.

Transfer reversal details on deposit transactions​

Deposit transactions returned by GET /deposits/transactions/{id} with full details and by POST /deposits/transactions/{id}:adjust now carry an optional transferReversal object on both legs of a reversed transfer and on both reversal entries. It describes the reversal, including the amount, outcome, recovery option applied, account keys, and recovery block reference.

Reversals refused when the beneficiary cannot pay back​

Before posting a transfer reversal, Mambu now checks whether the beneficiary can pay the amount back, based on its available balance when it received the money, at its lowest point since, and today. If it cannot and the recovery option is STRICT_VALIDATION, the reversal is refused with INSUFFICIENT_BENEFICIARY_FUNDS (errorCode 11064) and a detail naming the shortfall. AUTO_BLOCK and MANUAL_BLOCK refuse the same way unless the beneficiary's state can take a block or manual recovery applies.

Recovery block placed on beneficiaries that cannot pay back​

With the AUTO_BLOCK recovery option, reversing a transfer whose beneficiary cannot pay now restores the payer and places a block fund for the full amount on the beneficiary in the same transaction. The reversal record on REVERSAL_TRANSFER_SENT shows the outcome RECOVERY_BLOCK_PLACED with the block's key and reference, and the block can be settled by seizing or releasing it.

Manual recovery and a new notification event for transfer reversals​

Under the MANUAL_BLOCK recovery option, or under AUTO_BLOCK when the beneficiary's account cannot take a block, a reversal now completes with the payer restored and nothing taken from the beneficiary. The reversal record shows MANUAL_RECOVERY_REQUIRED, and the new SAVINGS_TRANSFER_RECOVERY_REQUIRED notification event is raised on the beneficiary so the bank can recover the amount by hand. The event is available for templates and streaming.

Literal transaction type matching and optional compact type storage​

Searching deposit transactions on API v2 with the STARTS_WITH operator on transaction type now matches the value literally, so _ and % are no longer wildcards. For example, FEE_ no longer matches FEES_DUE_REDUCED. Transaction types can also be stored as short codes (for example D for DEPOSIT) to reduce storage. This is off by default and enabled per tenant, and the API, webhooks, streaming, and UI continue to show full type names.

Groundwork for upcoming features​

  • Continued build-out of full cash inflow support on the next-generation deposit engine, including hold settlement and cash inflow configuration validation.

Additional work​

  • Internal deposit engine changes with no customer-visible impact.

Accounting​

Additional work​

  • Backend-only ledger storage changes.

Improvements​

Lending​

Last day of February counts as day 29 for 30E/360 ISDA loans​

Dynamic term loans that use the 30E/360 ISDA day count with a monthly due day of 29 can now treat the last day of February as day 29 in schedule, interest accrual and late interest calculations. The behavior is controlled by a tenant feature toggle that is off by default and applies only to loans created after it is enabled.

Undoing a loan disbursement fully restores Reload deposit accounts​

Undoing a loan disbursement into a Reload deposit account now reverses the deposit in full, restores the account balance and allows later backdated transactions again. If accounting is enabled on the loan product, the undo is rejected and nothing is changed.

Accounting​

GL closure lists all loan accounts where interest could not be applied​

When interest cannot be applied on branch loan accounts, the closure is not created and the Close Accounts dialog now lists every affected loan account ID, so you can fix them all before retrying instead of one at a time.

Bug fixes​

Access Control​

Undo Approve on group loans now enforces the same permissions as single loans​

Users without the Approve Loans and Apply Loan Adjustments permissions can no longer undo the approval of a group loan, because the Undo Approve option is now hidden and blocked for them, as it is for single loans.

Lending​

Group name now appears in the browser tab for closed group loans​

The browser tab title of a closed group loan now shows the group name followed by the loan ID, instead of "undefined".

Additional disbursements on refinanced tranche loans no longer fail with a valid channel​

Disbursing a refinanced or rescheduled loan with disbursement tranches now uses the transaction channel you provide, and keeps the stored channel when none is provided. A disbursement with no channel at all is now rejected.

Accurate principal paid on installments after reversing a payment on dynamic term loans​

Reversing a payment on a dynamic term loan now fully updates the principal paid across installments, even when a penalty rate change occurred afterward. Installment schedules now match account-level principal balances.

Correct fees on overdue installments after a backdated disbursement​

On loans using Fee included in Total Due, each overdue installment now shows only the fee for its own period, and a fee can no longer fall below zero. Existing affected loans are corrected the next time their schedule is recalculated.

Fee amortization no longer exceeds the fee amount​

On loans with amortized fees, a single amortization step can no longer recognise more than the part of the fee still left to amortize. This prevents rounding from causing daily amortization failures and blocking account closure after a fee transfer, reschedule, or refinance.

First repayment date stays correct after a centre meeting day change​

The first repayment date in a loan's disbursement details now matches the first installment in the repayment schedule after a client or group moves to a centre with a different meeting day, or after a centre's meeting day is edited.

Edit Account now regenerates the repayment schedule for revolving credit accounts​

Editing the principal payment amount, percentage, or method of an active revolving credit account through Edit Account (UI or API) now regenerates the repayment schedule and principal due immediately, rather than waiting for the next recalculation.

Late repayment fee is applied once on loans with optimized payments​

On loans with optimized payments where installments were repaid ahead of schedule, the late repayment fee is now applied once, to the installment that is actually late. This prevents inflated fee balances and end-of-day processing failures. The fix is controlled by a feature toggle and is enabled per tenant.

Clear validation message for backdated Index Interest Rate settings​

Creating or editing a loan, or generating its schedule, with an Index Interest Rate setting dated before the earliest available rate now returns a clear validation error instead of a generic internal error. The message appears inline under the relevant Valid from field in the UI, and as a descriptive 400 error via the API.

Deposits​

Deposit product updates no longer rejected for products with a product feature and existing interest settings​

Updating a deposit product that has a product feature attached (for example, the deposit rounding policy) and existing interest rate settings now succeeds through the UI, the API, and the deposits configuration YAML when the interest settings are unchanged. Adding a new legacy interest section to a product built on product features is still rejected.

End-of-day processing no longer fails for deposit accounts without an interest payment point​

Deposit accounts with no interest payment point, typically on products without interest, are now processed normally at end of day when bulk reversal of interest applications is enabled. Deposits and withdrawals on these accounts no longer fail with an internal error.

Deposit product updates no longer rejected for unchanged opening balance values​

With opening balance validation enabled for non-fixed-deposit products, an update is now rejected only when it adds or changes an opening balance value on a product type other than fixed deposit. Existing values that are left unchanged, or removed, are accepted.

Stable paging for deposit account transactions created in the same second​

Paging through /api/deposits/{depositAccountId}/transactions with limit and offset now returns each transaction exactly once, because transactions created in the same second are ordered by descending transaction ID. This applies to both the BASIC and FULL details levels.

Correct total balance on deposit accounts after backdated transactions or reversals​

Backdated transactions and reversals on deposit accounts with older withholding tax, profit, transfer, or fee-reduction transactions no longer understate the total balance or the running balances of later transactions. Deposits are no longer accepted or refused incorrectly against the product's maximum balance.

For more information, see Mambu Release Cycle.

Last updated on