Skip to main content

Cbe - v9.195

This page contains the following releases for v9.195:

v9.195​

Release Dates

  • Sandbox: 16.10.2026

Features​

Lending​

Previously paid installments are no longer incorrectly marked as late on dynamic term loans that use the IRC freezing solution. The earlier behavior is restored as the default, and the recent grace-installment change is available behind a new toggle.

Additional work​

  • Internal test coverage for lending balance downloads.

Mortgages​

Additional work​

  • Internal design and planning work for mortgage penalties.

Deposits​

Added Monthly Deposit Limits for Mexico as an Installable Extension in API v2.0​

We introduced support for monthly deposit limits on Mexican deposit accounts, allowing organizations to cap monthly deposit totals based on account compliance levels.

Key Features:

  • UDI-Based Monthly Caps: Allowance limits are configured in Investment Units (UDIS). Any deposit that causes cumulative monthly deposits to exceed the account's compliance limit is automatically rejected.
  • Value-Date Compliance Rules: Compliance levels apply effective from specific dates, ensuring backdated deposits are evaluated against the exact compliance level active on their value date.
  • Extension-Based Management: Delivered as an installable API v2.0 extension rather than manual setup. Requires deposit products to have dynamic balances enabled.

Extension Points API Update:

  • Removed the inactive deposits.deposit.afterBalanceUpdate phase from the response list in GET /api/extensionpoints (API v2.0). Integrations should use deposits.deposit.afterValidate instead.

Availability Note: To discuss requirements and enable Mexican deposit limits for your tenant, please contact your Customer Success Manager.

Groundwork for upcoming features​

  • Extending the next-generation cash-inflow engine toward a full implementation, with consistent eligibility, access, account-state, backdating and rejection-reason handling for deposits.
  • Building the next-generation cash-outflow engine for withdrawals, including a non-production preview of balance routing and stricter product-feature validation.

Cards​

Cardholder Balance Now Visible on GET Credit Account Endpoint​

We updated the GET /creditaccounts/{id} API response to expose cardholder balance information resulting from overpayments.

What Changed:

  • New cardholderBalance Field: The GET /creditaccounts/{id} response payload now includes a cardholderBalance field, displaying any credit balance held in the cardholder's favor from an overpayment. This field is always present in response payloads and defaults to 0 when no cardholder balance exists.
  • Updated availableBalance Calculation: The availableBalance field now correctly incorporates the cardholder balance when the credit product is configured to allow overpayments to extend the available credit limit.

Developer​

Process instance search accepts usernames​

The process instance search API now accepts a username, in addition to an encoded key, when filtering by the starting user (startUserId). Existing encoded-key filters continue to work unchanged.

View and edit extension fields on account and product pages​

Deposit and loan account and product pages now show a tab for each installed extension that has externally visible CURRENT_ONLY fields, with a sub-tab per field. Users can view current values and, with the relevant edit permission, update editable fields; internal, temporal and read-only fields remain excluded or protected.

Duplicate requests now return the original response on five endpoints​

Retrying a request with a previously used idempotency key no longer fails with an internal server error on loan schedule preview, tranche schedule preview, external loan account migration, or deposit account interest availability creation. Collateral asset reevaluation no longer returns an empty body, and all five endpoints now return the original response.

Improvements​

Access Control​

Strengthened authentication for Mambu UI requests to API v2​

We strengthened how the Mambu UI authenticates its own requests to API v2. Users who were logged in while this update was deployed may need to log in again once.

Lending​

Added API Endpoint for Downloading End-of-Day Loan Account Balances​

We introduced a new API endpoint that allows users to retrieve recorded end-of-day (EOD) closing balances for loan accounts in bulk.

Key Capabilities:

  • Flexible Date Selection: Query closing balances for a specific date, or omit the date parameter to automatically fetch data for the most recent completed day.
  • Optimized Bulk Export: Large datasets can be split across account ranges and retrieved in parallel for faster data processing.

