Skip to main content

Cbe - v9.194

This page contains the following releases for v9.194:

v9.194​

Release Dates

  • Sandbox: 26.08.2026

Features​

Lending​

Automated Allocation of Refund Overflow to Credit Balance for FORWARD_ONLY Refunds​

We have enhanced the behavior of the FORWARD_ONLY refund recalculation method to seamlessly handle excess refund amounts on revolving credit accounts.

How it Works: When a refund transaction is executed under the FORWARD_ONLY strategy, the amount is applied to reduce the outstanding principal balance. If the total refund amount exceeds the remaining outstanding principal on the loan, the system now automatically routes and stores the overflow (surplus) amount in the revolving account's Credit Balance.

Prerequisites: This automated routing behavior is active only when both the Refund and Credit Balance features are explicitly enabled on the target revolving product configuration.

Implemented FORWARD_ONLY Refund Recalculation Method for Revolving Credit Products​

Revolving Credit products can now be configured with a FORWARD_ONLY refund recalculation method. When a refund is posted to an account on such a product, it is treated as a principal-only repayment:

  • The outstanding principal balance is reduced by the refund amount.
  • Billed (late) installments have their principal settled in chronological order (oldest first); their interest and fees remain due and are never reduced or reversed.
  • Only future (pending) installments are re-amortised on the new, lower principal. For the billing period that contains the refund date, interest is split between the pre-refund and post-refund balances.
  • Any refund amount exceeding the outstanding principal is moved to the account's credit balance.
  • The refund can be adjusted and reversed.

This behaviour is opt-in and applies only when the product's refund recalculation method is set to FORWARD_ONLY and the ALLOW_REFUND_TRANSACTIONS_FOR_REVOLVING_ACCOUNTS and ENABLE_REVOLVING_RELOAD feature toggles are enabled. Products using the default (LEGACY) or RETROACTIVE method are unaffected.

Introduced Notification Templates for Refund Forward-Only Transactions​

We have added notification support for the FORWARD_ONLY refund workflow on revolving credit accounts. This update allows you to automatically alert and update your customers whenever refunds or refund adjustments are processed.

The Improvement: You can now configure automated communications triggered by specific refund events. Two new message templates have been introduced to the communication engine:

  • REFUND_FORWARD_ONLY: Triggers automatically when a forward-only refund is posted to a customer's account (such as when an overflow amount is successfully routed to their Credit Balance).
  • REFUND_FORWARD_ONLY_ADJUSTMENT: Triggers when a previously applied forward-only refund is adjusted or reversed.

Configurable Maximum Days for Refund Window on Revolving Credit Products​

We have introduced the Max Number of Days for Refund setting for Revolving Credit loan products. This optional, product-level configuration enables automated enforcement of lending refund policies by establishing a strict time window within which a disbursement can be refunded.

When configured, the system evaluates the transaction timeline and automatically rejects any refund request whose value date falls outside the designated calendar day threshold.

  • Key Rules & Behaviors

  • Optional & Backward Compatible: When this parameter is left blank, refunds remain permitted without any time constraints, preserving legacy behavior.

  • Inclusive Boundary Controls: A refund value-dated exactly on the final allowed day will be permitted, whereas a request even one calendar day beyond the limit is rejected. Setting the parameter to 0 restricts refunds strictly to the same calendar day as the disbursement.

  • Anchored to the Specific Disbursement: The time window is calculated directly from the entry date of the linked disbursement transaction, rather than the account's historical first disbursement.

  • Governed by Value Date: Validation evaluates the value date of the refund. This ensures that backdated refunds are successfully processed if their value date falls within the permitted window, regardless of when they are physically posted.

  • Recalculation Method-Agnostic: This constraint applies uniformly across both FORWARD_ONLY and RETROACTIVE refund recalculation methods.

Availability Note: This new product-level configuration is fully supported and manageable across all core interfaces: the Product API v2, the Mambu SDK, and the Product Administration Screen (Admin UI).

Fixed Penalty Application After Final Installment Date​

We resolved an issue where penalties could not be applied after a loan's maturity date on products configured with the Outstanding Principal * # of Late Days * Penalty Rate calculation method.

Previous Behavior: Once the interest for the last installment was fully paid on a loan past its maturity date, attempting to manually apply a penalty failed, and automatic penalty accrual stopped functioning.