Feature Toggle Note: This endpoint is disabled by default and can be enabled upon request.

Groundwork for upcoming features​

  • Daily end-of-day balance snapshots for active loan accounts, in support of upcoming EOD balance download capabilities.

Additional work​

  • Internal lending maintenance with no customer-facing changes.

Mortgages​

Additional work​

  • Internal mortgages maintenance with no customer-facing changes.

Deposits​

Additional work​

  • Backend-only deposit transaction processing changes.

Credit Arrangements​

Additional work​

  • Internal credit arrangements maintenance with no customer-facing changes.

Auditing​

Locale Data Provider Updated (COMPAT → CLDR)​

We updated the platform's internal locale data provider from the legacy COMPAT provider to the standard CLDR provider in preparation for future JDK upgrades.

What Changed:

  • Provider Migration: Transitioned from the legacy COMPAT locale data provider to CLDR (the standard JDK default since Java 9).
  • Minor Display Adjustments: Most organizations will experience no functional or visual changes. Organizations using custom date formats with textual month names (e.g., MMM or MMMM, such as "17-Nov-2017") in General Settings may notice subtle rendering differences in the activity feed and audit trail.

Note: This is an internal platform update with display-only formatting impacts. No underlying date data or business logic is affected.

Islamic Banking​

Idempotency-Key header described on Murabaha contract endpoints​

The Idempotency-Key header on the Murabaha endpoints for creating a contract (POST /islamic-financing/murabaha/contracts), posting a repayment and correcting a repayment now has a description in the API documentation and generated Java SDK, consistent with other endpoints. The API behaviour itself is unchanged.

Developer​

Process Definition Uploads Now Validate Template and Decision References​

We updated process definition validation to verify that referenced message templates and decision tables exist at the time of upload.

Previous Behavior: Uploading a process definition that referenced a non-existent message template or decision table was accepted by the system, causing errors later when the process definition was activated or executed.

New Behavior: The system now validates references during the upload phase and fails immediately if a referenced message template or decision table does not exist, preventing invalid process definitions from being saved.

Additional work​

  • Internal developer tooling maintenance.

Bug fixes​

Access Control​

Enforced Access Permissions on Loan Planned Fees and Repayment Schedule Endpoints​

We resolved an authorization issue where read endpoints for loan planned fees and repayment schedule versioning were accessible without validating user permissions.

Previous Behavior: The GET /loans/{id}/plannedfees and GET /loans/{id}:repaymentScheduleVersioning endpoints lacked permission validation checks, allowing API users to access this data without needing the VIEW_LOAN_ACCOUNT_DETAILS permission.

New Behavior: Both endpoints now strictly enforce permission checks and require the VIEW_LOAN_ACCOUNT_DETAILS permission, aligning with other loan account read endpoints. API requests made without this permission will now return HTTP 403 Forbidden.

Lending​

Accurate Repayment Amount Display When Editing Revolving Loan Products​

The Edit Product screen now shows the saved Repayment Amount setting for Revolving Loan Products, so products configured with Total Due Payment are no longer displayed as Principal Payment.

Correct Handling of Three-Decimal Percentages for Comma-Decimal Organizations​

On the Edit Repayment Method Value screen for revolving credit accounts, a percentage with exactly three decimal places (e.g. 8.125) is no longer saved as 8125 for organizations using a comma decimal separator; out-of-range values now trigger an immediate error stating the valid range and the decimal separator to use. Organizations configured with a comma separator should enter such values with a comma (e.g. 8,125).

Fixed Error Response for Invalid Product Keys in Reschedule and Refinance APIs​

We resolved an issue where passing a non-existent product key to the loan Reschedule or Refinance APIs resulted in a generic internal server error.

Previous Behavior: Providing a loan product key that did not exist in requests to the loan Reschedule or Refinance API endpoints caused the system to respond with an HTTP 500 Internal Server Error.

New Behavior: The API endpoints now validate the loan product key upfront and return a descriptive HTTP 404 (INVALID_PRODUCT_ID) error when an invalid or non-existent product key is supplied.

Fixed Validation Error for Invalid Interest Spread in Create Loan Account API​

We resolved an issue where creating a loan account with an invalid interest spread returned an internal server error instead of a descriptive validation message.

Previous Behavior: When creating a loan account via the API with an interest spread that violated the product's defined minimum or maximum limits, the system returned an internal server error instead of an actionable response.

New Behavior: The API now properly validates interest spread constraints upon loan creation and returns a clear, specific validation error detailing which product constraint was violated.

Fixed Rescheduling and Refinancing Loans with Inactive Products in UI​

We resolved an issue where loan accounts could still be rescheduled or refinanced onto an inactive loan product through the admin UI.

Previous Behavior: When a loan product was deactivated, it continued to appear in the reschedule and refinance dropdown menus in the admin UI. Completing the action in the UI succeeded despite the operation being correctly rejected by the API, resulting in inconsistent validation logic.

New Behavior: Inactive loan products are no longer displayed in the reschedule and refinance dropdown menus. Submitting these operations against inactive products via the UI is now blocked, bringing UI validation into full alignment with the API.

Fixed Savings-to-Loan Transfers Blocking Pending Loan Tranche Disbursements​

We resolved an issue where performing a savings-to-loan transfer on the same date as a scheduled tranche disbursement permanently prevented the tranche from being disbursed.

Previous Behavior: When a savings-to-loan transfer was executed on the same date as a pending tranche's expected disbursement, the system accepted the transfer. However, this transfer subsequently blocked the tranche from being disbursed, leaving the loan account in an unrecoverable state.

New Behavior: The system now proactively rejects savings-to-loan transfers upfront with a clear error if they conflict with a pending tranche disbursement on the same date. Transfers made on other dates and transfers to loan accounts without pending tranches are unaffected.

Fixed Custom Field Selection Values with IN Operator in Search API​

We resolved an issue where using selection values for custom fields with the IN operator in search endpoints failed with an error.

Previous Behavior: When querying loan accounts, clients, deposits, or other entities via search APIs using a custom field selection value with the IN filter operator, the API rejected the request. Users had to perform extra lookups to use internal encoded keys as a workaround.

New Behavior: The search APIs now properly support custom field selection values when using the IN filter operator alongside internal encoded keys, fully aligning implementation with the documented API specifications.

Fixed Display of 'Accrue Late Interest' on Fixed Term Loan Product Summaries​

We resolved a display issue where Fixed Term Loan (FTL) product summaries incorrectly showed an inapplicable late interest setting.

Previous Behavior: Product summaries for Fixed Term Loans displayed Accrue Late Interest: Yes, even though late interest accrual is not applicable to Fixed Term Loan products.

New Behavior: The Accrue Late Interest field has been removed from the summary display for Fixed Term Loan products, ensuring that product configuration details accurately reflect applicable functionality.

Accurate Arrears Dates After Schedule Edits on Percentage-Tolerance Loans​

For loans using the Date Account First Went to Arrears method with an outstanding-principal tolerance percentage, the arrears date is now determined from the schedule as it existed at the time of each repayment, so installments already paid are no longer counted toward the arrears threshold after a schedule edit.

Fixed Interest Type Display and Validation Messaging for Fixed Term Loan Products​

We resolved two issues on the Fixed Term Loan (FTL) product configuration screen regarding field visibility and error messaging.

Previous Behavior:

  • Fixed Term Loan products configured with Simple Interest did not display the Interest Type field on the product overview page, making the setting appear absent.
  • Attempting to save an FTL product configured with Compound Interest alongside the Using Repayment Periodicity repayment calculation threw a generic error message that provided no context.

New Behavior:

  • The Interest Type field is now consistently visible on the product overview page for all Simple Interest FTL products.
  • Validation messaging has been updated to clearly state that Compound Interest is not supported when Using Repayment Periodicity is selected.