New Behavior: Penalties now accrue and apply automatically after the final installment date. Manual penalty applications are also accepted as expected, regardless of whether the interest on the last installment has been cleared.

Configuration Note: This behavior fix is gated behind a feature toggle and is currently Toggled Off in production by default.

Additional work​

  • Internal lending archival infrastructure.

Deposits​

Deposit command path now records user, branch, centre and product keys on the transaction​

The next-gen cash-inflow (deposit) command path now stamps the audit and context keys on the created SAVINGSTRANSACTION row — USERKEY (the user performing the deposit), BRANCHKEY, CENTREKEY and PRODUCTTYPEKEY (copied from the account) — matching the legacy LogSavingsTransactionService behaviour. This closes an audit/access-control gap so transactions created through the command path are no longer left with NULL user/branch/centre/product keys.

Groundwork for upcoming features​

  • Cash outflow distribution engine for deposit withdrawals.

Cards​

Automated Hold on Pin Debit Refunds to Prevent Double-Dipping Fraud​

To help prevent "double-dipping" fraud on prepaid card refunds, single-message Pin Debit Refund events can now be automatically placed on a temporary hold instead of being credited to the available balance immediately.

How it Works: When a Pin Debit Refund event is received for a Current Account linked to a card token, Mambu checks whether refund hold settings are enabled for the account's savings product. If enabled, the refunded amount is placed on hold for the configured duration and released automatically after the configured hold duration has elapsed, with no manual intervention required. If no refund hold settings are enabled for the product, the refund falls through to the regular financial transaction flow and is credited immediately, as before.

Note: This behavior applies only to single-message Pin Debit Refund events processed through the Mambu Marqeta Connector. Dual-message refund flows and loan accounts are unaffected.

For more information, see Pin debit refund holds

Improvements​

Lending​

Automated Accounting for Refund Forward-Only Transactions​

We have introduced automated General Ledger (GL) accounting support for the FORWARD_ONLY refund workflow on revolving credit products. Financial data is now properly logged and tracked in the ledger for both the initial refund events and their subsequent adjustments.

The core banking engine now automatically records accounting journal entries for:

  • REFUND_FORWARD_ONLY Transactions
  • REFUND_FORWARD_ONLY_ADJUSTMENT Transactions

Decimal Amounts Supported for Manual Fees on DBEI Loans with Whole Unit Rounding​

We resolved an issue where applying a manual fee with a decimal amount silently failed on Declining Balance Discounted (DBEI) loan accounts using whole unit currency rounding.

Previous Behavior: When applying a manual fee with a decimal value to a DBEI loan product configured with the ROUND_TO_NEAREST_WHOLE_UNIT repayment rounding method, the fee was not applied. The system failed silently in the user interface without displaying an error message, while throwing an InvalidFeeException in the backend logs.

New Behavior: Decimal amounts are now correctly accepted and processed for manual fees on DBEI loan products using ROUND_TO_NEAREST_WHOLE_UNIT rounding.

Technical Context: This fix aligns behavior with the ROUND_UP_TO_NEAREST_WHOLE_UNIT setting, as whole unit rounding on DBEI products applies strictly to the overall Total Due rather than individual fee components.

Added Input Validation for the ID Pattern Field in Loan Products​

We have introduced input validation for the ID pattern (random pattern) field in Loan Products to enhance system security and prevent potential Cross-Site Scripting (XSS) vulnerabilities.

The Improvement: To block malicious scripts and invalid inputs, the system now strictly validates that the ID pattern field only contains authorized template characters:

  • # (for numbers)
  • @ (for letters)
  • $ (for alphanumeric characters)

Any special characters, HTML tags, or other unsupported inputs are now rejected when creating or modifying a loan product's ID pattern.

Configuration & Compatibility:

  • Feature Toggle: This validation is gated behind the validateSpecialCharactersInLoanProductIdPattern feature toggle.
  • Existing Products: Loan products currently using non-conforming ID patterns will remain unaffected and active. However, validation rules will be enforced the next time those products are edited.

For more information see Setting up new loan products in the user guide.

Additional work​

  • Internal lending development workflow improvements.

Deposits​

Extended ArchUnit Guardrails to Prevent Mutable Singletons in Deposits​

We have implemented an internal architectural guardrail to prevent mutability issues within singleton service classes in the Deposits transaction processing path.

What Changed:

  • Expanded ArchUnit Testing: The automated ArchUnit architecture tests have been extended to cover both Guice (com.google.inject.@Singleton) and JSR-330 (javax.inject.@Singleton) annotations, ensuring strict compile-time and test-time validation across dependency injection frameworks.
  • Singleton Remediation: Following a comprehensive audit, we applied final and volatile modifiers to 8 singleton classes to eliminate potential multi-threading issues and enforce state immutability.
  • Incident Context: This proactive improvement was triggered by INC-1598. The core concurrency bug associated with this behavior was already resolved and patched under DIF-2766 (released in versions v9.189.8, v9.190.4, and v9.191.3).

Operational Impact: This is a backend architectural improvement focused on long-term system stability and safety. There is no change to user-visible behavior or API contracts.

Groundwork for upcoming features​

  • Next-generation deposit transaction processing with backward-compatible API response mapping.

Mortgages​

Additional work​

  • Internal mortgage development maintenance.

Developer​

Additional work​

  • Internal development tooling fixes.

Bug fixes​

Lending​

Fixed One-Cent Fee Tax Residual on Dynamic Term Loans​

We resolved an issue where settling taxable fees across multiple payments on Dynamic Term Loans could leave a 1-cent tax residual.

Previous Behavior: When a taxable fee was paid across two or more repayments, a $0.01 tax-on-fees residual could remain on the installment due to rounding. As a result, the installment status would be marked as Paid, but the schedule would incorrectly display a small negative Fees Due amount.

New Behavior: The fee tax calculation engine now handles split fee repayments cleanly without leaving rounding residuals. Installments now balance to zero across principal, fee, and tax components when fully settled.

Fixed an issue where a backdated repayment on a Dynamic Term Loan with Round Remainder into Last Repayment could fail with a schedule inconsistency error​

Backdated repayments on Dynamic Term Loans using Declining Balance Equal Installments with Round Remainder into Last Repayment now complete successfully. Previously, the operation could fail with an inconsistency error when the rounding adjustment could not be absorbed by the last non-zero installment alone.

Payment Holidays No Longer Blocked by Grace Period Validation​

We resolved an issue where adding a payment holiday to a dynamic-term loan's repayment schedule was incorrectly rejected by the system's grace-period validation logic.

The Issue: Previously, applying a payment holiday could trigger an inaccurate rejection error claiming an invalid grace-period installment count, even when the modification was completely valid. This occurred because the validation check was being executed on the newly recomputed schedule. Since the recomputed schedule does not have access to the necessary persisted custom-installment settings, the validation check became unreliable and threw false-positive errors.

The Fix: The system now safely bypasses this unreliable post-compute grace-period validation when modifying schedules for payment holidays. This ensures that valid holiday periods can be added successfully without operational interruption.

Configuration Note: This fix is delivered behind the feature toggle fixGracePeriodValidationBlockingPaymentHoliday and is disabled by default. When the toggle is disabled, legacy behavior is maintained.

Tax Rate Changes No Longer Revert Status of Installments Covered by Advance Payments​

We resolved an issue where applying a tax rate change could retroactively alter the status of installments previously settled by advance payments.

Previous Behavior: When a tax rate change occurred later in a loan's schedule, installments that had already been fully covered by an advance payment could incorrectly revert from Paid to Partially Paid.

New Behavior: Installments covered by advance payments now reliably maintain their Paid status when subsequent tax rate changes take effect on the schedule.

Fixed Mismatch Between Installment and Schedule-Level Total Penalty Due​

We resolved an issue where the total Penalty Due displayed at the bottom of the repayment schedule did not match the sum of penalty amounts shown across individual installments.

The Issue: Previously, the total Penalty Due shown at the schedule level included taxes, whereas the individual per-installment penalty amounts excluded them. Because of this calculation discrepancy, attempting to process a Custom Repayment for the displayed total penalty amount would trigger an Excess Payment error and fail.

The Fix: The schedule summary and installment penalty display logic have been aligned. The total Penalty Due now accurately reflects the sum of individual installment penalties, allowing Custom Repayments based on the displayed totals to process successfully.

Fixed an issue where adjusting a Reduce Penalty Due transaction returned a generic internal error instead of a clear message​

Attempting to adjust a Reduce Penalty Due transaction now returns a clear message explaining that this transaction type must be adjusted manually. Previously, the operation failed with a generic internal error with no indication of the next step.