Fixed Disbursed Amount Display in Loan Accounts Report for Deducted Fees​

We resolved an issue in the Loan Accounts report where the Disbursed Amount column displayed the gross loan amount rather than the net amount received by the borrower when fees were deducted at disbursement.

Previous Behavior: When a loan had fees deducted upon disbursement, both the Disbursed Amount and Loan Amount columns in the Loan Accounts report displayed identical gross values, obscuring the actual net funds disbursed to the customer.

New Behavior: The Disbursed Amount column now accurately reflects the net amount received by the customer (calculated as the total Loan Amount minus any fees deducted at disbursement).

Fixed Schedule Recalculation After Large Prepayments on Optimized Payments Loans​

We resolved an issue where applying a large prepayment to an Optimized Payments loan unexpectedly dropped trailing installments from the schedule.

Previous Behavior: When a loan configured with Optimized Payments, Reduce Amount Per Installment, and Mark Installment as Paid When: Full Due is Paid received a large prepayment, the schedule recalculation engine zeroed out the final installments. The system incorrectly behaved as if configured for Reduce Number of Installments, altering the schedule length.

New Behavior: Prepayments now correctly reduce the due amounts evenly across all remaining installments, preserving the full schedule term and preventing trailing installments from being removed.

Fixed Validation Error When Adjusting Payment Holidays on Loans with Grace Installments​

We resolved an issue where adding or removing payment holidays on dynamic loan accounts with initial grace installments failed with a validation error.

Previous Behavior: When adding or removing payment holidays on dynamic loans using the Reduce Number of Installments or Reduce Amount per Installment repayment methods, requests failed with an INVALID_GRACE_PERIOD_SETUP error if the schedule included a grace installment caused by schedule-end rounding.

New Behavior: Payment holiday adjustments now correctly synchronize grace installment markers on the recomputed schedule, allowing payment holiday additions or removals to complete successfully.

Fixed Predefined Fee Allocation in Custom Repayments​

We resolved an issue where custom repayments failed to apply payment amounts to the explicitly selected predefined fee on off-schedule loans.

Previous Behavior: When executing a custom repayment selecting a specific predefined fee for fees applied after loan schedule maturity (off-schedule), the system incorrectly allocated the payment amount to a different fee (such as the oldest fee) instead of the user-selected fee.

New Behavior: Custom repayments now consistently apply the payment amount to the selected target fee. Any remaining unallocated payment amount is then applied to any other outstanding fees.

Fixed Interest Calculation for Advance Payments on Loans with Capitalized Fees​

We resolved an issue where advance payments on Dynamic Term Loans with capitalized disbursement fees calculated interest without including the fee in the principal balance.

Previous Behavior: When an advance payment was processed for a Dynamic Term Loan with a capitalized disbursement fee, interest was computed solely on the base loan amount. This produced a discrepancy against the interest applied on regular scheduled due dates.

New Behavior: Interest for advance payments is now calculated using the full outstanding principal balance, including any capitalized disbursement fees, ensuring consistency across scheduled and early repayments.

Fixed Loan State Corruption When Editing Schedule on Approved Loans​

We resolved an issue where editing a fixed-term loan's repayment schedule while in an APPROVED state corrupted the account status and broke disbursement workflows.

The Issue: Editing a repayment schedule for an APPROVED loan (e.g., via a stale UI session) silently transitioned the loan status to ACTIVE_IN_ARREARS. This corrupted the account state and permanently prevented the Undo Disbursement action from working.

The Fix: The server now strictly validates account status before allowing schedule modifications. Schedule edit requests are now rejected for all non-disbursed accounts, regardless of the entry point (REST API or legacy UI).

Deposits​

Fixed Currency Reset Issue When Editing Foreign-Currency Savings Products​