Fixed Schedule Screen Display for Custom Repayments Allocated to Fees and Principal​

We resolved a display inconsistency where applying a Custom Repayment split between principal and a fee balance did not update the Schedule screen properly.

Previous Behavior: When a Custom Repayment was allocated to both principal in the repayment schedule and an outstanding fee balance (feeBalance), the payment posted successfully and appeared on the Account Overview and Transactions screens. However, the principal portion was not reflected on the Schedule screen.

New Behavior: The Schedule screen now accurately reflects the principal amount paid for Custom Repayments involving fee balance allocations, ensuring consistency across all account view screens.

Fixed Paid Installments Reverting to Unpaid After Interest Rate Changes​

We resolved an issue where applying an Interest Rate Change (IRC) could retroactively modify completed installments, incorrectly reverting their status to unpaid.

The Issue: When an Interest Rate Change (IRC) was applied with an effective date falling prior to an already PAID installment, the schedule recalculation engine would mistakenly modify historical data. This led to:

  • Previously fully settled PAID installments reverting to an UNPAID state.
  • The calculation of expected interest instead of preserving the actual interest already paid (specifically on accounts where no prepayment recalculation method was configured).

The Fix: The interest rate modification logic has been corrected. The system now guarantees that retroactive or backdated IRC updates will not touch, recalculate, or modify completed, PAID installments. Your historical payment records and finalized schedules remain locked and accurate.

Fixed Prepayment Interest Calculation Errors on DBEI Loans​

We resolved an issue on Dynamic Term Loan accounts where entering a prepayment could result in an installment incorrectly showing more interest paid than was actually due.

Conditions for the Issue: This calculation discrepancy occurred strictly under a specific combination of product configurations:

  • Amortization Method: Declining Balance Equal Installments (DBEI)
  • Prepayment Recalculation Element: Reduce Amount per Installment (RAI)
  • Grace Period Type: Interest Forgiveness set to exactly zero (0) days

Under these parameters, processing a prepayment caused the interest allocation logic to miscalculate the installment breakdown, creating an irregular state where the interest paid exceeded the interest due.

The calculation engine has been corrected to handle zero-day interest forgiveness grace periods accurately during prepayments, ensuring proper financial balancing for all installments.

Scope Note: Accounts configured with an Interest Forgiveness grace period greater than zero days are entirely unaffected by this fix.

Corrected Transaction Selection and Validation for Loan Adjustments​

We resolved an issue where adjusting a loan transaction could incorrectly pull in unrelated transactions that had an earlier entry date but a later creation date. This flawed selection logic caused adjustment operations to fail or unexpectedly reverse and re-apply unrelated transactions.

Key Improvements:

  • Logical Timeline Alignment: Transaction adjustment now strictly filters and selects affected transactions by their entry date (the logical transaction timeline) instead of their system creation timestamp. This ensures that only the intended transactions are reversed and re-applied.
  • Streamlined Validation: Because the correct, scoped set of transactions is now targeted accurately, the locked-operation validation that previously ran as a safety fallback during the bulk re-apply process has been removed.

Configuration Note: This improvement is delivered behind the tenant feature toggle ADJUSTMENT_SELECTION_BY_ENTRY_DATE and is disabled by default. When the toggle is disabled, the system retains its legacy behavior.

Resolved Unique Custom Field Validation Errors on Backdated Payments​

We resolved an issue where processing a backdated payment failed if the operation required the system to adjust and reapply subsequent downstream transactions that contained unique custom fields.

The Issue: When backdating a payment, the core banking engine automatically reverses and replays subsequent transactions to accurately rebuild the financial timeline. Previously, this reapply process would attempt to copy all custom field values to the new transactions. For custom fields configured with strict uniqueness constraints, this automated duplication triggered a validation error, causing the backdated payment to fail.

The Fix: The transaction reapplication logic has been corrected to safely process downstream records without triggering unique constraint conflicts.

Configuration Note: This fix ensures that custom field values are not duplicated during the transaction reapply sequence when the RETAIN_CUSTOM_FIELD_VALUES_IN_ORIGINAL_REPAYMENT_TRANSACTION_DURING_REAPPLY_PROCESS feature toggle is disabled.

Fixed Transaction Adjustments Following Delayed End-of-Day Runs​

We resolved an issue where interest applied transactions could not be adjusted if they were posted following a missed or delayed End-of-Day (EOD) process.

The Issue: Previously, if the system's scheduled EOD run was delayed, transactions posted during that missed processing window could be stamped with an incorrect entry date. Because of this timeline misalignment, any subsequent attempts to adjust or reverse these interest applied transactions would be blocked by validation errors.

The Fix: The entry date assignment logic has been corrected to handle delayed EOD processing windows accurately. Adjustments to interest applied transactions now succeed seamlessly, ensuring financial timelines remain consistent and editable even if daily automated runs are temporarily disrupted.

Resolved End-of-Day Failures From Missing Payment Holiday Accounting Rules​

We fixed an issue where end-of-day cron jobs failed unexpectedly during interest accrual processing for loan products utilizing the Payment Holiday Interest Accrual feature.

The Issue: If a loan product had Payment Holiday Interest Accrual enabled but lacked the corresponding General Ledger (GL) account mapping configuration, the daily automated processing would crash. The system threw an UndefinedGLAccountForFinancialResourceException because it could not resolve the account for the PAYMENT_HOLIDAY_INTEREST_RECEIVABLE financial resource.

The system's interest accrual processing has been corrected to prevent these unhandled end-of-day crashes.

Configuration Reminder: To ensure smooth financial operations and accurate ledger tracking, verify that all accounting rules for the PAYMENT_HOLIDAY_INTEREST_RECEIVABLE resource are fully mapped in the loan product setup whenever payment holiday interest accrual is enabled.

Resolved Loans Stuck in Arrears After a Large Prepayment on Dynamic Term Loans​

We resolved an issue where a large early prepayment on Dynamic Term Loans using Declining Balance Equal Instalment (DBEI) with the Reduce Amount Per Installment recalculation method could leave the account permanently in arrears, even after the outstanding amount had effectively been repaid.

When the prepayment reduced each remaining installment to a very small amount, a tiny residual principal could no longer be amortized: the principal due for each installment repeatedly computed to zero while interest continued to round up to 0.01. As a result the residual never cleared and the account remained late indefinitely. The system now forces the outstanding residual principal into the final installment so the schedule fully amortizes and the loan can be repaid.

**Configuration Note: **This corrected calculation logic is gated behind the fixUnamortizedResidualPrincipal feature. Interest on installments that still carry a genuine outstanding balance continues to be charged as before.

Pay-Off Amounts No Longer Include Penalties During Arrears Tolerance Period​

We resolved an issue where the loan pay-off preview API incorrectly included late-payment penalties for installments that were still within their arrears tolerance period.

Previous Behavior: The preview pay-off calculation would include a late penalty for an installment within its grace/tolerance window, even though no penalty had actually been applied to the loan. As a result, the quoted payoff amount was higher than the true balance owed, causing submitted payoff payments to be rejected by the system.

New Behavior: Pay-off calculations now evaluate and apply the arrears tolerance period consistently with the repayment schedule. No late penalties are included in the payoff calculation while an installment remains within its tolerance period.

Scope Note: Installments that have passed the arrears tolerance period are unaffected and will continue to include applicable late penalties in the pay-off preview.

Fixed Schedule Due-Date Edits Corrupting Installments on Dynamic Term Loans​

We resolved an issue where editing repayment schedule due dates on Dynamic Term Loans could leave trailing installments empty and improperly reopen previously paid installments.

The Issue: On loan accounts configured with Declining Balance Equal Installments (DBEI) and the Reduce Amount per Installment (RAI) prepayment recalculation method, moving future due dates caused schedule corruption:

  • Trailing installments were left with nothing due.
  • Installments that had already been paid in full were reopened, incorrectly displaying an outstanding balance owed by the borrower.

This occurred because the payment amount was not being recalculated when due dates shifted. Shorter interest periods reduced the interest component per installment, causing principal to amortize faster than planned and exhausting the loan balance before reaching the final installments.

The Fix: The schedule engine now correctly recalculates installment payment amounts whenever due dates are modified:

  • Every installment remains properly funded and the total installment count is preserved, keeping the final installment close to a regular payment.
  • Installments already marked as paid retain their original settled values.
  • Custom, manually set installment amounts are preserved.

Note & Enablement: Previously affected loan accounts will be automatically corrected the next time their repayment schedule is edited. This change is delivered behind a tenant feature flag and can be enabled upon request by contacting Mambu Support.