We resolved an issue where editing a foreign-currency savings or deposit product could silently revert its currency to the organization's base currency or block changes from saving.

Previous Behavior: When editing an existing foreign-currency savings or deposit product in the admin UI, updating any non-currency field could silently reset the product's currency to the organization's base currency. If accounts had already been opened in the original currency, saving the product updates was blocked completely.

New Behavior: The product's configured currency is now reliably preserved when updating product details, and will only change if explicitly modified in the Currencies field.

Breaking Change: Normalized Decimal Formatting for Deposit Balance Summary, Transactions, and Blocks API Responses​

We corrected an API response formatting issue where monetary fields across several deposit endpoints returned raw 10-decimal storage values instead of standard normalized decimal representations.

Previous Behavior: Monetary fields returned by GET /api/deposits/{accountId}/balanceSummary, GET /api/deposits/{accountId}/transactions, and GET /api/deposits/{accountId}/blocks were displayed using an internal 10-decimal storage format (e.g., 468234148.4600000000).

New Behavior: Monetary fields are now returned using standard normalized decimal representations (e.g., 468234148.46).

Affected Endpoints & Fields:

  • GET /api/deposits/{accountId}/balanceSummary: avgBalance, totalBalance, minBalance
  • GET /api/deposits/{accountId}/transactions: amount, fee/tax amount fields
  • GET /api/deposits/{accountId}/blocks: amount, seizedAmount

Breaking Change & Feature Toggle Note: Numerical values are unchanged, but literal JSON string representations have changed for default responses. Tenants using the TEN_DECIMALS_BACKWARDS_COMPATIBILITY_APIV2_RESPONSE feature toggle will continue to receive the existing 10-decimal scale format.

Fixed Deposit Account lastModifiedDate Not Updating on Approval​

We resolved an issue where approving a deposit account failed to update the account's lastModifiedDate timestamp.

Previous Behavior: Approving a deposit account (transitioning from Pending Approval to Approved) updated the accountState and approvedDate fields, but left lastModifiedDate unchanged. As a result, integrations that poll for changes using lastModifiedDate missed newly approved accounts.

New Behavior: Approving a deposit account now automatically updates lastModifiedDate to the approval timestamp, aligning approval with all other deposit account state transitions (such as activate, lock, unlock, close, and undo-approve).

Note: This fix applies forward-only. Deposit accounts approved prior to this release retain their existing lastModifiedDate and can be reconciled using approvedDate if necessary.

Breaking Change: Normalized Decimal Formatting for Daily Accrued Interest Search API​

We corrected a formatting issue in the POST /api/deposits/{accountId}/dailyAccruedInterest:search endpoint where BigDecimal fields were returned with trailing zeros from internal 10-decimal storage representations.

Previous Behavior: Response payload fields were formatted using an internal 10-decimal storage format (e.g., 314625738.7700000000, or 0E-10 for zero) instead of standard normalized decimal representations.

New Behavior: Response fields are now properly formatted using standard normalized decimal representation (e.g., 314625738.77, or 0).

Affected Fields:

  • accruedInterest
  • negativeInterestAccrued
  • overdraftInterestAccrued
  • technicalOverdraftInterestAccrued
  • accountBalance
  • creditInterestRate

Feature Toggle & Breaking Change Note: Numerical values are unchanged, but this modification may impact API consumers performing exact string comparisons or strict decimal-place validation. To prevent unexpected integration impact, this change is behind a feature toggle and disabled by default.

Fixed HTTP 500 Internal Error When Creating Deposit Products With Fee Accounting Rules​

We resolved an issue where creating a deposit product via the API v2 endpoint (POST /depositproducts) returned an HTTP 500 internal server error when fee-level accounting rules were included in the request payload.

Previous Behavior: Including feesSettings.fees[*].accountingRules in the request body when creating a deposit product caused the request to crash with HTTP 500 (errorCode: 6, INTERNAL_ERROR) instead of persisting the configuration or returning a valid error message.