Document Templates Retained During Loan Product API Updates​

We resolved an issue where updating a loan product via the API inadvertently deleted attached document templates from the database.

The Issue: Previously, sending a PATCH request to update a loan product caused all document templates linked to that product—along with their template content—to be unexpectedly deleted from the system.

The Fix: The loan product update logic via the API has been corrected. Updating loan products now preserves all linked document templates and their content, ensuring no template data is lost during product configuration changes.

Fixed Due Date Edits for Weekly-Schedule Loans​

We resolved an issue where editing an installment due date via the loan schedule API would return a success response but silently fail to save the change on certain accounts.

The Issue: This silent failure occurred specifically on loan accounts configured with a weekly-based repayment schedule that were not linked to a meeting center. While the API responded with a success status, the system did not persist the updated due date, leaving the schedule unchanged.

The Fix: The schedule modification logic has been corrected. Editing installment due dates via the API on weekly-aligned loans without a meeting center now successfully applies and saves the changes.

Scope Note: Loans that are linked to a meeting center were not impacted by this issue and remain completely unaffected.

Fixed Empty Trailing Installments on Dynamic Term Loans​

We resolved an issue where editing the repayment schedule of a Dynamic Term Loan (DTL) could result in the final installments of the schedule becoming empty (£0, graced) instead of properly redistributing the outstanding principal.

The Issue: This issue occurred under a specific combination of loan configurations and events:

  • Amortization & Prepayment Settings: Declining Balance (Equal Installments) with the Reduce Amount per Installment (RAI) prepayment recalculation method.
  • Trigger Sequence: The account underwent both a reschedule event and had a fee applied prior to editing the schedule.

When editing the repayment schedule under these conditions, the system failed to redistribute the freed principal across the remaining term. Instead, it left the trailing installment(s) with a balance of zero, causing a discrepancy between the previewed schedule and the finalized, saved schedule.

The Fix: The schedule recalculation engine has been corrected to ensure that any freed principal is accurately and proportionally redistributed across the remaining installments. The saved schedule now correctly aligns with the recalculated preview.

Configuration Note: This fix is controlled by a feature toggle and can be enabled per tenant upon request. Please contact your Mambu representative to activate this change.

Fixed PATCH /loanproducts/{key} Failures for Products with Adjustable Interest Rates​

We resolved an issue where the PATCH /loanproducts/{key} API endpoint failed when updating loan products configured with the new-style interestRateSettings array (used for adjustable interest rate sources).

The Issue: Previously, sending a PATCH request to update any field on these specific loan products would fail unexpectedly, returning an INVALID_PARAMETERS or INTERNAL_ERROR. This occurred regardless of whether the interest rate fields themselves were being modified, effectively blocking product updates.

The Fix: The partial update logic has been corrected to properly handle the interestRateSettings array. Lenders can now seamlessly update these loan products via the API.

Technical Note: This update introduces no changes to the existing API contract. Loan products using the legacy indexRateSettings object were not impacted and remain unaffected.

Fixed Loan Risk Level Filter in Loans Search API​

We resolved an issue where filtering loan accounts by risk level in the POST loans search API was ignored by the system.

Previous Behavior: When searching for loan accounts via the API using the loanRiskLevelKey filter, the criteria was bypassed and all loan accounts were returned regardless of their assigned risk level.

New Behavior: The POST loans search API now correctly processes the loanRiskLevelKey filter and returns only loan accounts matching the specified risk level, aligning API behavior with the UI search functionality.

Deposits​

Fee Details (name, type, amount) Added to GL Journal entries for Deposit Fee Transactions​

The GET /v2/gljournalentries API response now includes a feeDetails object for GL journal entries originating from deposit fee transactions (FEE_APPLIED, FEE_ADJUSTED, FEES_DUE_REDUCED, FEE_REDUCTION_ADJUSTMENT). The feeDetails object contains the transaction type, fee amount, fee name, and fee type (trigger), enabling API consumers to trace fee-related journal entries back to their originating fee definition without a separate lookup.

Additionally, four new columns are now available in the Accounting → Journal Entries UI table column picker and CSV export: Fee Name, Fee Type, Fee Amount, and Fee Transaction Type. These columns are populated automatically for deposit fee transactions and are blank for non-fee or non-deposit entries.

Developer​

Subscription Timestamps Now Returned in Tenant's Configured Timezone Offset​

We resolved an issue in the Streaming API where subscription creation responses returned created_at and updated_at timestamps in UTC offset, bypassing the tenant's organization timezone settings.

Previous Behavior: When creating a subscription via the Streaming API, the created_at and updated_at fields in SubscriptionResponse were strictly formatted in UTC (+00:00). This caused validation discrepancies for tenants using custom organization timezones.

New Behavior: The created_at and updated_at timestamps in Streaming API subscription responses are now formatted using the tenant's configured organization timezone offset. This change aligns the Streaming API with standard API v2 response behavior and resolves timezone offset validation errors.

Technical Note: This update only changes the string representation of the timestamp (the offset displayed). The underlying point in time (UTC instant) remains exact and unchanged.

v9.194.7​

Release Date: 01.09.2026

Features​

Lending​

Fixed Interest Expected Calculation on Redraw Loans Following Interest Rate Changes​

We resolved an issue where performing an interest rate change on a redraw-enabled loan caused previously applied interest to be omitted when recalculating installment interest expectations.

Previous Behavior: On redraw-enabled Declining Balance Equal Installments loans, applying an interest rate change dropped interest previously applied via a Custom Repayment Allocation on Principal from the calculation base. This resulted in an understated Interest Expected value for the remainder of the current installment period.

New Behavior: Interest rate changes on redraw-enabled loans now accurately retain interest previously applied through a Custom Repayment Allocation on Principal when recalculating Interest Expected for the current installment.

v9.194.6​

Release Date: 31.08.2026

Bug fixes​

Lending​

Branch Reassignment Fix for Partially-Paid Taxable Fees Now Behind a Feature Toggle​

We identified that the fix released in v9.194.2 for branch reassignment failures on loans with partially-paid taxable fees could cause loan write-off transactions to fail with an internal error on accounts with taxes on fees enabled.

The Issue: After the v9.194.2 fix, writing off a dynamic loan account could fail with an internal error when one of its fee transactions had no tax rate recorded, affecting loans configured with taxes on fees enabled.

The Change: To prevent this issue, the v9.194.2 branch reassignment fix is now controlled by a feature toggle, which is disabled by default. With the toggle disabled, dynamic loan accounts with partially-paid taxable fees will again fail to reassign to a different branch, as they did before v9.194.2.

Configuration Note: If you need branch reassignment to succeed for dynamic loan accounts with partially-paid taxable fees, contact Mambu Support to have the toggle enabled for your tenant.

v9.194.5​

Release Date: 28.08.2026

This release contains the following:

  • Internal maintenance improvements to platform stability and user interface enhancements across core banking functionality.

v9.194.4​

Release Date: 26.08.2026

This release contains the following:

  • Internal maintenance improvements to platform stability and user feedback tracking mechanisms.

v9.194.3​

Release Date: 26.08.2026

This release contains the following:

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

v9.194.2​

Release Date: 26.08.2026

Features​

Cards​

Automated Hold on Pin Debit Refunds to Prevent Double-Dipping Fraud​

To help prevent "double-dipping" fraud on prepaid card refunds, single-message Pin Debit Refund events can now be automatically placed on a temporary hold instead of being credited to the available balance immediately.

How it Works: When a Pin Debit Refund event is received for a Current Account linked to a card token, Mambu checks whether refund hold settings are enabled for the account's savings product. If enabled, the refunded amount is placed on hold for the configured duration and released automatically after the configured hold duration has elapsed, with no manual intervention required. If no refund hold settings are enabled for the product, the refund falls through to the regular financial transaction flow and is credited immediately, as before.

Note: This behavior applies only to single-message Pin Debit Refund events processed through the Mambu Marqeta Connector. Dual-message refund flows and loan accounts are unaffected.

For more information, see Pin debit refund holds

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.194.1​

Release Date: 26.08.2026

Improvements​

Data​

Fixed Database Backup Failures in /api/database/backup​

We resolved an issue where database backups created through the /api/database/backup endpoint failed when Notifications database views were present.

The Issue: Database backups initiated via the API could fail to complete whenever Notifications-owned message queue views (MessageQueueItem views) were included in the export schema.

The Fix: Notifications-owned message queue views are now automatically excluded from the generated database dump, allowing the /api/database/backup endpoint to complete backup operations successfully.

For more information, see Mambu Release Cycle.

Last updated on