New Behavior: The POST /depositproducts endpoint now successfully accepts and processes fee-level GL accounting rules:

  • Returns HTTP 201 Created upon successful deposit product creation, properly persisting fee-level accounting rules.
  • Returns an actionable HTTP 4xx error (such as INVALID_ACCOUNTING_SETUP) if the accounting configuration fails business validation criteria.

Breaking Change: Normalized Decimal Formatting for Deposit Account Interest Rate API Responses​

We corrected an API response formatting issue where interest rate fields in deposit account endpoints returned raw 10-decimal storage values instead of standard normalized decimal representations.

Previous Behavior: The interestRate fields on GET /api/deposits/{accountId} and interestAvailabilities endpoints were serialized using internal 10-decimal precision formatting (e.g., 10.0000000000).

New Behavior: Interest rate fields are now returned using standard normalized decimal representations (e.g., 10.00), consistent with the formatting used for balance and overdraft limit fields.

Affected Fields:

  • interestSettings.interestRateSettings.interestRate
  • overdraftInterestSettings.interestRateSettings.interestRate

Breaking Change & Feature Toggle Note: Numerical values are unchanged, but literal JSON string representations have been normalized. This update aligns with the TEN_DECIMALS_BACKWARDS_COMPATIBILITY_APIV2_RESPONSE feature toggle mechanism to manage backward compatibility for API consumers.

Credit Arrangements​

Fixed Loan Disbursement Failures When Linking to Credit Arrangements via API​

We resolved an issue where linking a loan to a Credit Arrangement using the Loan Patch API left the Credit Arrangement in an invalid state and prevented loan disbursement.

The Issue: Previously, when a loan was associated with a Credit Arrangement via a PATCH request to the loan endpoint, the Credit Arrangement was left in an inconsistent internal state. As a result, subsequent attempts to disburse the loan would fail.

The Fix: The association logic within the Loan Patch API has been corrected. Loans linked to a Credit Arrangement via PATCH are now properly recognized and integrated, ensuring the Credit Arrangement maintains a valid state so disbursement can proceed smoothly.

Transactions and Interest​

Fixed Custom Field Value Overflow on Transaction Detail Views​

We resolved a display issue where long custom field values visually overflowed their container on transaction detail pages for users without edit permissions.

Previous Behavior: When viewing deposit or loan account transaction details without edit permissions, long custom field values overflowed their container bounds and overlapped adjacent UI elements.

New Behavior: Custom field values now text-wrap correctly within their designated field containers for read-only users, matching the standard layout used when edit permissions are enabled.

Note: This is a visual UI fix only. No underlying data or backend functionality has changed.

Accounting​

Lifted Restrictions on Exporting Large Numerical Values to Excel​

We resolved an issue where exporting financial reports to Excel truncated large numerical values.

Previous Behavior: When exporting reports to Excel (such as Trial Balance reports), numerical values exceeding 15 digits were truncated, leading to incomplete or imprecise financial figures.

New Behavior: The 15-digit limitation on Excel exports has been removed. Large numerical values are now preserved and exported in full without truncation.

Fixed Decimal Formatting for Foreign Currency Amounts in Generated Documents​

We resolved an issue where document template fields for credit and debit amounts applied base currency decimal rules to foreign or non-traditional currencies, resulting in incorrect decimal rounding.

Previous Behavior: When generating documents containing posted credit or debit amounts (such as DEBIT_AMOUNT or CREDIT_AMOUNT) in a foreign or non-traditional currency, the system formatted values using the organization's base currency decimal rules instead of the target currency's rules. For example, a tenant with a 2-decimal base currency and a 4-decimal foreign currency would see 0.6552 rounded to 0.6600.

New Behavior: Document generation now respects and applies the specific decimal precision rules configured for the transaction's foreign or non-traditional currency, accurately displaying full precision (e.g., 0.6552).

For more information, see Mambu Release Cycle.

Last updated on