# Mambu Documentation — Full Content > Generated: 2026-06-26 | Source: https://docs.mambu.com | Pages: 471 docs + 78 API specs > > This file contains the complete text of all Mambu user-guide, release-note, > API-overview pages, and API v2 reference (endpoint summaries) for use by LLMs > and AI agents. ## Table of Contents > Two access patterns — pick by section: > • User Guide / Release Notes / API Overview Pages: fetch https://docs.mambu.com/md/{path}.md (or .txt fallback) > e.g. https://docs.mambu.com/md/docs/access-preferences.txt or https://docs.mambu.com/md/api/pages/api-v2/authentication.txt > • API v2 Reference: NOT in /md/. Fetch the raw OpenAPI spec instead — e.g. > https://docs.mambu.com/swagger_files/v2/clients.json for the clients spec, or > https://docs.mambu.com/swagger_files/v2/index.json for the manifest of all 78 v2 specs. ### User Guide & Release Notes (396 pages) - Access Preferences — https://docs.mambu.com/docs/access-preferences/ - Accounting Closures — https://docs.mambu.com/docs/accounting-closures/ - Accounting Reports — https://docs.mambu.com/docs/accounting-reports/ - Accounting Setup — https://docs.mambu.com/docs/accounting-setup/ - Adding accounts to a credit arrangement — https://docs.mambu.com/docs/adding-accounts-to-a-credit-arrangement/ - Adjustable Interest Rates — https://docs.mambu.com/docs/adjustable-interest-rates/ - Adjusting Overdraft Terms — https://docs.mambu.com/docs/adjusting-overdraft-terms/ - Adjusting Transactions — https://docs.mambu.com/docs/adjusting-transactions/ - AML Suspense Accounting Flows — https://docs.mambu.com/docs/aml-suspense-accounting-flows/ - Introduction & Setup — https://docs.mambu.com/docs/aml-suspense-accounting/ - API Consumers — https://docs.mambu.com/docs/api-consumers/ - API response and error codes — https://docs.mambu.com/docs/api-response-error-codes/ - Applying and Reversing Fees and Penalties — https://docs.mambu.com/docs/applying-and-reversing-fees-and-penalties/ - Approving a Loan — https://docs.mambu.com/docs/approving-a-loan/ - Arrears Settings — https://docs.mambu.com/docs/arrears-settings/ - Audit Trail V2 — https://docs.mambu.com/docs/audit-trail-v2/ - Audit Trail — https://docs.mambu.com/docs/audit-trail/ - Making Requests with Mambu Apps — https://docs.mambu.com/docs/authenticating-requests/ - Authorization Holds — https://docs.mambu.com/docs/authorization-holds/ - Automated EOD Account Exclusion Processing — https://docs.mambu.com/docs/automated-eod-account-exclusion-processing/ - End of Day Processing and Cron Jobs — https://docs.mambu.com/docs/automatic-end-of-day-actions/ - Backwards Compatibility — https://docs.mambu.com/docs/backwards-compatibility/ - Basic Jasper report for Journal Entries — https://docs.mambu.com/docs/basic-jasper-report-for-journal-entries/ - Blocking Funds in Deposit Accounts — https://docs.mambu.com/docs/blocking-funds-in-deposit-accounts/ - Blocking SEPA Direct Debits — https://docs.mambu.com/docs/blocking-sepa-direct-debits/ - Booking Date vs Value Date — https://docs.mambu.com/docs/booking-date-vs-value-date/ - Branches and Centres — https://docs.mambu.com/docs/branches-and-centres/ - Branding — https://docs.mambu.com/docs/branding/ - Call an external service when the database changes to Read-Only mode — https://docs.mambu.com/docs/call-an-external-service-when-the-database-changes-to-read-only-mode/ - Card Transactions and Authorization Holds — https://docs.mambu.com/docs/card-payments-and-authorization-holds/ - Transaction Processing — https://docs.mambu.com/docs/card-transaction-processing/ - Cards Introduction — https://docs.mambu.com/docs/cards-introduction/ - Carry forward balances at reschedule or refinance — https://docs.mambu.com/docs/carry-forward-balances-at-reschedule-or-refinance/ - Cash vs Accruals Accounting — https://docs.mambu.com/docs/cash-vs-accruals-accounting/ - Using Centrify as your IdP — https://docs.mambu.com/docs/centrify-as-idp/ - Changing the interest rate — https://docs.mambu.com/docs/change-interest-rate/ - Profile and Password Management — https://docs.mambu.com/docs/change-your-password-and-edit-your-profile/ - Changing Interest Rates on Active Deposit Accounts — https://docs.mambu.com/docs/changing-the-interest-rate/ - Choose Prepayment Recalculation Method at Repayment Time — https://docs.mambu.com/docs/choose-prepayment-recalculation-method-at-repayment-time/ - Client Custom Fields — https://docs.mambu.com/docs/client-custom-fields/ - Client Life Cycle — https://docs.mambu.com/docs/client-life-cycle/ - Client Types — https://docs.mambu.com/docs/client-types/ - Clients and Groups Overview — https://docs.mambu.com/docs/clients-and-groups-overview/ - Clients by State — https://docs.mambu.com/docs/clients-by-state/ - Closing a Loan With All Obligations Met — https://docs.mambu.com/docs/closing-a-loan-with-all-obligations-met/ - Closing Accounts — https://docs.mambu.com/docs/closing-accounts/ - Compound Interest with Daily Rest — https://docs.mambu.com/docs/compound-interest-with-daily-rest/ - Configuration as Code Overview — https://docs.mambu.com/docs/configuration-as-code-1/ - Accounting Rules Configuration — https://docs.mambu.com/docs/configuration-as-code-for-accounting-rules/ - Authorization Holds Configuration — https://docs.mambu.com/docs/configuration-as-code-for-authorization-holds/ - Branches Configuration — https://docs.mambu.com/docs/configuration-as-code-for-branches/ - Centres Configuration — https://docs.mambu.com/docs/configuration-as-code-for-centres/ - Client and Group Roles Configuration — https://docs.mambu.com/docs/configuration-as-code-for-client-and-group-roles/ - Currencies Configuration — https://docs.mambu.com/docs/configuration-as-code-for-currencies/ - Custom Fields Configuration — https://docs.mambu.com/docs/configuration-as-code-for-custom-fields/ - Group Role Names Configuration — https://docs.mambu.com/docs/configuration-as-code-for-group-role-names/ - Holidays Configuration — https://docs.mambu.com/docs/configuration-as-code-for-holidays/ - ID Templates Configuration — https://docs.mambu.com/docs/configuration-as-code-for-id-templates/ - Internal Controls Configuration — https://docs.mambu.com/docs/configuration-as-code-for-internal-controls/ - Labels Configuration — https://docs.mambu.com/docs/configuration-as-code-for-labels/ - Organization Details Configuration — https://docs.mambu.com/docs/configuration-as-code-for-organization-general-details/ - User Roles Configuration — https://docs.mambu.com/docs/configuration-as-code-for-roles/ - Transaction Channels Configuration — https://docs.mambu.com/docs/configuration-as-code-for-transaction-channels/ - Configuring System Options — https://docs.mambu.com/docs/configurations/ - Configuring an Equal Installment Interest-Only Loan — https://docs.mambu.com/docs/configuring-an-equal-installment-interest-only-loan/ - Configuring Classes — https://docs.mambu.com/docs/configuring-classes/ - Configuring Expenses — https://docs.mambu.com/docs/configuring-expenses/ - Configuring Income — https://docs.mambu.com/docs/configuring-income/ - Content Editors — https://docs.mambu.com/docs/content-editors/ - Creating an Individual Client — https://docs.mambu.com/docs/create-an-individual-client/ - Creating a Deposit Account — https://docs.mambu.com/docs/creating-a-deposit-account/ - Creating a Group — https://docs.mambu.com/docs/creating-a-group/ - Creating a new credit arrangement — https://docs.mambu.com/docs/creating-a-new-credit-arrangement/ - Creating a New Loan — https://docs.mambu.com/docs/creating-a-new-loan/ - Creating Deposit Accounts With Profit Sharing — https://docs.mambu.com/docs/creating-deposit-accounts-with-profit-sharing/ - Creating a User — https://docs.mambu.com/docs/creating-new-users/ - Creating Profit Sharing Accounts — https://docs.mambu.com/docs/creating-profit-sharing-accounts/ - Creating your Chart of Accounts — https://docs.mambu.com/docs/creating-your-chart-of-accounts/ - Credit arrangement states — https://docs.mambu.com/docs/credit-arrangement-states/ - Currencies — https://docs.mambu.com/docs/currencies/ - Custom fields and custom views for credit arrangements — https://docs.mambu.com/docs/custom-fields-and-custom-views-for-credit-arrangements/ - Custom Fields Quota Announcement — https://docs.mambu.com/docs/custom-fields-quota-announcement/ - Custom Fields — https://docs.mambu.com/docs/custom-fields/ - Custom reports starting kit — https://docs.mambu.com/docs/custom-reports-starting-kit/ - Custom Views and API v1 — https://docs.mambu.com/docs/custom-views-and-api-v1/ - Custom Views — https://docs.mambu.com/docs/custom-views/ - Customer Service Portal — https://docs.mambu.com/docs/customer-service-portal/ - Customizing Columns — https://docs.mambu.com/docs/customizing-columns/ - Customizing Index Interest Rates and Tax Rates — https://docs.mambu.com/docs/customizing-index-rates/ - Dashboard — https://docs.mambu.com/docs/dashboard/ - Data Adapter — https://docs.mambu.com/docs/data-adapter/ - Data Dictionary and API Standards — https://docs.mambu.com/docs/data-dictionary-and-api-standards/ - Data Lake Integration Guide — https://docs.mambu.com/docs/data-lake-integration-guide/ - Data Management Overview — https://docs.mambu.com/docs/data-migration-overview/ - Database Backups — https://docs.mambu.com/docs/database-backups/ - Database clone — https://docs.mambu.com/docs/database-clone/ - Deactivating, Reactivating and Deleting User Accounts — https://docs.mambu.com/docs/deactivating-reactivating-and-deleting-user-accounts/ - Defining Risk Levels — https://docs.mambu.com/docs/defining-risk-levels/ - Deleting a Loan — https://docs.mambu.com/docs/deleting-a-loan/ - Deleting Accounts — https://docs.mambu.com/docs/deleting-accounts/ - Deposit Account Overview Details — https://docs.mambu.com/docs/deposit-account-overview-details/ - Deposit Account Life Cycle and States — https://docs.mambu.com/docs/deposit-accounts-life-cycle-and-states/ - Deposit Fees Setup — https://docs.mambu.com/docs/deposit-fees-setup/ - Deposit Products Configuration — https://docs.mambu.com/docs/deposit-products-configuration/ - Deposits, Withdrawals and Transfers — https://docs.mambu.com/docs/deposits-withdrawals-and-transfers/ - Developer Handbook — https://docs.mambu.com/docs/developer-handbook/ - Overview — https://docs.mambu.com/docs/developer-overview/ - Disbursing a Loan — https://docs.mambu.com/docs/disbursing-a-loan/ - Documentation Changelog — https://docs.mambu.com/docs/documentation-changelog/ - Dynamic Mortgages — https://docs.mambu.com/docs/dynamic-mortgages/ - Repayment Schedule Options for Dynamic Mortgage and Interest-Only Equal Installment Loans — https://docs.mambu.com/docs/edit-schedule-mortgage-options/ - Editing a Loan Account — https://docs.mambu.com/docs/editing-a-loan/ - Editing Accounts — https://docs.mambu.com/docs/editing-accounts/ - Editing and Customizing Repayment Schedules — https://docs.mambu.com/docs/editing-customizing-repayment-schedules/ - Enabling Federated Authentication with Mambu — https://docs.mambu.com/docs/enable-federated-authentication-with-mambu/ - Enabling Single Logout — https://docs.mambu.com/docs/enable-single-logout/ - Enabling Ping Identity SSO — https://docs.mambu.com/docs/enabling-ping-identity-sso/ - End of Day Processing Configuration — https://docs.mambu.com/docs/end-of-day-processing-configuration/ - Using Microsoft Entra ID as your Identity Provider (IdP) — https://docs.mambu.com/docs/entra-id-as-idp/ - Equal Installment Interest-Only Loans — https://docs.mambu.com/docs/equal-installment-interest-only-loans/ - Excel Migration Template — https://docs.mambu.com/docs/excel-migration-template/ - Fair use policy — https://docs.mambu.com/docs/fair-use-policy/ - Fee Capitalization — https://docs.mambu.com/docs/fee-capitalization/ - Fees Accounting — https://docs.mambu.com/docs/fees-accounting/ - Funding Sources - P2P Lending — https://docs.mambu.com/docs/funding-sources-p2p-lending/ - Glossary — https://docs.mambu.com/docs/glossary/ - Using Google as your Identity Provider (IdP) — https://docs.mambu.com/docs/google-as-idp/ - Group Role Names — https://docs.mambu.com/docs/group-role-names/ - Group Types — https://docs.mambu.com/docs/group-types/ - Holidays and Non-Working Days — https://docs.mambu.com/docs/holidays-and-non-working-days/ - ID Templates — https://docs.mambu.com/docs/id-templates/ - Ideas and Feature Planning — https://docs.mambu.com/docs/ideas-and-feature-planning/ - Import Database clone — https://docs.mambu.com/docs/import-database-clone/ - Importing Your Data via API — https://docs.mambu.com/docs/importing-your-data-via-api/ - Importing Your Data via Excel — https://docs.mambu.com/docs/importing-your-data-via-excel/ - Incoming and Outgoing Payment Messages — https://docs.mambu.com/docs/incoming-and-outgoing-payment-messages/ - Index Rates Configuration — https://docs.mambu.com/docs/index-rates-configuration/ - Welcome to Mambu — https://docs.mambu.com/docs/ - Indicators — https://docs.mambu.com/docs/indicators/ - Initial Payment Adjustment — https://docs.mambu.com/docs/initial-payment-adjustment/ - Initial setup — https://docs.mambu.com/docs/initial-setup/ - Connecting Third Party Tools — https://docs.mambu.com/docs/insights-connecting-third-party-tools/ - Insights Data Catalog — https://docs.mambu.com/docs/insights-data-catalog/ - Getting Started with Mambu Insights — https://docs.mambu.com/docs/insights-getting-started/ - Mambu Data Lake — https://docs.mambu.com/docs/insights-mambu-data-lake/ - Operations and Monitoring — https://docs.mambu.com/docs/insights-operations-and-monitoring/ - Pricing and Consumption — https://docs.mambu.com/docs/insights-pricing-and-consumption/ - Security — https://docs.mambu.com/docs/insights-security/ - Defining and Installing Mambu Apps — https://docs.mambu.com/docs/installing-apps/ - Installments on Non-Working Days — https://docs.mambu.com/docs/instalments-on-non-working-days/ - Inter-Branch Transfer GL Account — https://docs.mambu.com/docs/inter-branch-transfer-gl-account/ - Interest Application — https://docs.mambu.com/docs/interest-application/ - Interest Calculation Methods in Deposit Accounts — https://docs.mambu.com/docs/interest-calculation-methods-in-deposit-accounts/ - Interest Calculation Methods in Loans — https://docs.mambu.com/docs/interest-calculation-methods-in-loans/ - Interest From Arrears — https://docs.mambu.com/docs/interest-from-arrears/ - Interest on Arrears and Decoupling of Interest on Arrears — https://docs.mambu.com/docs/interest-on-arrears-and-interest-on-arrears-decoupling/ - Interest Rate Management Enhancements — https://docs.mambu.com/docs/interest-rate-management-enhancements/ - Interest Types — https://docs.mambu.com/docs/interest-types/ - Internal Controls for Loans — https://docs.mambu.com/docs/internal-controls-for-loans/ - Internal Controls — https://docs.mambu.com/docs/internal-controls/ - Mambu Apps Basics — https://docs.mambu.com/docs/introduction-to-mambu-apps/ - Islamic Funding Contracts — https://docs.mambu.com/docs/islamic-funding-contracts/ - Convert to Islamic Products & Accounts — https://docs.mambu.com/docs/islamic-profit-sharing-configurations/ - Introduction — https://docs.mambu.com/docs/iso-20022-introduction/ - Jasper Reporting Overview — https://docs.mambu.com/docs/jasper-reporting-overview/ - Journal Entries — https://docs.mambu.com/docs/journal-entries/ - Known Issues — https://docs.mambu.com/docs/known-issues/ - Labels — https://docs.mambu.com/docs/labels/ - Language Settings — https://docs.mambu.com/docs/language-settings/ - Linking Products to Accounting — https://docs.mambu.com/docs/linking-products-to-accounting/ - Linking Deposit and Loan Accounts — https://docs.mambu.com/docs/linking-savings-and-loan-accounts/ - Loan Account Attachments — https://docs.mambu.com/docs/loan-account-attachments/ - Loan account goes in arrears — https://docs.mambu.com/docs/loan-account-goes-in-arrears/ - Loan Account Life Cycle and States — https://docs.mambu.com/docs/loan-account-life-cycle-and-states/ - Loan Account Overview Details — https://docs.mambu.com/docs/loan-account-overview-details/ - Loan Auto Approve workflow — https://docs.mambu.com/docs/loan-auto-approve-workflow/ - Loan Fees Setup — https://docs.mambu.com/docs/loan-fees-setup/ - Loan Fractionalisation - P2P Lending — https://docs.mambu.com/docs/loan-fractionalisation-p2p-lending/ - Loan Penalties Setup — https://docs.mambu.com/docs/loan-penalties-setup/ - loan-products-configuration — https://docs.mambu.com/docs/loan-products-configuration/ - Loan Risk Levels Configuration — https://docs.mambu.com/docs/loan-risk-levels-configuration/ - Loan Securities - Guarantors and Collateral Assets — https://docs.mambu.com/docs/loan-securities-guarantors-and-collateral-assets/ - Loans in Arrears — https://docs.mambu.com/docs/loans-in-arrears/ - Loans overview — https://docs.mambu.com/docs/loans-overview/ - Loans with Funding Sources - P2P Lending — https://docs.mambu.com/docs/loans-with-funding-sources-p2p-lending/ - Locking and Unlocking Deposit Accounts — https://docs.mambu.com/docs/locking-and-unlocking-deposit-accounts/ - Locking and Unlocking Loans — https://docs.mambu.com/docs/locking-loans/ - Mambu APIs — https://docs.mambu.com/docs/mambu-apis/ - Mambu Data Dictionary — https://docs.mambu.com/docs/mambu-data-dictionary/ - Mambu Extract — https://docs.mambu.com/docs/mambu-extract/ - Mambu Payment Gateway — https://docs.mambu.com/docs/mambu-payment-gateway/ - Mambu Payments — https://docs.mambu.com/docs/mambu-payments/ - Mambu Release Cycle — https://docs.mambu.com/docs/mambu-release-cycle/ - Mambu Search — https://docs.mambu.com/docs/mambu-search/ - Mambu Status — https://docs.mambu.com/docs/mambu-status/ - Getting Support — https://docs.mambu.com/docs/mambu-support/ - Mambu UI Management Overview — https://docs.mambu.com/docs/mambu-ui-management-overview/ - Management Reports — https://docs.mambu.com/docs/management-reports/ - Managing Clients — https://docs.mambu.com/docs/managing-clients/ - Managing Corrections and Adjustments in Tills — https://docs.mambu.com/docs/managing-corrections-and-adjustments-in-tills/ - Managing credit arrangements — https://docs.mambu.com/docs/managing-credit-arrangements/ - Managing Deposit Products — https://docs.mambu.com/docs/managing-deposit-products/ - Managing Fees in Deposit Accounts — https://docs.mambu.com/docs/managing-fees-in-deposit-accounts/ - Managing Groups — https://docs.mambu.com/docs/managing-groups/ - Managing Islamic Deposit Accounts — https://docs.mambu.com/docs/managing-islamic-deposit-accounts/ - Managing Loan Products — https://docs.mambu.com/docs/managing-loan-products/ - Managing Profit Sharing Deposit Product — https://docs.mambu.com/docs/managing-profit-sharing-deposit-products/ - Managing Users under Federated Authentication — https://docs.mambu.com/docs/managing-sso-provisioned-users/ - Working with Tills — https://docs.mambu.com/docs/managing-tills-tellering-widget/ - Managing your Organization Overview — https://docs.mambu.com/docs/managing-your-organization-overview/ - Manual and Automated EOD Process — https://docs.mambu.com/docs/manual-and-automated-eod-process/ - Manual Email Notifications — https://docs.mambu.com/docs/manual-email-notifications/ - Manual SMS Notifications — https://docs.mambu.com/docs/manual-sms-notifications/ - Marqeta Integration — https://docs.mambu.com/docs/marqeta-integration/ - Maximum Deposit Account Balance — https://docs.mambu.com/docs/maximum-deposit-account-balance/ - Menu Items and Custom Views Showcase — https://docs.mambu.com/docs/menu-items-and-custom-views-showcase/ - Menu Items — https://docs.mambu.com/docs/menu-items/ - MySQL 8.0 Update — https://docs.mambu.com/docs/mysql-8-update/ - Native Fields — https://docs.mambu.com/docs/native-fields/ - Navigating in the Mambu UI — https://docs.mambu.com/docs/navigating-in-mambu/ - Non-Scheduled Fee Allocation — https://docs.mambu.com/docs/non-scheduled-fee-allocation/ - Automated email notifications — https://docs.mambu.com/docs/notifications-channels-email-automated-email-notifications/ - Email setup — https://docs.mambu.com/docs/notifications-channels-email-email-setup/ - Automated SMS notifications — https://docs.mambu.com/docs/notifications-channels-sms-automated-sms-notifications/ - SMS setup — https://docs.mambu.com/docs/notifications-channels-sms-sms-setup/ - Streaming API — https://docs.mambu.com/docs/notifications-channels-streaming-streaming-api/ - Webhook best practices — https://docs.mambu.com/docs/notifications-channels-webhooks-best-practices/ - Circuit breaker — https://docs.mambu.com/docs/notifications-channels-webhooks-circuit-breaker/ - Create webhook templates — https://docs.mambu.com/docs/notifications-channels-webhooks-defining-a-new-webhook/ - Webhooks Overview — https://docs.mambu.com/docs/notifications-channels-webhooks-overview/ - Troubleshoot webhooks — https://docs.mambu.com/docs/notifications-channels-webhooks-troubleshooting/ - Webhook notifications — https://docs.mambu.com/docs/notifications-channels-webhooks-webhook-notifications/ - Event triggers — https://docs.mambu.com/docs/notifications-event-triggers/ - Managing notifications — https://docs.mambu.com/docs/notifications-managing-notifications/ - Notifications overview — https://docs.mambu.com/docs/notifications-overview/ - Notification placeholders — https://docs.mambu.com/docs/notifications-placeholders/ - Troubleshoot delayed notification dispatch — https://docs.mambu.com/docs/notifications-troubleshooting-delayed-notifications/ - Troubleshoot Email and SMS Failures — https://docs.mambu.com/docs/notifications-troubleshooting-email-and-sms-setup/ - Troubleshoot Failed Notification Sending — https://docs.mambu.com/docs/notifications-troubleshooting-failed-notifications/ - Troubleshoot Failed Notification Triggers — https://docs.mambu.com/docs/notifications-troubleshooting-notifications-not-generated/ - Using Okta as your Identity Provider (IdP) — https://docs.mambu.com/docs/okta-as-idp/ - Set up federated authentication with OneLogin — https://docs.mambu.com/docs/onelogin-as-idp/ - Organization Contact Details and Time Zone — https://docs.mambu.com/docs/organization-contact-currency-and-timezone/ - Overdraft Products — https://docs.mambu.com/docs/overdraft-products/ - Interest Rate Change Threshold Overpayment — https://docs.mambu.com/docs/overpayment-and-interest-rate-change-threshold/ - Pacs.008 — https://docs.mambu.com/docs/pacs008/ - Paginated Report — https://docs.mambu.com/docs/paginated-report/ - Paying Off a Loan — https://docs.mambu.com/docs/paying-off-a-loan/ - Payments Introduction — https://docs.mambu.com/docs/payment-gateway-introduction/ - System Properties — https://docs.mambu.com/docs/payment-gateway-system-properties/ - Payment Holidays — https://docs.mambu.com/docs/payment-holidays/ - Payment Methods for Declining Balance Equal Installments (DBEI) Loans — https://docs.mambu.com/docs/payment-methods-for-dbei-loans/ - Payment Modification Thresholds (PMT Thresholds) — https://docs.mambu.com/docs/payment-modification-thresholds/ - Payment Order Flow — https://docs.mambu.com/docs/payment-order/ - Payment Plan for Fixed Term Loans — https://docs.mambu.com/docs/payment-plan-for-fixed-term-loans/ - Paymentology Integration — https://docs.mambu.com/docs/paymentology-integration/ - Getting Started — https://docs.mambu.com/docs/payments-settings/ - Permissions — https://docs.mambu.com/docs/permissions/ - Placeholders — https://docs.mambu.com/docs/placeholders/ - Pool Accounting — https://docs.mambu.com/docs/pool-accounting/ - Posting Transactions with Custom Fields — https://docs.mambu.com/docs/posting-transactions-with-custom-fields/ - Prepayment Recalculation Methods — https://docs.mambu.com/docs/prepayment-recalculation-methods/ - Principal Overpayment — https://docs.mambu.com/docs/principal-overpayment/ - Processing Loan Repayments — https://docs.mambu.com/docs/processing-loan-repayments/ - Processing Transactions via a Till — https://docs.mambu.com/docs/processing-transactions-via-a-till-tellering-widget/ - Product Documents — https://docs.mambu.com/docs/product-documents/ - Profit Application — https://docs.mambu.com/docs/profit-application/ - Profit Approval — https://docs.mambu.com/docs/profit-approval/ - Profit Calculation and Distribution — https://docs.mambu.com/docs/profit-calculation-and-distribution/ - Profit Calculation — https://docs.mambu.com/docs/profit-calculation/ - Profit Sharing Accounting Principles — https://docs.mambu.com/docs/profit-sharing-accounting-principles/ - Configurations — https://docs.mambu.com/docs/profit-sharing-configurations/ - Profit sharing introduction — https://docs.mambu.com/docs/profit-sharing-introduction/ - Re-opening a Deposit Account — https://docs.mambu.com/docs/re-opening-a-deposit-account/ - Redraw and Offset Settings — https://docs.mambu.com/docs/redraw-facility-and-offset-loans/ - Redraw balance and transactions — https://docs.mambu.com/docs/redraw-for-dynamic-term-loans/ - Reduced Payment Deviations for Equal Installment Loans — https://docs.mambu.com/docs/reduced-payment-deviations-for-equal-installment-loans/ - Rejecting a Deposit Account Application — https://docs.mambu.com/docs/rejecting-a-deposit-account-application/ - Rejecting a Loan — https://docs.mambu.com/docs/rejecting-a-loan/ - Removing accounts from a credit arrangement — https://docs.mambu.com/docs/removing-accounts-from-a-credit-arrangement/ - Repayment Allocation Order — https://docs.mambu.com/docs/repayment-allocation-order/ - Repayment collection — https://docs.mambu.com/docs/repayment-collection/ - Repayment due in 10 days — https://docs.mambu.com/docs/repayment-due-in-10-days/ - Repayments Schedule Editing — https://docs.mambu.com/docs/repayments-schedule-editing/ - Reports Overview — https://docs.mambu.com/docs/reports-overview/ - Rescheduling and Refinancing Loans — https://docs.mambu.com/docs/rescheduling-and-refinancing-loans/ - Revamp of Mambu APIs — https://docs.mambu.com/docs/revamp-of-mambu-apis/ - Reviewing a Client's Loan History — https://docs.mambu.com/docs/reviewing-a-clients-loan-history/ - Revolving Loans — https://docs.mambu.com/docs/revolving-credit-loans/ - Risk Report — https://docs.mambu.com/docs/risk-report/ - Roles — https://docs.mambu.com/docs/roles/ - Rounding Repayment Schedule — https://docs.mambu.com/docs/rounding-repayment-schedule/ - Running Proposals — https://docs.mambu.com/docs/running-proposals/ - Sandbox — https://docs.mambu.com/docs/sandbox/ - Schedulers and holidays — https://docs.mambu.com/docs/schedulers-and-holidays/ - SEPA Credit Transfer Inquiries — https://docs.mambu.com/docs/sct-inquiries/ - Secondary Marketplace for Peer-to-Peer Loans — https://docs.mambu.com/docs/secondary-marketplace-for-p2p-loans/ - Securities Settings — https://docs.mambu.com/docs/securities-settings/ - Sending Secure Information — https://docs.mambu.com/docs/sending-secure-information/ - SEPA Credit Transfer XML Messages — https://docs.mambu.com/docs/sepa-credit-transfer-technical-information/ - Introduction — https://docs.mambu.com/docs/sepa-credit-transfers/ - SEPA Direct Debit (Creditor flow) — https://docs.mambu.com/docs/sepa-direct-debit-creditor-flow/ - SEPA Direct Debit (Debtor flows) — https://docs.mambu.com/docs/sepa-direct-debit-debtor-flows/ - Refunding a SEPA Direct Debit — https://docs.mambu.com/docs/sepa-direct-debit-refunds/ - Introduction — https://docs.mambu.com/docs/sepa-direct-debit/ - Introduction — https://docs.mambu.com/docs/sepa-instant-credit-transfer-introduction/ - SEPA Instant Creditor Flows — https://docs.mambu.com/docs/sepa-instant-creditor-flows/ - SEPA Credit Transfers — https://docs.mambu.com/docs/sepa/ - Setting-up a Maturity Period — https://docs.mambu.com/docs/setting-up-a-maturity-period/ - Setting up Shari'ah-based Deposit Products — https://docs.mambu.com/docs/setting-up-deposit-products-with-profit-sharing/ - Setting Up New Deposit Products — https://docs.mambu.com/docs/setting-up-new-deposit-products/ - Setting Up New Loan Products — https://docs.mambu.com/docs/setting-up-new-loan-products/ - Setting up SEPA Direct Debit — https://docs.mambu.com/docs/setting-up-sepa-direct-debit/ - Setting up SEPA Instant Credit Transfer — https://docs.mambu.com/docs/setting-up-sepa-instant-credit-transfer/ - Shari'ah Based Deposits vs Interest Based Deposits — https://docs.mambu.com/docs/shariah-based-deposits-vs-interest-based-deposits/ - Shari'ah Deposit Principles and Process — https://docs.mambu.com/docs/shariah-deposit-principles-and-process/ - Software Requirements — https://docs.mambu.com/docs/software-requirements/ - AML Standard Flows — https://docs.mambu.com/docs/standard-aml-flows/ - Tasks — https://docs.mambu.com/docs/tasks/ - Technical Overdraft — https://docs.mambu.com/docs/technical-overdraft/ - Teller Users — https://docs.mambu.com/docs/teller-users/ - Terminating a Loan — https://docs.mambu.com/docs/terminating-a-loan/ - Mambu Tips and Tricks — https://docs.mambu.com/docs/tips-tricks/ - Token Management — https://docs.mambu.com/docs/token-management/ - Tracking Activities — https://docs.mambu.com/docs/tracking-activities/ - Transaction Channels — https://docs.mambu.com/docs/transaction-channels/ - Transaction Holds — https://docs.mambu.com/docs/transaction-holds/ - Transactions per Account — https://docs.mambu.com/docs/transactions-per-account/ - Transfer Account Ownership — https://docs.mambu.com/docs/transfer-account-ownership/ - Truncating and rounding interest — https://docs.mambu.com/docs/truncating-and-rounding-interest-deposits/ - Truncating and rounding interest — https://docs.mambu.com/docs/truncating-and-rounding-interest-loans/ - Loans for Groups — https://docs.mambu.com/docs/types-of-loan-groups/ - Types of Loan Products — https://docs.mambu.com/docs/types-of-loan-products/ - Understanding Users, Roles, and Permissions — https://docs.mambu.com/docs/understanding-users-roles-and-permissions/ - User Link Custom Field Showcase — https://docs.mambu.com/docs/user-link-custom-field-showcase/ - User Management and Audit Trail — https://docs.mambu.com/docs/user-management-and-audit-trail/ - Using JumpCloud as Your Identity Provider — https://docs.mambu.com/docs/using-jumpcloud-as-your-identity-provider/ - Withdrawing a Deposit Account Application — https://docs.mambu.com/docs/withdrawing-a-deposit-account-application/ - Withdrawing a Loan — https://docs.mambu.com/docs/withdrawing-a-loan/ - Working with Credit Arrangements (Lines of Credit) — https://docs.mambu.com/docs/working-with-credit-arrangements-lines-of-credit/ - Working With Overdue Loans — https://docs.mambu.com/docs/working-with-overdue-loans/ - Working with Payment Holidays — https://docs.mambu.com/docs/working-with-payment-holidays/ - Writing Off a Loan — https://docs.mambu.com/docs/writing-off-a-loan/ - Cbe - v9.165 — https://docs.mambu.com/release-notes/cbe/v9/v9.165/ - Cbe - v9.166 — https://docs.mambu.com/release-notes/cbe/v9/v9.166/ - Cbe - v9.167 — https://docs.mambu.com/release-notes/cbe/v9/v9.167/ - Cbe - v9.168 — https://docs.mambu.com/release-notes/cbe/v9/v9.168/ - Cbe - v9.169 — https://docs.mambu.com/release-notes/cbe/v9/v9.169/ - Cbe - v9.170 — https://docs.mambu.com/release-notes/cbe/v9/v9.170/ - Cbe - v9.171 — https://docs.mambu.com/release-notes/cbe/v9/v9.171/ - Cbe - v9.172 — https://docs.mambu.com/release-notes/cbe/v9/v9.172/ - Cbe - v9.173 — https://docs.mambu.com/release-notes/cbe/v9/v9.173/ - Cbe - v9.174 — https://docs.mambu.com/release-notes/cbe/v9/v9.174/ - Cbe - v9.175 — https://docs.mambu.com/release-notes/cbe/v9/v9.175/ - Cbe - v9.176 — https://docs.mambu.com/release-notes/cbe/v9/v9.176/ - Cbe - v9.177 — https://docs.mambu.com/release-notes/cbe/v9/v9.177/ - Cbe - v9.178 — https://docs.mambu.com/release-notes/cbe/v9/v9.178/ - Cbe - v9.179 — https://docs.mambu.com/release-notes/cbe/v9/v9.179/ - Cbe - v9.180 — https://docs.mambu.com/release-notes/cbe/v9/v9.180/ - Cbe - v9.181 — https://docs.mambu.com/release-notes/cbe/v9/v9.181/ - Cbe - v9.182 — https://docs.mambu.com/release-notes/cbe/v9/v9.182/ - Cbe - v9.183 — https://docs.mambu.com/release-notes/cbe/v9/v9.183/ - Cbe - v9.184 — https://docs.mambu.com/release-notes/cbe/v9/v9.184/ - Cbe - v9.185 — https://docs.mambu.com/release-notes/cbe/v9/v9.185/ - Cbe - v9.186 — https://docs.mambu.com/release-notes/cbe/v9/v9.186/ - Cbe - v9.187 — https://docs.mambu.com/release-notes/cbe/v9/v9.187/ - Cbe - v9.188 — https://docs.mambu.com/release-notes/cbe/v9/v9.188/ - Cbe - v9.189 — https://docs.mambu.com/release-notes/cbe/v9/v9.189/ - Cbe - v9.190 — https://docs.mambu.com/release-notes/cbe/v9/v9.190/ - Cbe - v9.191 — https://docs.mambu.com/release-notes/cbe/v9/v9.191/ - Cbe - v9.192 — https://docs.mambu.com/release-notes/cbe/v9/v9.192/ - Connectors - v1.0.0 — https://docs.mambu.com/release-notes/connectors/v1.0.0/ - Connectors - v1.1.0 — https://docs.mambu.com/release-notes/connectors/v1.1.0/ - Connectors - v1.2.0 — https://docs.mambu.com/release-notes/connectors/v1.2.0/ - Connectors - v1.2.1 — https://docs.mambu.com/release-notes/connectors/v1.2.1/ - Connectors - v1.2.4 — https://docs.mambu.com/release-notes/connectors/v1.2.4/ - Release notes — https://docs.mambu.com/release-notes/ - Notifications - v1.63.0 — https://docs.mambu.com/release-notes/notifications/v1.63.0/ - Notifications - v1.68.0 — https://docs.mambu.com/release-notes/notifications/v1.68.0/ - Notifications - v1.69.0 — https://docs.mambu.com/release-notes/notifications/v1.69.0/ - Notifications - v1.73.0 — https://docs.mambu.com/release-notes/notifications/v1.73.0/ - Notifications - v1.75.0 — https://docs.mambu.com/release-notes/notifications/v1.75.0/ - Notifications - v1.77 — https://docs.mambu.com/release-notes/notifications/v1.77/ - Payments - v1.44.85 — https://docs.mambu.com/release-notes/payments/v1.44.85/ - Payments - v1.44.86 — https://docs.mambu.com/release-notes/payments/v1.44.86/ - Payments - v1.44.87 — https://docs.mambu.com/release-notes/payments/v1.44.87/ - Payments - v1.44.88 — https://docs.mambu.com/release-notes/payments/v1.44.88/ - Payments - v1.44.89 — https://docs.mambu.com/release-notes/payments/v1.44.89/ - Payments - v1.44.90 — https://docs.mambu.com/release-notes/payments/v1.44.90/ - Payments - v1.44.91 — https://docs.mambu.com/release-notes/payments/v1.44.91/ - Payments - v1.44.92 — https://docs.mambu.com/release-notes/payments/v1.44.92/ - Payments - v1.44.93 — https://docs.mambu.com/release-notes/payments/v1.44.93/ - Payments - v1.44.94 — https://docs.mambu.com/release-notes/payments/v1.44.94/ - Payments - v1.44.95 — https://docs.mambu.com/release-notes/payments/v1.44.95/ - Payments - v1.44.96 — https://docs.mambu.com/release-notes/payments/v1.44.96/ - Payments - v1.44.97 — https://docs.mambu.com/release-notes/payments/v1.44.97/ ### API Overview Pages (75 pages) - About Mambu API V1 — https://docs.mambu.com/api/pages/api-v1/about-mambu-api-v1/ - Audit Trail and the User-Agent Header — https://docs.mambu.com/api/pages/api-v1/audit-trail-and-the-user-agent-header/ - Authentication — https://docs.mambu.com/api/pages/api-v1/authentication/ - Base URLs — https://docs.mambu.com/api/pages/api-v1/base-urls/ - Custom View Filtering — https://docs.mambu.com/api/pages/api-v1/custom-view-filtering/ - Data Types and Examples — https://docs.mambu.com/api/pages/api-v1/data-types-and-examples/ - Detail Level — https://docs.mambu.com/api/pages/api-v1/detail-level/ - Filter Constraints — https://docs.mambu.com/api/pages/api-v1/filter-constraints/ - Filter Elements — https://docs.mambu.com/api/pages/api-v1/filter-elements/ - HTTP Verbs — https://docs.mambu.com/api/pages/api-v1/http-verbs/ - Pagination — https://docs.mambu.com/api/pages/api-v1/pagination/ - Payloads — https://docs.mambu.com/api/pages/api-v1/payloads/ - Posting Data — https://docs.mambu.com/api/pages/api-v1/posting-data/ - requests — https://docs.mambu.com/api/pages/api-v1/requests/ - Responses — https://docs.mambu.com/api/pages/api-v1/responses/ - Sandbox — https://docs.mambu.com/api/pages/api-v1/sandbox/ - Searching and Filtering — https://docs.mambu.com/api/pages/api-v1/searching-and-filtering/ - Timezone Offsets — https://docs.mambu.com/api/pages/api-v1/timezone-offsets/ - Mambu API v1 Reference Page — https://docs.mambu.com/api/pages/api-v1/welcome/ - About Mambu API v2 — https://docs.mambu.com/api/pages/api-v2/about-mambu-api-v2/ - OAS v2 Discovery — https://docs.mambu.com/api/pages/api-v2/api-oas2-discovery/ - OAS v3 API Discovery — https://docs.mambu.com/api/pages/api-v2/api-oas3-discovery/ - Audit Trail and the User-Agent Header — https://docs.mambu.com/api/pages/api-v2/audit-trail-and-the-user-agent-header/ - Authentication — https://docs.mambu.com/api/pages/api-v2/authentication/ - Base URLs — https://docs.mambu.com/api/pages/api-v2/base-urls/ - Considerations for specific field types — https://docs.mambu.com/api/pages/api-v2/considerations-for-specific-field-types/ - Cursor-based search pagination — https://docs.mambu.com/api/pages/api-v2/cursor-based-search-pagination/ - Details Level — https://docs.mambu.com/api/pages/api-v2/details-level/ - Filter Operators — https://docs.mambu.com/api/pages/api-v2/filter-operators/ - Generating SDKs from OAS — https://docs.mambu.com/api/pages/api-v2/generating-sdks-from-oas/ - Grouped custom field sets — https://docs.mambu.com/api/pages/api-v2/grouped-custom-field-sets/ - HTTP Verbs — https://docs.mambu.com/api/pages/api-v2/http-verbs/ - Idempotency — https://docs.mambu.com/api/pages/api-v2/idempotency/ - OpenAPI Specification — https://docs.mambu.com/api/pages/api-v2/openapi-specification/ - Optimising Searches — https://docs.mambu.com/api/pages/api-v2/optimising-searches/ - Pagination — https://docs.mambu.com/api/pages/api-v2/pagination/ - Payloads — https://docs.mambu.com/api/pages/api-v2/payloads/ - Requests — https://docs.mambu.com/api/pages/api-v2/requests/ - Responses — https://docs.mambu.com/api/pages/api-v2/responses/ - Retrieving v2 OAS Files — https://docs.mambu.com/api/pages/api-v2/retrieving-v2-oas-files/ - Retrieving v3 OAS Files — https://docs.mambu.com/api/pages/api-v2/retrieving-v3-oas-files/ - Sandbox — https://docs.mambu.com/api/pages/api-v2/sandbox/ - Searching by custom fields — https://docs.mambu.com/api/pages/api-v2/searching-by-custom-fields/ - Searching for Records — https://docs.mambu.com/api/pages/api-v2/searching-for-records/ - Standard custom field sets — https://docs.mambu.com/api/pages/api-v2/standard-custom-field-sets/ - Time Zone Offsets — https://docs.mambu.com/api/pages/api-v2/timezone-offsets/ - Using Custom Fields — https://docs.mambu.com/api/pages/api-v2/using-custom-fields/ - Versioning — https://docs.mambu.com/api/pages/api-v2/versioning/ - Welcome — https://docs.mambu.com/api/pages/api-v2/welcome/ - Best Practices — https://docs.mambu.com/api/pages/audit-trail/best-practices/ - Data Retention and Service Quota — https://docs.mambu.com/api/pages/audit-trail/data-retention-and-service-quota/ - Pagination — https://docs.mambu.com/api/pages/audit-trail/pagination/ - Security — https://docs.mambu.com/api/pages/audit-trail/security/ - Mambu Audit Trail API — https://docs.mambu.com/api/pages/audit-trail/welcome/ - About the Mambu Payments API — https://docs.mambu.com/api/pages/payments-mpg/about-the-mambu-payments-api/ - Incoming and Outgoing Messages — https://docs.mambu.com/api/pages/payments-mpg/incoming-and-outgoing-messages/ - Open API Specification — https://docs.mambu.com/api/pages/payments-mpg/open-api-specification/ - Welcome — https://docs.mambu.com/api/pages/payments-mpg/payments-index/ - Welcome — https://docs.mambu.com/api/pages/payments-mpg/payments-mpg-index/ - Using the API — https://docs.mambu.com/api/pages/payments-mpg/using-the-api/ - About Mambu Streaming API — https://docs.mambu.com/api/pages/streaming/about-mambu-streaming/ - Authentication — https://docs.mambu.com/api/pages/streaming/authentication/ - Base URLs — https://docs.mambu.com/api/pages/streaming/base-urls/ - Committing Cursors — https://docs.mambu.com/api/pages/streaming/committing-cursors/ - Consuming Events from a Subscription — https://docs.mambu.com/api/pages/streaming/consuming-events-from-a-subscription/ - Creating an Event Stream — https://docs.mambu.com/api/pages/streaming/creating-an-event-stream/ - Creating Subscriptions — https://docs.mambu.com/api/pages/streaming/creating-subscriptions/ - Deleting a Subscription — https://docs.mambu.com/api/pages/streaming/deleting-a-subscription/ - Event Streaming Configurations — https://docs.mambu.com/api/pages/streaming/event-streaming-configurations/ - Event Streaming Recommendations — https://docs.mambu.com/api/pages/streaming/event-streaming-recommendations/ - HTTP Verbs — https://docs.mambu.com/api/pages/streaming/http-verbs/ - Java Sample Client — https://docs.mambu.com/api/pages/streaming/java-sample-client/ - OpenAPI Specification — https://docs.mambu.com/api/pages/streaming/openapi-specification/ - Mambu Streaming API — https://docs.mambu.com/api/pages/streaming/streaming-index/ - Subscription Cursors — https://docs.mambu.com/api/pages/streaming/subscription-cursors/ ### API v2 Reference (78 specs) — fetch raw spec via https://docs.mambu.com/swagger_files/v2/{resource}.json - accounting/interestaccrual — https://docs.mambu.com/api/v2/accounting/interestaccrual/ - accounting/reports — https://docs.mambu.com/api/v2/accounting/reports/ - apikey/rotation — https://docs.mambu.com/api/v2/apikey/rotation/ - application/status — https://docs.mambu.com/api/v2/application/status/ - backgroundprocess — https://docs.mambu.com/api/v2/backgroundprocess/ - branches — https://docs.mambu.com/api/v2/branches/ - bulks — https://docs.mambu.com/api/v2/bulks/ - cards — https://docs.mambu.com/api/v2/cards/ - centres — https://docs.mambu.com/api/v2/centres/ - clients — https://docs.mambu.com/api/v2/clients/ - clients/documents — https://docs.mambu.com/api/v2/clients/documents/ - comments — https://docs.mambu.com/api/v2/comments/ - communications/messages — https://docs.mambu.com/api/v2/communications/messages/ - configuration/accountingrules.yaml — https://docs.mambu.com/api/v2/configuration/accountingrules.yaml/ - configuration/authorizationholds.yaml — https://docs.mambu.com/api/v2/configuration/authorizationholds.yaml/ - configuration/branches.yaml — https://docs.mambu.com/api/v2/configuration/branches.yaml/ - configuration/centres.yaml — https://docs.mambu.com/api/v2/configuration/centres.yaml/ - configuration/clientroles.yaml — https://docs.mambu.com/api/v2/configuration/clientroles.yaml/ - configuration/currencies.yaml — https://docs.mambu.com/api/v2/configuration/currencies.yaml/ - configuration/customfields — https://docs.mambu.com/api/v2/configuration/customfields/ - configuration/depositproducts.yaml — https://docs.mambu.com/api/v2/configuration/depositproducts.yaml/ - configuration/endofdayprocessing.yaml — https://docs.mambu.com/api/v2/configuration/endofdayprocessing.yaml/ - configuration/grouprolenames.yaml — https://docs.mambu.com/api/v2/configuration/grouprolenames.yaml/ - configuration/holidays.yaml — https://docs.mambu.com/api/v2/configuration/holidays.yaml/ - configuration/iddocumenttemplates.yaml — https://docs.mambu.com/api/v2/configuration/iddocumenttemplates.yaml/ - configuration/indexrates.yaml — https://docs.mambu.com/api/v2/configuration/indexrates.yaml/ - configuration/internalcontrols.yaml — https://docs.mambu.com/api/v2/configuration/internalcontrols.yaml/ - configuration/labels.yaml — https://docs.mambu.com/api/v2/configuration/labels.yaml/ - configuration/loanproducts.yaml — https://docs.mambu.com/api/v2/configuration/loanproducts.yaml/ - configuration/loanrisklevels.yaml — https://docs.mambu.com/api/v2/configuration/loanrisklevels.yaml/ - configuration/organization — https://docs.mambu.com/api/v2/configuration/organization/ - configuration/transactionchannels.yaml — https://docs.mambu.com/api/v2/configuration/transactionchannels.yaml/ - configuration/userroles — https://docs.mambu.com/api/v2/configuration/userroles/ - consumers — https://docs.mambu.com/api/v2/consumers/ - creditarrangements — https://docs.mambu.com/api/v2/creditarrangements/ - crons/earlyeod — https://docs.mambu.com/api/v2/crons/earlyeod/ - crons/eod — https://docs.mambu.com/api/v2/crons/eod/ - currencies — https://docs.mambu.com/api/v2/currencies/ - currencies/accountingRates — https://docs.mambu.com/api/v2/currencies/accountingrates/ - customfields — https://docs.mambu.com/api/v2/customfields/ - customfieldsets — https://docs.mambu.com/api/v2/customfieldsets/ - data/import — https://docs.mambu.com/api/v2/data/import/ - database/backup — https://docs.mambu.com/api/v2/database/backup/ - depositproducts — https://docs.mambu.com/api/v2/depositproducts/ - deposits — https://docs.mambu.com/api/v2/deposits/ - deposits/balanceSummary — https://docs.mambu.com/api/v2/deposits/balancesummary/ - deposits/transactions — https://docs.mambu.com/api/v2/deposits/transactions/ - documents — https://docs.mambu.com/api/v2/documents/ - extensionpoints — https://docs.mambu.com/api/v2/extensionpoints/ - fundingsources — https://docs.mambu.com/api/v2/fundingsources/ - glaccounts — https://docs.mambu.com/api/v2/glaccounts/ - gljournalentries — https://docs.mambu.com/api/v2/gljournalentries/ - groups — https://docs.mambu.com/api/v2/groups/ - indexratesources — https://docs.mambu.com/api/v2/indexratesources/ - installments — https://docs.mambu.com/api/v2/installments/ - loanproducts — https://docs.mambu.com/api/v2/loanproducts/ - loans — https://docs.mambu.com/api/v2/loans/ - loans/schedule — https://docs.mambu.com/api/v2/loans/schedule/ - loans/tranches — https://docs.mambu.com/api/v2/loans/tranches/ - loans/transactions — https://docs.mambu.com/api/v2/loans/transactions/ - notificationsettings/webhook — https://docs.mambu.com/api/v2/notificationsettings/webhook/ - organization/holidays — https://docs.mambu.com/api/v2/organization/holidays/ - organization/holidays/general — https://docs.mambu.com/api/v2/organization/holidays/general/ - organization/holidays/nonworkingdays — https://docs.mambu.com/api/v2/organization/holidays/nonworkingdays/ - organization/identificationDocumentTemplates — https://docs.mambu.com/api/v2/organization/identificationdocumenttemplates/ - organization/transactionChannels — https://docs.mambu.com/api/v2/organization/transactionchannels/ - profitsharing/cash-flows — https://docs.mambu.com/api/v2/profitsharing/cash-flows/ - profitsharing/pools — https://docs.mambu.com/api/v2/profitsharing/pools/ - profitsharing/product-settings — https://docs.mambu.com/api/v2/profitsharing/product-settings/ - profitsharing/proposals — https://docs.mambu.com/api/v2/profitsharing/proposals/ - setup/general — https://docs.mambu.com/api/v2/setup/general/ - setup/organization — https://docs.mambu.com/api/v2/setup/organization/ - streaming/publisher/stats — https://docs.mambu.com/api/v2/streaming/publisher/stats/ - subscriptions — https://docs.mambu.com/api/v2/subscriptions/ - tasks — https://docs.mambu.com/api/v2/tasks/ - templates — https://docs.mambu.com/api/v2/templates/ - userroles — https://docs.mambu.com/api/v2/userroles/ - users — https://docs.mambu.com/api/v2/users/ --- # Access Preferences URL: https://docs.mambu.com/docs/access-preferences/ *Access Preferences* refers to the restrictions that secure the way all users access the system. A user must be an admin user or have the **Manage Access Preferences** (`MANAGE_ACCESS_PREFERENCES`) to edit these preferences. :::note Access preferences include password policy settings. For security reasons, we recommend carefully controlling which users have the **Manage Access Preferences** permission. ::: ## Managing access preferences To add and edit access preferences: 1. On the main menu, go to **Administration** > **Access** > **Preferences**. 2. Enter all the necessary information. See below for more information on the fields. 3. Select **Save Changes**. ![All the available Access Preferences](@site/static/img/support/users-and-access-control--preferences-tab.png) ## Fields for access preferences Fields with a green outline are required fields. Fields with a grey outline are not required. ### Timeout Session (required) Sets the amount of inactive time that can elapse before a user is automatically logged out. ### Min Password Length (required) Sets the minimum number of characters for user passwords. The minimum password length Mambu allows is 6 characters; as a best practice we recommend at least 8. For more information, see [Password Policy](/docs/change-your-password-and-edit-your-profile#password-requirements). ### Minimum Numeric Character Count (required) Sets the minimum number of characters that are numbers for user passwords. Mambu recommends a minimum value of at least 3 numerical characters. Minimum values of less than 3 will result in a warning message. The default value is 1. ### Minimum Uppercase Character Count Sets the minimum number of uppercase characters for user passwords. Mambu recommends a minimum value of at least 3 uppercase characters. Minimum values of less than 3 will result in a warning message. If this field is selected, the default value of 0 must be changed. ### Minimum Special Character Count Sets the minimum number of special characters for user passwords. Mambu recommends a minimum value of at least 3 special characters. Minimum values of less than 3 will result in a warning message. If this field is selected, the default value of 0 must be changed. ### Automatic Expiry of User Passwords Defines the validity time period of user passwords. When a password expires, the user will be forced to change it before accessing Mambu. :::note This setting does not apply to API users. ::: ### Automatic Expiry of API Consumer Key Defines the expiration value for all API keys generated during key rotation. This value will not affect keys created in the UI, or created using the createApiKeyByConsumer endpoint. For more information, see [API key rotation](/docs/api-consumers#api-key-rotation) in the User Guide and the [API consumers](/api/api-v2/consumers/consumers/) endpoint in our API Reference. ### Limit Previously Used Passwords Sets the amount of previously used passwords that may not be reused when setting a new user password. The limit value must be between 1 and 10. The default value is 4. If you edit this setting, it only applies to new passwords, not to passwords that were set before the setting was re-configured. ### Lock User After Failed Logins (required) The **Lock User After Failed Logins** option is activated across all environments in Mambu. The number of failed login attempts can now be set between 3 and 6. :::warning Please Be Aware Locked users can only be unlocked by an administrator. ::: The cooldown duration refers to the period after which a user can try logging in again after they've reached the maximum login attempts. The recommended minimum values for the cooldown duration are as follows: |Failed login attempts|Cooldown duration| |---|---| |3|15 minutes| |4|30 minutes| |5|60 minutes| |6|permanent| :::note When the maximum number of failed logins is reached, Mambu will automatically send an email to the user to inform them that their account is locked. In order to make use of this functionality: * You must have [set up a valid email server](/docs/email-setup). * The user must have an email address associated with their account. ::: If the invalid login attempts come via the APIs using basic auth, the same rules defined in **Administration** > **Access** > **Preferences** > **Lock User After Failed Logins** apply. ### IP Access Restrictions #### Whitelist approved IP Addresses An administrator may define a whitelist of approved IP addresses and also define the types of users that the whitelist applies to by using the **Apply To** setting, which applies to all the IP addresses. It is not possible to configure granular settings for each IP address. :::note This feature does not support IPv6 IP addresses. ::: :::note IP Whitelisting currently covers the cloud banking platform only. From 15 July 2024, IP addresses will apply universally to all current and future Mambu capabilities, apart from the Mambu Process Orchestrator (MPO IP whitelisting will cover services such as Cards, Payments, Islamic Profit Sharing, Notifictions, Audit Trail, and Streaming API.) ::: ![Whitelist approved IP Adresses](@site/static/img/support/users-and-access-control--ip-access-restrictions.png) The types of users that the whitelist may apply to are: * Admins: users or API consumers with admin access rights accessing through the UI or API. * Users: users accessing through the Mambu UI. * API: users with API rights or API consumers accessing via API. If a whitelist is defined, devices must use one of the approved IP addresses in order to log in to Mambu. To add an IP address to the whitelist: 1. Select the **Whitelist approved IP Adresses** checkbox. 2. Enter the IP address in the field below the whitelist. 3. Select **Add**. IP whitelisting supports the following IP address formats: - Static IPv4 IP addresses - IPv4 IP addresses with wildcards (Example: `192.168.0.*`) - IPv4 IP addresses with byte range (Example: `192.168.0.1-25`) - Classless Inter-Domain Routing (CIDR) notation (Example: `192.168.0.1/24`) #### Blocked IP addresses API consumers generate API keys which are used to authenticate API requests. Mambu blocks any IP address that issues a total of 10 unauthorized API requests from an API consumer. This applies even if the IP has been whitelisted. There is no timeframe within which these 10 calls need to be made. Administrators may remove IP addresses from the blocked list. ![Blocked IPs list](@site/static/img/support/users-and-access-control--ip-access-restrictions-3.png) :::note API Consumers is an early access feature. For more information, see [API Consumers](/docs/api-consumers). ::: To remove an IP address from the blocked list: 1. On the main menu, go to **Administration** > **Access** > **Preferences**. 2. Under the **IP Access Restrictions** section, select the **Show / Hide blocked IPs** check box. 3. Select the IP addresses you would like to remove and select **Reset**. ### Critical Actions Re-Authentication A *Critical Action* is an action which Mambu deems has business critical functionality. You can find a list of all critical actions below. If you select the **Require Admin Password** check box in the **Critical Actions Re-Authentication** section, then this protection mechanism invokes a re-authentication request, and users are asked to provide their credentials when they perform critical actions in the system. #### In the context of using Mambu login With this setting enabled, logged-in users are prompted to re-enter their password for identity verification whenever performing critical actions such as changing important settings, modifying products, making transfers, and so on. #### In the context of using federated authentication When using federated authentication, you delegate user and password management to your identity provider, hence we cannot manage its re-authentication requests. We generally advise you to use granular administrative permissions properly and setup multi-factor authentication (MFA) in your Identity Provider, if you want to setup good access practices. If you choose to keep this option enabled when you are using federated authentication, please note that we will only ask administrators to re-authenticate before executing a critical action, as the rest of the users do not have Mambu credentials. ## Actions considered "Critical" in Mambu The following is a list of critical actions: * Toggle App State * Store App * Delete App * Database export * Reset Data * Store Accounting Settings * Store Security Settings * Store General Settings * Toggle Loan Product Activation * Change Branch State * Store Product Document Template * Delete Product Document Template * Toggle Savings Product Activation * Delete Savings Product * Store Federated Authentication Settings * Delete Role * Store Role * Store User * Delete User * Change User State * Lock User * Toggle Support/Delivery Access * Store API consumer * Update API consumer * Delete API consumer * Delete API key * Store Loan Product * Store Savings Product --- # Accounting Closures URL: https://docs.mambu.com/docs/accounting-closures/ For all organizations (regardless of their use of Mambu's Accounting module) it's important to be able to close their accounts periodically, mainly to ensure that no new transactions will be logged into closed periods, which could affect the previously submitted accounting reports. Mambu ensures this business need is covered by the “Accounting Closure” functionality, available under the **Accounting > Closures** menu item. *** ## Adding a New Closure Date New closure dates always need to be added: * in the past (future dates are not allowed) and * after existing closures (for example, if accounts were closed as of July 1st, you can't add a new closure on June 15th). **To add a new closure date:** 1. Go to **Accounting > Closures >** click **Close Accounts** 1. Enter the closure date -> the system will not allow any transactions to be posted before this date 1. Select the branch (if applicable, you can do closures per branch; for example, if a branch has finished processing their transactions for the day, they already close the day without waiting for all the other branches to finish processing) 1. Enter your comments (optional) 1. Click **Close Accounts**. ![Close Accounts screen with Closure Date, Branch and Notes fields.](@site/static/img/support/accounting--add-closure-date-modal.png) *** ## Editing and Deleting a Closure If you need to change a closure's description, **click on the Edit icon > make the changes > Save Changes.** If for some reason you need to backdate a transaction to a date before the closure date, you will have to first *delete* the closure. To delete a closure date, **click on the deletion icon > Delete.** ![Accounting Closures view with Edit or Delete buttons](@site/static/img/support/accounting--accounting-closures-list.png) *** ## Automatic Closures In case you prefer accounting closures to be performed automatically by the system at a specified frequency, you can set this up from **Administration > Financial Setup > Accounting > Accounting Closures** : * tick the checkbox to enable automatic closures and * define the frequency (in days) with which closures should be performed. From that point on, Mambu will perform the closures automatically during the nightly automated cron jobs: ![Accounting Closures from Administration, Financial Setup, Accounting tab](@site/static/img/support/accounting--accounting-closures-configuration.png) *** --- # Accounting Reports URL: https://docs.mambu.com/docs/accounting-reports/ You can generate the following accounting reports in Mambu: * [Balance Sheet](#balance-sheet) * [Profit & Loss report (or Income Statement)](#profit--loss-or-income-statement) * [Trial Balance](#trial-balance) :::note It is also possible to generate your reports asynchronously via API, for more information, see [Accounting Reports API](/api/api-v2/accounting_reports/accounting-reports) in our API Reference. ::: ![Start generating Accounting Reports](@site/static/img/support/accounting-reports-start.png) ## Permissions and accounting reports To view, generate, and print (export) accounting reports, your user needs to have the **View Accounting Reports** (`VIEW_ACCOUNTING_REPORTS`) permission or they need to be an administrator user (admin). For more information, see [Permissions - Accounting](/docs/permissions#accounting) and [Creating a User - Type](/docs/creating-new-users#type). ## Time range for accounting reports For all three types of reports, you need to specify the time range for which the report is generated. :::note Currently, Mambu does not restrict the dates you can specify, so selecting a date in the future is also possible (but of little practical use). ::: ### Time range for Balance Sheet reports For **Balance Sheet** reports, you can choose between generating a report for a specific month, or generating a report until specified date using the **Show** option and selecting **Month** or **Date**. When you select **Show** **Month**, the **Balance Sheet** report is created for that month only. If you select the current month, the report is created from the beginning of the month until the current date. ![balance-sheet-month](@site/static/img/support/balance-sheet-month.png) When you select **Show** **Date**, the **Balance Sheet** report is created from the creation of the organization until the date you specify. ![balance-sheet-month](@site/static/img/support/balance-sheet-date.png) ### Time range for Profit & Loss and Trial Balance reports For **Profit & Loss** and **Trial Balance reports**, you need to specify a starting date and an ending date in the **From** and **To** fields, respectively. ![Specify the start and end date for your Accounting Report](@site/static/img/support/start-end-date-accounting-reports.png) :::note The maximum range for **Profit & Loss** and **Trial Balance reports** is 366 days. ::: ## Including or excluding zero balance accounts By default, accounts that do not have any debit or credit for the specified period, also known as **zero balance accounts**, are excluded from the report. To include these accounts in the report, select **More > Show Zero Balance Accounts**. ![Show more options for Balance Sheet](@site/static/img/support/balance-sheet-more.png) ![Show zero balance accounts in the Balance Sheet](@site/static/img/support/show-zero-balance-accounts-balance-sheet.png) ## Computing Accounting Reports Mambu computes accounting reports based on summaries of GL account balances broken down by branch and entry date, after which they are stored daily with the End of Day processes. If the End of Day processes did not run and the account summaries are missing, the balance is computed using the accounting entries (a larger, unaggregated dataset), which could make the generation of the report take a little longer. ## Balance Sheet The Balance Sheet shows the balances of GL accounts for a specific month, displaying the overall standing of assets, liabilities and equity. It gives you information about the organization's financial situation and the chance to identify potential problems. To generate a Balance Sheet, go to **Accounting > Balance Sheet > choose the specific date or the month and year > Generate Report.** ![Balance Sheet screen with options to be set in order to Generate the report.](@site/static/img/support/accounting--balance-sheet-report.png) ## Profit & Loss (or Income Statement) It shows your organization's revenue and expenses for a given date range or for a month. The difference between the total revenue and the total expense is your business net income. This report's main purpose is to evaluate if your business has made a profit or a loss. A key element of this statement, and one that distinguishes it from a balance sheet, is that the amounts displayed in the Profit and Loss report represent transactions over a period of time while the values on the balance sheet provide financial information at a given moment. To generate a Profit and Loss report **go to Accounting > Profit & Loss > choose a date range > click on Generate Report.** ![Profit & Loss screen with options to be set in order to Generate the report.](@site/static/img/support/accounting--profit-and-loss-statement.png) ## Trial Balance Shows a list of all the accounts in your General Ledger and its balances for a specified date range or month. A trial balance is usually prepared at the end of an accounting period and is used to see if additional adjustments are required to any of the balances. Since the basic accounting system relies on double-entry bookkeeping, a trial balance will have the same total debit amount as it has total Credit amounts. You can choose what information to display in the report and Mambu will keep your preferences, so the next time you access the Trial Balance report, the columns that you checked will be displayed by default. **Opening Balance** shows the accounting balance as of the first day of the selected interval The **Debits** and **Credits** columns show the total net change for each account, where the Net Change is equal to "Debits minus Credits" for Assets and Expenses account; and "Credits minus Debits" for Liability, Equity and Income accounts **Closing Balance** displays the accounting balance in the last day of the selected interval :::note The report can be pulled only for a 366 days maximum range. ::: To generate a Trial Balance report: navigate to **Accounting > Trial Balance > choose the date range for the report > Generate Report.** ![Trail Balance screen with options to be set in order to Generate the report.](@site/static/img/support/accounting--trial-balance.png) ## Interest accrual breakdown For more information about accessing the interest accrual breakdown report, see [Interest accrual calculation in accounting](/docs/cash-vs-accruals-accounting#interest-accrual-calculation-in-accounting). ## Branch-level accounting reports If you have several branches in your organization, the Chart of Accounts will apply to the entire organization but you can still have accounting reports at the branch level. This is possible because: * for the automatic Journal Entries, Mambu automatically assigns them to the branch to which the client is assigned * for the manual Journal Entries, you can select the branch to which it should apply when posting the entry. When exporting or printing any of Balance Sheet, Profit & Loss or Trial Balance reports, the resulting document will include the selected ‘Branch’ information in the header. ![Branch Level Account Reports with information like name of report, period, branch and many more.](@site/static/img/support/accounting--branch-level-balance-sheet-report.png) --- # Accounting Setup URL: https://docs.mambu.com/docs/accounting-setup/ ## Before using the accounting module To use the accounting module, you need to go through the following steps: 1. Make sure you have the proper permissions. If another user will be setting up the Accounting module, give them the permissions to access and perform operations in it. For more information, see [Permissions](/docs/permissions). 2. Set up or import your [chart of accounts](/docs/creating-your-chart-of-accounts). Now you are ready to enable accounting for every product. ## Enabling accounting for loans and deposits When [creating a new loan product](/docs/setting-up-new-loan-products), you can choose whether or not to enable accounting for that product and between the two different methodologies supported: accruals or cash. For more information, see [Cash vs Accruals Accounting](/docs/cash-vs-accruals-accounting). If you enable accounting, you must set up the accounting rules for each transaction before saving the product. For more information, see [Linking Products to Accounting](/docs/linking-products-to-accounting). After that, all the transactions under that product will be automatically logged in accounting. ![Accounting Rules - Methodology dropdown with None, Cash and Accrual options](@site/static/img/support/accounting--accounting-rules-methodology-dropdown.png) ## Accounting Rates Accounting rates are used to convert accounting entries related to transactions made in multicurrency into the base currency. The accounting rates are applied to the transaction date with the exception of accounting entries related to end of day (EOD) processes and manual journal entries which are applied to the booking date. This feature is part of the [Accounting in Multicurrency](/docs/inter-branch-transfer-gl-account#accounting-in-multicurrency) feature. :::warning Rates need to be set immediately after enabling the Accounting in Multicurrency feature to cover all time periods, including the one before the feature is enabled. Once Accounting in Multicurrency is enabled, the accounting rate will be the only exchange rate used for converting foreign transaction amounts to the base currency in journal entries. ::: As manual journal entries contain only the date, and not the time, the accounting rate used will be the one from the beginning of the day. Each accounting rate has a rate value and a date from which it is valid (**Date Set**). You may set the accounting rate either via the UI or the API. Once an accounting rate is set, it will be available from that moment onwards until a new accounting rate is set and can not be changed. :::note When you configure accounting rates via the UI, the date from which the accounting rate is valid is always set automatically to the date and time you are creating the record in the UI. Using the API to add accounting rates is more flexible, allowing you to set the date and time from which the account rate should be used, even if this is in the past. ::: ### Setting an accounting rate via the UI To set an accounting rate: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. Under **Accounting rates**, find the currency you're interested in and, on the right-hand side of the row, select **Actions** > **Set Rate**. 3. Set the **Accounting Rate** from the new currency to the base currency. 4. Select **Save Changes**. ![Setting the accounting rate](@site/static/img/support/Screen%20Shot%202020-11-18%20at%202.29.28%20PM.png) ![Setting the accounting rate](@site/static/img/support/Screen%20Shot%202021-01-26%20at%2011.35.01%20AM.png) When setting up an accounting rate via the UI, the date from which it is valid (**Date Set**) is automatically set as the date and time you set the accounting rate. The date-time format is determined by the organization settings you have set up. For more information, see [Organization Contact Details and Time Zone](/docs/organization-contact-currency-and-timezone). ### Setting an accounting rate via the API To set up an accounting rate via the API, make a `POST` request to the [/currencies/\/accountingRates](/api/api-v2/currencies_accountingrates/create) endpoint. Once you set an accounting rate, you may no longer change the `startDate` to an earlier date than the date that was set initially. However, you can post accounting rates starting at an earlier point in time, with the condition that no accounting rate is already posted for that period. To be able to post backdated transactions, you must have accounting rates that cover that date. For example, if you have an initial accounting rate set on the 1st of February and you need to post a backdated transaction on the 28th of January: 1. Set a new accounting rate on the 28th of January. This accounting rate will be available for all the transactions posted from the 28th of January until the 1st of February, when you have your initial accounting rate set. 2. Post your transaction backdated to the 28th of January. :::warning Adding backdated accounting rates has no effect on ledger accounts. Given that an accounting rate is available from the moment you set it until another accounting rate is set and cannot be changed, we highly recommend you to set accounting rates in descending chronological order. Taking the previous example, if you typically update currency exchange rates daily, set accounting rates starting with the 31st of January and continue with the 30th, 29th and 28th to have the entire period covered. ::: --- # Adding accounts to a credit arrangement URL: https://docs.mambu.com/docs/adding-accounts-to-a-credit-arrangement/ This page explains how to add accounts to a credit arrangement via the Mambu UI. You can also do the same via Mambu API v2, by making a `POST` request to the `/creditarrangements/:addAccount` endpoint. For more information, see [Add account](/api/api-v2/creditarrangements/add-account) in our API Reference. ## Accounts managed under credit arrangements The functionality to add loan accounts or overdraft accounts to a credit arrangement is defined in the settings of the respective products. This setting is available in the **Loan Amount** section for loan products and in the **Overdraft Conditions** section for deposit products. You can choose from three available alternatives: * **Optional:** accounts in a product with the *Optional* setting defined can be managed as part of a credit arrangement, but it’s not neccessary to have a credit arrangement extended in order to open an account in that product. * **Required:** accounts in a product with the *Required* setting defined cannot be approved if they’re not associated with a credit arrangement. * **No:** accounts in a product with the *Restricted* setting defined can't be managed under credit arrangements. ## Add an account to a credit arrangement When a credit arrangement is created, no accounts are associated with it automatically and only existing loan and overdraft accounts can be added to it. In other words, loan or overdraft accounts have to be created for a client or group first, and only then can they be linked to a credit arrangement. Users can add active accounts to a credit arrangement under the following conditions: * **Loan Accounts**: can be added if the disbursement date is after the credit arrangement start date and the maturity date is before the credit arrangement end date. Additionally, the sum of loan amounts - or the original funds - cannot exceed the credit arrangement maximum exposure amount. * **Overdraft Accounts**: can be added if the overdraft expiry date is before the credit arrangement expiry date and if the overdraft balance doesn’t exceed the credit arrangement maximum exposure amount. Overdrafts that don’t have an expiry date or maximum overdraft amount can’t be added to credit arrangements. To add an account to a credit arrangement: 1. Open the client's or the group's profile. 2. Select the credit arrangement to which you want to add an account. 3. On the right-hand side of the screen, select **More** > **Add Account**. ![Adding an account to a credit arrangement.png](@site/static/img/support/Adding%20an%20account%20to%20a%20credit%20arrangement.png) 4. In the **Add Account To Credit Arrangement** dialog, choose from the list of available loan accounts or deposit accounts allowing overdrafts, which: * Already exist for a given client. * Have a product setup allowing accounts to be added to credit arrangements. * Are in the following states: `Partial Application`, `Pending Approval`, `Approved`, or `Active`. * Are not yet assigned to a credit arrangement. * Have terms falling within the constraints of the credit arrangement. ![Add account to credit arrangement dialog.png](@site/static/img/support/Add%20account%20to%20credit%20arrangement%20dialog.png) 5. Select **Add Account**. Once an account is linked to a credit arrangement, the link will be visible in the account’s **Overview**. ## Loans in Multicurrency If you have the **Loans In Multicurrency** feature enabled, then you may set up credit arrangement in different currencies. You may only add loan and overdraft accounts to a credit arrangment if they are in the same currency as the credit arrangement itself. --- # Adjustable Interest Rates URL: https://docs.mambu.com/docs/adjustable-interest-rates/ Adjustable Interest Rate (AIR) loans allow users to have all available interest rate types on **fixed interest rate** and **index interest rate** loans, and to switch between them based on defined time periods. You can set as many interest rate sources as possible at an account level, which offers more flexibility. :::note If you wish to use Adjustable Interest Rates, please get in touch with your Mambu Customer Success Manager or contact us through [Mambu Support](/docs/mambu-support) to discuss your requirements. ::: ## Use cases A loan could have a fixed interest rate for the first three years of the account's term, and switch to an indexed interest rate for the remainder of the loan's term. This gives loans the ability to handle a number of products with similar behavior, such as honeymoon rate periods, rest periods, loyalty discount rate spreads, and government-subsidized rates. ### Negative spread discounts Negative spreads can be used to lower the index rate of an AIR loan, which allows lenders to offer specific discounts while still keeping the rate pinned to the index, which can go up or down for the entire portfolio. For instance, this can provide banks the flexibility to refinance and differentiate between their front-book and back-book rates. For example, if the Index rate = 2%, and the Spread = -0.01%, the rate then becomes 1.99%. The `allowNegativeInterestRate` flag must be set to `true` to allow for negative spread discounts. ## Adjustable Interest Rate setup AIR offers the possibility to set up a list of interest rate sources at both a [product](/docs/adjustable-interest-rates#product-level-setup) and [account](/docs/adjustable-interest-rates#account-level-setup) level. The following settings are used to configure AIR: * `validFrom` date: the period from which an interest rate becomes active * Interest Rate Source: Fixed or Index * Interest rate/Spread % * In the case of an **Index** interest rate, you will also define: * Rate source * Interest rate ceiling * Interest rate floor * Interest rate review frequency :::important You must have an Interest Rate Source defined in the Administration area before you can use it in AIR. Refer to [Interest Rate Sources](/docs/interest-calculation-methods-in-loans#interest-rate-source) for more information. ::: ### Product level setup At the product level we can define only one **Fixed** interest rate source with the following details: * Interest Rate: default/min/max However we can define multiple **Index** interest rate sources - as long as they already exist in the Administration area - with the details described above. The period of the interest rate source (`validFrom`) is not defined at a product level. See [below](#migrating-non-air-products-to-air-products) to learn more about migrating products to AIR via the API. ### Account level setup To create a loan account with AIR: * At account creation you should define the periods (`valueFrom` date for each interest rate source. * The anticipated disbursement date should be the same as the first `validFrom` date for the first AIR settings, in order to fulfill the main use case. For example, the first two years should be fixed and after that it should be variable. * Only an AIR set at the product level can be defined at the account level. * You can define **multiple** fixed interest rate sources at an account level for different periods (`validFrom` dates) and with or without different rates. * You can define **the same** index interest rate sources at the account level but with different periods (`validFrom` dates) and with or without different rates. * You can overwrite the values in the product level at the account level for each interest rate source. ### Disbursing a loan account with AIR For more information, refer to [Disbursing a Loan](/docs/disbursing-a-loan). * When the anticipated disbursement date and the `validFrom` defined for the first AIR period from loan account creation is different than the disbursement date - for instance, when the account and disbursement are done on different days - then the API flag or UI checkbox `shiftAdjustableInterestPeriods` will do the following actions: * If false (un-checked): the AIR `validFrom` date will be the one from the loan account creation moment. This will then define the start of the AIR from the loan account creation moment, rather than the disbursement moment. * If True (checked) : Mambu will automatically move the `validFrom` date for all AIR periods to be from the disbursement date. This will then define the first period of the Fixed/Index interest rates from the disbursement date. * If it is not specified, the default value will be false. * if `shiftAdjustableInterestPeriods` is not passed in a case where the disbursement date is not equal to the firist AIR `validFrom` date, the disbursement call will return an error notifying you that the disbursement date is different from the first valid from date. You will need to either adjust the dates to match the disbursement, or pass `shiftAdjustableInterestPeriods` as true. ## Negative interest rate spreads via AIR Adjustable Interest Rates can be used to achieve a negative spread, which will decrease the overall applicable interest rate for a product. ### Use case examples 1. Multiple interest sources that were defined at the product level, in any order: * Product level: * Fixed Interest Rate * Libor Index Interest Rate * Account level: * From 01.09.2021 Fixed Interest Rate with 5% * From 01.12.2021 Fixed Interest Rate with 7% * From 01.03.2022 Libor Index Interest Rate with 2% interest spread 2. One interest source defined at an account level, with the condition that the source Index rate should be available in Administration: * Product level: * Fixed Interest Rate * Libor Index Interest Rate * Account level: * From 01.09.2021 Libor Index Interest Rate with 2% interest spread 3. AIR with the first two years Fixed Interest Rate, and thereafter an Index Interest Rate: * Current date 01.01.2021. Create a loan account with AIR: * Anticipated disbursement date: 01.01.2021 * First repayment due date: 01.02.2021 * AIR setup: * Valid from 01.01.2021 Fixed Interest Rate with 10% interest rate * Valid from 01.01.2023 Index Interest Rate with 5% interest spread * Current date: 15.01.2021: Approve the account * Current date: 15.01.2021: Disburse the account * _Expected result_: we need to keep the use case of having first 2 years fixed interest rate and after that index from the disbursement moment. * _Solution_: * On disburse action, let the user modify the _valid from_ dates for AIR: * Valid from **15.01.2021** Fixed Interest Rate with 10% interest rate * Valid from **15.01.2023** Index Interest Rate with 5% interest spread ## API details The [Index Rate Sources](/api/api-v2/indexratesources/indexratesources) entity in the v2 API is used to define the type of interest rate used for a specific period in the duration of the loan. This parameter is also visible in the response payload for [GET loan accounts by ID](/api/api-v2/loans/get-by-id): ```json "interestSettings": { "accountInterestRateSettings": [ { "encodedKey": "string", "indexSourceKey": "string", "interestRate": 0, "interestRateCeilingValue": 0, "interestRateFloorValue": 0, "interestRateReviewCount": 0, "interestRateReviewUnit": "DAYS", "interestRateSource": "FIXED_INTEREST_RATE", "interestSpread": 0, "validFrom": "2016-09-06T13:37:50+03:00" } ``` ## Migrating non-AIR products to AIR products You can migrate non-AIR products to AIR products. This can be done in the UI or via a PUT/PATCH call to the loan product. :::warning The PUT/PATCH call should only perform the steps that are strictly necessary for the migration, in other words, the step of moving the `interestRateSource` and `interestRate` from `indexRateSettings` to `interestRateSettings`. Any additional adjustments such as changing the interest rate or adding another source should be done via a separate PUT/PATCH call. ::: --- # Adjusting Overdraft Terms URL: https://docs.mambu.com/docs/adjusting-overdraft-terms/ In Mambu, you can adjust overdraft terms on *Active* deposit accounts. To do so: 1. Open the deposit account. 2. On the right hand side of the screen, click on **More** > **Adjust Overdraft Terms**. 3. Make the changes (adjust Overdraft limit, Interest Rate, Expiry Date, or Notes). 4. Click on **Save Changes**. !["Adjust Overdraft Terms" screen with Overdraft Limit, Interest Rate (% per year), Expiry Date, and Notes fields with two buttons below: Cancel and Save Changes](@site/static/img/support/deposits--adjust-overdraft-terms.png) ## Adjust overdraft limit When the overdraft limit is changed, a non financial transaction, "Overdraft Limit Changed", will be logged, which helps in calculating the number of days in arrears for the account. When the limit is set below the negative balance, the difference between Overdraft Limit and Balance will set the account "In Arrears". When the Overdraft is in arrears, you will see "Overdraft In Arrears" on the account overview, under the "Overdraft Conditions" section. --- # Adjusting Transactions URL: https://docs.mambu.com/docs/adjusting-transactions/ A *transaction* is any operation implying changes in the balance of an account such as deposits, withdrawals or disbursements. Mambu tracks all transactions and associates them to the clients' accounts where they occurred. ## Adjusting transactions You can adjust transactions on an account as long as the account is still open. :::warning Doing backdated adjustments on transactions will affect the overall performance. ::: Transactions are of two types: * Financial transactions, or transactions that involve an amount: * Loans: payment made, redraw repayment, withdrawal redraw, disbursement, card disbursement reversal, fee applied, fees due reduced, interest applied, interest due reduced, interest paid applied, prepaid interest applied, penalty applied, penalties due reduced, transfer, and write off. * Deposits: deposit, card withdrawal, fee applied, fee reduction, interest applied, loan fraction bought, loan fraction sold, loan funded, loan repaid, transfer, withdrawal, withholding tax, write off. * Non-financial transactions: transactions triggered by an event such as an interest rate change made to an active account, branch changed, fees locked, interest locked, penalty locked, tax rate changed, terms changed, overdraft limit changed, and seized amount. Only financial transactions can be adjusted by users who have the **Apply Loan Adjustments** (`APPLY_LOAN_ADJUSTMENTS`) or the **Apply Deposit Account Adjustments** (`APPLY_SAVINGS_ADJUSTMENTS`) permission. If you try to adjust a non-financial transaction, you will get an error, "Transaction type does not allow adjustment". You can adjust: * Transactions posted automatically: penalties, automatic fees, interest accrued. * Transactions posted manually: arbitrary and predefined fees, manual repayments. To adjust a transaction: 1. Open the account where the transaction was posted. 2. Go to the **Transactions** tab. 3. Find the transaction you want to adjust in the list and on the right hand side of the row, select **Actions** > **Adjust**. 4. Under **Adjustment Reason**, enter the reason for the adjustment. 5. Adjust the transaction. ![Actions button with Adjust option selected and Ajust Repayment pop-up](@site/static/img/support/transactions-and-interest--adjust-repayment-dialog.png) :::warning If you adjust a deposit and there’s a withdrawal after it, you can’t repost that withdrawal if the balance of the account goes below zero. ::: ## Adjusting transactions in bulk To adjust transactions in bulk, you need the **Bulk Loan Corrections** (`BULK_LOAN_CORRECTIONS`) or the **Bulk Deposit Corrections** (`BULK_DEPOSIT_CORRECTIONS`) permission, which gives you access to the **Adjust** button on all financial transactions. :::note The **Apply Loan Adjustments** and **Apply Deposit Account Adjustments** permissions are granted implicitly for the **Bulk Loan Corrections** and **Bulk Deposit Corrections** permissions. Therefore, if you have the **Bulk Loan Corrections** or **Bulk Deposit Corrections** permission, you will also be able to edit individual loan or deposit transactions even if that specific permission hasn't been granted to you. ::: When adjusting a transaction which has other transactions after it, Mambu will automatically adjust all the transactions until the adjusted one and then will repost them. Mambu captures the amount and entry date and will re-apply the amount on the initial entry date. For interest the amount might differ, but it will be recalculated according to the adjusted transaction. Mambu will also use the account's current branch and centre (if it has changed since the original transaction was logged). The custom field values from the original transaction will be moved to the new one. The adjustment transactions will be linked to the current user. --- # AML Suspense Accounting Flows URL: https://docs.mambu.com/docs/aml-suspense-accounting-flows/ ## Suspense Accounting AML Flow for an Incoming Payment
**Accepted** - The Beneficiary Account is credited with the amount specified in the payment ![AML flow using suspense accounting for an incoming payment which is accepted](@site/static/img/support/aml-suspense-acceted-flow-incoming-payment.png) --- **Rejected** - The Payment is returned and a Payment Return instruction (pacs.004.001.02) is issued by the Mambu Payment Gateway (MPG) ![AML flow using suspense accounting for an incoming payment which is rejected](@site/static/img/support/aml-suspense-rejected-incoming.png) --- **Suspended** - The Suspense Account is Credited with the amount specified in the payment ![AML flow using suspense accounting for an incoming payment which is suspended](@site/static/img/support/aml-suspense-suspended-flow-incoming-payment.png) --- **Accepted** when the payment was originally **Suspended** - The Suspense Account is Debited and the Beneficiary Account is Credited with the original amount ![AML flow using suspense accounting for an incoming payment which is accepted after having been suspended](@site/static/img/support/aml-suspense-accepted-incoming-originally-suspended.png) --- **Rejected** when the payment was originally **Suspended** - The Suspense Account is Debited and a Payment Return instruction (pacs.004.001.02) is sent out by the MPG ![AML flow using suspense accounting for an incoming payment which is rejected after having been suspended](@site/static/img/support/aml-suspense-rejected-incoming-originally-suspended.png) --- **Manual Redirect Internal** - transaction AML status is updated accordingly, the actual internal payment execution must be initiated through the standard Payment Initiation flow. ![AML flow using suspense accounting for an incoming payment which is manually redirected to an internal account after having been suspended](@site/static/img/support/aml-suspense-manual-redirect-internal-incoming-originally-suspended.png) --- **Manual Redirect External** - transaction AML status is updated accordingly, the actual external payment execution must be initiated through the standard Payment Initiation flow. ![AML flow using suspense accounting for an incoming payment which is manually redirected to an external account after having been suspended](@site/static/img/support/aml-suspense-manual-redirect-external-incoming-originally-suspended.png) --- ## Suspense Accounting AML Flow for an Outgoing Payment
**Accepted** - The Originator Account was already debited part of the standard outgoing payment clearing flow, and now a Credit Transfer Instruction (pacs.008.001.02) is issued by the MPG ![AML flow using suspense accounting for an outgoing payment which is accepted](@site/static/img/support/aml-suspense-accepted-outgoing.png) --- **Rejected** - The Payment is marked as failed and the funds are credited back to the Originator Account ![AML flow using suspense accounting for an outgoing payment which is rejected](@site/static/img/support/aml-suspense-rejected-outgoing.png) --- **Suspended** - The Originator Account was already debited part of the standard outgoing payment clearing flow, and now the Suspense Account is Credited with the original payment amount ![AML flow using suspense accounting for an outgoing payment which is suspended](@site/static/img/support/aml-suspense-suspended-flow-outgoing.png) --- **Accepted** when the payment was originally **Suspended** - The Suspense Account is Debited and a Credit Transfer Instruction (pacs.008.001.02) is issued by the MPG ![AML flow using suspense accounting for an outgoing payment which is accepted after having been suspended](@site/static/img/support/aml-suspense-accepted-putgoing-originally-suspended.png) --- **Rejected** when the payment was originally **Suspended** - The Suspense Account is Debited and the Originator Account is Credited with the original amount ![AML flow using suspense accounting for an outgoing payment which is rejected after having been suspended](@site/static/img/support/aml-suspense-rejected-outgoing-originally-suspended.png) --- **Manual Redirect Internal** - transaction AML status is updated accordingly, the actual internal payment execution must be initiated through the standard Payment Initiation flow. ![AML flow using suspense accounting for an outgoing payment which is manually redirected to an internal account after having been suspended](@site/static/img/support/aml-suspense-manual-redirect-internal-outgoing-originally-suspended.png) --- **Manual Redirect External** - transaction AML status is updated accordingly, the actual external payment execution must be initiated through the standard Payment Initiation flow. ![AML flow using suspense accounting for an outgoing payment which is manually redirected to an external account after having been suspended](@site/static/img/support/aml-suspense-manual-redirect-external-outgoing-originally-suspended.png) --- # Introduction & Setup URL: https://docs.mambu.com/docs/aml-suspense-accounting/ The AML Suspense Accounting feature allows Mambu customers to redirect the money of an incoming or outgoing transaction which requires in-depth AML verification to a predefined “Suspense Account”, while the external third party AML provider (AML TPP) analyses the payments details. If this feature is enabled, when the Mambu Payment Gateway (MPG) receives a `SUSPENDED` AML result (through the standard AML response endpoint), it will automatically redirect the funds towards the Suspense Account. When a definitive result is received, such as `ACCEPTED`, the MPG will move the funds from the Suspense Account to the beneficiary account, or execute the standard return flow in case of AML true positive response (`REJECTED` status). ## AML Suspense Account configuration The Suspense Account needs to be configured on the Mambu Core Banking System, following the description [here](/docs/payments-settings). A Suspense Account can be created for each BIC used inside the MPG (either configured as Bank BIC in the System Properties page, or assigned to a specific scheduler in the Schedulers page). After a Suspense Account has been created, it has to be configured on the MPG's System Properties page before it can be used by the MPG. After enabling AML Suspense Accounting, a new section will be available giving the possibility to set a Suspense Account for each BIC. All suspended incoming or outgoing payments which were initiated with a specific BIC will be redirected to the Suspense Account assigned to it. ![Manage AML Suspense Accounts](@site/static/img/support/aml_manage_suspense_accounts_per_bic.png) In this example, two separate BICs are configured in the MPG, and a Suspense Account ID is specified for each of them. At the same time, an External Account Representation can be configured for each bank account, in case the funds need to be redirected to an account other than the originator or beneficiary of the payment, either within the same Mambu tenant, or towards an external bank. In this case, the payment can be marked with one of two additional AML statuses: `MANUAL_REDIRECT_INTERNAL`, when the funds were redirected towards an account managed by the same Mambu tenant, or `MANUAL_REDIRECT_EXTERNAL` when the funds were redirected towards another bank. Both these statuses can be specified through the standard AML response endpoint. ## AML Suspense Accounting execution flows In the following section, both the standard and Suspense Accounting AML flows will be described in detail. --- # API Consumers URL: https://docs.mambu.com/docs/api-consumers/ API consumers are an abstraction similar to an OAuth client. The primary purpose of an API consumer is to generate API keys, which are used to authenticate API requests by including them in an `apiKey` header. Mambu currently supports two methods for authenticating API requests: * Basic authentication using user credentials, or * API keys, which are individual UUID tokens provided in an `apiKey` header. API consumers replace user accounts as the source of access credentials. :::note Basic authentication may only be used with the Mambu API. However, we recommend using API keys instead of basic authentication whenever possible - as it provides better flexibility and security. Audit Trail, Mambu Payments Gateway API, and Streaming API do not support basic authentication. You must use API consumers and API keys to access these APIs. ::: API keys inherit the scope of access settings from the API consumer that creates them. For more information, see [API consumer access settings and permissions](/docs/api-consumers#api-consumer-access-settings-and-permissions). It is up to you to determine the right policy governing who has access to API consumers, how and when API keys are generated and expire, when to rotate keys, and so forth. Depending on how you configure your system, multiple users may be able to create and access one or many API consumers with different degrees of access, and each API consumer may generate multiple keys. Once we have enabled API consumers for your account, you will no longer be able to add the `API` permission when creating a new user. However, you may edit any existing user to add the permission in **Administration** > **Access** > **Users**. Existing users with API access permissions may continue to use basic authentication. ## Managing API consumers API consumers are managed in two ways: * **Using the Mambu UI**. We will cover this process in this article, along with providing a general introduction that will be useful for anyone using or managing API consumers. * **Via the API consumers endpoint**. For more information on creating, using, and managing API consumers via API v2, see the [API Consumers](/api/api-v2/consumers/consumers/) section of our API Reference. :::note Some settings controlling API consumers may only be configured in the Mambu UI, and some default settings in the Mambu UI will override settings included in the body of requests, such as the API key expiration period for keys generated by rotation. ::: ### User permissions for managing API consumers The following permissions are required for a user to be able to perform the relevant management actions on API consumers either via the UI or API: * **View Api Consumers and Keys** (`VIEW_API_CONSUMERS_AND_KEYS`) * **Create Api Consumers and Keys** (`CREATE_API_CONSUMERS_AND_KEYS`) * **Edit Api Consumers and Keys** (`EDIT_API_CONSUMERS_AND_KEYS`) * **Delete Api Consumers and Keys** (`DELETE_API_CONSUMERS_AND_KEYS`) If these permissions are not assigned to a user, that user will not be able to see the **API Consumers** tab under **Administration** > **Access**. :::note User access permissions are only required for calls to the API consumers endpoint when using basic authentication. Anyone with a valid API key may make any request to the API, regardless of their user permissions, as long as the key was generated by an API consumer with the appropriate permission. For more information, see [API consumer access settings and permissions](#api-consumer-access-settings-and-permissions). ::: Once we have enabled API consumers for you, an **API Consumers** tab will appear under **Administration** > **Access**. You may generate and manage API consumers and keys in **Administration** > **Access** > **API consumers**. You may configure relevant settings in **Administration** > **Access** > **Preferences**. ![API consumers list](@site/static/img/support/View%20API%20consumers%281%29.png) ### Creating API consumers To create an API consumer in the Mambu UI: 1. On the main menu, go to **Administration** > **Access** > **API Consumers**. 2. Select **Add consumer**. 3. Enter all the necessary information in the **Create Api Consumer** dialog. For more information about access settings and permissions fields, see [API consumer access settings and permissions](#api-consumer-access-settings-and-permissions). 4. Select **Save Api Consumer**. ![Create API consumer dialog](@site/static/img/support/Create%20API%20consumer%20part%201%281%29.png) ### API consumer access settings and permissions When you create an API consumer, you must assign the relevant access settings. The API keys that the API consumer creates, will then inherit the access settings scope. The access settings determine which capabilities an API key may access and which actions it may authorize. They may be assigned either by assigning permissions directly to the API consumer, by assigning a role, or assigning a user type. For more information, see [Understanding Users, Roles, and Permissions](/docs/understanding-users-roles-and-permissions). The table shows some of the available capabilities Mambu offers and which permissions an API consumer must have to access them. | Capability | Permissions | Links for more information| |----------------------------| --- | --- | | Audit Trail | Manage Audit Trail (`MANAGE_AUDIT_TRAIL`) | [Audit Trail](/docs/audit-trail)| | Streaming API | Manage Events Streaming (`MANAGE_EVENTS_STREAMING`) |[Streaming API](/docs/streaming-api) | | Mambu Payments Gateway API | Manage Payments (`MANAGE_PAYMENTS`) | [Getting Started - Payments](/docs/payments-settings)| ### Deleting API consumers If you delete an API consumer, any API keys and secret keys the consumer created will be deleted and immediately invalidated as well. You cannot delete an API consumer after any of its keys has been used. The API consumer will have an activity logged, and it must be maintained for audit trail purposes. To delete an API consumer: 1. On the main menu, go to **Administration** > **Access** > **API Consumers**. 2. Find the API consumer in the list that you would like to delete and select **Actions** > **Delete**. 3. In the **Delete** dialog, select **Delete**. ![Delete dialog for deleting an API consumer](@site/static/img/support/developer--delete-api-consumer-confirmation.png) ## API keys The primary purpose of an API consumer is to generate API keys, which are used to authenticate API requests by including them in an `apiKey` header. API keys inherit the access settings scope from the API consumer that was used to create them. * One API consumer may generate multiple API keys, and they may be used concurrently. * You may optionally set an expiration time for any API key that you create. If you set an expiration time for your API key, the remaining lifetime of the key will be displayed next to the API key in the **Manage Keys** dialog in the Mambu UI. * Because API keys are used to authenticate access to your account, we recommend setting an expiration length for them, rather than creating keys that do not expire. * You may invalidate API keys by [deleting them in the Mambu UI or API](#deleting-api-keys), or by [rotating them](#api-key-rotation) using secret keys. :::note For security and compliance reasons, when you clone your production data to sandbox, API keys are not copied over. You must create new API keys for your newly cloned sandbox environment. For more information on cloning production data to your sandbox environment, see [Customer Service Portal - Cloning production to sandbox](/docs/customer-service-portal#cloning-production-to-sandbox). ::: ### Generating API keys When you generate an API key, it will be presented in clear text only once. After this, you may view the API key ID and a six character clear text prefix of the API key. Since you are not able to retrieve an API key in clear text after generation, you must store your API key in a secure location upon generation. Also, the six character API key prefix is not guaranteed to be unique. Therefore, you must base any identification process on the API key ID. ![Manage Keys option displayed in API consumer list](@site/static/img/support/Click%20Button%20Manage%20Keys.png) To generate an API key: 1. On the main menu, go to **Administration** > **Access** > **API Consumers**. 2. Find the API consumer in the list that you would like to make an API key for, select **Actions** > **Manage keys**. 3. In the **Manage Keys** dialog, select **Generate**. 4. In the **Generate New API Key** dialog, you can optionally choose whether you want to enter an expiration time to live (TTL) in seconds. 5. Select **Generate** to finish generating the key. 6. Store your API key in a secure location. ![Generate New API Key dialog](@site/static/img/support/developer--generate-new-api-key.png) ### Deleting API keys When you delete an API key from the Mambu UI, it is immediately invalidated. Note that the grace period for key rotation does not apply when keys are deleted. To delete an API key: 1. On the main menu, go to **Administration** > **Access** > **API Consumers**. 2. Find the API consumer in the list that you would like to make an API key for, select **Actions** > **Manage keys**. 3. Find the API key you want to delete in the list and select **Delete**. 4. In the dialog, select **Delete**. ![Manage Keys Dialog](@site/static/img/support/developer--manage-keys-dialog.png) ## API key rotation API key rotation allows you to invalidate specific API keys using a secret key for authentication. When a key is rotated, you will immediately receive a replacement API key and a new secret key in the response body. You may specify the expiration TTL for the replacement key in the rotation request. If you do not provide an expiration value, and no automatic expiration time is specified in the UI, then the replacement key will never expire. We generally recommend always setting an expiration value for better security. Note that if an automatic expiration time is configured in **Automatic Expiry of API consumer key** in the Mambu UI, that value will overwrite any expiration value you provide with your API call. For more information, see [Automatic API key expiration for rotated keys](/docs/api-consumers#automatic-api-key-expiration-for-rotated-keys). :::note Do not include an API key or basic authentication headers when making calls to rotate keys, or you will receive an invalid credentials error. Use the secret key only when authenticating rotation requests. ::: For more information about the API key rotation endpoint, see the [API Key Rotation](/api/api-v2/apikey_rotation/rotate-key) section of our API Reference. ### Secret keys Secret keys are generated by API consumers, and are used to authenticate API key rotation requests. They cannot be used to validate any other request. Unless a grace period is configured for key rotation, secret keys expire in 5 minutes, as this is our minimum TTL used in caching for performance purposes. Secret keys otherwise never expire. You may only have one active secret key per consumer at any one time. The key may not be invalidated, but it may be regenerated through the Mambu UI, which will invalidate any existing key. To generate a secret key in the Mambu UI: 1. On the main menu, go to **Administration** > **Access** > **API Consumers**. 2. Find the API consumer in the list that has the API key that you want to rotate and select **Actions** > **Manage keys**. 3. Select **Generate Secret Key**. 4. In the **Generate Secret Key** dialog, select **Generate**. 5. Copy the secret key and select **Close**. ![Generate Secret Key dialog with a secret key generated](@site/static/img/support/developer--generate-secret-key-modal.png) ### Key rotation grace period You may configure a grace period for key rotation in the Mambu UI. After a key is rotated, it will still be valid for the length of time specified by the grace period. The grace period applies to both API keys and secret keys. :::warning The default grace period for key rotation is 1800 seconds, or 30 minutes. Note that if you do not change this value, then all rotated keys will remain valid for this amount of time. ::: To set the key rotation grace period: 1. On the main menu, go to **Administration** > **Access** > **Preferences**. 2. Under **API Key Rotation Grace Period**, enter the amount of seconds you want the grace period to last. 3. Select **Save Changes**. ![Access preferences with API Key Rotation Grace Period and Automatic Expiry of API consumer key fields available.](@site/static/img/support/developer--access-preferences-security-settings.png) ### Automatic API key expiration for rotated keys You may configure an expiration value for all API keys generated during key rotation by setting an **Automatic Expiry of API Consumer Keys** value in the Mambu UI. This value will not affect keys created in the UI, or created using the `createApiKeyByConsumer` endpoint. If you set this value, it will override any specified value for key expiration when new keys are generated by key rotation through the API. If no value is provided in the **Automatic Expiry of API Consumer Keys** field of the Mambu UI, then rotated API keys will never expire by default. To set the **Automatic Expiry of API Consumer Keys** value for keys generated by key rotation: 1. On the main menu, go to **Administration** > **Access** > **Preferences**. 2. Select the **Automatic Expiry of API Consumer Keys** checkbox. 3. Enter the TTL for the key in seconds. 4. Select **Save Changes**. ## Key lifecycle The table summarizes our key lifecycle policy. | Key | Where created | Default expiration | Can override? | Default grace period | Can override? | | --- | --- | --- | --- | --- | --- | | API Key | API | never | yes | 1800 s | yes | | API Key | UI | never | yes | 1800 s | yes | | Secret Key | API | 5 mintes after use | no | 1800 s | yes | | Secret Key | UI | 5 mintes after use | no | 1800 s | yes | | API Key | rotation | never | yes | 1800 s | yes | | Secret Key | rotation | 5 mintes after use | no | 1800 s | yes | ## Blocking IP Adresses Mambu automatically blocks any IP address that issues a total of 10 requests from an API consumer using invalid credentials. This applies even if the IP has been whitelisted. The addresses will be blocked regardless of how much time elapses between calls. For more information on IP blocking and instructions on how to clear an address from being blocked, see the [IP Access Restrictions](/docs/access-preferences#ip-access-restrictions) section of our Access Preferences article. --- # API response and error codes URL: https://docs.mambu.com/docs/api-response-error-codes/ These response codes provide a more detailed description of any problems which may have occurred with an API call including incorrect parameters or actions which violate the business logic of the system, such as illegal state changes, invalid amounts or dates, and so forth. :::note The response codes listed below cover both Mambu API v1 and v2 ::: ## Generic Response Codes (1 - 60) |Response Code|Description| |---|---| | 0 `SUCCESS` | The request was successful | | 1 `INVALID_BASIC_AUTHORIZATION` | The application ID or application key are not configured properly | | 2 `INVALID_CREDENTIALS` | The username and password provided was invalid | | 4 `INVALID_PARAMETERS` | A required parameter for this API operation is invalid or has not been provided | | 5 `METHOD_NOT_IMPLEMENTED` | The HTTP method for this operation is not implemented.
For example, the API operation has only been defined for HTTP GET request and an HTTP Post request was called | | 6 `INTERNAL_ERROR` | An unknown Mambu exception was thrown | | 7 `API_NOT_AUTHORIZED` | Caller is not authorized to make user of the API service. Check your Keys in the API Portal | | 8 `USER_TRANSACTION_LIMIT_EXCEEDED` | The API was not properly configured for monitoring | | 9 `API_CONFIGURATION_ERROR` | The API account is not authorized to make transactions (deposits, disbursals, etc) of this size | | 10 `INVALID_TENANT_ID` | No tenant to answer this API call was found | | 11 `INVALID_PAGINATION_OFFSET_VALUE` | The pagination offset value was not a proper Integer value | | 12 `OUT_OF_BOUNDS_PAGINATION_OFFSET_VALUE` | The pagination offset value was smaller than 0 | | 13 `INVALID_PAGINATION_LIMIT_VALUE` | The pagination limit value was not a proper Integer value | | 14 `OUT_OF_BOUNDS_PAGINATION_LIMIT_VALUE` | The pagination limit value was smaller than 0 or bigger than its upper limit | | 15 `INVALID_PERMISSIONS` | The user is missing permissions to complete an operation | | 16 `INVALID_IP_ADDRESS` | This IP address is not authorized for API access | | 17 `INACTIVE_USER` | User account is not active and cannot be used | | 18 `NO_API_ACCESS` | User doesn't have API access permissions | | 19 `FEATURE_DISABLED` | | | 20 `MAX_FILE_SIZE_EXCEEDED` | The file size is larger than 52428800 bytes (50MB) | | 21 `MAX_FILENAME_LENGTH_EXCEEDED` | The file name size, including the path, is larger than 256 characters | | 22 `UNSUPPORTED_CHARACTER_ENCODING` | The file has an unsupported character encoding. The character encoding must be supported by java | | 23 `INVALID_API_PROTOCOL` | The request was done through an invalid protocol. Mambu API's always use HTTPS | | 24 `EXCESSIVE_INVALID_REQUESTS` | The account is temporarily disabled due to excessive incorrect logins and must be unlocked by an administrator. For instructions on how to re-enable the account, please see: [Managing Users and Permissions](/docs/deactivating-reactivating-and-deleting-user-accounts#deactivating-the-mambu-support-user)| | 25 `INCONSISTENT_IDENTIFIER_WITH_JSON` | When the identifier does not match with the encoded key or ID from the JSON object | | 26 `INVALID_JSON_SYNTAX` | When the JSON parsing fails. Some cases that can cause this error: invalid JSON syntax, invalid enum values, invalid data type for value, etc | | 27 `PARAMETER_NOT_ALLOWED` | A parameter in the API call is not allowed in this context | | 28 `START_DATE_AFTER_END_DATE` | When the API parameter start date is after API parameter end date | | 29 `OBJECT_NOT_FOUND` | When no object is found for the given identifier | | 30 `MISSING_ENTITY_JSON` | When the required entity JSON object is missing | | 31 `MISSING_REQUIRED_PARAMETER` | A required parameter is missing from input | | 33 `UNSUPPORTED_PAGINATION` | | | 34 `NOT_AVAILABLE_FOR_API_V1` | | | 60 `BLOCKING_OPERATION_IN_PROGRESS` | When operation cannot be performed due to another pending operation that locked shared resources | | 61 `QUERY_TIMEOUT_EXCEPTION` | | ## Loan Accounts (97 - 199) |Response Code|Description| |---|---| | 97 `NON_REVERSIBLE_WRITE_OFF` | When the loan account cannot reverse the write-off transaction | | 98 `NON_WEEKLY_LOAN_REPAYMENTS` | When the entity, which is reassigned to a centre with a different centre meeting day, has a loan account with non-weekly repayments | | 99 `INCONSISTENT_LINKED_ACCOUNT` | When the linked account is not consistent with the current loan | | 100 `INVALID_LOAN_ACCOUNT_ID` | The loan account specified does not exist | | 101 `INVALID_AMOUNT` | The amount parameter is 0, not an integer, or otherwise invalid | | 102 `INVALID_DATE` | The date parameter is not properly formatted. Must follow the ISO standard such as: yyyy-MM-dd | | 103 `INVALID_NOTES` | The notes parameter is not valid | | 104 `INVALID_TRANSACTION_TYPE_ID` | When the provided ID or key for the transaction channel is invalid | | 105 `INVALID_ACCOUNT_STATE` | One of the accounts involved in the call is in an invalid state. This can occur for example when posting transactions to or from accounts in non-active statuses or when posting transactions that trigger bulk reversals to or from another account in non-active status | | 106 `INVALID_FEE` | The account is in an invalid state for the given operation | | 107 `LOAN_PRODUCT_MISMATCH` | The account parameters don't match the loan product parameters | | 108 `INVALID_FIELD_FOR_TRANSACTION_TYPE` | When a field is given as a parameter, but the transaction type does not allow it | | 109 `INACTIVE_TRANSACTION_TYPE` | When trying to make a transaction using an inactive transaction channel | | 110 `EXCESS_REPAYMENT_ERROR` | The repayment amount exceed the loan balance | | 111 `TRANSACTION_LOGGED_AFTER_NOT_DISBURSED_TRANCHE` | When a transaction is logged after a non disbursed tranche | | 112 `UNDEFINED_ACCOUNT_FOR_FINANCIAL_RESOURCE_ERROR` | The account specified for the financial resource is not defined | | 113 `INVALID_ACCOUNT_FOR_JOURNAL_ENTRY_ERROR` | The account specified for the journal entry is invalid | | 114 `MISSING_LOAN_ID` | The loan account identifier has not been specified | | 115 `MAXIMUM_EXPOSURE_EXCEEDED` | when the maximum exposure is exceeded for a client | | 116 `INVALID_STATE_TRANSITION` | An invalid loan account state transition | | 117 `NUMBER_OF_LOANS_EXCEED` | When the number of loans for an organization is exceeded | | 118 `INVALID_FIRST_REPAYMENT_DUE_DATE` | When the first repayment due date it's not valid | | 119 `INVALID_REPAYMENT_DUE_DAY` | When repayment date is not the same as assigned centre's meeting day | | 120 `INVALID_INTEREST_RATE` | An invalid interest rate is being used as a parameter | | 121 `INVALID_INSTALLMENTS` | An invalid number of installments rate is being used as a parameter | | 122 `MISSING_LINKED_ACCOUNT` | | | 123 `PREPAYMENT_NOT_ALLOWED_ERROR` | When a pre-payment it's trying to be posted and it's not allowed at loan product level | | 124 `REPAYMENT_DATE_IN_THE_FUTURE_ERROR` | When the specified repayment date it's set in future | | 125 `INVALID_DISBURSEMENT_DATE` | When the specified disbursement date is invalid | | 126 `INVALID_ACCOUNT_STATE_FOR_RESCHEDULE` | When the account's state doesn't allow a reschedule | | 127 `ORIGINAL_ACCOUNT_HAS_FUNDS` | When trying to reschedule a loan which has funds | | 128 `INVALID_ACCOUNT_STATE_FOR_REPAYMENTS` | When the account's state doesn't allow a repayment to be entered | | 129 `DISBURSEMENT_FEES_EXCEED_LOAN_AMOUNT` | When the total of disbursement fees exceeds the loan amount | | 130 `INTEREST_CANNOT_BE_APPLIED` | When the interest cannot be applied in the account, because either the account it's not active, either there's no interest to be applied, either it's a flat fixed account and the interest has already been applied | | 131 `ENTRY_DATE_BEFORE_OTHER_TRANSACTIONS` | Another balance transaction has already been logged before this entry date and must be undone for this one to be backdated | | 132 `INCONSISTENT_SCHEDULE_PRINCIPAL_DUE_WITH_LOAN_AMOUNT` | When the total principal expected from the repayment schedule doesn't match the loan amount (no rounding was selected) | | 133 `ACCOUNT_HAS_NO_ACCRUED_INTEREST` | When trying to apply the accrued interest and the account has no accrued interest | | 134 `INTEREST_ALREADY_APPLIED_ON_DISBURSEMENT_ACCOUNT` | When trying to apply interest for an account with Interest application method 'On Disbursement'. In this case the interest was already applied | | 135 `INCONSISTENT_WITH_FIXED_DAYS_OF_MONTH` | When first repayment date doesn't match the loan product Fixed days of month Payment interval method settings | | 136 `NEGATIVE_PRINCIPAL_FOR_INSTALLMENT` | When after the calculation of a repayments schedule, one of its repayments contains a negative principal | | 137 `INVALID_TAX_RATE` | When the tax rate for an account that has taxes enabled does not exist | | 138 `INSUFFICIENT_GUARANTEES` | When the loan account doesn't have the required guaranties percentage | | 139 `MISSING_REPAYMENT_PERIOD_COUNT` | When the repayment period count is missing for a loan with a repayment method set to Interval | | 140 `MISSING_REPAYMENT_INTERVAL` | When the repayment interval is missing for a loan with repayment method set to Interval | | 141 `FUTURE_PAYMENT_NOT_ALLOWED_ERROR` | When a future payment is trying to be posted and it's not allowed at loan product level | | 142 `DISBURSEMENT_WITH_ZERO_LOAN_AMOUNT_NOT_ALLOWED` | when a loan have zero loan amount and no cAPItalized fees, it can't be disbursed | | 143 `ACCOUNT_ALREADY_LOCKED` | When trying to lock an account that is already in a LOCK state | | 144 `ACCOUNT_ALREADY_UNLOCKED` | When trying to unlock an account that is not in a LOCK state | | 145 `LOAN_AMOUNT_DECIMALS_NOT_ALLOWED_WITH_ROUNDING` | When trying to give an amount to a loan account that has rounding enabled | | 146 `RESCHEDULED_LOAN` | When the deletion is not allowed on the account, because it has been rescheduled | | 147 `REFINANCED_LOAN` | When the deletion is not allowed on the account, because it has been refinanced | | 148 `TRANSACTION_IDENTIFIER_ALREADY_USED` | When the posted transaction identifier has already been used; it already exists in the data store | | 149 `INVALID_ID` | When identifier for a posted transaction is only spaces or empty space | | 150 `FAILED_TO_GENERATE_IDENTIFIER` | When the account identifier failed to be generated due to internal concurrency issue | | 151 `INCONSISTENT_ACCOUNT_ID_WITH_ACCOUNT_HOLDER_TYPE` | when trying to fetch an account for a client using a group ID or vice-versa | | 152 `INVALID_ASSET_NAME` | When trying to store an account with guarantees of type asset and asset name is null | | 153 `GUARANTOR_KEY_NOT_ALLOWED` | When trying to store an account with guarantees of type asset, guarantor key should be empty | | 154 `GUARANTOR_SAVINGS_KEY_NOT_ALLOWED` | When trying to store an account with guarantees of type asset, deposit account key should be empty | | 155 `INVALID_GUARANTOR_KEY` | When trying to store an account with guarantees of type guarantor and guarantor key is empty | | 156 `INVALID_SAVINGS_ACCOUNT_KEY` | When trying to store an account with guarantees of type guarantor and deposit account key is empty | | 157 `INVALID_GUARANTOR_STATE` | When trying to store an account with guarantees of type guarantor and guarantor's state is not ACTIVE or INACTIVE | | 158 `DUPLICATED_GUARANTOR_WITHOUT_SAVINGS_ACCOUNT` | When trying to store an account with guarantees the guarantor can guaranty only once without an account | | 159 `DUPLICATED_SAVINGS_ACCOUNT` | When trying to store an account with guarantees the guarantor cannot guaranty with the same account twice | | 160 `INSUFFICIENT_SAVINGS_ACCOUNT_BALANCE` | When the amount guaranteed in a given guaranty is not covered by the deposit account's balance (if one existing) | | 161 `INVALID_SAVINGS_ACCOUNT_STATE` | When a deposit account used for a guarantee is not in ACTIVE, ACTIVE_IN_ARREARS, MATURED or LOCKED state | | 162 `DUPLICATED_ASSET` | When a guarantor guarantees twice with the same asset | | 163 `GUARANTOR_ASSET_NAME_NOT_ALLOWED` | When trying to store an account with guarantees of type guarantor, asset name should be empty | | 164 `TRANSACTION_NOT_FOUND` | When trying to undo the disbursement of a not found transaction | | 165 `INVALID_TRANSACTION_TYPE` | When trying to undo the disbursement of a transaction and its type is invalid | | 166 `UNREVERSED_TRANSACTION_LOGGED_AFTER_CURRENT_ONE` | When trying to post a transaction but there has already been a different transaction posted after it, which cannot be reversed by bulk correction | | 167 `INVALID_GUARANTOR_PERMISSION` | When trying to store a guarantee for a guarantor that does not have permissions to guarantee | | 168 `INVALID_CLIENT_ROLE_PERMISSION_FOR_OPENING_ACCOUNTS` | When trying to create a loan account for a client that does not have permissions for opening accounts. The permission can be granted from Client Type from administration | | 169 `MISSING_PENALTY_RATE` | When the product requires penalties but the account doesn't have a penalty rate specified (or the product doesn't have a default penalty rate) | | 170 `INVALID_REPAYMENT_NUMBER` | When the specified repayment number can't be found in the schedule | | 171 `MISSING_REPAYMENT_NUMBER` | When the repayment number is mandatory but wasn't specified | | 172 `INVALID_REPAYMENT_STATE` | When the state if the given repayment is not valid for the action | | 173 `CENTRE_MEETING_DAY_IN_NON_WORKING_DAY` | When a centre meeting day is set in a non-working day and the due date of the repayment has to be moved | | 174 `ARBITRARY_FEE_NOT_ALLOWED` | When an arbitrary fee is posted, but the product settings does not allow it | | 175 `INVALID_REPAYMENT_ID` | When the repayment posted does not belong to the account | | 176 `ACCOUNT_BALANCE_OUTSIDE_CONSTRAINTS` | When the account balance after applying the updates (principal balance, interest balance, etc) is negative or greater than the original balance | | 177 `EDITING_DATE_NOT_IN_CENTER_MEETING_DAY` | When editing a schedule for a loan account which has center meeting day, and the new edited value is not on the same day of week | | 178 `EDITING_DUE_DATES_NOT_ALLOWED` | When the product has interest application method ON_REPAYMENT and the repayment was fully paid or partially paid or the repayment had interest already applied, the due date of that repayment cannot be modified | | 179 `EDITING_REPAYMENTS_NOT_ALLOWED` | When the loan product does not allow editing the repayment schedule | | 180 `INTEREST_BALANCE_CANT_BE_EDITED_AT_SPECIFIED_DATE` | When the user can't edit the interest from a specific repayment cannot be modified. For example when INTEREST DUE REDUCED is reversed and the user could reapply it on some other repayment | | 181 `INVALID_DUE_DATE` | When a due date of the schedule is not valid. For example: the due date of a repayment is before the due date of the previous repayment | | 182 `NEGATIVE_BALANCE` | When a balance (principal balance, interest balance, etc) for a repayment is negative | | 183 `NON_POSITIVE_TOTAL_BALANCE` | When the total balance for a repayment is not strictly positive | | 184 `PARAMS_INCONSISTENT_WITH_PRODUCT_RULES` | When the parameter from API call is inconsistent with product info (\>max, \
Please note that obfuscated PDF files will be rejected, since we cannot scan them for malware | | 975 `INVALID_FILENAME` | When the file name is invalid (for example, when it contains invalid characters, such as "&") | | 976 `NO_PROFILE_PICTURE_SET` | When the profile picture is not set on the client account | | 977 `NO_PROFILE_SIGNATURE_SET` | When the profile signature is not set on the client account | | 978 `HAS_DOCUMENT_ATTACHED` | When trying to delete an entity that has a document attached | | 979 `UNSUPPORTED_IMAGE_TYPE` | When the profile picture format is not supported | | 980 `INVALID_TASK_ID` | When the given ID for a task is null or not set | | 981 `INVALID_TASK_STATE_AND_COMPLETION_DATE` | When the task is in COMPLETED state without completion date or in OPEN state with completion date | | 982 `INVALID_TASK_FIELD_CHANGE` | When the user of the API tries to alter the ID of the task | | 983 `INVALID_TASK_STATUS` | When the task status supplied by the user is not a valid one (OVERDUE, COMPLETED, OPEN) | | 984 `INVALID_TASK_TITLE_LENGTH` | When the task title exceeds the maximum length | | 985 `HAS_TASK_ATTACHED` | When trying to delete an entity that has a task attached | | 986 `EDITING_VIEW_TYPE_NOT_ALLOWED` | When attempting to edit the type of a view, this being an illegal change | | 987 `INVALID_CUSTOM_FIELD_SET_ID` | Invalid custom field set key or ID | | 988 `TRANSACTION_LINKED_TO_A_REPAYMENT` | When a payment due fee applied on due dates linked to a repayment transaction is trying to be reversed | | 989 `ANTIVIRUS_NOT_AVAILABLE` | | | 992 `CONCURRENT_UPDATE` | When the same data is updated by two concurrent requests, the second request is rejected in order to ensure data consistency. | ## Activities (1000 - 1049) |Response Code|Description| |---|---| | 1000 `MISSING_FROM_DATE` | When getting activities and the from date is missing | | 1001 `MISSING_TO_DATE` | When getting activities and the from date is missing | | 1002 `MAXIMUM_ONE_FILTER_ALLOWED` | When getting activities and more than one filter specified (such as clientID and branchID altogether) | ## Tills (1100 - 1149) |Response Code|Description| |---|---| | 1100 `TILL_BALANCE_OUTSIDE_CONSTRAINTS` | When the till balance goes outside the minimum / maximum constraints that are defined while opening a new till | | 1101 `TRANSACTION_IS_NOT_WITHIN_CHANNEL_CONSTRAINTS` | When the amount, type or product, etc. associated with the transaction are not within the constraints defined at transaction channel level | ## Addresses (1150 - 1199) |Response Code|Description| |---|---| | 1150 `INVALID_ADDRESS` | When the address does not contain correct data (for example, line1 is too long)| | 1151 `CLIENT_ROLE_DOES_NOT_ALLOW_ADDRESS` | The default address fields are disabled for the client type. The default address can be enabled from **Administration > General > Client Types**| | 1152 `ADDRESS_CHANGE_NOT_ALLOWED` | For clients/groups when at one point the client role allowed address but the new client role does not allow any. Cannot be changed if the client role does not allow addresses/ | | 1153 `INVALID_ADDRESS_LINE1` | Must be less than 256 characters. | | 1154 `INVALID_ADDRESS_LINE2` | Must be less than 256 characters. | | 1155 `INVALID_CITY`| | | 1156 `INVALID_REGION`| | | 1157 `INVALID_POSTCODE` | | | 1158 `INVALID_COUNTRY`| | ## Data Import (1200 - 1249) |Response Code|Description| |---|---| | 1200 `DATA_IMPORT_IN_PROGRESS` | When an illegal operation is performed during a data import in progress| | 1201 `DATABASE_BACKUP_IN_PROGRESS` | When triggering a database backup but one is already in progress | | 1202 `DATABASE_BACKUP_NOT_FOUND` | When downloading a backup but there is no backup file | | 1203 `CLIENT_IN_MIGRATION` | When trying to delete a client that is pending migration process | | 1204 `INVALID_NUMBER_OF_SHEETS` | When the number of sheets for an imported document is not correct | | 1205 `UNDEFINED_SHEET` | When the imported document contains an undefined sheet or requires a sheet | | 1206 `WRONG_SHEET_POSITION` | When the order of the sheets in the imported document is not correct | | 1207 `INVALID_NUMBER_OF_COLUMNS_FOR_SHEET` | When the number of columns for a sheet part of the imported document is not correct. | 1208 `UNDEFINED_COLUMN` | When the imported document contains an undefined column in one of its sheets or requires a column. | 1209 `WRONG_COLUMN_POSITION` | When the assignment constraints are not respected (default value when nothing specific can be extracted). ## Assignment (1250- 1299) |Response Code|Description| |---|---| | 1250 `INVALID_ASSIGNMENT` | When trying to delete a client that is pending migration process | ## Index and Tax Rate (1300 - 1349) |Response Code|Description| |---|---| | 1300 `INVALID_INDEX_RATE_SOURCE_ID` | The key specified is not a valid index rate encoded key | | 1301 `START_DATE_BEFORE_LAST_INDEX_REVIEWD_DATE` | The start date is before the last index review date | | 1302 `INVALID_START_DATE` | The start date is not unique within the same source | | 1303 `NO_INDEX_RATE_AVAILABLE` | When there is no index rate available at the specified date | | 1304 `NO_TAX_RATE_AVAILABLE` | When there is no tax rate available at the specified date | | 1305 `INVALID_INDEX_RATE_SOURCE` | | | 1306 `INDEX_RATE_SOURCE_IN_USE` | | | 1307 `NON_TAXABLE_FEE_NOT_ALLOWED` | | | 1308 `INVALID_INDEX_RATE_ID` | | | 1309 `DUPLICATE_INDEX_RATE_ID` | | | 1310 `DUPLICATE_INDEX_RATE_SOURCE_ID` | | ## Group Key (1350 - 1399) |Response Code|Description| |---|---| | 1350 `INCONSISTENT_GROUP_MEMBER_PARENT_KEY` | The group member parent key is not the same with the group encoded key | | 1351 `INCONSISTENT_GROUP_MEMBER_ENCODED_KEY` | The group member encoded key is not contained in the stored group members | | 1352 `INCONSISTENT_GROUP_ROLE_PARENT_KEY` | The group role parent key is not the same with the group encoded key | | 1353 `INCONSISTENT_GROUP_ROLE_ENCODED_KEY` | The group role encoded key is not contained in the stored group roles | ## Lines of Credit (1400 - 1449) |Response Code|Description| |---|---| | 1400 `PRODUCT_LINE_OF_CREDIT_AFFILIATION_CONSTRAINT_MISMATCH` | When the product requires a line of credit and the account is not part of a line of credit OR the product doesn't allow a line of credit, but the account has a line of credit set | | 1401 `DISBURSEMENT_DATE_BEFORE_LINE_OF_CREDIT_START_DATE` | When the loan disbursement (or expected disbursement) date is before the line of credit start date | | 1402 `MATURITY_DATE_AFTER_LINE_OF_CREDIT_END_DATE` | When the loan last repayment date is after the line of credit expiration date | | 1403 `LINE_OF_CREDIT_AMOUNT_EXCEEDED` | When the maximum line of credit amount would be exceeded if the account joined the line of credit | | 1404 `LINE_OF_CREDIT_REQUIRED_EXCEPTION` | The product requires the account to be part of a credit arrangement| | 1405 `OVERDRAFT_EXPIRY_DATE_AFTER_LINE_OF_CREDIT_END_DATE` | The overdraft expiry date cannot be after the line of credit end date | | 1406 `CANNOT_CREATE_ACCOUNT_WITH_LINE_OF_CREDIT` | When a loan or deposit account is created with a line of credit key set in the JSON | | 1407 `LINE_OF_CREDIT_REQUIRES_OVERDRAFT_MAX_LIMIT` | The overdraft maximum limit is required because the account is part of the line of credit and in a consuming state | | 1408 `LINE_OF_CREDIT_REQUIRES_OVERDRAFT_EXPIRY_DATE` | The overdraft expiry date is required because the account is part of a Line of Credit and in a consuming state | | 1409 `INVALID_LINE_OF_CREDIT_ID` | The ID or the encoded key used for getting a line of credit is invalid | | 1410 `ACCOUNT_ALREADY_ON_LINE_OF_CREDIT` | When trying to add an account to a line of credit, but the account already has a line of credit defined | | 1411 `INCONSISTENT_LINE_OF_CREDIT_CLIENT_WITH_ACCOUNT_OWNER` | When the key of the line of credit is not the same as the holder key of the account | | 1412 `ACCOUNT_IS_NOT_PART_OF_LINE_OF_CREDIT` | When trying to delete an account but it is not part of the line of credit mentioned in the URL | | 1413 `INVALID_LINE_OF_CREDIT_STATE` | When trying to add accounts on a line of credit but the the state of the line is invalid | | 1414 `HAS_LINE_OF_CREDIT` | When trying to remove item that has line of credit | | 1415 `LINE_OF_CREDIT_ID_ALREDY_IN_USE` | When when trying to store a line of credit with an ID that is already taken | | 1416 `EXPIRE_DATE_BEFORE_START_DATE` | When trying to store a line of credit with an expiration date before the start date | | 1417 `INVALID_CLIENT_ROLE_PERMISSION_FOR_OPENING_LINES_OF_CREDIT` | When trying to store a line of credit, but the client type does not allow opening line of credits | | 1418 `MISSING_LINE_OF_CREDIT_START_DATE` | When trying to store a line of credit with a missing start date | | 1419 `MISSING_LINE_OF_CREDIT_EXPIRE_DATE` | When trying to store a line of credit with a missing expire date | | 1420 `MISSING_LINE_OF_CREDIT_AMOUNT` | When trying to store a line of credit with a missing amount | | 1421 `LINE_OF_CREDIT_AMOUNT_NOT_STRICTLY_POSITIVE` | When trying to store a line of credit with an amount that is not strictly positive | ## Account Holder (1450 - 1499) |Response Code|Description| |---|---| | 1489 `INVALID_ACCOUNT_HOLDER_ID` | | | 1490 `MISSING_ACCOUNT_HOLDER_KEY` | When trying to store an entity and the account holder key is not defined | | 1491 `MISSING_ACCOUNT_HOLDER_TYPE` | When trying to store an entity and the account holder type is not defined | | 1492 `ACCOUNT_HOLDER_NOT_FOUND` | When trying to store an entity and the account holder is not found in system | | 1499 `INVALID_ACCOUNT_HOLDER_STATE` | The account holder is in an invalid state for the given operation | ## Organization (1500 - 1599) |Response Code|Description| |---|---| | 1500 `NO_ORGANIZATION_ICON` | When trying to fetch organization branding icon and there is no picture set for this case | | 1501 `NO_ORGANIZATION_LOGO` | When trying to fetch organization branding logo and there is no picture set for this case | ## POST Comment (1600 - 1699) |Response Code|Description| |---|---| | 1600 `MISSING_TEXT` | The required text for the object is missing | | 1601 `MAX_TEXT_LENGTH_EXCEEDED` | The maximum allowed size for the text in the parameter was reached | ## Revolving Credit (1900 - 1999) |Response Code|Description| |---|---| | 1901 `NUM_INSTALLMENTS_NOT_AVAILABLE_FOR_REVOLVING_CREDIT` | When `repaymentInstallments` is specified but not available for revolving credit | | 1902 `PRINCIPAL_PAYMENT_INCONSISTENT_WITH_PRODUCT` | When principal payment settings from the account are inconsistent with the product | | 1903 `SCHEDULE_PREVIEW_NOT_AVAILABLE_FOR_REVOLVING_CREDIT` | When revolving credit account doesn't have a schedule | | 1904 `AMOUNT_MORE_THAN_CURRENT_AVAILABLE_AMOUNT` | When the disbursement amount is greater than the approved loan amount | | 1905 `INCONSISTENT_WITH_CENTRE_MEETING_DAY` | When the custom schedule due dates are not in the centre meeting day | | 1906 `FIELD_IS_NOT_EDITABLE` | When the custom schedule fields cannot be adjusted | | 1907 `RESCHEDULED_REPAYMENT_BEFORE_DISBURSEMENT_DATE` | When the first repayment date was moved to before the disbursement date because of a non-working day | ## 2000 - 2049 |Response Code|Description| |---|---| | 2001 `FIELD_NOT_ALLOWED` | The client provided a field that is not allowed | | 2002 `OPERATION_NOT_ALLOWED_ON_FIELD` | Client provided a patch operation that is restricted for that field | | 2018 `INVALID_FUND_ENCODED_KEY` | When trying to post a loan account with fund which contains invalid guarantor key | | 2019 `INVESTORS_TOTAL_AMOUNT_MORE_THAN_LOAN_AMOUNT` | When total funds amount is more than the loan account amount | | 2020 `INVALID_FUND_ID` | When the ID or the key used for an investor fund action is invalid | | 2021 `INACTIVE_FUND_ID` | When an action is performed on an inactive fund | ## Sell funding source investment (2050 - 2099) |Response Code|Description| |---|---| | 2050 `INVALID_FUNDED_ACCOUNT_STATE` | Sell operation is done for a funded account in an invalid state (for example, the loan `ispending` or `closed`) | | 2051 `FUND_SELL_WITH_NO_PURCHASES` | When sell action is performed with no purchases | | 2052 `FUND_OVERSELL` | Sell operation was attempted for an amount larger than the sold loan fraction | | 2053 `INVALID_SELLER_FUND_AMOUNT` | Seller's fund amount is not positive | | 2054 `INVALID_SELLER_FUND_STATE` | Seller's fund state is not active | | 2055 `INVALID_SELLER_FUNDING_ACCOUNT` | Seller's funding account is not valid | | 2056 `INVALID_INVESTMENT_PERCENTAGES_FOR_AMOUNTS` | Percentages determined by amounts are not valid | | 2057 `FUND_SELF_SELL` | The fund buyer deposit account cannot be the same as the fund to sell owner deposit account | | 2061 `INVALID_BUYER_FUNDING_ACCOUNT` | Buyer's funding account key doesn't correspond to a proper funding deposit account owned by buyer | | 2062 `DUPLICATE_BUYER_FUNDING_ACCOUNT` | Buyer's funding account key is found more than once in the list of buyers | | 2063 `INVALID_BUYER_FUND_AMOUNT` | Buyer's bought amount is invalid: negative, zero, or not a number | | 2064 `INVALID_FUND_PURCHASE_PRICE` | Buy price is not the same as the buyer's bought amount | | 2065 `INSUFFICIENT_BUYER_FUNDING_ACCOUNT_FUNDS` | Buyer's funding account key doesn't have sufficient funds for buy action | | 2099 `INVALID_FILTER_VALUES` | Values are invalid for the type of the data field specified | ## 2100 |Response Code|Description| |---|---| | 2100 `INVALID_FILTER_SELECTION` | When the value of filter selection is not a valid data field or custom field key when searching on the fly | | 2101 `INVALID_FILTER_ELEMENT` | When the value of filter element is not valid or supported and is not applicable for the type of the data field | | 2102 `INVALID_FILTER_VALUE` | When invalid value for the type of the data field | | 2103 `INVALID_FILTER_SECOND_VALUE` | When invalid second value - second value not provided when using BETWEEN filter element or provided but not for a between filter | | 2104 `TOO_MANY_FILTERS_PROVIDED` | When more filters are provided than the maximum supported number | | 2105 `INVALID_FILTER_DATA_ITEM_TYPE` | When the value of dataItemType property is not recognized (not a valid value) | | 2106 `INSUFFICIENT_FUNDS_ACCOUNT_BALANCE` | When there is not enough deposit balance to be used as fund | | 2107 `INSUFFICIENT_FUNDS_TOTAL_AMOUNT` | When the the total amount of the funds is not enough | | 2108 `FUNDS_NOT_ALLOWED` | When trying to post a loan account with funds, but the product don't accept investors | | 2109 `FUNDING_AMOUNT_MUST_BE_STRICTLY_POSITIVE` | When trying to post a loan account with fund which contains negative or zero amount | | 2110 `FUNDER_INTEREST_COMMISSION_CONSTRAINTS_VALIDATION` | When trying to post a funding source with interest commission outside of boundaries | | 2111 `MISSING_FUNDER_INTEREST_COMMISSION` | When trying to post a funding source with missing interest commission for a fixed interest commission product type | | 2112 `LOAN_ACCOUNT_NOT_FUNDED_BY_SAVINGS_ACCOUNT` | When the loan account should be funded by an investor's deposit account, but it is not | | 2113 `INVALID_INTEREST_RATE_AGAINST_INTEREST_COMMISSION` | When trying to post a loan account with funds and the account interest rate is less than the fund interest commission | | 2114 `INVALID_SAVINGS_ACCOUNT_TYPE_FOR_FUNDING` | When trying to post a loan account with funds and the deposit account for funding is not an investor account | | 2115 `DUPLICATED_SAVINGS_ACCOUNT_FOR_FUNDING` | When trying to post a loan account with investor fund and investors have the same deposit account key | | 2116 `INVALID_FIXED_DAYS_OF_MONTH` | When trying to post a loan account with invalid fixed days of month, like duplicated days or day number greater than 31 | | 2117 `INVALID_SORTING_COLUMN` | When trying to post a search using on the fly search and the given sorting column is null, empty or invalid | | 2118 `COLUMN_NOT_SORTABLE` | When trying to post a search using on the fly search and the column is not sortable (DataField.FilteringCapabilities = FilteringCapabilities.UNFILTERABLE) | | 2119 `INVALID_SORTING_ORDER` | When trying to post a search using on the fly search and the given sorting order is null, empty or invalid (not in SortingOrder enum) | | 2120 `ACCOUNT_TYPE_DOES_NOT_ALLOW_FIELD` | When trying to change a field for an account that does not allow that field | | 2121 `INVALID_GUARANTY_ENCODED_KEY` | When trying to edit the guaranty of a loan account and an invalid guaranty key is encountered | | 2122 `INVALID_GUARANTY_TYPE` | When trying to edit the type of a guaranty (guarantor/asset/investor) with an invalid value | | 2123 `INVALID_GUARANTOR_TYPE` | When trying to edit the type of a guarantor (client/group) with an invalid value | | 2124 `GUARANTY_KEY_TYPE_MISMATCH` | When the guaranty key is not of the mentioned type | | 2125 `LOAN_ACCOUNT_NOT_FUNDED_BY_DEPOSIT_ACCOUNT` | When calling GET for funded loan accounts, the error means that the loan account you are trying to get is not funded by a deposit account | ## 2200 |Response Code|Description| |---|---| | 2200 `INVALID_TEMPLATE_ID` | When the template ID provided is not valid | | 2201 `INVALID_TEMPLATE_TYPE` | When the type of the template provided to be processed through API doesn't match with the context | | 2202 `MISSING_FIXED_DAYS_OF_MONTH` | When the fixed days of month are missing | | 2203 `FIXED_DAYS_OF_MONTH_NOT_ALLOWED` | When the fixed day of month are provided but the product does not allow them | | 2204 `REPAYMENT_FREQUENCY_NOT_ALLOWED` | When the repayment frequency is provided but the product does not allow it | | 2205 `REPAYMENT_PERIOD_COUNT_NOT_ALLOWED` | When the repayment period count is provided but the product does not allow it | | 2206 `APPLIED_INTEREST_BALANCE_CANNOT_BE_REALLOCATED` | When the user tries to update the interest balance across repayments, between a repayment with interest applied and one without | | 2207 `INVALID_NEW_TOTAL_LOAN_AMOUNT` | When trying to reschedule a loan account without any write off transaction, and the loan amount of the new account isn't equal with original account principal balance | | 2208 `NEGATIVE_WRITE_OFF_AMOUNT` | When trying to reschedule or refinance a loan account and a write off transaction is requested, but a negative amount is provided | | 2209 `CAPITALIZED_AMOUNTS_NOT_ALLOWED_DUE_TO_DIFFERENT_ACCOUNTING` | When trying to reschedule or refinance a loan account with cAPItalized amounts to a new product that has a different accounting methodology than the current one | | 2210 `TOP_UP_AMOUNT_IS_MANDATORY` | When trying to refinance a loan account but not provide the top up amount | | 2211 `RESTRUCTURE_DETAILS_ARE_MANDATORY` | When trying to refinance a loan account and restructure details aren't provided | | 2212 `NEGATIVE_TOP_UP_AMOUNT` | When trying to refinance a loan account and the top up amount provided is negative | | 2213 `WRITE_OFF_AMOUNT_MORE_THAN_BALANCE_AMOUNT` | | | 2214 `CANNOT_REFINANCE_REVOLVING_CREDIT_LOAN` | When trying to refinance a revolving credit loan | | 2215 `POSITIVE_CAPITALIZED_AMOUNTS_FOR_LOAN_FUNDED_NOT_ALLOWED` | When rescheduling a loan with investor funds and positive cAPItalized amounts are defined | | 2216 `WRITE_OFF_AMOUNT_FOR_LOAN_FUNDED_DIFFERENT_BY_BALANCE_AMOUNT` | When trying to reschedule a loan account with investor funds and the write off outstanding balance amount is different than the current balance amount(interest/fees/penalty) | | 2217 `CURRENCY_NOT_AVAILABLE_FOR_PRODUCT` | When trying to create a deposit account with a currency which is not available for the desired product type | | 2218 `CURRENCY_NOT_EDITABLE` | When trying to edit the currency of a deposit account but it is linked to a loan account | | 2219 `TELLER_CANNOT_POST_TRANSACTION_IN_MULTI_CURRENCY` | When trying to post a transaction as teller in a currency different than the base one | | 2220 `NOT_ENOUGH_PRINCIPAL_TO_CONTINUE_FEE_AMORTIZATION` | When trying to reschedule/refinance a loan account and the transferred principal is less or equal than the remaining fee amount to amortize | | 2221 `MISSING_TEMPLATE_KEY` | | | 2240 `TELLER_CANNOT_POST_TRANSACTION_WITHOUT_OPENED_TILL` | | ## Principal Payment Settings (2300 - 2399) |Response Code|Description| |---|---| | 2300 `SETTINGS_ONLY_AVAILABLE_FOR_REVOLVING_CREDIT_ACCOUNTS` | When the loan account is not of revolving credit type but it does have any principal payment settings | | 2301 `INCONSISTENT_FLAT_AMOUNT_WITH_PRODUCT_CONSTRAINTS` | When the loan product's settings constraints don't match the account's flat principal payment amount | | 2302 `INCONSISTENT_PERCENTANGE_WITH_PRODUCT_CONSTRAINTS` | When the loan product's settings constraints don't match the account's outstanding principal payment percentage | | 2303 `AMOUNT_REQUIRED_FOR_FLAT_PRINCIPAL_PAYMENT_METHOD` | When the account's flat principal payment amount is null but mandatory | | 2304 `PERCENTAGE_REQUIRED_FOR_PRINCIPAL_PAYMENT_PERCENTAGE_METHOD` | When the account's principal payment percentage is null but mandatory | | 2305 `AMOUNT_ONLY_AVAILABLE_FOR_FLAT_PRINCIPAL_PAYMENT_METHOD` | When the account's flat principal payment amount is set but unavailable | | 2306 `PERCENTAGE_ONLY_AVAILABLE_FOR_OUTSTANDING_PRINCIPAL_PERCENTAGE_METHOD` | When the account's principal payment percentage is set but unavailable | | 2307 `INVALID_PRINCIPAL_PAYMENT_FLAT_AMOUNT_WITH_DECIMALS` | When the account's flat principal payment amount is not valid with regards to the decimals settings | | 2308 `INVALID_PRINCIPAL_PAYMENT_PERCENTAGE_VALUE` | When the account's principal payment percentage value is not a valid percentage value | | 2309 `CANT_EDIT_LOCKED_OPERATIONS_IN_LOCKED_CAPPING_STATE` | When the locked operations are edited and the account is in locked capping state | | 2310 `CANT_UNLOCK_WHEN_INCOME_BALANCE_IS_OVER_PRINCIPAL_CAPPING_CONSTRAINTS` | Error code for the case when the income balance(interest + fee + penalties) is over the principal capping constrains set on the product, the unlock is not allowed | | 2311 `CANNOT_BULK_REVERSE_INTERNAL_TRANSFER_REPAYMENT` | When trying to reverse an internal transfer repayment as part of a bulk reversal operation | | 2312 `CANNOT_BULK_REAPPLY_TRANSACTION_BECAUSE_LOCKED_TRANSACTIONS_LOGGED_AFTER_IT` | When as part of a bulk reversal operation, a transaction is re-applied after a interest, fees or penalty locked transaction | | 2313 `CANNOT_BULK_REAPPLY_POSTDATED_REPAYMENTS` | When as part of a bulk reversal operation, a postdated repayment is re-applied | | 2314 `CANNOT_BULK_REVERSE_ACTIVATION_TRANSACTION` |Transaction cannot be backdated before the disbursement of a loan account | | 2315 `CLOSURE_DATE_AFTER_MAX_ALLOWED_UNDO_CLOSURE_PERIOD` | When the undo closure date is after account closure date + maximum allowed undo closure days | | 2316 `CLOSURE_DATE_BEFORE_GL_ACCOUNT_CLOSURE` | When there is a GL Accounts closure logged after the loan account closure date | | 2317 `MISSING_ORGANIZATION_INTEREST_COMMISSION` | When there is product without having default value set for organization interest commission and this value is not specified in the API call | | 2318 `INSUFFICIENT_TRANSACTION_AMOUNT` | When there isn't enough amount in the account to reverse the transaction | | 2319 `CANNOT_REVERSE_INTEREST_ON_DISBURSEMENT` | When there are transaction to be adjusted for an account having the interest applied on disbursement, which isn't allowed | | 2320 `TRANSACTION_TYPE_IS_IRREVERSIBLE` | The transaction we're attempting to adjust has a type that does not allow adjustments | | 2321 `INTEREST_APPLIED_WITH_NULL_AMOUNT` | The transaction is an interest applied and has null amount | | 2322 `CANNOT_REVERSE_OFFSET_DEPOSIT_TRANSACTION` | When trying to reverse a transaction for a linked offset deposit | | 2323 `CANNOT_LOCK_CAPPING_ACCOUNT_INVALID_ACCOUNT_ID` | Can't lock (capping) account because the account's ID is invalid | | 2324 `CANNOT_LOCK_CAPPING_ACCOUNT_INVALID_ACCOUNT_STATE_FOR_LOCK` | Can't lock (capping) account because the account's state is not valid for locking | | 2325 `INCOME_BALANCE_CONSTRAINTS_EXCEEDED` | Income balance constraints would be exceeded if income transaction would be applied | | 2326 `CANNOT_BULK_REVERSE_LOAN_FRACTION_SOLD` | Loan fraction sold cannot be directly bulk reversed | | 2327 `LATE_FEE_TRANSACTIONS_LOGGED_AFTER_REPAYMENT_TO_REAPPLY_ON_FIXED_ACCOUNT` | When there are late fee transactions logged after a repayment transaction to reapply on a fixed loan account | | 2328 `FEE_CANNOT_BE_POSTED_ON_RECOMPUTED_SCHEDULE` | When a late fee cannot be re applied on recomputed schedule after | | 2329 `INVALID_ORGANIZATION_INTEREST_COMMISSION` | When organization interest commission does not represent a valid numeric value or does not comply with product security settings | | 2330 `ACCOUNT_ALREADY_LOCKED` | When trying to lock an already locked account| | 2331 `CANNOT_BULK_ADJUST_ACTIVATION_TRANSACTION` | Cannot bulk-adjust the activation transaction for a loan account | | 2332 `PAYMENT_DUE_FEE_APPLIED_ON_DUE_DATES_TRANSACTIONS_LOGGED_AFTER_REPAYMENT_TO_REAPPLY_ON_FIXED_ACCOUNT` | | | 2333 `REALLOCATION_CAN_BE_DONE_ONLY_ON_FUTURE_REPAYMENTS` | | | 2334 `REALLOCATION_NOT_ALLOWED_ON_GRACE_INSTALLMENTS` | | | 2335 `INVALID_PRINCIPAL_PAYMENT_METHOD` | | | 2340 `REPAYMENT_VALUE_CHANGE_NOT_ALLOWED` | | ## 2400 |Response Code|Description| |---|---| | 2400 `INTEREST_RATE_CHANGED_TRANSACTION_NOT_ALLOWED` | The LoanTransactionType.INTEREST_RATE_CHANGED transaction can't be applied | | 2401 `INTEREST_RATE_CHANGED_TRANSACTION_NOT_ALLOWED_FOR_LOAN_PRODUCT_TYPE` | The LoanTransactionType `INTEREST_RATE_CHANGED` transaction can only be applied for revolving credit products | | 2402 `INSTALLMENT_WITH_INTEREST_APPLIED_CANNOT_BE_EDITED` | When the custom schedule has interest applied and an edit was tried | | 2403 `UNABLE_TO_DETERMINE_DELETED_REPAYMENTS` | When the we cannot properly identify the deleted repayments | | 2404 `PAID_OR_PURE_GRACE_INSTALLMENT_CANNOT_BE_DELETED` | When a pure grace installment or a paid installment was deleted | | 2405 `NON_CUSTOM_MADE_INTALLMENT_CANNOT_BE_DELETED_FOR_REVOLVING_CREDIT_ACCOUNT` | When a non custom-made installment is deleted for a revolving credit account | | 2406 `INVALID_NUMBER_OF_INSTALLMENTS` | When the number of installments is not within the product constraints | | 2407 `INVALID_PRINCIPAL_AMOUNT_WITH_DECIMALS` | When a principal amount is not valid with regarding to the decimals settings | | 2408 `INCONSISTENT_WITH_LINE_OF_CREDIT_VALID_UNTIL_DATE` | When the due date (of repayment) is after the Line of Credit valid until date | | 2409 `DUE_DATES_NOT_UNIQUE` | When there are multiple installments with the same due date (edit repayment schedule) | | 2410 `NON_ZERO_PRINCIPAL_REPAYMENT_CANNOT_BE_DELETED` | When a delete for a repayment that has not non zero principal due was tried | | 2411 `NON_DYNAMIC_ACCOUNT_REPAYMENT_DELETION_NOT_ALLOWED` | When there is a a delete for a repayment for non dynamic account (not allowed) | | 2412 `INVALID_LOAN_ACCOUNT_STATE_FOR_FUNDS_EDIT` | When the loan account state is invalid for the case when the investor funds are edited | | 2413 `ENTRY_DATE_AFTER_MATURITY_DATE_WITH_LATE_FEES_AND_BULK_REVERSAL` | When the interest is applied after account maturity date and there are late fees and also it trigger a bulk reverse and re-apply of transactions | | 2414 `DIFFERENT_ACCOUNTING_STATE_BETWEEN_INVOLVED_PRODUCTS` | When the deposit product has different accounting states | | 2415 `ACCOUNT_ALREADY_LINKED` | When the account is already linked with the provided deposit account | | 2416 `PRODUCT_DOES_NOT_ALLOW_LINKING` | When the product does not allow linking of settlement accounts | | 2417 `UNLINKABLE_SAVINGS_PRODUCT` | When the deposit product is not accepted by the loan product for linking | | 2418 `INVALID_SAVINGS_ACCOUNT_HOLDER` | When the linking should be done only between account under same account holder | | 2419 `LINK_BETWEEN_ACCOUNTS_DOES_NOT_EXIST` | When a link between the loan account and the deposit account does not exist | | 2420 `NON_NATIVE_GRACE_INSTALLMENT_CANNOT_BE_EDITED` | When a non-native grace installment was edited | | 2421 `NON_NATIVE_GRACE_INSTALLMENT_CANNOT_BE_DELETED` | When a non-native grace installment was deleted | | 2422 `INSUFFICIENT_ACCOUNT_BALANCE` | When the account balance is insufficient for the given operation | | 2423 `INVALID_SAVINGS_ACCOUNT_TYPE` | When the deposit account type is invalid for the given operation | | 2424 `MATURITY_PERIOD_ALREADY_STARTED` | When the maturity date period is already started on the account | | 2425 `LOAN_PRODUCT_PRINCIPAL_PAID_INSTALLMENT_STATUS_MISMATCH` | Principal paid installment status from loan account doesn't match the one from loan product | | 2426 `CANNOT_DELETE_LINK_FOR_ACTIVATED_OFFSET_LOAN` | A link cannot be deleted for an offset loan account that was activated | | 2427 `INVALID_LANGUAGE` | When the provided language is invalid(null or something else, the error source will provide the detailed reason) | | 2428 `INVALID_LINKED_SETTLEMENT_ACCOUNT_KEYS` | When the list with the provided linked settlement account keys on a deposit account is invalid | | 2429 `SAVINGS_ACCOUNT_ALREADY_LINKED` | When the settlement account is already linked to loan accounts from different branches | | 2430 `INSTALLMENT_WITH_PENALTY_APPLIED_CANNOT_BE_EDITED` | When the custom schedule has penalty applied and an edit was tried | | 2431 `INSTALLMENT_DUE_DATE_MOVED_BEFORE_LAST_PENALTY_APPLIED_DATE` | When the custom due date was moved before penalty applied | | 2432 `MATURITY_PERIOD_NOT_STARTED` | When the maturity date period is not yet started on the account | | 2433 `INVALID_AMOUNT_WITH_DECIMALS` | | | 2434 `PAYMENT_HOLIDAY_INVALID_INSTALLMENT_STATE` | | | 2436 `PAYMENT_HOLIDAYS_ARE_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_ALREADY_HAVE_PAYMENT_HOLIDAYS` | | | 2437 `PAYMENT_HOLIDAYS_ARE_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_INTEREST_APPLIED` | | | 2438 `PAYMENT_HOLIDAYS_ARE_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_FEE_APPLIED` | | | 2439 `PAYMENT_HOLIDAYS_ARE_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_PENALTY_APPLIED` | | | 2440 `RESEND_FAILED_NOTIFICATION_FAILED` | When trying to resend a failed notification and it fails (due to different causes: invalid encoded key of notification message or other various reasons, incorrect notification configuration) | | 2441 `TRY_TO_RESEND_NON_FAILED_NOTIFICATION` | When trying to resend a non failed notification | | 2442 `DUPLICATED_NOTIFICATION_ENCODED_KEY` | When trying to resend a list of notification message encoded keys and at least one key is duplicated | | 2443 `MAXIMUM_NUMBER_OF_NOTIFICATIONS_TO_RESEND_EXCEEDED` | When the maximum number of failed notifications to resend exceeds the set Mambu property | | 2444 `DUE_DATES_NOT_IN_ASCENDING_ORDER` | When the generated schedule doesn't have the due dates in ascending order. This can happen due to first repayment settings, as offset and repayment rescheduling options | | 2445 `ACCOUNT_PRODUCT_BRANCH_AVAILABILITY_MISMATCH` | Mismatch between the account's assigned branch key and the branches for which the product is available | | 2446 `CLIENT_HAS_ACTIVE_ACCOUNTS_WITH_PRODUCT_BRANCH_AVAILABILITY_MISMATCH` | In case a change to a client's (or group) assigned branch is done and that client(group) has active accounts that are unavailable for the new assigned branch | | 2447 `PRODUCT_HAS_ASSOCIATED_ACCOUNTS` | The product has associated accounts | | 2448 `MAX_NUMBER_OF_FILTERS_REACHED` | When the number of filters exceeds the maximum allowed | | 2449 `MAX_NUMBER_OF_COLUMNS_REACHED` | When the number of columns exceeds the maximum allowed | | 2450 `USAGE_RIGHTS_ROLE_NOT_AVAILABLE` | When the custom view is tried to be stored with a usage rights not available for it | | 2452 `CURRENCY_NOT_DEFINED` | When the deposit product doesn't have a currency defined | | 2453 `BASE_CURRENCY_CANNOT_BE_REMOVED` | When the deposit product is linked to a loan product, then the base currency cannot be removed from it | | 2454 `CURRENCY_IN_USE_CANNOT_BE_REMOVED` | When the currency is in use by other deposit product, then it cannot be removed | | 2455 `CURRENCY_DOES_NOT_EXIST` | When the specified currency code was not found (via API) | | 2492 `PAYMENT_HOLIDAYS_ADJUSTMENT_IS_NOT_ALLOWED_FOR_ACCOUNTS_WITH_PAYMENT_DUE_FEE_APPLIED_ON_DUE_DATES` || | 2493 `ACCOUNT_HAS_NO_PAYMENT_HOLIDAYS_ACCRUED_INTEREST` || | 2494 `ACCOUNT_HAS_LESS_PAYMENT_HOLIDAY_ACCRUED_INTEREST_THAN_THE_PROVIDED_AMOUNT_TO_APPLY` || | 2495 `PAYMENT_HOLIDAYS_ADJUSTMENT_IS_NOT_ALLOWED_FOR_INSTALLMENTS_WITHOUT_PAYMENT_HOLIDAYS` || | 2496 `PAYMENT_HOLIDAYS_ADJUSTMENT_IS_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_REPAYMENTS_POSTED` | | | 2497 `PAYMENT_HOLIDAYS_ADJUSTMENT_IS_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_INTEREST_APPLIED` || | 2498 `PAYMENT_HOLIDAYS_ADJUSTMENT_IS_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_FEE_APPLIED` || | 2499 `PAYMENT_HOLIDAYS_ADJUSTMENT_IS_NOT_ALLOWED_FOR_INSTALLMENTS_THAT_HAVE_PENALTY_APPLIED` || ## Credit arrangement (return codes used in API V2.0) (2456 - 2499) |Response Code|Description| |---|---| | 2456 `INVALID_CREDIT_ARRANGEMENT_ID` | When the ID or the key used for getting a credit arrangement is invalid | | 2457 `INVALID_CREDIT_ARRANGEMENT_STATE` | When trying to create a credit arrangement and the state does not match internal controls | | 2458 `CREDIT_ARRANGEMENT_ID_ALREADY_IN_USE` | When trying to store a credit arrangement with an ID that is already taken | | 2459 `INVALID_CLIENT_ROLE_PERMISSION_FOR_OPENING_CREDIT_ARRANGEMENTS` | When trying to store a credit arrangement, but the client type does not allow opening credit arrangements | | 2460 `CREDIT_ARRANGEMENT_AMOUNT_NOT_STRICTLY_POSITIVE` | When trying to store a credit arrangement with an amount that is not strictly positive | | 2461 `PRODUCT_CREDIT_ARRANGEMENT_AFFILIATION_CONSTRAINT_MISMATCH` | When the product requires a credit arrangement and the account is not part of a credit arrangement or the account doesn't allow a credit arrangement, but the account has a credit arrangement set | | 2462 `ACCOUNT_ALREADY_ON_CREDIT_ARRANGEMENT` | When trying to add an account to a credit arrangement, but the account already has a credit arrangement defined | | 2463 `INCONSISTENT_CREDIT_ARRANGEMENT_CLIENT_WITH_ACCOUNT_OWNER` | When the key of the credit arrangement is not the same as the holder key of the account | | 2464 `CREDIT_ARRANGEMENT_REQUIRES_OVERDRAFT_EXPIRE_DATE` | when overdraft expire date is required because the account is part of a credit arrangement and in a consuming state | | 2465 `CREDIT_ARRANGEMENT_REQUIRES_OVERDRAFT_MAX_LIMIT` | When overdraft maximum limit is required because the account is part of a credit arrangement and in a consuming state | | 2466 `CREDIT_ARRANGEMENT_AMOUNT_EXCEEDED` | When the maximum credit arrangement amount would be exceeded if the account would join the credit arrangement | | 2467 `MATURITY_DATE_AFTER_CREDIT_ARRANGEMENT_END_DATE` | When the loan last repayment date is after the credit arrangement expire date | | 2468 `OVERDRAFT_EXPIRY_DATE_AFTER_CREDIT_ARRANGEMENT_END_DATE` | When the overdraft expiry date is after the credit arrangement expire date | | 2469 `DISBURSEMENT_DATE_BEFORE_CREDIT_ARRANGEMENT_START_DATE` | When the loan disbursement (or expected disbursement) date is before the credit arrangement start date | | 2470 `CREDIT_ARRANGEMENT_REQUIRED_EXCEPTION` | When the product requires a credit arrangement but the account is not part of a credit arrangement | | 2471 `ACCOUNT_IS_NOT_PART_OF_CREDIT_ARRANGEMENT` | When trying to delete an account but it is not part of the credit arrangement mentioned in the URL | | 2472 `CREDIT_ARRANGEMENT_ILLEGAL_PARAMETER_MODIFICATION` | When trying to modify some credit arrangement parameters, but due to credit arrangement state the modification is not permitted | | 2473 `CREDIT_ARRANGEMENT_HAS_NON_CLOSED_ACCOUNTS` | When trying to close a credit arrangement that has non closed accounts | | 2474 `BASE_CURRENCY_NOT_UNIQUE` | When adding a default currency but there is already a default in the system | | 2475 `CURRENCY_SYMBOL_LENGTH_OUTSIDE_CONSTRAINTS` | When a currency symbol is outside its length constraints | | 2476 `INEXISTING_CURRENCY_SYMBOL` | When no currency symbol is specified | | 2480 `INVALID_TO_INSTALLMENT_POSITION` | When the installment value for a periodic payment is an invalid value (should be positive integer) | | 2481 `INVALID_PMT_VALUE` | When the PMT value for a periodic payment is invalid (should be zero or positive amount) | | 2482 `PAYMENT_PLAN_NOT_AVAILABLE` | When the payment plan is not available for the loan account | | 2483 `AT_LEAST_ONE_PERIODIC_PAYMENT_PLAN_MANDATORY` | When at least one periodic payment should be defined in a payment plan | | 2484 `SUM_OF_PERIODIC_PAYMENTS_LESS_OR_EQUAL_WITH_LOAN_AMOUNT` | When the sum of periodic payments defined in payment plan is less than or equal to the loan amount | | 2485 `PAYMENT_PLAN_ENTRIES_NOT_ORDERED` | When the periodic payments of a payment plan are not in ascending order (starting position is greater than ending position for a periodic payment) | | 2486 `INTEREST_RATE_COMPUTATION_ERROR` | When the interest rate cannot be computed based on a payment plan | | 2487 `INVALID_PERIODIC_PAYMENT_ENCODED_KEY` | When an update is done on a non existing payment plan entry | | 2488 `DUPLICATED_PERIODIC_PAYMENT_ENCODED_KEY` | When a payment plan update contains duplicate encoded keys | | 2489 `INVALID_INTEREST_CHARGE_FREQUENCY_METHOD_MUST_BE_NULL` | InterestChargeFrequency is invalid (should be null for Fixed payment plan product) | | 2490 `INVALID_DAYS_IN_YEARS_METHOD_MUST_BE_NULL` | DaysInYears is invalid (should be null for Fixed payment plan product) | ## 2500 |Response Code|Description| |---|---| | 2500 `PRODUCT_ID_ALREADY_IN_USE` | When the product ID is already in use | | 2501 `INVALID_ROUNDING_REPAYMENT_CURRENCY_FOR_PRODUCT`(2501), | When rounding repayment currency is inconsistent with the product options | | 2502 `INVALID_COMMUNICATION_MESSAGE_ENCODED_KEY` | When the provided encoded key for the communication message is invalid | | 2503 `INVALID_EMAIL_SUBJECT` | When the email is sent without a valid subject | | 2504 `CANNOT_ADJUST_OFFSET_DEPOSIT_TRANSACTION` | When trying to adjust a transaction for a linked offset deposit | | 2505 `CURRENCY_CANNOT_BE_CHANGED` | | | 2506 `ONLY_ORGANISATION_BASE_CURRENCY_IS_ALLOWED` | | ## 2600 |Response Code|Description| |---|---| | 2600 `SDK_CLIENT_COULD_NOT_BE_GENERATED` | When something went wrong while generating the SDK client and the client could be generated | | 2601 `SDK_CLIENT_LANGUAGES_COULD_NOT_BE_OBTAINED` | When something went wrong while trying to obtain the available languages for SDK client generation | | 2602 `MAXIMUM_NUMBER_OF_COMMUNICATION_MESSAGES_TO_RESEND_EXCEEDED` | When the maximum number of failed communication messages to resend exceeds the set Mambu property | | 2604 `RESEND_FAILED_COMMUNICATON_FAILED` | When trying to resend a failed communication and it fails (due to different causes: invalid encoded key of the communication message or other various reasons such as incorrect communication message configuration) | | 2605 `DUPLICATE_ENCODED_KEY` | When trying to resend a list of communication messages and at least one encoded key is duplicated | | 2606 `MESSAGE_STATE_MUST_BE_FAILED` | When trying to resend a non failed communication | | 2607 `NO_MESSAGE_FOUND` | When no message was found in a list of message encoded keys | | 2608 `MESSAGE_NOT_FOUND` | When the message was not found for that specific encoded key | | 2609 `MISSING_ENCODED_KEY` | When the message to be resend doesn't have the encoded key specified | | 2610 `URL_CONTAINS_QUOTES` | WebHook URLs cannot contain quotes | | 2611 `MISSING_RECIPIENT` | The message recipient is missing when required | | 2612 `RECIPIENT_NOT_ALLOWED` | The message recipient is set but not allowed | | 2613 `INVALID_CLIENT_RECIPIENT` | The client recipient is not valid | | 2614 `INVALID_CREDIT_OFFICER_RECIPIENT` | The credit officer recipient is not valid | | 2615 `INVALID_GROUP_ROLE_RECIPIENT` | The group role recipient is not valid | | 2616 `INVALID_CUSTOM_FIELD_RECIPIENT` | The custom field recipient is not valid | | 2617 `INVALID_EVENT` | The event of the template used for this message is not valid | | 2618 `INVALID_TARGET` | The target of the template used for this message is not valid | | 2619 `INVALID_PLACEHOLDER` | A placeholder from the template is not allowed | | 2620 `INVALID_FIELD_LENGTH` | When the name or subject has invalid length | | 2621 `INVALID_WEBHOOK_REQUEST_TYPE` | WebHook request type is not valid | | 2622 `URL_CONTAINS_INVALID_PLACEHOLDERS` | WebHook URLs cannot contain specific placeholder, like Repayment schedule placeholder | | 2623 `UNABLE_TO_RECALCULATE_SCHEDULE` | When the schedule recalculate fails | | 2624 `UNABLE_TO_APPRAISE_LOAN_ACCOUNT` | When the appraisal of the loan account fails | | 2625 `TRANSACTION_MADE_BY_A_DISBURSEMENT_FEE` | Transaction is an up-front disbursement fee type that cannot be individually reversed | | 2626 `INVALID_TARGET_ACCOUNT_TYPE` | When the target account is a term deposit (fixed deposit or savings plan) | | 2627 `NEGATIVE_TARGET_ACCOUNT_BALANCE` | When the target account has negative balance. Disbursements cannot be transferred to overdraft accounts (can't pay an overdraft with another loan) | | 2628 `ZERO_DISBURSE_AMOUNT` | When an account is trying to be disbursed to a deposit account but with a zero amount | | 2629 `INVESTOR_FUNDED_LOAN_ACCOUNT` | When an account is trying to be disbursed with external investor funds in a deposit account | | 2630 `INVALID_TARGET_ACCOUNT_HOLDER_KEY` | When the account holder of target account is not the same with the one from the loan account (disbursements can only be transferred from a client's loan to one of its deposits) | | 2631 `TRANSFER_NOTES_LENGTH_EXCEEDS_MAXIMUM_SIZE` | When transfer notes are longer than the maximum allowed size | | 2632 `CANNOT_MAKE_TRANSFER_FOR_FOREIGN_CURRENCY_IF_ACCOUNTING_ENABLED` | When the user tries to make a transfer between two deposit accounts and the source account has accounting enabled and a foreign currency | ## Cards (2700 - 2799) |Response Code|Description| |---|---| | 2700 `CARD_REFERENCE_TOKEN_FORMAT_INVALID` | When the card reference format is invalid (null or too long) | | 2701 `CARD_REFERENCE_TOKEN_ALREADY_IN_USE` | This card token is already in use with another current or revolving credit account and cannot be used | | 2702 `CARD_REFERENCE_HAS_ASSOCIATED_HOLDS_OR_TRANSACTIONS` | When the card reference has associated authorization holds or card transactions upon deleting | | 2703 `CARD_REFERENCE_NOT_FOUND` | When the card reference token not found in database | | 2704 `DUPLICATE_AUTHORIZATION_HOLD` | When an authorization hold with the same card token and external reference ID already exists | | 2705 `DUPLICATE_CARD_TRANSACTION` | When a card transaction with the same card token and external reference ID already exists | | 2706 `AVAILABLE_BALANCE_BELOW_ZERO` | When the available balance drops below zero (becomes negative) | | 2707 `AUTHORIZATION_HOLD_NOT_FOUND` | When the authorization hold was not found in database | | 2708 `INVALID_AUTHORIZATION_HOLD_STATE` | When the operation is denied for authorization hold state | | 2709 `CARD_TRANSACTION_CANNOT_BE_ADJUSTED` | If a transaction is card-originated, this cannot be reversed. If a reversal is intended, please consult our [Support Page](/docs/card-payments-and-authorization-holds)| | 2710 `TECHNICAL_OVERDRAFT_IS_NOT_ALLOWED_FOR_PRODUCT` | | | 2711 `CARD_TRANSACTION_NOT_FOUND` | No original card transaction was found for: `, ` | | 2712 `CARD_TRANSACTION_MAX_REVERSAL_AMOUNT_EXCEEDED` |The amount exceeds transaction maximum available amount for reversal: ``| | 2713 `CARDS_FEATURE_DISABLED` | The action cannot be completed until the cards features is enabled for your Mambu tenant | ## 2800 |Response Code|Description| |---|---| | 2801 `PRODUCT_MUST_BE_ACTIVE` | When updating an account with an inactive product | | 2802 `TARGET_AMOUNT_IS_NEGATIVE` | When deposit account target amount is negative | | 2803 `MAX_WITHDRAWAL_AMOUNT_OUTSIDE_CONSTRAINTS` | When maximum withdrawal amount does not match product | | 2804 `ACCOUNT_HOLDER_KEY_INVALID` | The account holder key specified is not valid | | 2805 `ACCOUNT_HOLDER_TYPE_INVALID` | The account holder type specified is not valid | | 2806 `INVALID_WITHHOLDING_TAX_SOURCE_KEY` | The withholding tax source key is not a valid index rate of type Withholding Tax | | 2807 `INTEREST_RATE_OUTSIDE_CONSTRAINTS` | The interest rate does not match product constraints | | 2808 `INVALID_INTEREST_PAYMENT_POINT` | When the account has null interest payment point or different than the one from the product | | 2809 `INVALID_INTEREST_PAYMENT_DATES` | When the account interest payment dates don't match the ones from the product | | 2810 `REQUIRED_OVERDRAFT_INTEREST_RATE` | When the overdraft interest spread is required due to product settings | | 2811 `REQUIRED_OVERDRAFT_EXPIRY_DATE` | When the overdraft expiry date is required due to product settings | | 2812 `REQUIRED_OVERDRAFT_LIMIT` | When overdraft limit is required due to product settings | | 2813 `DEPOSIT_ACCOUNT_FIELD_NOT_EDITABLE` | When a field on deposit account cannot be edited | | 2814 `DEPOSIT_PRODUCT_MISMATCH` | When a field on deposit account does not match the product settings | | 2815 `ACCOUNT_TYPE_DOES_NOT_ALLOW_RECOMMENDED_DEPOSIT_AMOUNT` | When account type does not allow recommended deposit amount | | 2816 `ACCOUNT_TYPE_DOES_NOT_ALLOW_MAX_WITHDRAWAL_AMOUNT` | When account type does not allow maximum withdrawal amount | | 2817 `ACCOUNT_TYPE_DOES_NOT_ALLOW_TARGET_AMOUNT` | When account type does not allow target amount | | 2818 `REQUIRED_INTEREST_RATE` | When the interest rate is required due to product settings | | 2819 `INTEREST_RATE_SHOULD_BE_NULL` | When interest rate should be null | | 2820 `OVERDRAFT_INTEREST_RATE_SHOULD_BE_NULL` | When overdraft interest rate should be null | | 2821 `OVERDRAFT_INTEREST_SPREAD_SHOULD_BE_NULL` | When overdraft interest spread should be null | | 2822 `INVALID_ACCOUNT_TYPE` | When account type is invalid | | 2823 `INVALID_ACCOUNT_KEY` | When account key is invalid | ## 3000 |Response Code|Description| |---|---| | 3000 `INVALID_AMORTIZATION_PROFILE` Amortization profile for the fee is not valid | | 3001 `AMORTIZATION_PROFILE_NOT_ALLOWED` | Amortization profile is not allowed by product settings | | 3002 `INVALID_AMORTIZATION_FREQUENCY` | Amortization frequency for the fee is not valid | | 3003 `INVALID_AMORTIZATION_FREQUENCY_CUSTOM_INTERVAL_PERIOD_COUNT` | Amortization frequency custom interval period count for the fee is not valid | | 3004 `INVALID_AMORTIZATION_SETTINGS` | Amortization settings not valid or missing | | 3005 `AMORTIZATION_FREQUENCY_CUSTOM_INTERVAL_TOTAL_STEPS_NOT_ALLOWED` | Amortization frequency custom interval total steps for the fee is not allowed | | 3006 `AMORTIZATION_FREQUENCY_CUSTOM_INTERVAL_PERIOD_UNIT_NOT_ALLOWED` | Amortization frequency custom interval period unit for the fee is not valid | | 3007 `AMORTIZATION_FREQUENCY_CUSTOM_INTERVAL_PERIOD_COUNT_NOT_ALLOWED` | Amortization frequency custom interval period count for the fee is not valid | | 3008 `INVALID_AMORTIZATION_FREQUENCY_CUSTOM_INTERVAL_TOTAL_STEPS` | Amortization frequency custom interval total steps for the fee is not valid | | 3009 `INVALID_AMORTIZATION_FREQUENCY_CUSTOM_INTERVAL_PERIOD_UNIT` | Amortization frequency custom interval period unit for the fee is not allowed | | 3010 `AMORTIZATION_SETTINGS_NOT_ALLOWED` | Amortization settings not allowed (for example, for product type) | | 3011 `INVALID_INTEREST_RATE_TERMS` | When interest rate terms is invalid | | 3012 `TRANSACTION_DISBURSEMENT_DATE_DOES_NOT_MATCH_WITH_TRANCH_EXPECTED_DATE` | When the disbursement date provided doesn't match with the next tranch to disburse expected disbursement date | ## 3100 Transaction Channels |Response Code|Description| |---|---| | 3100 `DUPLICATE_TRANSACTION_CHANNEL_NAME` | The provided name for transaction channel already exists | | 3101 `DUPLICATE_TRANSACTION_CHANNEL_ID` | The provided ID for transaction channel already exists | | 3102 `TRANSACTION_CHANNEL_ID_CONTAINS_SPACES` | The provided ID contains white spaces | | 3103 `INVALID_TRANSACTION_CHANNEL_LOAN_CONSTRAINTS` | When trying to store a channel with invalid loan constraints | | 3104 `INVALID_TRANSACTION_CHANNEL_SAVINGS_CONSTRAINTS` | When trying to store a channel with invalid deposit constraints | | 3105 `INVALID_TRANSACTION_CHANNEL_ACCOUNT_USAGE` | When trying to store a channel with an account usage different than of type DETAIL | | 3106 `CANNOT_DELETE_DEFAULT_TRANSACTION_CHANNEL` | The default transaction channel should not get deleted | | 3107 `TRANSACTION_CHANNEL_IN_USE` | Used transaction channels should not get deleted | | 3108 `TRANSACTION_CHANNEL_CANNOT_BE_DEACTIVATED` | Thrown when trying to deactivate a transaction channel that should not be deactivated | ## 3200 |Response Code|Description| |---|---| | 3202 `INCONSISTENT_TRANSACTION_USER_KEY_WITH_ACCOUNT_USER` | When user assigned on the transaction is different than the user making the request | | 3203 `INCONSISTENCY_BETWEEN_CHANNEL_KEY_AND_ID` | When the provided key of the transaction channel and the ID does not match the same transaction channel | | 3204 `INCONSISTENT_TRANSACTION_PRODUCT_KEY_WITH_ACCOUNT_PRODUCT` | When the provided product key on transaction is not consistent (equal) to the product key assigned on the account | ## 3300 |Response Code|Description| |---|---| | 3300 `DUPLICATE_ID` | When trying to store an entity and the ID is already taken by other entity | | 3301 `DUPLICATE_NAME` | When trying to store an entity and the name already exists | | 3303 `ID_CONTAINS_SPACES` | The ID used in store operation contains spaces and it shouldn't | | 3304 `INVALID_EXTERNAL_ID` | The external ID from transactions is invalid | | 3305 `EXTERNAL_ID_ALREADY_EXISTS` | Another transaction of the same financial source already has this external ID | | 3311 `INVALID_ASSIGNMENT_FROM_NO_MEETING_DAY` | When trying to assign an entity which is not assigned to a centre or is assigned to a centre without meeting day, to a centre with a meeting day in place | | 3312 `HOLDER_HAS_ACCOUNTS_IN_DIFFERENT_BRANCH_WITH_CENTRE_OR_CREDITOFFICER_MISMATCH` | Account Holder has accounts in different branches for which the centre or the credit officer does not belong | | 3320 `ACCOUNT_ALREADY_DISBURSED` | The available amount has been reduced to below the amount already disbursed (the available amount is negative), and further disbursements will not be possible | | 3321 `ACCOUNT_APPROVED_AMOUNT_HAS_BEEN_EXCEEDED` | | | 3322 `USER_WHO_CREATED_OR_EDITED_THE_LOAN_ACCOUNT_CANNOT_APPROVE_IT` | | | 3323 `FOUR_EYES_PRINCIPLE_DISABLED_ON_GENERAL_SETTINGS` | | ## 3400 |Response Code|Description| |---|---| | 3400 `AMORTIZATION_FREQUENCY_INTERVAL_TYPE_NOT_ALLOWED` | Amortization interval type not allowed | | 3401 `AMORTIZATION_FREQUENCY_INTERVAL_COUNT_NOT_ALLOWED` | Amortization interval count not allowed | | 3402 `INVALID_AMORTIZATION_FREQUENCY_INTERVAL_TYPE` | Amortization frequency interval type for the fee is not valid | | 3403 `INVALID_AMORTIZATION_FREQUENCY_PREDEFINED_INTERVALS_UNIT` | Amortization frequency predefined intervals unit for the fee is not valid | | 3404 `NON_POSITIVE_DEFAULT_INTEREST_RATE` | When the default interest rate is not positive | | 3405 `NON_POSITIVE_MIN_INTEREST_RATE` | When the minimum interest rate is not positive | | 3406 `NON_POSITIVE_MAX_INTEREST_RATE` | When the maximum interest rate is not positive | | 3407 `INVALID_INTEREST_RATE_MIN_MAX_DEFAULT_TUPLE` | When the tuple minimum maximum default for interest rate is not valid | | 3408 `DEFAULT_MIN_MAX_NOT_AVAILABLE` | When the minimum maximum default values for interest rate are not available | | 3409 `INTEREST_RATE_TERMS_ARE_READONLY` | When the interest rate terms are not available | | 3410 `INTEREST_CALCULATION_BALANCE_METHOD_READONLY` | Interest calculation balance method is read-only | | 3411 `INTERNAL_TRANSFER_CANNOT_USE_CUSTOM_FIELDS` | Internal transfer transactions don't have a transaction channel and thus can't have custom fields | | 3412 `INCONSISTENT_FEE_CALCULATION_METHOD_WITH_INCLUDE_FEE_IN_FLOOR_AMOUNT_OPTION_ENABLED` | When the loan product doesn't support repayment principal amount percentage on fess with include fees in floor amount option enabled | | 3413 `INCONSISTENT_FEE_CALCULATION_METHOD_WITH_TOTAL_BALANCE_OPTION_ENABLED` | When the loan product doesn't support repayment principal amount percentage on fess with total balance percentage option | | 3414 `INCONSISTENT_LATE_REPAYMENT_FEE_TRIGGER_WITH_TOTAL_BALANCE_OPTION_ENABLED` | When the loan product doesn't support late fess with total balance percentage option | | 3415 `INACTIVE_ACCOUNT_BRANCH` | Can store loan accounts only assigned to an active branch | | 3416 `INCONSISTENT_ACCOUNT_BRANCH_ASSOCIATION_CENTRE_OR_CREDITOFFICER_MISMATCH` | When the other assignments on centre or credit officer become inconsistent due to branch association | | 3417 `INVALID_ACCOUNT_BRANCH_ASSIGNMENT_DUE_CENTRE_MEETING_DAY_MISMATCH` | Only for fixed accounts, when a loan account's branch which is not assigned to a centre or is assigned to a centre without meeting day is tried to be assigned to a centre with a meeting day | | 3418 `CANNOT_CHANGE_LOAN_GROUP_BRANCH_FOR_A_SOLIDARITY_GROUP` | When changing the branch while creating or editing a loan group for a solidarity group | | 3419 `CANNOT_CHANGE_LOAN_ACCOUNT_BRANCH_WHEN_RESHEDULE_REFINANCE` | When trying to change the branch when reschedule or refinance a loan account | | 3420 `INVALID_FEE_APPLICATION` | When the loan product's fee application is not valid | | 3421 `INVALID_FEE_AMORTIZATION_UPON_RESCHEDULE_REFINANCE_OPTION` | When the loan product's fee amortization upon reschedule/refinance option is not valid | | 3422 `FEE_AMORTIZATION_UPON_RESCHEDULE_REFINANCE_OPTION_IS_MANDATORY` | When the loan product's continue fee amortization value is mandatory for the fee | | 3424 `NOT_ADJUSTED_TRANSACTION_LOGGED_AFTER_CURRENT_ONE` | When a transaction that is not adjusted is logged after the current one | | 3425 `CANNOT_ADJUST_INTEREST_ON_DISBURSEMENT` | When an interest on disbursement cannot be adjusted | | 3426 `TRANSACTION_TYPE_DOES_NOT_ALLOW_ADJUSTMENT` | When the type of transaction does not allow adjustment | | 3427 `TRANSACTION_ALREADY_ADJUSTED` | When trying to adjust a transaction that has already been adjusted | | 3423 `FEE_TRIGGER_NOT_ALLOWED` | When the fee trigger is not allowed for product setup | | 3428 `PAYMENT_DUE_FEES_ON_DUE_DATES_TRIGGER_NOT_ALLOWED` | Payment due fees on due dates trigger is not allowed for current product setup | | 3429 `EDITING_PAYMENT_DUE_FEES_APPLIED_ON_DUE_DATES_NOT_ALLOWED` | When editing payment due fees applied on due dates (for do not allow Payment Due Fee Applied on Due Dates reallocation at Edit Schedule) | | 3434 `INACTIVE_DEPOSIT_ACCOUNT_BRANCH` |Only the active branches can be assigned to a Deposit Account. | | 3430 `DEPOSIT_INTEREST_FEATURE_DISABLED` | Interest fields cannot be set when DEPOSIT_INTEREST feature is disabled | ## 3500 Federated Authentication |Response Code|Description| |---|---| | 3500 `CANNOT_CREATE_NEW_USER_IN_FEDERATED_CONTEXT` | When you try to create a new user, and federated authentication is enabled | ## 3600 |Response Code|Description| |---|---| | 3600 `EMPTY_CUSTOM_FIELD_ID` | Custom field ID is empty | | 3610 `ACCOUNT_ALREADY_CLOSED` | Account closed | | 3611 `INVALID_GUARANTEE_TYPE` | Guarantee type is invalid | | 3612 `ORIGINAL_ACCOUNT_NOT_FOUND` | No original account found that reschedules this one | | 3613 `INVALID_ORIGINAL_ACCOUNT_STATE` | The original account is not in Closed Rescheduled/Refinanced state | | 3614 `INCONSISTENT_AMORTIZATION_ACCOUNTING_SETUP` | The original account has a fee with amortization and cannot be Rescheduled/Refinanced into another product| | 3615 `PAYMENT_DUE_FEES_ON_DUE_DATES_NOT_ALLOWED_AT_RESCHEDULE_REFINANCE` | The original loan product or new selected product has payment due fees on due dates defined and loan account cannot be Rescheduled/Refinanced | | 3616 `TAXES_ON_PRODUCT_NOT_ALLOWED` | | | 3617 `TAX_CALCULATION_METHOD_NOT_ALLOWED` | | | 3618 `TAXES_NOT_EDITABLE` | | | 3620 `CANNOT_APPLY_REPAYMENT_ON_ZERO_BALANCE_ACCOUNT` | When the account has zero balance no repayments can be applied | | 3621 `LOCKED_BALANCE_NOT_ALLOWED` | When locked balance is set and should not be modified | | 3622 `INEXISTING_TOLERANCE_CALCULATION_METHOD` | When arrears tolerance calculation method is not present | | 3623 `ARREARS_TOLERANCE_DAY_OUTSIDE_CONSTRAINTS` | When arrears tolerance calculation method is not present | | 3624 `INCONSISTENT_ARREARS_TOLERANCE_VALUES_WITH_ARREARS_TOLERANCE_METHOD` | When the arrears tolerance calculation method and the arrears tolerance parameters do not match | | 3629 `SAVINGS_PRODUCT_DOES_NOT_ALLOW_OFFSET_LINKING` |A loan account cannot be linked to a deposit account that does not not allow offset linking. Check that the deposit account ID is correct or that the deposit product offers this functionality | | 3630 `INVALID_SETTLEMENT_ACCOUNT_KEY` | When a settlement account key is invalid | | 3631 `INVALID_SETTLEMENT_ACCOUNT_STATE` | When a deposit account state is not valid for linking | | 3632 `INVALID_DATA_MIGRATION_EVENT_KEY` | When there is no data migration event available for given identifier | | 3633 `ANOTHER_TASK_IN_PROGRESS` | When there is another background task in progress | | 3634 `INVALID_DATA_IMPORT_TASK_KEY` | When there is no data import task available for given identifier | | 3640 `DEPOSIT_ACCOUNT_LINKED_TO_LOAN_ACCOUNTS_ON_DIFFERENT_BRANCHES` | When a deposit account is linked to another loan accounts which are on different branches | | 3641 `SAVINGS_ACCOUNT_LINKED_TO_LOAN_ACCOUNTS_ON_DIFFERENT_BRANCHES` | When a savings account is linked to another loan accounts which are on different branches | | 3642 `INVALID_DEPOSIT_ACCOUNT_HOLDER` | The linking should be done only between account under same account holder | | 3643 `UNLINKABLE_DEPOSIT_PRODUCT` | The deposit product is not accepted by the loan product for linking | | 3644 `INEXISTING_DATE_CALCULATION_METHOD` | When no date calculation method was specified | | 3645 `INEXISTING_NON_WORKING_DAYS_METHOD` | When no non-working days method was specified | | 3650 `MESSAGE_SENDING_ERROR` | When an error occurred while trying to send the background task message to the messaging system | | 3651 `CONNECTION_CLOSING_ERROR` | When an error occurred while trying to close the connection with the messaging system | | 3652 `CONSUMER_SERVICE_STARTING_ERROR` | Validation error for the case when starting message consumer service and it is already started | | 3653 `CONSUMER_SERVICE_ALREADY_STARTED` | When an error occurred while trying to send the background task message to the messaging system | | 3654 `CONSUMER_UNSUBSCRIPTION_FAILED` | When an error occurred while trying to un-subscribe from the queue | | 3655 `CONSUMER_SUBSCRIPTION_FAILED` | When an error occurred while trying to subscribe the queue | | 3660 `INVALID_SUPPORT_ROLE_ASSOCIATION` | The support role cannot be assigned to an admin or teller | | 3661 `INVALID_SUPPORT_ROLE_NAME` | The support role name cannot be changed | | 3662 `INVALID_SUPPORT_ROLE_USER_RIGHTS` | The user rights for the support role cannot be changed | | 3663 `INVALID_SUPPORT_ROLE_PERMISSIONS` | The permissions for the support role must be view only | ## 3700 |Response Code|Description| |---|---| | 3700 `LOAN_ACCOUNT_FIELD_NOT_EDITABLE` | When a field on loan account cannot be edited | | 3701 `INCOMPATIBLE_ARREARS_TOLERANCE_METHOD_AND_PRODUCT_TYPE` | When the chosen product type is incompatible with the chosen arrears tolerance method | | 3710 `TRANSACTION_CHANNEL_NOT_ALLOWED_WHEN_DISBURSE_TO_DEPOSIT` | When trying to disburse a loan account to a deposit account and the transaction channel key/id is provided | | 3720 `INVALID_TARGET_ACCOUNT_STATE_FOR_DEPOSIT` | When the target account state doesn't allow deposit | | 3730 `FEE_AMOUNT_ALREADY_DEFINED_IN_PRODUCT` | Fee amount cannot be specified because it is already defined on product | | 3732 `MANDATORY_FEE_AMOUNT` | The provided fee's amount is mandatory | | 3740 `INVALID_SORTING_SELECTION` | When value of sorting selection is not a valid data field or custom field ID when searching on the fly | | 3741 `BLACKLISTED_CLIENT_NOT_EDITABLE` | When attempting to update a blacklisted client | | 3742 `INVALID_STRING_VALUE` | When attempting to update a field with unsupported characters | | 3743 `NOTIFICATION_STATE_IS_REQUIRED` | Notification state is required | | 3744 `NOTIFICATION_EVENT_MESSAGE_IS_REQUIRED` | Notification event message is required | | 3750 `INSTALLMENT_NUMBER_MANDATORY_FOR_FIXED_ACCOUNTS` | Installment number is mandatory for fixed loan accounts | | 3759 `CLIENT_ID_ANONYMIZATION_ERROR` | When there was an error while anonymizing client ID | | 3751 `INSTALLMENT_NUMBER_NOT_ALLOWED_FOR_DYNAMIC_ACCOUNTS` | Installment number is not allowed for dynamic accounts | | 3752 `INVALID_INSTALLMENT_NUMBER` | Installment number is outside constraints | | 3753 `CANNOT_APPLY_FEE_ON_PAID_INSTALLMENT` | When attempting to apply a fee on a paid installment | | 3754 `MANDATORY_ACCOUNT_HOLDER_TYPE` | The account holder type must be specified | | 3760 `CLIENT_DOES_NOT_HAVE_EXITED_STATE` | When trying to anonymize a client which doesn't have EXITED state | | 3761 `UNSUBSCRIBE_CLIENT_FROM_NOTIFICATIONS_ERROR` | When there was an error while unsubscribing client from notifications (when deleting client notification requests) | | 3762 `CLIENT_PERSONAL_INFORMATION_ANONYMIZATION_ERROR` | When there was an error while anonymizing client personal data | | 3763 `CLIENT_LOAN_ACCOUNTS_ANONYMIZATION_ERROR` | When there was an error while anonymizing client loan accounts | | 3764 `CLIENT_SAVINGS_ACCOUNTS_ANONYMIZATION_ERROR` | When there was an error while anonymizing client deposit accounts | | 3765 `CLIENT_LINES_OF_CREDIT_ANONYMIZATION_ERROR` | When there was an error while anonymizing client lines of credit | | 3766 `CLIENT_GUARANTEES_ANONYMIZATION_ERROR` | When there was an error while anonymizing client guarantees | | 3767 `CLIENT_NOTIFICATION_MESSAGES_ANONYMIZATION_ERROR` | When there was an error while anonymizing client notification messages | | 3768 `CLIENT_ASSOCIATED_TASKS_ANONYMIZATION_ERROR` | When there was an error while anonymizing client associated tasks | | 3780 `INVALID_API_KEY` | When the API key found in request header is not valid | | 3781 `API_KEY_REFRESH_ERROR` | When the API key found in request header is not valid | | 3782 `FILE_NOT_FOUND` | When downloading a file that doesn't exist on remote storage | | 3783 `UPLOADED_FILE_NOT_FOUND` | When the uploaded file is not found | | 3784 `MISSING_CLIENT_ROLE` | When during a GET Client Role call, the provided client is not associated with a Client Role | | 3785 `BACKGROUND_PROCESS_STATE_IS_REQUIRED` | | | 3786 `BACKGROUND_PROCESS_STATE_CANNOT_BE_IN_PROGRESS` | | | 3790 `NOT_ALLOWED_TO_CREATE_REOPEN_ACCOUNTS_WITH_RECALCULATE_SCHEDULE_KEEP_SAME_TOTAL_REPAYMENT_AMOUNT` | Return code for the case when an user tries to create or reopen an account with Recalculate the Schedule, Keep the Same Total Repayment Amount prepayment recalculation method | | 3791 `NOT_ALLOWED_TO_CREATE_REOPEN_ACCOUNTS_WITH_DEPRECATED_REDUCE_NUMBER_OF_INSTALLMENTS `| | | 3792 `NOT_ALLOWED_TO_REOPEN_REVOLVING_ACCOUNTS_WITHOUT_KEEP_EMPTY_INSTALLMENTS_SCHEDULE` | | | 3800 `FEATURE_NOT_ENABLED` | | | 3810 `AUTOMATIC_END_OF_DAY_PROCESSING` | | | 3820 `ACCOUNT_NOT_ACTIVE` | | | 3821 `DUPLICATE_ENTRY_FOR_CUSTOM_FIELD_VALUE` | | | 3822 `ACCOUNT_ACTIVATION_FAILED` | | | 3830 `INSUFFICIENT_AVAILABLE_AMOUNT_FOR_AUTHORIZATION_HOLD_ON_LOANS` | | | 3840 `INVALID_MCC_EXPIRATION_ENTRY` | The `daysToExpiration` value for the default authorization hold must be positive and must not be more than 36,525 | | 3841 `MCC_ALREADY_EXISTS` | | | 3842 `MCC_EXPIRATION_ENTRY_NOT_FOUND` | | | 3843 `PRODUCT_DISBURSEMENT_FEES_PREVENT_CARD_ATTACHMENT` | | | 3844 `INTEREST_CALCULATION_BALANCE_METHOD_NOT_ALLOWED` | | | 3900 `INVALID_API_CONSUMER_USERNAME` | | | 3910 `YAML_PROCESSING_FAILED` | | | 3920 `CARD_TRANSACTION_REVERSAL_CANNOT_BE_ADJUSTED` | | | 3930 `DUPLICATE_CUSTOM_FIELD_SELECTION_ID` | | | 3940 `INVALID_CREDIT_DEBIT_INDICATOR_FOR_OPERATION` | | | 3950 `ASYNC_TRANSACTION_IN_PROGRESS` | | ## 4900 |Response Code|Description| |---|---| | 4900 `BLANK_INSTITUTION_NAME` | The institution name cannot be blank | | 4901 `INSTITUTION_NAME_LENGTH` | The institution name must not exceed 256 characters | | 4902 `BLANK_DECIMAL_SEPARATOR` | The decimal separator must not be blank | | 4903 `INVALID_DECIMAL_SEPARATOR` | The value of the decimal separator must be either `POINT` or `COMMA` | | 4904 `BLANK_DATE` | The local date format must not be blank | | 4905 `INVALID_DATE_FORMAT` | The local date format must use the appropriate ISO 8601 characters | | 4906 `HAS_INVALID_DATE_CHARACTER` | An invalid character was found in the local date format. The local date format must use the appropriate ISO 8601 characters | | 4907 `MISSING_REQUIRED_DATE_CHARACTER` | The local date format must use the appropriate ISO 8601 characters | | 4908 `BLANK_DATE_TIME` | The local date time format must not be blank | | 4909 `INVALID_DATE_TIME_FORMAT` | The local date time format must use the appropriate ISO 8601 characters | | 4910 `HAS_INVALID_DATE_TIME_CHARACTER` | An invalid character was found in the local date time format. The local date time format must use the appropriate ISO 8601 characters | | 4911 `MISSING_REQUIRED_DATE_TIME_CHARACTER` | The local date time format must use the appropriate ISO 8601 characters | | 4950 `INVALID_TERMINATION_DATE` | | | 4951 `LOAN_ACCOUNT_ALREADY_FULLY_PAID` | | | 4952 `TERMINATE_LOAN_ACCOUNT_FEATURE_DISABLED` | | | 4953 `LATE_REPAYMENT_FEES_PRODUCT_NOT_ALLOWED` | | | 4954 `LOAN_ACCOUNT_SCHEDULE_EDITING_NOT_ALLOWED` | | | 4955 `AGGREGATOR_INSTALLMENT_ALREADY_HAS_CUSTOM_DUE_DATE` | | | 4956 `TERMINATED_ACCOUNT_DOES_NOT_ALLOW_EDITING_AGGREGATOR_INSTALLMENT` | | | 4957 `INVALID_SETUP_OF_LOAN_ACCOUNT_TO_TERMINATE` | | | 4958 `LOAN_ACCOUNT_TERMINATION_AFTER_LAST_INSTALLMENT_DUE_DATE` | | ## 5000 |Response Code|Description| |---|---| | 5014 `ROLE_ID_ALREADY_IN_USE` | | | 5015 `INVALID_CHARACTERS_IN_ROLE_ID` | | | 5016 `ROLE_NAME_ALREADY_IN_USE` | | | 5017 `REMOVED_ADMIN_FOR_CURRENT_USER` | | | 5018 `ADDED_ADMIN_FOR_CURRENT_USER` | | | 5019 `REMOVED_MAMBU_ACCESS_RIGHT_FOR_CURRENT_USER` | | | 5020 `MISSING_REQUIRED_BRANCH` | | | 5021 `A_TELLER_CAN_SEE_ONLY_ONE_BRANCH` | | | 5022 `CANNOT_REMOVE_TELLER_PROPERTY` | | | 5023 `CANNOT_CHANGE_BRANCH_ASSIGNMENT` | | | 5024 `CANNOT_DELETE_TELLER` | | | 5025 `A_TELLER_CANNOT_BE_ADMINISTRATOR` | | | 5026 `CREDIT_OFFICER_PROPERTY_REMOVED` | | | 5027 `CREDIT_OFFICER_PROPERTY_REMOVED_FROM_ROLE` | | | 5028 `USER_BRANCH_CHANGE` |You cannot change a branch or a user with clients of groups assigned. | | 5029 `USER_DEACTIVATED` |You cannot deactivate a credit officer with clients or groups assigned. | | 5030 `USER_DELETED` |You cannot delete a credit officer with clients or groups assigned.| | 5031 `SUPPORT_ROLE_CANNOT_BE_ASSIGNED_TO_AN_ADMINISTRATOR` | | | 5032 `SUPPORT_ROLE_CANNOT_BE_ASSIGNED_TO_A_TELLER` | | | 5033 `SUPPORT_ROLE_CANNOT_BE_ASSIGNED_TO_A_REGULAR_USER` | | | 5034 `SUPPORT_ROLE_NAME_CANNOT_BE_CHANGED` | It is not possible to change the name of the Support role | | 5035 `SUPPORT_ROLE_USER_RIGHTS_CANNOT_BE_CHANGED` | It is not possible to change Support role user rights | | 5036 `SUPPORT_ROLE_PERMISSIONS_MUST_BE_VIEW_ONLY` | It is only possible to assign view only permissions to the Support role | | 5037 `INVALID_ROLE_NAME` | The role name is a required field for a role | | 5038 `ROLES_CONFIGURATION_EMPTY` | The roles configuration cannot be empty | | 5039 `INVALID_ROLE_ID` | The role ID is a required field for a role | | 5040 `ROLE_IN_USE` | It is not possible to delete a role that is currently assigned to a user | | 5041 `SUPPORT_ROLE_CANNOT_BE_DELETED` |It is not possible to delete the Support role | | 5042 `NULL_OR_EMPTY_ID` | | | 5043 `MISSING_ROLE_NAME` | | | 5044 `DELIVERY_ROLE_CANNOT_BE_DELETED` | | | 5045 `DELIVERY_ROLE_NAME_CANNOT_BE_CHANGED` | | | 5046 `DELIVERY_ROLE_USER_RIGHTS_CANNOT_BE_CHANGED` | | | 5047 `DELIVERY_ROLE_CANNOT_BE_ASSIGNED_TO_A_REGULAR_USER` | | | 5048 `DELIVERY_ROLE_CANNOT_BE_ASSIGNED_TO_AN_ADMINISTRATOR` | | | 5049 `DELIVERY_ROLE_CANNOT_BE_ASSIGNED_TO_A_TELLER` | | ## 6000 |Response Code|Description| |---|---| | 6000 `HYBRID_GROUP_NOT_AVAILABLE_FOR_DBEI_CAPITALIZED_INTEREST` | Loans with Declining Balance (Equal Installments) and CAPItalized Interest are not available for [Hybrid (solidarity)](/docs/types-of-loan-groups#solidarity-groups) groups, only `forIndividuals` and `forPureGroups`. Set the `forHybridGroups` to false | | 6001 `HYBRID_GROUP_NOT_AVAILABLE_WHEN_REDRAW_ENABLED` | Loan products with a Redraw facility are not available for [Hybrid (solidarity)](/docs/types-of-loan-groups#solidarity-groups) groups. Set the `forHybridGroups` to false | | 6002 `PRODUCT_LINKING_NOT_AVAILABLE_WHEN_REDRAW_ENABLED` | Product linking is not available when the Redraw facility has been enabled | | 6003 `FUNDING_SOURCES_NOT_AVAILABLE_WHEN_REDRAW_ENABLED` | Loan accounts with a Redraw facility cannot be financed by a p2p funding source | | 6004 `TAXES_NOT_AVAILABLE_WHEN_REDRAW_ENABLED` | It is not possible to apply taxes to an account with a redraw facility enabled. Set `taxesOnInterestEnabled`, `taxesOnFeesEnabled`and `taxesOnPenaltyEnabled` to false or remove them from your request | | 6005 `REDRAW_AND_OFFSET_SETTINGS_ENABLED_SIMULTANEOUSLY` | A loan account can only have either the redraw or offset facility enabled, not both | | 6006 `HYBRID_GROUP_NOT_AVAILABLE_FOR_OFFSET_LOAN` | Products with offset enabled are not available for hybrid (solidarity) groups | | 6007 `INCONSISTENT_OFFSET_SETTINGS_WITH_PRODUCT_TYPE` | Offset settings are not available for the specified product type | | 6008 `INCONSISTENT_OFFSET_SETTINGS_WITH_OFFSET_FEATURE` | Offset settings are not available when offset feature is disabled | | 6009 `PRODUCT_LINKING_IS_MANDATORY_WHEN_OFFSET_ENABLED` |Offset settings are enabled and product linking is not defined | | 6010 `LINKED_DEPOSIT_PRODUCT_DOES_NOT_ALLOW_OFFSET` | Linked deposit product doesn’t allow offset | | 6011 `LINKED_DEPOSIT_PRODUCT_DOES_NOT_EXIST` | Linked deposit product doesn’t exist | | 6012 `FUNDING_SOURCES_NOT_AVAILABLE_WHEN_OFFSET_ENABLED` | Funding sources are not supported when offset is enabled| | 6013 `TAXES_NOT_AVAILABLE_WHEN_OFFSET_ENABLED` | Taxes are not supported when offset is enabled | | 6014 `ACCOUNT_HAS_POSITIVE_OR_ZERO_BALANCE` | | | 6015 `ACCOUNT_DOES_NOT_ALLOW_OVERDRAFT` | | | 6016 `INVALID_NOTES_LENGTH` | | | 6017 `WITHDRAWAL_AMOUNT_GREATER_THAN_DUE_AMOUNT` |This error can appear if **Withdrawal Redraw Limitation** has been enabled for a loan account with **Redraw Balance** enabled and the account holder attempts to withdraw an amount which will bring their total redraw balance to less than the amount due for the next monthly repayment | | 6018 `FEE_AMORTIZATION_FREQUENCY_CANNOT_BE_CHANGED` | | | 6019 `FEE_AMORTIZATION_PROFILE_IS_NOT_PROVIDED` | | | 6020 `WITHDRAWAL_AMOUNT_GREATER_THAN_DUE_AMOUNT` | | | 6021 `WITHDRAWAL_COVERING_LATE_REPAYMENTS_NOT_ALLOWED_WITHOUT_REDRAW_REPAYMENT` | | | 6022 OFFSET_NOT_ALLOWED_FOR_PRODUCT_IN_FOREIGN_CURRENCY | | | 6030 `INTEREST_RATE_CHANGED_TRANSACTION_NOT_ALLOWED_FOR_DEPOSIT_PRODUCT_SETTINGS` | | | 6031 `BLOCKED_BALANCE_SHOULD_BE_ZERO_OR_NULL` | | | 6033 `INTEREST_RATE_CHANGED_NOT_ALLOWED_INTEREST_APPLIANCE_TRANSACTIONS_AFTER_VALUE_DATE` | | | 6100 `FORWARD_AVAILABLE_BALANCE_SHOULD_BE_ZERO_OR_NULL` | | ## 7000 |Response Code|Description| |---|---| | 7000 `CUSTOM_FIELD_DEFAULT_SET_CANNOT_BE_MORE_THAN_ONE` | There cannot be more than one default custom field set | | 7001 `CUSTOM_FIELD_DEFAULT_SET_ID_CANNOT_BE_CHANGED` | The ID of a default custom field set cannot be changed | | 7002 `CUSTOM_FIELD_DEFAULT_SET_NAME_CANNOT_BE_CHANGED` | The name of a default custom field set cannot be changed | | 7003 `CUSTOM_FIELD_DEFAULT_DESCRIPTION_CANNOT_BE_CHANGED` | The description of a default custom field set cannot be changed | | 7004 `CUSTOM_FIELD_DEFAULT_SET_TYPE_CANNOT_BE_CHANGED` | The type of a default custom field set cannot be changed | | 7005 `CUSTOM_FIELD_SET_BLANK_ID` | The ID for a custom field set must not be blank | | 7006 `CUSTOM_FIELD_SET_INVALID_ID_LENGTH` | The ID of a custom field set must not exceed 32 characters | | 7007 `CUSTOM_FIELD_SET_INVALID_ID_FORMAT` | The ID of a custom field set must contain only characters that are alpha-numeric, dash, or underscore | | 7008 `CUSTOM_FIELD_SET_MISSING_ID_PREFIX` | The ID of a custom field set must begin with an underscore `_` which is the custom Mambu prefix | | 7009 `CUSTOM_FIELD_SET_DUPLICATE_ID` | The ID of a custom field set must be unique | | 7010 `CUSTOM_FIELD_SET_ID_RESERVED_KEYWORD` | | | 7011 `CUSTOM_FIELD_SET_BLANK_NAME` | The name of a custom field set must not be blank | | 7012 `CUSTOM_FIELD_SET_NAME_LENGTH` | The name of a custom field set must not exceed 32 characters | | 7013 `CUSTOM_FIELD_SET_DUPLICATE_NAME` | The name of a custom field set must be unique | | 7014 `CUSTOM_FIELD_SET_TYPE_REQUIRED` | The type of a custom field set must not be null, it must be SINGLE or GROUPED | | 7015 `CUSTOM_FIELD_SET_TYPE_CANNOT_BE_CHANGED` | The type of a custom field set cannot be changed because the custom field set has at least one custom field defined | | 7016 `CUSTOM_FIELD_SET_AVAILABLE_FOR_REQUIRED` | The `availableFor` field is required for a custom field set | | 7017 `CUSTOM_FIELD_SET_AVAILABLE_FOR_CANNOT_BE_CHANGED` | The `availableFor` field of a custom field set cannot be changed | | 7018 `CUSTOM_FIELD_BLANK_ID` | The ID of a custom field must not be blank | | 7019 `CUSTOM_FIELD_INVALID_ID_LENGTH` | The ID of a custom field must not exceed 32 characters | | 7020 `CUSTOM_FIELD_INVALID_ID_FORMAT` | The ID of a custom field must contain only characters that are alpha-numeric, dash, or underscore | | 7021 `CUSTOM_FIELD_DUPLICATE_ID` | The ID of a custom field must be unique | | 7022 `CUSTOM_FIELD_BLANK_NAME` | The name of a custom field must not be blank | | 7023 `CUSTOM_FIELD_NAME_LENGTH` | The `displayName` length of a custom field must not exceed 256 characters | | 7024 `CUSTOM_FIELD_DUPLICATE_NAME` | The `displayName` of a custom field must be unique | | 7025 `CUSTOM_FIELD_DEPENDENT_INVALID_TYPE_FOR_FIELD_WITH_DEPENDENT_FIELD` | A field that has a dependent field must be of type SELECTION | | 7026 `CUSTOM_FIELD_DEPENDENT_FIELD_DOES_NOT_EXIST_IN_SET` | The dependent field ID must exists in the custom field set. A dependent field ID that does not exist in the custom field set was found | | 7027 `CUSTOM_FIELD_DEPENDENT_INVALID_TYPE_FOR_THE_DEPENDENT_FIELD` | The dependent field defined by the dependent field ID must be of type SELECTION | | 7028 `CUSTOM_FIELD_SELECTIONS_OPTION_CANNOT_BE_DELETED` | The selection option cannot be deleted because it is in use | | 7029 `CUSTOM_FIELD_SELECTIONS_FOR_SELECTION_ID_PRESENT_BUT_NO_DEPENDENT_FIELD` | The `forSelectionId` field should only be specified when the selection custom field has a dependent field ID defined | | 7030 `CUSTOM_FIELD_SELECTIONS_DEPENDENT_FIELD_PRESENT_BUT_FOR_SELECTION_IS_MISSING` | The `forSelectionId` field does not have an ID specified | | 7031 `CUSTOM_FIELD_SELECTIONS_FOR_SELECTION_ID_COULD_NOT_BE_FOUND`

`_IN_THE_DEPENDENT_FIELD` | The ID specified in the `forSelectionId` field of a dependent custom field could not be found in the parent custom field | | 7032 `CUSTOM_FIELD_SELECTIONS_DUPLICATED_SELECTION_IDS` | The ID of a selection option of a selection custom field must be unique | | 7033 `CUSTOM_FIELD_SELECTIONS_SELECTION_ID_SHOULD_NOT_BE_EMPTY` | The ID of a selection option of a selection custom field cannot be empty | | 7034 `CUSTOM_FIELD_SELECTIONS_SELECTION_ID_CONTAINS_INVALID_CHARACTERS` | [THIS ERROR DOESN'T TELL YOU WHAT THE RIGHT ERRORS ARE!] | | 7035 `CUSTOM_FIELD_SELECTIONS_INVALID_SCORE_NUMBER` | An invalid score number was provided. The score must be a number with a maximum 19 digits | | 7036 `CUSTOM_FIELD_SELECTIONS_DEPENDENT_FIELD_OPTIONS_NOT_COVERED` | Options in the parent field are not covered in the dependent field | | 7037 `CUSTOM_FIELD_SELECTIONS_DUPLICATE_OPTION_VALUES` | The value of a selection option of a selection custom field must be unique. A duplicate was found | | 7038 `CUSTOM_FIELD_SELECTIONS_VALUE_CANNOT_BE_EMPTY` | The value of a selection option of a selection custom field cannot be empty | | 7039 `CUSTOM_FIELD_SELECTIONS_CIRCULAR_DEPENDENCY` | | | 7040 `CUSTOM_FIELD_SELECTION_OPTIONS_ARE_REQUIRED` | Selection options are required for a selection custom field | | 7041 `CUSTOM_FIELD_ACCESS_RIGHTS_INVALID_ROLE_ID` | A role ID was provided in `editRights` or `viewRights` for a role that does not exist | | 7042 `CUSTOM_FIELD_SUPPORT_ROLE_INVALID_RIGHTS` | The Mambu support role cannot have edit rights | | 7043 `CUSTOM_FIELD_BLANK_ROLE_ID` | The role ID is required and cannot be blank. At least one role ID defined for `viewRights` or `editRights` that is blank | | 7044 `CUSTOM_FIELD_USAGE_BLANK_ID` | The usage ID is required and cannot be blank. At least one usage field that has a blank or missing ID | | 7045 `CUSTOM_FIELD_USAGE_ID_NOT_FOUND` | The usage ID must exist | | 7046 `CUSTOM_FIELD_INVALID_USAGE_FOR_RECORD_TYPE` | If a custom field is required, it must be default as well. At least one invalid usage defined | | 7047 `CUSTOM_FIELD_INVALID_USAGE_FOR_FIELD` | There is an invalid usage configuration. If a custom field is required, it must be default as well | | 7048 `CUSTOM_FIELD_USAGE_FOR_RECORD_TYPE_NOT_ALLOWED` | This custom field type doesn't support defining the usage for different record types, you must define the usage for the custom field as a whole. This is either because the `availableForAll` field is set to `true` or because the custom field type is not one of the types that allows for defining the usage per record type. The types that allow defining usage per record type are CLIENT, GROUP, LOAN_ACCOUNT, DEPOSIT_ACCOUNT DEPOSIT_PRODUCT, TRANSACTION_CHANNEL and TRANSACTION_TYPE | | 7049 `CUSTOM_FIELD_USAGE_FOR_RECORD_TYPE_REQUIRED` | If a custom field is required then you must define usage settings. If you want to define the same usage settings and make the custom field available for all record types, you must set only the usage on the custom field level, via the default and required fields, and it will apply for all available records types. If you want to define different usage settings for each record type, then only the list of record types and their settings must be provided. The custom field will be available with the given settings only for the records specified in the list by ID. These settings are mutually exclusive and cannot be set at the same time | | 7050 `CUSTOM_FIELD_SELECTION_USAGE_NOT_ALLOWED` | For selection custom fields that are a dependent fields, the usage is inherited from the parent field and the `usage` field must not be defined | | 7051 `CUSTOM_FIELD_SELECTION_REQUIRED_NOT_ALLOWED` | For selection custom fields that are a dependent fields, the usage is inherited from the parent field and the `required` field must not be defined | | 7052 `CUSTOM_FIELD_SELECTION_DEFAULT_NOT_ALLOWED` | For selection custom fields that are a dependent fields, the usage is inherited from the parent field and the `default` field must not be defined | | 7053 `CUSTOM_FIELD_BLANK_TYPE` | The type of a custom field must not be blank | | 7054 `CUSTOM_FIELD_TYPE_CHANGED` | The type of a custom field cannot be changed | | 7055 `CUSTOM_FIELD_VALIDATION_RULES_NOT_ALLOWED` | Validation rules can be defined only for string custom fields | | 7056 `CUSTOM_FIELD_VALIDATION_RULES_DUPLICATE_VALUES` | | | 7057 `CUSTOM_FIELD_STATE_REQUIRED` | Custom field state cannot be null. It must be either ACTIVE or INACTIVE | | 7058 `CUSTOM_FIELD_DISPLAY_SETTINGS_REQUIRED` | The `displaySettings` of a custom field are required and cannot be blank | | 7059 `CUSTOM_FIELD_DESCRIPTION_LENGTH_EXCEEDED` | The description length of a custom field must not exceed 256 characters | | 7060 `CUSTOM_FIELD_SIZE_REQUIRED` | The `fieldSize` of a custom field is required and cannot be blank | | 7061 `CUSTOM_FIELD_SET_BUILT_IN_USAGE` | | | 7062 `CUSTOM_FIELD_DUPLICATE_USAGE_ID` | The IDs defined in the `usage` of a custom field must be unique | | 7063 `CUSTOM_FIELD_DUPLICATE_ROLE_ID` | Role IDs defined in the `viewRights` and `editRights` of a custom field must be unique | | 7064 `CUSTOM_FIELD_ACCESS_RIGHTS_REQUIRED` | The `viewRights` and `editRights` of a custom field are required and cannot be null | | 7065 `CUSTOM_FIELD_ACCESS_RIGHTS_ROLES_REQUIRED` | If `allUsers` is set to `false` then the roles for `viewRights` or `editRights` are required and cannot be null | | 7066 `CUSTOM_FIELD_ACCESS_RIGHTS_ALL_USERS_REQUIRED` | The `allUsers` field for `viewRights` and `editRights` is required and cannot be null | | 7067 `CUSTOM_FIELD_ACCESS_RIGHTS_ALL_USERS_FALSE_WHEN_ROLES_SPECIFIED` | The `allUsers` for `viewRights` or `editRights` should be `false` when some roles are specified in the `roles` field | | 7068 `CUSTOM_FIELD_SELECTION_OPTIONS_NULL` | A selection option in a selection custom field cannot be null. At least one null entry was detected | | 7069 `CUSTOM_FIELD_AVAILABLE_OPTIONS_NULL` | An available option in a selection custom field cannot be null. At least one null entry was detected | | 7070 `CUSTOM_FIELD_NULL_USAGE` | A usage entry cannot be null. At least one null entry was detected | | 7071 `CUSTOM_FIELD_SET_NULL_FIELD` | A custom field set cannot be null. At least one null entry was detected | | 7072 `CUSTOM_FIELDS_CONFIGURATION_EMPTY` | The custom field configuration cannot be empty | | 7073 `CUSTOM_FIELD_SET_NULL_ENTRY` | Custom field sets cannot have null entries. At least one null entry was detected | | 7074 `CONFIGURATION_AS_CODE_UPDATE_IN_PROGRESS` | | | 7075 `CUSTOM_FIELD_RESERVED_ID` | | | 7099 `CONFIGURATION_AS_CODE_FEATURE_DISABLED` | | | 7100 `PREPAYMENT_RECALCULATION_METHOD_ON_REPAYMENT_NOT_ALLOWED_FOR_LOAN_ACCOUNT`|Loan account does not allow to choose prepayment recalculation method at repayment time, the repayment method is generally set at the product level | | 7101 `PREPAYMENT_RECALCULATION_METHOD_ON_REPAYMENT_NOT_SUPPORTED` | | | 7102 `CONFLICT_BETWEEN_EDIT_SCHEDULE_OPERATIONS_AND_ATTEMPTED_PREPAYMENT_RECALCULATION_METHOD` | | | 7103 `CONFLICT_BETWEEN_PREPAYMENT_RECALCULATION_METHOD_FROM_TRANSACTIONS_AND_NEW_SCHEDULE_EDIT` | | | 7104 `EDITING_INSTALLMENTS_DUE_BEFORE_LAST_PAID_INSTALLMENT_IS_NOT_ALLOWED` | | | 7200 `INVALID_INSTALLMENT_KEY` | | | 7201 `INVALID_REPAYMENT_AMOUNT_FOR_SPECIFIC_INSTALLMENT` | | | 7202 `SPECIFIC_INSTALLMENT_REPAYMENTS_NOT_ALLOWED_IF_GENERIC_REPAYMENTS_EXIST` | | | 7203 `GENERIC_REPAYMENTS_NOT_ALLOWED_IF_SPECIFIC_INSTALLMENT_REPAYMENTS_EXIST` | | | 7204 `INSTALLMENT_ALREADY_PAID` | | | 7205 `PREPAYMENT_RECALCULATION_METHOD_NOT_SUPPORTED` | | | 7206 `ONLY_IOI_METHOD_SUPPORTED` | | | 7207 `ACCRUE_LATE_INTEREST_NOT_SUPPORTED` | | | 7208 `ONLY_PARTIALLY_PAID_STATUS_SUPPORTED` | | | 7209 `ONLY_NO_PENALTY_PRODUCTS_SUPPORTED` | | | 7210 `ACCOUNT_IS_LOCKED` | | | 7211 `ONLY_STANDARD_PAYMENTS_SUPPORTED` | | | 7212 `ARBITRARY_FEES_NOT_SUPPORTED` | | | 7213 `TAXES_ON_INTEREST_NOT_SUPPORTED` | | | 7214 `REPAYMENT_DUE_DATE_DUPLICATED` | | | 7215 `TAXES_ON_FEE_NOT_SUPPORTED` | | | 7216 `CHANGING_NO_OF_POSITIVE_PRINCIPAL_INSTALLMENTS_NOT_ALLOWED` | | | 7217 `INSTALLMENTS_ADJUSTMENT_DETAILS_NOT_EXPECTED` | When adjusting a transaction, installments adjustment details are expected only when the transaction type is either Fee Due Reduced or Penalty Due Reduced and product type is Fixed Term | | 7218 `INSTALLMENTS_ADJUSTMENT_DETAILS_NOT_EXPECTED_BULK` | Installments adjustment details are not expected when adjustment affects multiple transactions | | 7219 `INSTALLMENTS_ADJUSTMENT_DETAILS_MISSING` | When adjusting a transaction, installments adjustment details must be present in request body for Fixed Term loan product type and Fee / Penalty Due Reduced transaction type | | 7220 `INSTALLMENT_KEY_NOT_FOUND` | When adjusting a transaction of type Fee / Penalty Due Reduced, for Fixed Term product type and the installment encoded key from input request body is invalid | | 7221 `INSTALLMENT_KEY_DUPLICATED` | When adjusting a transaction of type Fee / Penalty Due Reduced, for Fixed Term product type and the installment encoded key appears multiple times in input request body | | 7222 `INSTALLMENT_STATE_NOT_ALLOWED` | When adjusting a transaction of type Fee / Penalty Due Reduced, for Fixed Term product type and the installment received in the input request body is not in one of the editable states (PARTIALLY_PAID, LATE, PENDING) | | 7302 `S3_REGION_NOT_FOUND` | | | 7400 `DUPLICATE_BLOCK_ID` | A block fund is already specified with the ID specified on the deposit account | | 7401 `INVALID_BLOCK_FUND_STATE` | When trying to execute an action over a block fund with an invalid state | | 7402 `BLOCK_FUND_DOES_NOT_EXIST` | When trying to execute an action over a block fund that does not exist | | 7250 `NOT_ALLOWED_FOR_CURRENT_ACCOUNT_TYPE` | | | 7251 `NOT_ALLOWED_BEFORE_ACTIVATION_DATE` | | | 7252 `NOT_ALLOWED_BEFORE_OR_DURING_PAID_INSTALLMENT` | | | 7301 `GET_NOTIFICATION_MESSAGE_UPDATE_FAILURE` | | | 7500 `INVALID_TRANSACTION_CHANNEL_ID` | | | 7501 `INVALID_ACCOUNTING_METHOD` | | | 7502 `MISSING_RULE` | | | 7503 `NOT_REQUIRED_RULE` | | | 7504 `HEADER_ACCOUNT_NOT_ALLOWED` | | | 7505 `INVALID_GLACCOUNT_TYPE` | | | 7506 `RULE_WITHOUT_GLACCOUNT` | | | 7507 `INVALID_INTEREST_ACCRUED_METHOD` | | | 7508 `GLACCOUNTS_ARE_NOT_IN_ORGANIZATION_OR_PRODUCT_CURRENCY` | | | 7509 `INCONSISTENT_GLACCOUNTS_CURRENCY_SETUP` | | | 7510 `INCONSISTENT_FEE_GLACCOUNTS_CURRENCY_SETUP` | | | 7511 `INVALID_GL_ACCOUNT_CURRENCY` | | | 7512 `CANNOT_EDIT_GL_ACCOUNT_CURRENCY_AS_ACCOUNT_IS_IN_USE` | | | 7513 `FOREIGN_CURRENCY_IS_NOT_ALLOWED` | | | 7514 `INEXISTING_GLACCOUNT` | | | 7515 `GLACCOUNTS_ARE_NOT_IN_PRODUCT_CURRENCY` | | | 7550 `CHANGE_ARREARS_SETTINGS_NOT_ALLOWED_FOR_PRODUCT_TOLERANCE_CALCULATION_METHOD` | | | 7600 `BULK_API_REQUEST_SIZE_LIMIT_REACHED` | | | 7700 `INVALID_BULK_PROCESS_KEY` | | | 7701 `POSITIVE_AMOUNT_REQUIRED` | | | 7702 `ID_NOT_UNIQUE` | | | 7703 `ENCODED_KEY_NOT_FOUND` | | | 7800 `CHANGE_MONTHLY_REPAYMENT_DAY_NOT_ALLOWED_FOR_ACCOUNTS_WITH_CUSTOM_SCHEDULE` | | | 7801 `CHANGE_MONTHLY_REPAYMENT_DAY_ALLOWED_ONLY_FOR_ACCOUNTS_WITH_A_SINGLE_FIXED_DAY_OF_MONTH` | | | 7820 `INVALID_INTEREST_ROUNDING_VERSION` | | | 7830 `FEE_NOT_AVAILABLE_FOR_PRODUCT` | | | 7900 `MAXIMUM_DEPOSIT_BALANCE_EXCEEDED` | | | 7901 `MAXIMUM_DEPOSIT_BALANCE_FEATURE_DISABLED` | | | 7902 `MAX_DEPOSIT_BALANCE_NOT_AVAILABLE_FOR_INVESTOR_ACCOUNTS` | | ## 8100 Interest Availability Error Codes |Response Code|Description| |---|---| | 8101 `INTEREST_TYPE_NOT_SUPPORTED` | When the provided interest type is not supported for Interest Availabilities| | 8102 `PRODUCT_DOES_NOT_ALLOW_INTEREST_SETTINGS` | When trying to create Interest Availability for an account, but paidIntoAccount in the interest settings of a deposit product is set to false| | 8103 `PRODUCT_DOES_NOT_ALLOW_NEGATIVE_INTEREST_RATE` | The deposit product interest settings does not allow negative interest rate| | 8104 `INVALID_INTEREST_RATE_SETTINGS` | The interest rate settings provided for Interest Availabilities are invalid. The text parameter should include more details| | 8105 `DELETE_FIRST_INTEREST_AVAILABILITY_NOT_ALLOWED` | The first chronological interest availability for a savings account cannot be deleted| | 8106 `INTEREST_AVAILABILITY_DOES_NOT_BELONG_TO_SAVINGS_ACCOUNT` | The interest availability with the provided key does not belong to the savings account| | 8107 `INTEREST_RATE_TERMS_NOT_SUPPORTED` | When the interest rate terms are not supported for Interest Availabilities| | 8108 `OPERATIONS_ON_BACKDATED_INTEREST_AVAILABILITY_NOT_ALLOWED_FOR_CURRENT_ACCOUNT_STATE` | Operations on interest availabilities are not allowed for the current account state| | 8109 `BULK_INTEREST_AVAILABILITY_ACCOUNTS_LIMIT_REACHED` | You have reached the limit of account keys that can be provided to the interest availability bulk endpoint| ## 8000 |Response Code|Description| |---|---| | 8000 `INTEREST_ACCRUAL_BREAKDOWN_INTERNAL_ERROR` | | | 8001 `INTEREST_ACCRUAL_BREAKDOWN_BAD_REQUEST` | | | 8500 `BRANCHES_CONFIGURATION_EMPTY` | The branches configuration in the request body must not be empty | | 8501 `NULL_BRANCH_ENTRY` | Branches must not be null. At least one null entry was detected | | 8502 `BRANCH_NAME_LENGTH` | The name of the branch must not exceed 256 characters. The error will provide the ID of the branch | | 8503 `BLANK_BRANCH_NAME` | The name of the branch must not be blank. The error will provide the ID of the branch | | 8504 `BRANCH_ID_LENGTH` | The ID of the branch must not exceed 32 characters. The error will provide the ID of the branch | | 8505 `BLANK_BRANCH_ID` | The ID of the branch must not be blank. The error will provide the index of the branch | | 8506 `DUPLICATE_BRANCH_ID` |The ID of the branch must be unique. The error will provide the ID of the branch | | 8507 `BRANCH_EMAIL_FORMAT` | The email of the branch is not in the correct format. A valid email address consists of an email prefix before the @ sign and an email domain after the sign. The email prefix must not exceed 64 characters. The email domain must not exceed 63 characters. The error will provide the ID of the branch | | 8508 `BRANCH_EMAIL_LENGTH` | The length of the email address of the branch must not exceed 256 characters. The error will provide the ID of the branch | | 8509 `BRANCH_PHONE_LENGTH` | The phone number of the branch must not exceed 256 characters. The error will provide the ID of the branch | | 8510 `ADDRESS_FIELD_LENGTH` | The address field of the branch must not exceed 256 characters. The error will provide the ID of the branch | | 8511 `BLANK_HOLIDAY_ID` | The ID of the holiday must not be blank. The error will provide the index of the holiday and the ID of the branch | | 8512 `INVALID_HOLIDAY_ID` | The ID of the holiday must be within the range of 1 and 2,147,483,647. The error will provide the ID of the holiday and the ID of the branch | | 8513 `DUPLICATE_HOLIDAY_ID` | The ID of the holiday must be unique. The error will provide the ID of the branch and the ID of the holiday | | 8514 `BLANK_HOLIDAY_NAME` | The name of the holiday must not be blank. The error will provide the ID of the branch and the ID of the holiday | | 8515 `HOLIDAY_NAME_LENGTH` | The name of the holiday must not exceed 256 characters. The error will provide the ID of the branch and the ID of the holiday | | 8516 `HOLIDAY_DAY_OF_MONTH_ERROR` | The `dayOfMonth` of the holiday must not be blank and must be between 1 and 31. The error will provide the ID of the branch and the ID of the holiday | | 8517 `HOLIDAY_MONTH_OF_YEAR_ERROR` | The `monthOfYear` of the holiday must not be blank and must be between 1 and 12. The error will provide the ID of the branch and the ID of the holiday | | 8518 `HOLIDAY_YEAR_ERROR` | The `year` of the holiday must not be blank and must be between 1900 and 9999. The error will provide the ID of the branch and the ID of the holiday | | 8519 `HOLIDAY_VALID_DATE_ERROR` | The combination of the `dayOfMonth`, `monthOfYear`, or `year` of the holiday is not a valid date. The error will provide the ID of the branch and the ID of the holiday | | 8520 `CANNOT_DEACTIVATE_BRANCH` | The branch cannot be deactivated because it has active centres. The error will provide the ID of the branch | | 8700 `CENTRE_CONFIGURATION_EMPTY` | The centre configuration in the request body must not be empty | | 8701 `CENTRE_ID_LENGTH` | The ID of the centre must not exceed 32 characters. The error will provide the ID of the centre | | 8702 `BLANK_CENTRE_ID` | The ID of the centre must not be blank. The error will provide the index of the centre | | 8703 `DUPLICATE_CENTRE_ID` | The ID of the centre must be unique. The error will provide the ID of the centre | | 8704 `CENTRE_NAME_LENGTH` | The name of the centre must not exceed 256 characters. The error will provide the ID of the centre | | 8705 `BLANK_CENTRE_NAME` | The name of the centre must not be blank. The error will provide the ID of the centre | | 8706 `INVALID_CENTRE_MEETING_DAY` | The meeting day of the centre cannot be a non-working day of the organization. The error will provide the ID of the centre | | 8707 `BLANK_CENTRE_BRANCH_ID` | The branch ID of the centre must not be blank. The error will provide the ID of the centre | | 8708 `BRANCH_IS_INACTIVE` | The `assignedBranchId` value of the centre must not be that of an inactive branch. The error will provide the ID of the centre | | 8709 `BRANCH_DOES_NOT_EXIST` | The `assignedBranchId` value of the centre must be that of an existing branch. The error will provide the ID of the centre | | 8710 `CENTRE_STATE_BLANK` | The state of the centre must not be blank. The error will provide the ID of the centre | | 8712 `NULL_CENTRE_ENTRY` | Centres cannot be null. At least one null entry was detected | ## 8800 - 9039 Deposit product configuration | Response Code | Description | |---|---| | 8800 `DEPOSIT_PRODUCT_CONFIGURATION_EMPTY` | The deposit products configuration cannot be empty | | 8801 `BLANK_DEPOSIT_PRODUCT_NAME` | The deposit product name cannot be null or empty | | 8802 `BLANK_DEPOSIT_PRODUCT_ID` | The deposit product ID cannot be null or empty | | 8803 `DEPOSIT_PRODUCT_ID_LENGTH` | The deposit product ID length must not exceed 32 characters | | 8804 `DEPOSIT_PRODUCT_DUPLICATE_ID` | The deposit product ID must be unique. | | 8805 `DEPOSIT_PRODUCT_CONFIGURATION_NULL_ENTRY` | Deposit products cannot be null. At least one null entry was detected | | 8806 `DEPOSIT_PRODUCT_NAME_LENGTH` | The deposit product name length must not exceed 255 characters | | 8807 `BLANK_DEPOSIT_PRODUCT_TYPE` | The deposit product type cannot be null or empty | | 8810 `BLANK_DEPOSIT_PRODUCT_NEW_ACCOUNT_SETTINGS` | The new account settings of a deposit product cannot be null | | 8811 `BLANK_DEPOSIT_PRODUCT_ID_PATTERN` | The ID pattern of a deposit product cannot be null | | 8812 `DEPOSIT_PRODUCT_ID_PATTERN_LENGTH` | The deposit product ID pattern length must not exceed 32 characters | | 8813 `DEPOSIT_PRODUCT_INVALID_ID_PATTERN_FORMAT` | If the `idGeneratorType` is `INCREMENTAL_NUMBER`, then the deposit product ID pattern must be a whole positive number | | 8814 `DEPOSIT_PRODUCT_INVALID_ID_PATTERN_NUMBER` | If the `idGeneratorType` is set to `INCREMENTAL_NUMBER`, then the value of the `idPattern` must be between 0 and 2000000000 | | 8815 `BLANK_DEPOSIT_PRODUCT_ID_GENERATOR_TYPE` | The ID generator type cannot be null | | 8820 `DEPOSIT_PRODUCT_AVAILABILITY_SETTINGS_BLANK` | The availability settings of a deposit product cannot be blank | | 8821 `DEPOSIT_PRODUCT_BRANCH_AVAILABILITY_SETTINGS_BLANK` | The branch availability settings of a deposit product cannot be blank | | 8822 `DEPOSIT_PRODUCT_AVAILABILITY_ALL_BRANCHES_BLANK` | The `allBranches` flag cannot be blank | | 8823 `DEPOSIT_PRODUCT_AVAILABILITY_BRANCH_DOES_NOT_EXIST` | The branches listed in the `branches` array in the `branchSettings` of a deposit product must already exist | | 8824 `DEPOSIT_PRODUCT_AVAILABILITY_ALL_BRANCHES_FALSE` | If the `allBranches` flag is set to false, then there should be branch IDs defined in the `branches` array | | 8825 `DEPOSIT_PRODUCT_AVAILABILITY_ALL_BRANCHES_TRUE` | If the `allBranches` flag is set to true, then there should be no branch IDs defined in the `branches` array | | 8826 `DEPOSIT_PRODUCT_AVAILABILITY_DUPLICATE_BRANCH` | The branch IDs defined in the `branches` array must be unique. Duplicate entries in the branches list | | 8827 `DEPOSIT_PRODUCT_AVAILABILITY_INACTIVE_BRANCH` | The branches listed in the `branches` array must be active. The branches list contains an inactive branch | | 8828 `DEPOSIT_PRODUCT_AVAILABILITY_FOR_INDIVIDUALS_BLANK` | The `forIndividuals` flag cannot be blank | | 8829 `DEPOSIT_PRODUCT_AVAILABILITY_FOR_GROUPS_BLANK` | The `forGroups` flag cannot be blank | | 8835 `DEPOSIT_PRODUCT_CURRENCY_NOT_DEFINED` | The currencies listed in the `currencies` list must be defined for your tenant | | 8836 `BLANK_DEPOSIT_PRODUCT_CURRENCY` | The currency settings of a deposit product cannot be null | | 8837 `DEPOSIT_PRODUCT_MULTIPLE_CURRENCIES_NOT_ALLOWED` | If you have the `disableMultipleCurrenciesForDepositProducts` feature enabled, then you cannot define more than one currency for a deposit product. In the `currencies` array under `currencySettings`, you must only have one currency defined | | 8840`DEPOSIT_PRODUCT_INVALID_MATURITY_MIN_MAX` | When defining the `maturitySettings`, the `minValue` must not be greater than the `maxValue` | | 8841 `DEPOSIT_PRODUCT_INVALID_WITHHOLDING_TAX_ENABLED` | If `withholdingTaxEnabled` is set to `true`, the `paidIntoAccount` value in the `interestSettings` of a deposit product must also be set to `true` | | 8842 `DEPOSIT_PRODUCT_NEGATIVE_TERM_LENGTH` | The values for the maturity period cannot be negative | | 8843 `DEPOSIT_PRODUCT_FIELD_NOT_EDITABLE` | You are trying to edit a field in the deposit product which cannot be edited because at least one deposit account already exists for this deposit product. Refer to the `errorSource` to determine which field cannot be changed | | 8850 `DEPOSIT_PRODUCT_INTERNAL_CONTROL_DORMANCY_RANGE` | The deposit product dormancy period must be between [0,2000000000] | | 8851 `DEPOSIT_PRODUCT_INTERNAL_CONTROL_RECOMMENDED_AMOUNT_RANGE` | The deposit product recommended deposit amount must be between [0,1999999973982208] | | 8852 `DEPOSIT_PRODUCT_INTERNAL_CONTROL_MAX_WITHDRAWAL_AMOUNT_RANGE` | The deposit product maximum withdrawal amount must be between [0,1999999973982208] | | 8853 `DEPOSIT_PRODUCT_INTERNAL_CONTROL_INVALID_OPENING_BALANCE` | The deposit product internal controls opening balance default value is not in the interval [`minVal`, `maxVal`] | | 8854 `DEPOSIT_PRODUCT_INTERNAL_CONTROL_ALLOW_OFFSET_NOT_AVAILABLE` | If the `type` of a deposit product is set to `INVESTOR_ACCOUNT`, the `allowOffset` value must be set to `false` in the `internalControlsSetting` object | | 8860 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_FREQUENCY` | The deposit product `interestChargeFrequencyCount` cannot be negative | | 8861 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_DAYS_IN_YEAR_METHOD_NOT_ALLOWED` | An invalid value was provided for the `daysInYear` field of a deposit product | | 8862 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_EMPTY_DAYS_IN_YEAR` | If the `paidIntoAccount` in the `interestSettings` of a deposit product is set to `true`, then the deposit product interest settings `daysInYear` method cannot be null | | 8863 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_DEFAULT_INTEREST_RATE` | The default interest rate in the deposit product interest settings cannot be negative | | 8864 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INVALID_INTEREST_RATE_MIN_MAX_DEFAULT_TUPLE` | The default interest rate value in the deposit product interest settings is not in the interval [`minVal`, `maxVal`]. This may also be because the minimum value is great than the maximum value | | 8865 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_MAX_INTEREST_RATE` | The maximum interest rate in the deposit product interest settings cannot be negative | | 8866 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_MIN_INTEREST_RATE` | The minimum interest rate in the deposit product interest settings cannot be negative | | 8867 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_DEFAULT_MIN_MAX_NOT_AVAILABLE` | Given the interest rate settings of a deposit product, it is not possible to define the default, minimum, and maximum value of the interest rate | | 8868 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INDEX_INTEREST_RATE_NOT_AVAILABLE` | The `interestRateSource` can be set to `INDEX_INTEREST_RATE`, only if the `interestRateTerms` are set to `FIXED` | | 8869 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_EMPTY_INDEX_RATE_SOURCE_KEY` | The index rate source key in the deposit product interest settings cannot be empty | | 8870 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_MANDATORY_NEGATIVE_INTEREST_RATE` | The `allowNegativeInterestRate` must be set to true in the deposit product interest settings for index interest rates | | 8871 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INTEREST_RATE_MANDATORY_REVIEW_UNIT` | The interest rate review unit in the deposit product interest settings cannot be null | | 8872 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INTEREST_RATE_MANDATORY_REVIEW_COUNT` | The interest rate review count in the deposit product interest settings cannot be null | | 8873 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INVALID_INTEREST_REVIEW_COUNT` | The interest rate review count in the deposit product interest settings cannot be negative | | 8874 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INDEX_RATE_FOR_REGULAR_INTEREST_FEATURE_DISABLED` | | | 8875 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_READONLY_INTEREST_RATE_TERMS` | The deposit product interest settings interest rate terms are read-only | | 8876 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INDEXED_INTEREST_RATE_SOURCE_DEFINED_FOR_FIXED_INTEREST_RATE_SOURCE` | The deposit product interest settings index source key, review count, and review unit must be null for fixed interest rate | | 8877 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INVALID_MAXIMUM_BALANCE_VALUE` | The maximum balance in the deposit product interest settings cannot be negative | | 8878 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_MAXIMUM_BALANCE_NOT_AVAILABLE` | The deposit product interest settings maximum balance is not available for the interest calculation balance and interest rate terms combination | | 8879 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INTEREST_CALCULATION_BALANCE_METHOD_NOT_ALLOWED` | The interest calculation balance method in the deposit product interest settings cannot be changed | | 8880 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIERED_BAND_NOT_AVAILABLE_FOR_INTEREST` | | | 8881 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIERS_NOT_AVAILABLE` | | | 8882 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_EMPTY_TIERS` | The tiers in the deposit product interest settings cannot be empty if the `interestRateTerms` are set to `TIERED`, `TIERED_BAND`, or `TIERED_PERIOD` | | 8883 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIER_ENDING_DAY_NOT_AVAILABLE` | | | 8884 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIER_NEGATIVE_ENDING_BALANCE` | The tier ending balance in the deposit product interest settings must be a positive number | | 8885 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIER_ENDING_BALANCE_NOT_AVAILABLE` | | | 8886 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIER_NEGATIVE_INTEREST_RATE` | The tier interest rate in the deposit product interest settings must be a positive number | | 8887 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIER_DOES_NOT_ALLOW_NEGATIVE_INTEREST_RATE` | | | 8888 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_TIER_NEGATIVE_ENDING_DAY` | The tier ending day in the deposit product interest settings must be a positive number | | 8889 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_INTEREST_RATE_NOT_ENABLED` | | | 8890 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_INTEREST_RATE_MAMBU_NOT_ENABLED` | | | 8891 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_CANNOT_DISABLE_NEGATIVE_INTEREST_RATE` | The deposit product interest settings negative interest rate feature cannot be disabled | | 8992 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NEGATIVE_INTEREST_RATE_NOT_ALLOWED_FOR_INTEREST_RATE_TERM` | The negative interest rate in the deposit product interest settings is not allowed for the defined value in the `interestRateTerms` | | 8893 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_PRODUCT_TYPE_NOT_ALLOWS_NEGATIVE_INTEREST_RATE` | | | 8994 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_NOT_ALLOWED_WITHHOLDING_TAXES_AND_NEGATIVE_INTEREST_RATE` | The deposit product interest settings cannot have `withholdingTaxEnabled` set to true when `allowNegativeInterestRate` is set to true | | 8995 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_WITHHOLDING_TAX_NOT_AVAILABLE_INTEREST_TIERED_BAND` | If the `interestRateTerms` are set to `TIERED_BAND`, then the `withholdingTaxEnabled` must be false | | 8996 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INTEREST_RATE_SETTINGS_NOT_ALLOWED` | If `paidIntoAccount` in the interest settings of a deposit product is set to `false`, then the `interestRateSettings` cannot be defined for that deposit product | | 8997 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INVALID_DAYS_IN_YEAR_METHOD` | The days in year method in the deposit product interest settings is not supported for this type of account | | 8998 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_INVALID_INDEX_RATE_SOURCE_KEY` | The index rate source key in the deposit product interest settings must already exist | | 8999 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_ENDING_DAY_LESS_THAN_STARTING_DAY` | The deposit product interest rate tier ending day must be greater than the starting day of the previous tier | | 9000 `DEPOSIT_PRODUCT_INTEREST_SETTINGS_ENDING_BALANCE_LESS_THAN_STARTING_BALANCE` | The deposit product interest rate tier balance must be greater than the balance of the previous tier | | 9001 `SAVINGS_FEE_INCOMPATIBLE_INPUT` | The fee name is required. If the `trigger` of a fee is `MANUAL`, an `applyDateMethod` value must not be defined. An invalid monthly fee apply date was found in the configuration | | 9002 `ARBITRARY_SAVINGS_FEE_NOT_ALLOWED` | | | 9003 `SAVINGS_FEE_BLANK_ID` | The fee ID in the `feeSettings` cannot be blank | | 9004 `CANNOT_DELETE_SAVINGS_FEE` | A fee that is used in a transaction cannot be deleted | | 9005 `INTEREST_ACCRUED_METHOD_INVALID` | The account interest accrued method is not permitted. If the `accountingMethod` is set to `CASH`, then the `interestAccruedAccountingMethod` must be set to `NONE` | | 9006 `INVALID_INTEREST_ACCRUAL_CALCULATION` | | | 9007 `ACCOUNTING_RULE_WITHOUT_GLACCOUNT` | Every accounting rule in the accounting settings must have a GL account code defined for a GL account that exists | | 9008 `HEADER_GL_ACCOUNT_NOT_ALLOWED` | | | 9009 `DISABLED_DEPOSIT_INTEREST_FEATURE` | | | 9010 `NOT_REQUIRED_ACCOUNTING_RULE` | An extra accounting rule was defined that is not required for the selected accounting method | | 9011 `INVALID_RULE_GLACCOUNT_TYPE` | An invalid GL account type was defined for an accounting rule | | 9012 `INVALID_GLACCOUNT_CURRENCY` | The GL account defined in an accounting rule is not in an organization or product allowed currency | | 9013 `INCONSISTENT_CURRENCY_SETUP_FOR_GLACCOUNTS` | The GL accounts from accounting setup cannot be in multiple currencies | | 9014 `INCONSISTENT_CURRENCY_SETUP_ON_FEE_GLACCOUNTS` | The GL accounts from fees accounting setup cannot be different from accounting rules setup | | 9015 `MISSING_ACCOUNTING_RULE` | A required accounting rule is missing from the configuration | | 9016 `ACCOUNTING_ACTIONS_NOT_FULLY_DEFINED` | | | 9017 `ACCOUNTING_RULE_CURRENCY_NOT_DEFINED` | | | 9018 `GL_RULE_CURRENCY_NOT_DEFINED` | The GL account defined in an accounting rule does not have a currency | | 9019 `DEPOSIT_PRODUCT_OVERDRAFT_NEGATIVE_MAX_LIMIT` | The deposit product overdraft settings maximum limit cannot be negative | | 9020 `DEPOSIT_PRODUCT_OVERDRAFT_EMPTY_MAX_LIMIT` | The deposit product overdraft settings maximum limit cannot be null | | 9021 `DEPOSIT_PRODUCT_OVERDRAFT_ALLOW_TECHNICAL_OVERDRAFT_CANNOT_BE_DISABLED` | | | 9022 `DEPOSIT_PRODUCT_OVERDRAFT_EMPTY_INTEREST_SETTINGS` | The deposit product overdraft interest rate settings cannot be null | | 9023 `DEPOSIT_PRODUCT_OVERDRAFT_NEGATIVE_MIN_INTEREST_RATE` | The minimum interest rate in the deposit product overdraft settings cannot be negative | | 9024 `DEPOSIT_PRODUCT_OVERDRAFT_NEGATIVE_MAX_INTEREST_RATE` | The maximum interest rate in the deposit product overdraft settings cannot be negative. | | 9025 `DEPOSIT_PRODUCT_OVERDRAFT_INVALID_INTEREST_RATE_MIN_MAX_DEFAULT_TUPLE` | The deposit product overdraft settings default value is not in the interval [`minVal`, `maxVal`] | | 9026 `DEPOSIT_PRODUCT_OVERDRAFT_EMPTY_INDEX_RATE` | The index source key in the deposit product overdraft settings cannot be empty | | 9027 `DEPOSIT_PRODUCT_OVERDRAFT_EMPTY_INTEREST_REVIEW_UNIT` | The interest rate review unit in the deposit product overdraft settings cannot be null | | 9028 `DEPOSIT_PRODUCT_OVERDRAFT_NEGATIVE_INTEREST_REVIEW_COUNT` | The interest rate review count in the deposit product overdraft settings cannot be null | | 9029 `DEPOSIT_PRODUCT_OVERDRAFT_EMPTY_DAYS_IN_YEAR` | The deposit product overdraft settings days in year cannot be null | | 9030 `DEPOSIT_PRODUCT_OVERDRAFT_INVALID_DAYS_IN_YEAR_VALUE` | The deposit product overdraft settings days in year method is not valid | | 9031 `DEPOSIT_PRODUCT_OVERDRAFT_TIERED_BAND_NOT_AVAILABLE` | The `interestRateTerms` cannot be set to `TIERED_BAND` in the deposit product overdraft settings | | 9032 `DEPOSIT_PRODUCT_OVERDRAFT_TIERED_PERIOD_NOT_AVAILABLE` | The `interestRateTerms` cannot be set to `TIERED_PERIOD` in the deposit product overdraft settings | | 9033 `UPDATE_DEPOSIT_PRODUCTS_ERROR` | There was an error when updating the deposits product | | 9034 `DEPOSIT_PRODUCT_INTEREST_RATE_SETTINGS_NOT_ALLOWED_FOR_PRODUCT_WITH_CRYPTOCURRENCIES` | The deposit product interest rate settings are not allowed for product with cryptocurrencies | | 9035 `DEPOSIT_PRODUCT_OVERDRAFT_INTEREST_RATE_SETTINGS_NOT_ALLOWED_FOR_PRODUCT_WITH_CRYPTOCURRENCIES` | The deposit product overdraft interest rate settings are not allowed for product with cryptocurrencies | | 9036 `DEPOSIT_PRODUCT_INTEREST_RATE_SETTINGS_NOT_ALLOWED_FOR_PRODUCT_WITH_NON_TRADITIONAL_CURRENCIES` | The deposit product interest rate settings are not allowed for product with non-traditional currencies | | 9037 `DEPOSIT_PRODUCT_OVERDRAFT_INTEREST_RATE_SETTINGS_NOT_ALLOWED_FOR_PRODUCT_WITH_NON_TRADITIONAL_CURRENCIES` | The deposit product overdraft interest rate settings are not allowed for product with non-traditional currencies | | 9038 `DEPOSIT_PRODUCT_OVERDRAFT_INDEX_RATE_AVAILABLE_ONLY_FOR_FIXED_TERMS` | The deposit product overdraft settings index interest rate is only available if the `interestRateTerms` are set to `FIXED` | | 9039 `DEPOSIT_PRODUCT_HAS_ASSOCIATED_LOAN_PRODUCTS` | | ## 9000 - 9602 |Response Code|Description| |---|---| | 9001 `INVALID_CUSTOM_FILTER_CONSTRAINT_OPERATOR` | | | 9002 `EMPTY_CUSTOM_FILTER_CONSTRAINT_VALUE` | | | 9003 `INVALID_CUSTOM_FILTER_CONSTRAINT_VALUE` | | | 9004 `INVALID_CUSTOM_FILTER_CONSTRAINT_OPERATOR_USAGE` | | | 9005 `EMPTY_TRANSACTION_CHANNEL_NAME` | | | 9006 `EMPTY_TRANSACTION_CHANNEL_ID` | | | 9007 `INVALID_CUSTOM_FILTER_CONSTRAINT_TYPE` | | | 9008 `INVALID_CUSTOM_FILTER_USAGE` | | | 9009 `INVALID_CUSTOM_FILTER_CRITERIA` | | | 9209 `INCONSISTENT_DEPOSIT_ACCOUNT_BRANCH_ASSOCIATION_CENTRE_OR_CREDIT_OFFICER_MISMATCH` | When the other assignments in regards to Centre or Credit Officer become inconsistent due to branch association on Deposit Accounts. | | 9500 `CF_SET_ID_ERROR` | | | 9501 `CF_SET_INVALID_ID` | | | 9502 `CF_SET_DUPLICATE_ID` | | | 9503 `CF_GROUPED_SET_EMPTY_ERROR` | | | 9504 `CF_GROUPED_SET_INDEX_DUPLICATE_ERROR` | | | 9505 `CF_STANDARD_VALUES_DEFINED_FOR_GROUPED_SET_ERROR` | | | 9506 `CF_GROUPED_VALUES_DEFINED_FOR_STANDARD_SET_ERROR` | | | 9507 `CF_GROUPED_SET_CF_ID_DUPLICATE_ERROR` | | | 9508 `CF_STANDARD_SET_CF_ID_DUPLICATE_ERROR` | | | 9509 `CUSTOM_FIELD_ID_BLANK_ERROR` | | | 9510 `CUSTOM_FIELD_ID_INVALID_ERROR` | | | 9511 `CF_VALUE_CHECKBOX_TYPE_INVALID_ERROR` | | | 9512 `CF_VALUE_CLIENT_LINK_TYPE_INVALID_ERROR` | | | 9513 `CF_VALUE_DATE_TYPE_INVALID_ERROR` | | | 9514 `CF_VALUE_GROUP_LINK_TYPE_INVALID_ERROR` | | | 9515 `CF_VALUE_NUMBER_TYPE_INVALID_ERROR` | | | 9516 `CF_VALUE_SELECTION_TYPE_INVALID_ERROR` | | | 9517 `CF_VALUE_USER_LINK_TYPE_INVALID_ERROR` | | | 9518 `CF_VALUES_EMPTY_ERROR` | | | 9519 `CF_GROUPED_SET_NULL_INDEX_ERROR` | | | 9520 `CF_GROUPED_SET_INDEX_UNORDERED_ERROR` | | | 9600 `DUPLICATE_NON_WORKING_DAYS` | | | 9601 `INVALID_GENERAL_HOLIDAY_IDENTIFIER` | | | 9602 `HOLIDAY_ID_NOT_UNIQUE_INVALID_OPERATION` | | ## 9700 - 9716 Client roles configuration |Response Code|Description| |---|---| | 9700 `CLIENT_ROLE_EMPTY_CONFIGURATION` | The client roles configuration cannot be empty | | 9701 `CLIENT_ROLE_NULL_ROLES_CONFIG` | The client roles configuration cannot be null, at least one null entry was detected | | 9702 `CLIENT_ROLE_NULL_ROLES` | Client roles cannot be null, at least one null entry was detected | | 9703 `CLIENT_ROLE_ID_LENGTH` | The client role ID must not be more than 32 characters | | 9704 `CLIENT_ROLE_BLANK_ID` | The client role ID cannot be blank | | 9705 `CLIENT_ROLE_DUPLICATE_ID` | The client role ID must be unique for the given account holder type | | 9706 `CLIENT_ROLE_NAME_LENGTH` | The client role name must not be more than 255 characters | | 9707 `CLIENT_ROLE_BLANK_NAME` | The client role name must not be blank | | 9708 `CLIENT_ROLE_DUPLICATE_NAME` | The client role name must be unique for the given account holder type | | 9709 `CLIENT_ROLE_IDENTIFICATION_DOCUMENT_ERROR` | Identification documents cannot be applied to groups. The `requireIdentificationDocuments` field must be null for groups | | 9710 `CLIENT_ROLE_ID_TEMPLATE_LENGTH` | The ID template must not be more than 32 characters | | 9711 `CLIENT_ROLE_ID_TEMPLATE_FORMAT` | The ID template cannot contain any special characters besides placeholders of '#' for numbers, '@' for letters, or '$' for letters or numbers | | 9712 `CLIENT_ROLE_DESCRIPTION_LENGTH` | The client role description must not be more than 256 characters | | 9713 `CLIENT_ROLE_DEFAULT_ROLE_REQUIRED` | The default client role and default group role are required and cannot be deleted | | 9714 `CLIENT_ROLE_BLANK_TYPE` | The type field is required for a client role and cannot be null | | 9715 `CLIENT_ROLE_DUPLICATE_TYPES` | The type (either client or group) must be unique. Roles can be defined for types only once | | 9716 `DEFAULT_ROLE_ID` | The default role ID cannot be changed | ## 9750 - 9758 Internal controls configuration |Response Code|Description| |---|---| | 9750 `EXPOSURE_AMOUNT_RANGE_VIOLATION` | The value for `exposureAmount` must be between 0 and 2000000000 | | 9751 `EXPOSURE_AMOUNT_REQUIRED` | If `exposureType` is not `UNLIMITED`, then `exposureAmount` is required | | 9752 `ARREARS_DAYS_BEFORE_WRITE_OFF_RANGE_VIOLATION` | The value for `arrearsDaysBeforeWriteOff` must be between 0 and 2000000000 | | 9753 `MAX_ALLOWED_UNDO_CLOSURE_PERIOD_RANGE_VIOLATION` | The value for `maxAllowedUndoClosurePeriod` must be between 0 and 2000000000 | | 9754 `MIN_GROUP_SIZE_LIMIT_RANGE_VIOLATION` | The value for `minGroupSizeLimit` must be between 0 and 2000000000 | | 9755 `MIN_GROUP_SIZE_LIMIT_REQUIRED` | If `groupSizeLimitType` is not `NONE`, then `minGroupSizeLimit` is required | | 9756 `MAX_GROUP_SIZE_LIMIT_RANGE_VIOLATION` | The value for `maxGroupSizeLimit` must be between 0 and 2000000000 | | 9757 `MAX_LOWER_THAN_MIN_GROUP_SIZE_LIMIT` | The value of the maximum group size limit must be higher than the value of the minimum group size limit | | 9758 `MAX_GROUP_SIZE_LIMIT_REQUIRED` | If `groupSizeLimitType` is not `NONE`, then `maxGroupSizeLimit` is required | ## 9759 - 9770 Loan risk levels configuration |Response Code|Description| |---|---| | 9759 `LOAN_RISK_LEVELS_CONFIGURATION_EMPTY`| The loan risk levels configuration must not be empty | | 9760 `NULL_LOAN_RISK_LEVEL_ENTRY`| A loan risk level cannot be null, at least one null entry was detected | | 9761 `LOAN_RISK_LEVEL_ID_LENGTH`| The ID length for a loan risk level must not exceed 32 characters | | 9762 `BLANK_LOAN_RISK_LEVEL_ID`| The ID for a loan risk level must not be blank | | 9763 `DUPLICATE_LOAN_RISK_LEVEL_ID`| The ID for a loan risk level must be unique | | 9764 `NON_ALPHANUMERIC_LOAN_RISK_LEVEL_ID` | The ID for a loan risk level can only contain letters and numbers | | 9765 `LOAN_RISK_LEVEL_NAME_LENGTH`| The name length for a loan risk level must not exceed 256 characters | | 9766 `LOAN_RISK_LEVEL_NAME_BLANK`| The name for a loan risk level must not be blank | | 9767 `NEGATIVE_ARREARS_DAYS_NUMBER`| The value of `arrearsFrom` and `arrearsTo` cannot be negative | | 9768 `EMPTY_ARREARS_DAYS_NUMBER`| The value of `arrearsFrom` and `arrearsTo` cannot be blank | | 9769 `ARREARS_DAYS_NUMBER_SIZE`| The value of `arrearsFrom` and `arrearsTo` must not exceed 2000000000 | | 9770 `BLANK_PROVISIONING_PERCENT`| The provisioning percent of a loan risk level cannot be blank | ## 9800 - 9806 Group role names configuration |Response Code|Description| |---|---| | 9800 `GROUP_ROLE_NAMES_EMPTY_CONFIGURATION` | The group role name configuration cannot be empty. | | 9801 `GROUP_ROLE_NAMES_NULL_CONFIG` | The group role name configuration cannot be null, at least one null entry was detected | | 9802 `GROUP_ROLE_NAME_BLANK_ID` | The ID must not be blank for any group role name | | 9803 `GROUP_ROLE_NAME_ID_LENGTH` | The group role name ID length must not exceed 32 characters | | 9804 `GROUP_ROLE_NAME_DUPLICATE_ID` | The group role name ID must not be a duplicate. It must be unique | | 9805 `GROUP_ROLE_NAME_BLANK_NAME` | The group role name must not be blank | | 9806 `GROUP_ROLE_NAME_LENGTH` | The name length of the group role name must not exceed 255 characters | ## 9900 - 9908 Labels configuration |Response Code|Description| |---|---| | 9900 `OBJECT_LABELS_CONFIGURATION_EMPTY` | The object labels configuration cannot be empty | | 9901 `NULL_OBJECT_LABELS_ENTITY` | Object labels cannot be null, at least one null entry was detected | | 9902 `DUPLICATE_OBJECT_LABEL_PAIR` | Object label pairs must be unique in the configuration | | 9903 `INVALID_NUMBER_OF_OBJECT_LABEL_PAIRS` | You cannot add or delete object labels | | 9904 `NULL_OBJECT_LABELS_VALUE_ENTITY` | Labels cannot be null, at least one null entry was detected | | 9905 `MISSING_LANGUAGE` | A language is missing from the configuration. | | 9906 `DUPLICATE_LANGUAGE` | Duplicate language in the configuration. You cannot have duplicate languages | | 9907 `EMPTY_SINGULAR_OBJECT_LABEL_VALUE` | The value for the singular label cannot be empty | | 9908 `EMPTY_PLURAL_OBJECT_LABEL_VALUE` | The value for the plural label cannot be empty | ## 9909 - 9922 ID templates configuration |Response Code|Description| |---|---| | 9909 `ID_DOCUMENT_TEMPLATES_CONFIGURATION_EMPTY` | The ID document templates configuration must not be empty | | 9910 `NULL_ID_DOCUMENT_TEMPLATE_ENTRY` | An ID document template cannot be null, at least one null entry was detected | | 9911 `ID_DOCUMENT_TEMPLATE_ID_LENGTH` | The ID length of the ID document template must not exceed 32 characters | | 9912 `BLANK_ID_DOCUMENT_TEMPLATE` | The ID of an ID document template must not be blank | | 9913 `DUPLICATE_ID_DOCUMENT_TEMPLATE_ID` | The ID of an ID document template must be unique | | 9914 `NON_ALPHANUMERIC_ID_DOCUMENT_TEMPLATE_ID` | The ID of an ID document can only contain letters and numbers | | 9915 `BLANK_DOCUMENT_TYPE` | The document type of an ID document template must not be blank | | 9916 `DOCUMENT_TYPE_LENGTH` | The document type length must not exceed 256 characters | | 9917 `BLANK_DOCUMENT_ID_TEMPLATE` | The ID document template must not be blank | | 9918 `DOCUMENT_ID_TEMPLATE_LENGTH` | The template length for the ID document template must not exceed 256 characters | | 9919 `BLANK_ISSUING_AUTHORITY` | The issuing authority of an ID document template must not be blank | | 9920 `ISSUING_AUTHORITY_LENGTH` | The issuing authority length must not exceed 256 characters | | 9921 `BLANK_MANDATORY_FOR_CLIENT` | The mandatory for clients field of an ID document template must not be blank | | 9922 `BLANK_ALLOW_ATTACHMENTS` | The allow attachments field of an ID document template must not be blank | ## 9909 - 9929 Accounting rules configuration |Response Code|Description| |---|---| | 9909 `ACCOUNTING_RULE_BLANK_ID` | The ID of an accounting rule cannot be blank | | 9910 `ID_NOT_ALPHANUMERIC` | The ID of an accounting rule must contain only letters and numbers | | 9911 `INVALID_ID_LENGTH` | The ID of an accounting rule must not exceed 32 characters | | 9912 `ACCOUNTING_RULE_DUPLICATE_ID` | The ID of an accounting rule must be unique in the configuration. A duplicate ID was found | | 9913 `ACCOUNTING_RULES_CONFIGURATION_EMPTY` | | | 9914 `NULL_CUSTOM_ACCOUNTING_RULE_ENTRY` | Inter-branch transfer rule entry cannot be null | | 9915 `DUPLICATE_RULE_FOR_CURRENCY` | Accounting rules must be unique. Another rule is defined for the same pair of branches | | 9916 `BRANCHES_ARE_EQUAL` | An accounting rule must be defined for two different branches. The selected branches cannot be equal | | 9917 `GLACCOUNT_NOT_SET` | The mandatory value for a GL account was not defined or is invalid | | 9918 `BRANCHES_NOT_SET` | | | 9919 `GLACCOUNT_DOESNT_EXIST` | The GL account defined for an accounting rule must exist | | 9920 `BRANCHES_MUST_BE_SET` | | | 9921 `BOTH_BRANCHES_MUST_BE_SET_OR_BOTH_BRANCHES_NOT_SET` | | | 9922 `DEFAULT_RULE_ALLOWS_ONLY_GLACCOUNT_IN_ORGBASE_CURRENCY` | The default rule must be associated with a GL account in the organization's base currency, irrespective of whether the Accounting in Multicurrency feature is enabled or not | | 9923 `ONLY_FOREIGN_CURRENCY_ALLOWED_FOR_ALL_BRANCHES_`

`TO_ALL_BRANCHES_RULE` | When the 'Accounting in Multicurrency' feature is enabled, all other accounting rules can have GL accounts in any currency, except the organization's base currency. This does not apply to the default rule of the form 'All branches - All branches' | | 9924 `GLACCOUNT_MUST_HAVE_ORGBASE_CURRENCY` | | | 9925 `NEGATIVE_AUTOMATED_ACCOUNTING_CLOSURES_INTERVAL` | The automated accounting closures interval can't be a negative number | | 9926 `AUTOMATED_ACCOUNTING_CLOSURES_INTERVAL_EXCEEDS_LIMIT` | | | 9927 `DEFAULT_GLACCOUNT_DOESNT_EXIST` | The default GL account must exist. The selected default GL account does not exist | | 9928 `ACCOUNTING_RULE_INVALID_BRANCH_ID` | The branches defined in an accounting rule must exist | | 9929 `ACCOUNTING_RULE_EMPTY_BRANCH_ID` | Branch IDs defined in an accounting rule must not be empty | ## 9940 - 9972 Currencies configuration |Response Code|Description| |---|---| | 9940 `BASE_CURRENCY` | | | 9941 `BASE_CURRENCY_REQUIRED` | The base currency is required in the configuration | | 9942 `BASE_CURRENCY_EDITED` | The currency code of the base currency cannot be changed | | 9943 `CURRENCY_CODE_REQUIRED` | The currency code is required | | 9944 `CURRENCY_NAME_REQUIRED` | The currency name is required | | 9945 `CURRENCY_SYMBOL_REQUIRED` | The currency symbol is required | | 9946 `SYMBOL_POSITION_REQUIRED` | The currency symbol position is required | | 9947 `CURRENCY_NAME_LENGTH` | The currency name must not exceed 256 characters | | 9948 `CURRENCY_SYMBOL_LENGTH` | The currency symbol must not exceed 10 characters | | 9949 `CURRENCY_REQUIRED` | If foreign currencies are included in the configuration, the currency is required | | 9950 `FOREIGN_CURRENCY_NULL_ENTRIES` | A foreign currency cannot be null. At least one null entry was detected | | 9951 `DUPLICATE_BASE_CURRENCY` | | | 9952 `DUPLICATE_FOREIGN_CURRENCY` | Foreign currencies must be unique in the configuration. A duplicate currency code was found | | 9953 `EXCHANGE_RATE_REQUIRED` | Exchange rates are required for each foreign currency | | 9954 `BUY_EXCHANGE_RATE_REQUIRED` | The buy rate of an exchange rate is required | | 9955 `SELL_EXCHANGE_RATE_REQUIRED` | The sell rate of an exchange rate is required | | 9956 `ACCOUNTING_RATES_REQUIRED` | The accounting rates are required for foreign currencies | | 9957 `ACCOUNTING_RATE_REQUIRED` | The rate is required when defining an accounting rate | | 9958 `ACCOUNTING_RATE_CAN_NOT_BE_SET` | | | 9959 `BUY_EXCHANGE_RATE_RANGE_VIOLATION` | The buy rate of an exchange rate must be between 0 and 2000000000000000 | | 9960 `SELL_EXCHANGE_RATE_RANGE_VIOLATION` | The sell rate of an exchange rate must be between 0 and 2000000000000000 | | 9961 `ACCOUNTING_RATE_RANGE_VIOLATION` | The accounting rate must be between 0 and 2000000000000000 | | 9962 `RATE_START_DATE_REQUIRED` | The start date of an accounting rate is required | | 9963 `EXCHANGE_RATES_NULL_ENTRIES` | The exchange rate cannot be null. At least one null entry was detected | | 9964 `BUY_RATE_GRATER_THAN_SELL_RATE` | In an exchange rate, the buy rate cannot be greater than the sell rate | | 9965 `ACCOUNTING_RATES_NULL_ENTRIES` | The accounting rate cannot be null. At least one null entry was detected | | 9966 `START_DATE_BEFORE_PREVIOUS_RATE` | The start date of an exchange rate or accounting rate cannot be before the previous defined rate start date | | 9967 `EDIT_EXISTING_RATE_NOT_ALLOWED` | Existing accounting rates or exchange rates cannot be edited | | 9968 `EXISTING_RATES_REMOVAL_NOT_ALLOWED` | Existing accounting rates or exchange rates cannot be deleted | | 9969 `GL_JOURNAL_ENTRIES_USING_CURRENT_RATES` | | | 9970 `BEFORE_CONFIGURATION_START_DATE` | | | 9971 `MULTICURRENCY_FEATURE_IS_DISABLED` | | | 9972 `DUPLICATE_RATE_START_DATE` | Duplicate start date | ## 9950 - 9959 Authorization Holds Configuration |Response Code|Description| |---|---| | 9950 `AUTHORIZATION_HOLDS_CONFIGURATION_EMPTY` | The authorization holds configuration must not be null | | 9951 `NULL_AUTHORIZATION_HOLD_ENTITY` | An authorization hold entry cannot be null in the configuration | | 9952 `NULL_DEFAULT_AUTHORIZATION_HOLD_ENTITY` | The default authorization hold must not be null in the configuration | | 9953 `NON_EMPTY_MCC_FOR_DEFAULT_AUTHORIZATION_HOLD` | The default authorization hold must not have an MCC value | | 9954 `NON_EMPTY_DESCRIPTION_FOR_DEFAULT_AUTHORIZATION_HOLD` | The default authorization hold must not have a description | | 9955 `INVALID_DAYS_TO_EXPIRE_FOR_DEFAULT_AUTHORIZATION_HOLD` | The value for the days to expire for the default authorization hold must be a positive number | | 9956 `EMPTY_MCC_FOR_AUTHORIZATION_HOLD` | The MCC value must not be empty for an authorization hold entry in the configuration | | 9957 `INVALID_DAYS_TO_EXPIRE_FOR_AUTHORIZATION_HOLD` | The days to expire value for an authorization hold must be a positive number | | 9958 `INVALID_DESCRIPTION_FOR_AUTHORIZATION_HOLD` | The description for an authorization hold entry must not exceed 256 characters | | 9959 `NON_UNIQUE_MCC_FOR_AUTHORIZATION_HOLD` | The MCC value for an authorization hold entry must be unique | ## 9973 - 9976 |Response Code|Description| |---|---| | 9973 `CUSTOM_PAYMENT_AMOUNT_DUPLICATE_PREDEFINED_FEE` | | | 9974 `CUSTOM_PAYMENT_AMOUNT_TYPE_DISALLOWS_PREDEFINED_FEE` | | | 9975 `CUSTOM_PAYMENT_AMOUNT_TYPE_DOES_NOT_MATCH_PREDEFINED_FEE` | | | 9976 `CUSTOM_PAYMENT_AMOUNT_TYPE_SHOULD_HAVE_FEE_NAME_FIRST` | | ## 10000 |Response Code|Description| |---|---| | 10000 `INVALID_YAML_SYNTAX` | | | 10500 `INVALID_API_CONSUMER_ID` | | | 10503 `API_CONSUMER_BRANCH_CHANGE` | | | 10504 `API_CONSUMER_HAS_ASSIGNED_CLIENTS_OR_GROUPS` | | | 10505 `CANNOT_DELETE_SUPPORT_USER_BY_REGULAR_API_CONSUMER` | | | 10506 `CANNOT_DELETE_DELIVERY_USER_BY_REGULAR_API_CONSUMER` | | | 10507 `CANNOT_DELETE_API_CONSUMER_WITH_PERFORMED_ACTIVITIES` | | | 10508 `API_CONSUMER_ALREADY_EXISTS` | | | 10509 `ONLY_MAMBU_API_CONSUMER_CAN_HAVE_A_ROLE` | | | 10510 `CANNOT_UPDATE_API_CONSUMER_NAME` | | | 10511 `CANNOT_UPDATE_API_CONSUMER_TYPE` | | | 10512 `INVALID_API_CONSUMER_NAME_FORMAT` | | | 10513 `INVALID_API_KEY_ID` | | | 10514 `MISSING_API_CONSUMER_TYPE` | | | 10515 `MISSING_API_CONSUMER_NAME` | | | 10516 `ROLE_DOES_NOT_HAVE_APIS_ACCESS` | | | 10517 `INVALID_API_CONSUMER_ROLE_KEY` | | | 10518 `CANNOT_UPDATE_AUDIT_OR_STREAMING_API_CONSUMERS` | | | 10519 `INVALID_PAYMENTS_PERMISSIONS` | | | 10520 `PAYMENTS_API_CONSUMER_CANNOT_BE_ADMIN_OR_CREDIT_OFFICER` | | | 10521 `AUDIT_TRAIL_AND_STREAMING_API_CONSUMERS_CANNOT_HAVE_ACCESS` | | | 10600 `DEADLOCK_ERROR` | | | 10601 `INDEX_RATES_EMPTY_CONFIGURATION`| The index rates configuration cannot be empty | | 10602 `INDEX_RATE_SOURCE_NULL_ENTRY`| The index rates sources cannot be null; at least one null entry was detected | | 10603 `INDEX_RATE_SOURCE_NULL_RATES`| The index rates cannot be null, at least one null entry was detected | | 10604 `INDEX_RATE_SOURCE_ID_INVALID`| The index rate source ID was incorrect. It cannot be null, must contain alphanumeric characters, and cannot exceed 32 characters | | 10605 `INDEX_RATE_SOURCE_ID_DUPLICATE`| The index rate source ID must be unique | | 10606 `INDEX_RATE_SOURCE_NAME_EMPTY`| The index rate source name must not be blank | | 10607 `INDEX_RATE_SOURCE_NAME_TOO_LONG`| The length of the index rate source name must not exceed 32 characters | | 10608 `INDEX_RATE_SOURCE_NOTES_TOO_LONG`| The length of the index rate source notes must not exceed 255 characters | | 10609 `INDEX_RATE_SOURCE_NAME_DUPLICATE`| The index rate source name must be unique | | 10610 `INDEX_RATE_SOURCE_TYPE_INCORRECT`| The index rate source type must not be null | | 10611 `INDEX_RATE_SOURCE_TYPE_IN_USE`|| | 10612 `INDEX_RATE_CANNOT_BE_CHANGED`|| | 10613 `INDEX_RATE_ID_INVALID`| The index rate ID was incorrect. It cannot be null, must contain alphanumeric characters, and cannot exceed 32 characters | | 10614 `INDEX_RATE_ID_DUPLICATE`| The index rate ID must be unique | | 10615 `INDEX_RATE_RATE_EMPTY`| The rate of the index rate must not be blank | | 10616 `INDEX_RATE_RATE_RANGE_VIOLATION`| For rates of type `TAX_RATE`, the `rate` value must be between value 0 and 100 | | 10617 `INDEX_RATE_NOTES_TOO_LONG`|The index rate notes length must not exceed 255 characters | | 10618 `INDEX_RATE_START_DATE_EMPTY`| The index rate start date must not be blank | | 10619 `INDEX_RATE_START_DATE_DUPLICATE`| The index rate start date must be unique | | 10620 `INDEX_RATE_START_DATE_BEFORE_REVIEWED_DATE`|| | 10650 `TRANSACTION_CHANNELS_CONFIGURATION_EMPTY` | The transaction channels configuration cannot be empty | | 10651 `TRANSACTION_CHANNEL_NULL_ROLES_CONFIG` | Transaction channels cannot be null. At least one null entry was detected | | 10652 `DEFAULT_TRANSACTION_CHANNEL_ID` | | | 10653 `BLANK_TRANSACTION_CHANNEL_ID` | The the transaction channel ID must not be blank | | 10654 `TRANSACTION_CHANNEL_ID_LENGTH` | The transaction channel ID length must not exceed 32 characters | | 10655 `DEFAULT_TRANSACTION_CHANNEL_CONFIG_ID` | The default transaction channel ID cannot be changed | | 10656 `DEFAULT_TRANSACTION_CHANNEL_STATE` | The default transaction channel cannot be deactivated | | 10657 `DEFAULT_TRANSACTION_CHANNEL_REQUIRED` | The default transaction channel is required and cannot be deleted | | 10658 `TRANSACTION_CHANNEL_NAME_LENGTH` | The transaction channel name must not exceed 256 characters | | 10659 `TRANSACTION_CHANNEL_BLANK_NAME` | The transaction channel name cannot be blank | | 10660 `TRANSACTION_CHANNEL_DUPLICATE_NAME` | The transaction channel name must be unique | | 10661 `TRANSACTION_CHANNEL_STATE_BLANK` | The transaction channel state must not be blank | | 10662 `TRANSACTION_CHANNEL_GL_ACCOUNT_DOES_NOT_EXIST` | The GL account does not exist | | 10700 `CONSTRAINTS_BLOCK_NULL` | The savings constraint and the loan constraints cannot be null | | 10701 `CONSTRAINT_ENTRY_NULL` | A null constraint entry was detected. Constraints must not be null | | 10702 `CONSTRAINT_USAGE_NULL` | The constraint usage cannot be null | | 10703 `INVALID_UNCONSTRAINED_USAGE` | The unconstrained usage must not have constraints defined | | 10704 `INVALID_LIMITED_USAGE` | The limited usage must have at least one constraint defined | | 10705 `CONSTRAINT_MATCH_FILTER_INVALID` | A match filter cannot be specified for unconstrained usage | | 10706 `CONSTRAINT_MATCH_FILTER_NULL` | A match filter must be specified for limited usage | | 10707 `AMOUNT_CONSTRAINT_INVALID_FILTER` | The available operators for the `IN` filter element are `EQUALS`, `EMPTY`, `NOT_EMPTY`, `BETWEEN`, `MORE_THAN`, and `LESS_THAN` | | 10708 `TRANSACTION_CONSTRAINT_INVALID_FILTER` | The available operators for the `TYPE` criterion are `EMPTY`, `NOT_EMPTY`, and `IN` | | 10709 `PRODUCT_CONSTRAINT_INVALID_FILTER` | The available operators for the `PRODUCT` criterion are `EMPTY`, `NOT_EMPTY`, and `IN` | | 10710 `BETWEEN_FILTER_INVALID_VALUES` | The `BETWEEN` filter must have two numeric values | | 10711 `EXISTENCE_FILTER_INVALID_VALUES` | The `EMPTY` or `NOT_EMPTY` filters must not have values defined | | 10712 `COMPARATOR_FILTER_INVALID_VALUES` | The `EQUALS`, `MORE_THAN`,and `LESS_THAN` filters must have one numeric value defined | | 10713 `IN_FILTER_INVALID_VALUES` | The `IN` filter must have at least one value defined | | 10714 `LOANS_IN_FILTER_INVALID_ID` | The IDs provided for the loan constraint `PRODUCT` criterion must exist | | 10715 `SAVINGS_IN_FILTER_INVALID_ID` | The IDs provided for the savings constraint `PRODUCT` criterion must exist | | 10716 `LOANS_IN_FILTER_INVALID_TYPE_VALUE` | The allowed values for the `TYPE` criterion are `DISBURSEMENT` and `REPAYMENT` | | 10717 `SAVINGS_IN_FILTER_INVALID_TYPE_VALUE` | The allowed values for the `TYPE` criterion are `DEPOSIT` and `WITHDRAWAL` | | 10800 `ACCESS_RIGHTS_BLANK` | The transaction channel access rights cannot be blank | | 10801 `ACCESS_RIGHTS_ALL_USERS_BLANK` | The `allUsers` field of a transaction channel must not be null | | 10802 `ACCESS_RIGHTS_ALL_USERS_FALSE` | If `allUsers` is set to `false` in the usage rights of a transaction channel, then you must specify role IDs in the `roles` array | | 10803 `ACCESS_RIGHTS_BLANK_ROLE_ID` | Roles defined in the access rights of a transaction channel cannot be blank. One or more blank entries was detected | | 10804 `ACCESS_RIGHTS_DUPLICATE_ROLE_ID` | Roles defined in the access rights of a transaction channel must be unique. One or more duplicate IDs was detected | | 10805 `ACCESS_RIGHTS_INVALID_ROLE_ID` | The roles IDs defined in the access rights of a transaction channel must correspond to existing roles | | 10810 `END_OF_DAY_PROCESSING_NULL_PROCESSING_METHOD` | The end of day processing method cannot be null | | 10811 `END_OF_DAY_PROCESSING_INVALID_FORMAT` | The accounting cut-off time must be in the HH:mm:ss format | ## 15000 | Response Code | Description | |------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 15001 `WEBHOOK_NOTIFICATIONS_SETTINGS_DISABLED` | Webhook notification settings are not enabled. Refer to the [`notificationsettings`](/api/api-v2/notificationsettings_webhook/notificationsettings-webhook) endpoint documentation for more details. | | 15002 `WEBHOOK_TEMPLATE_DUPLICATE_NAME` | A template with the same name already exists; a unique name must be chosen. | | 15004 `INVALID_TEMPLATE_BODY` | The body content exceeds the maximum allowed length (256 characters). | | 15006 `INVALID_WEBHOOK_TEMPLATE_URL` | The provided URL is invalid (e.g., does not use HTTPS, lacks a top-level domain, contains invalid characters like spaces). | | 15008 `INVALID_TEMPLATE_BASIC_AUTHORIZATION_USERNAME` | For BASIC_AUTHORIZATION, the mandatory username was not provided. | | 15009 `INVALID_TEMPLATE_BASIC_AUTHORIZATION_PASSWORD` | For BASIC_AUTHORIZATION, the mandatory password was not provided. | | 15010 `INVALID_TEMPLATE_BASIC_AUTHORIZATION_PASSWORD` | For BASIC_AUTHORIZATION, the mandatory password was not provided. | | 15011 `TRIGGER_MUST_BE_AUTOMATIC_FOR_WEBHOOKS_TEMPLATES` | The trigger was attempted to be set as `MANUAL`, but webhooks only support `AUTOMATIC triggers. | | 15015 `CUSTOM_FILTER_DATA_FIELD_VALUE_EMPTY` | No `dataFieldValue` was provided for a filter constraint. | | 15016 `CUSTOM_FILTER_CONSTRAINT_DATA_TYPE_INVALID` | The `filterElement` is incompatible with the provided `dataType` for a filter constraint. | | 15017 `CUSTOM_FILTER_CONSTRAINT_VALUE_NOT_EMPTY` | No valid `filterElement` was provided when a `value` for comparison exists for a filter constraint. | | 15018 `CUSTOM_FILTER_CONSTRAINT_SECOND_VALUE_NOT_EMPTY` | No valid `filterElement` was provided when a `secondValue` for comparison exists for a filter constraint. | | 15019 `CUSTOM_FILTER_CONSTRAINT_VALUE_EMPTY` | A `filterElement` was provided, but no value for the filtering itself was provided for a filter constraint. | | 15020 `CUSTOM_FILTER_CONSTRAINT_SECOND_VALUE_EMPTY` | A `filterElement` was provided, but no `secondValue` for the filtering itself was provided for a filter constraint. | | 15021 `CUSTOM_FILTER_CONSTRAINT_VALUE_INVALID` | The value set does not match the data type defined for the filter constraint. | | 15022 `CUSTOM_FILTER_CONSTRAINT_VALUE_INVALID_CSV` | An invalid CSV format was provided for the filter element for a filter constraint. | | 15023 `FILTERS_LINKING_OPERATOR_NOT_EMPTY` | A filter linking operator was provided without any associated filter constraints. | | 15024 `FILTERS_LINKING_OPERATOR_EMPTY` | No filter linking operator was provided despite the presence of filter constraints in the list. | | 15025 `INVALID_CUSTOM_FILTER_DATA_FIELD_ENTITY_TYPE` | Invalid `dataFieldEntityType` was provided for a filter constraint. | | 15026 `INVALID_CUSTOM_FILTER_DATA_FIELD_VALUE` | Invalid `dataFieldValue` was provided for a filter constraint. | | 15027 `INVALID_CUSTOM_FILTER_VALUE` | Invalid value was provided for a filter constraint. | | 15028 `INVALID_CUSTOM_FILTER_FIRST_VALUE_GREATER_THAN_SECOND_VALUE` | Invalid value and secondValue was provided for a filter constraint, as value must be smaller than `secondValue`. | | 15030 `UNKNOWN_TEMPLATES_ERROR` | This covers all other unhandled exceptions. Please contact the Notifications team for investigation in such cases. | | 15060 `WEBHOOK_TEMPLATE_POST_FIELDS_BREAKING_CONSTRAINTS` | The `POST` templates operation request causes the template parameters to violate certain constraints. More details are shown in the `errorSource` in the response. | | 15061 `ID_NOT_APPLICABLE` | ID should not be passed as part of webhook template creation. That includes the main template, the filter constraints, and the request headers. | | 15065 `ADJACENT_FEATURE_TOGGLE_DISABLED` | A filter constraint is referencing a feature toggle which is not enabled for the tenant. | | 15066 `TARGET_TYPE_NOT_COMPATIBLE_WITH_FILTER_CONSTRAINTS` | Webhook template cannot have filter constraints with the set target type. They can only have filter constraints for `CLIENT` or `GROUP` target. | | 15067 `DATA_FIELD_VALUE_NOT_APPLICABLE_FOR_CUSTOM_DATA_FIELD_TYPE` | A filter constraint cannot be of type `CUSTOM` and have data field value set. | | 15068 `REFERENCED_CUSTOM_FIELD_FOR_CUSTOM_FILTER_CONSTRAINT_NOT_FOUND` | The custom field referenced by the ID in the filter constraint does not exist. | | 15069 `CUSTOM_FIELD_NOT_APPLICABLE_FOR_NATIVE_DATA_FIELD_TYPE` | A filter constraint cannot be of type `CUSTOM` and have the custom field ID set. | | 15070 `CUSTOM_FIELD_DATA_NOT_COMPATIBLE_WITH_FILTER_CONSTRAINT` | The `CUSTOM` filter constraint data is not compatible with the referenced custom field. | ## 20000 |Response Code|Description| |---|---| | 26223 `INVALID_CUSTOM_REQUEST_HEADERS` | | ## Mambu Payment Gateway :::(Warning) (Please be Aware) As the Mambu Payment Gateway is under active development new errors may be added or error codes changed at short notice. ::: When using the Mambu Payment Gateway you may receive further, general errors. These include `SERVICE_INVALID` or `PARAMETER_NOT_SUPPORTED`. If you receive these errors, the `text` parameter should include additional information to help debug the error such as pointing out the parameter which contains an unsupported value, indicating that a required field has not been provided, or, where mutually exclusive fields have been provided in a message body. In these cases, there may be no specific error number but the `text` parameter will provide guidance on how to correct the error. |Response Code|Description| |---|---| | `CREDIT_TRANSFER_REJECTED` (-1) | Payment order failed due to an incoming pacs.002 Reject message | | `CREDIT_TRANSFER_RETURNED` (-1) | Payment order failed due to an incoming pacs.004 Return message | | `CREDIT_TRANSFER_RECALLED` (-1) | Payment order failed due to it being recalled through a camt.056 message | | `CREDIT_TRANSFER_FAILED` (-1) | Payment order failed due to an internal error | | `DIRECT_DEBIT_REVERSED` (-1) | Collection failed due to an incoming pacs.007 Reversal message | | `DIRECT_DEBIT_REFUNDED` (-1) | Collection failed due to an incoming pacs.004 Refund message | | `DIRECT_DEBIT_RETURNED` (-1) | Collection failed due to an incoming pacs.004 Return message | | `CREDIT_TRANSFER_REJECT_FAILED` (-1) | Storno transaction failed when attempting to reverse a payment which was rejected through an incoming pacs.002 message | | `CREDIT_TRANSFER_RETURN_FAILED` (-1) | Storno transaction failed when attempting to reverse a payment which was returned through an incoming pacs.004 message | `CREDIT_TRANSFER_RECALL_FAILED` (-1)| Storno transaction failed when attempting to reverse a payment which was recalled through an incoming camt.056 message | | `DIRECT_DEBIT_REVERSE_FAILED` (-1) | Storno transaction failed when attempting to reverse a collection which was reversed through an incoming pacs.007 message | | `DIRECT_DEBIT_REFUND_FAILED` (-1) | Storno transaction failed when attempting to reverse a collection which was refunded through an incoming pacs.004 message | | `DIRECT_DEBIT_RETURN_FAILED` (-1) | Storno transaction failed when attempting to reverse a collection which was returned through an incoming pacs.004 message | | `PAYMENT_BLOCKED` (-1) | Collection failed due to it being blocked by Debtor | | `SUSPENDED_CREDIT_TRANSFER_REJECT_COMPLETED` (-1) | A previously suspended Payment order failed due to an AML `Rejected` response | | `SUSPENDED_CREDIT_TRANSFER_REJECT_FAILED` (-1) | Storno transaction failed when attempting to reverse an originally suspended payment which was AML `Rejected` | | 401 `BALANCE_BELOW_ZERO` | The Payment would result in a Balance below zero for the specified Deposit Account | | 407 `INVALID_DEPOSIT_ACCOUNT_STATE` | The Deposit account is not in a valid state for initiating payments. It should be either Approved or Active | | 408 `LOCKED_SAVINGS_AMOUNT` | The amount cannot be decreased below the locked amount by withdraw or transfer | | 417 `MAXIMUM_WITHDRAWAL_AMOUNT_EXCEEDED` | The withdrawal value is grater than the maximum withdrawal constraint defined in the savings product or at savings account level | | 418 `MAXIMUM_OVERDRAFT_LIMIT_EXCEEDED` | The overdraft value is greater than the maximum overdraft limit constraint defined in the savings product | | 499 `UNKNOWN_SAVINGS_ACCOUNT_ERROR` | Mambu Core Banking System responded with unknown error | ## HTTP status codes Mambu uses standard HTTP status codes. The more frequent ones are described below: | Response Code | Description | | --- | --- | | 200 OK / 201 Created | The request was successful | | 400 Bad Request | The request was invalid or could not be understood by the server (wrong syntax). Resubmitting the request will likely result in the same error | | 401 Unauthorized | The username and password credentials are missing or invalid for the given request | | 402 Payment Required | Your Mambu account is not in good standing. Please pay any outstanding invoices | | 403 Forbidden | Either the user is attempting to perform an action they do not have the rights to perform or the login credentials are not correct. You may also receive this error if you have enabled [IP Access Restrictions](/docs/access-preferences#ip-access-restrictions) and are trying to access Mambu from a non-whitelisetd IP address. You may also get this response code if your account is locked, which can happen after failed attempts to log in to the UI. See [Access Preferences - Lock User After Failed Logins](https://support.mambu.com/docs/access-preferences#lock-user-after-failed-logins-required) for more information | | 404 Not Found | The resource was not found. This may be returned if the given loan account, deposit account. client or group does not exist. The response body will explain which resource was not found | | 422 Unprocessable Entity | You may receive this response if you have made too many bad API requests in a short space of time. Bad requests can include incorrect password for the supplied username or posting a malformed JSON body, where subsequent requests with the same body will produce this error | | 500 Internal Server Error | The server encountered an error while processing your request and failed | | 502 Gateway Error | The load balancer or web server has trouble connecting to the Mambu app. Try the request again | | 503 Service Unavailable | The service is temporarily unavailable. Try the request again. Possible reason for this could be too many invalid authentication attempts in a row | --- # Applying and Reversing Fees and Penalties URL: https://docs.mambu.com/docs/applying-and-reversing-fees-and-penalties/ ## Apply manual and arbitrary fees The following are fees which can be applied manually to the accounts at any point during the accounts' lifetime and with any given amount. ### Manual fees First, you must define [manual fees](/docs/loan-fees-setup#manual-fees) in the product's settings (see [Setting up new loan products](/docs/setting-up-new-loan-products)), then you can apply them to any account that has been disbursed. To apply a manual fee: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Apply Fee**. 3. In the **Apply Fee** dialogue, choose **Manual fee** from the dropdown. 4. Enter the amount. 5. Optional: Add notes that are relevant to the fee. 6. Select **Apply Fee**. The fee will be applied to the current installment if the state of the current installment is `Pending` or to the next installment if the state of the current installment is `Late`. ![More dropdown with Apply Fee option and Apply fee dialogue](@site/static/img/support/loans--apply-fee-dialog.png) #### Backdating manual fees By default, when entering a fee, the transaction date will be today. Backdating allows you to log a transaction earlier than the current date. You can choose to backdate the application of the fee, but you need to make sure that there are no repayments already entered after this date. :::note Backdating manual fees is available for all types of Dynamic Term loans. For Fixed Term loans, you already have the option to apply a manual fee to a specific installment, meaning you won't need to backdate manual fees. ::: To backdate a fee: 1. Open the client's profile in the Mambu UI. 2. Select the appropriate loan account. 3. On the right-hand side of the screen, select **More** > **Apply Fee**. 4. In the **Apply Fee** dialog, use the **Fee** dropdown to select the fee name and under **Fee Amount**, enter the amount. 5. Select **Backdate** and enter a date in the past. 6. Select **Apply Fee**. ![Apply Fee dialog with option to backdate the fee](@site/static/img/support/backdate-the-application-of-a-fee.png) ### Arbitrary fees [Arbitrary fees](/docs/loan-fees-setup#arbitrary-fees) do not have to be set up in advance. If the **Allow Arbitrary Fees** option is checked in the product's settings they can be applied on an ad hoc basis to any account, at any time. To apply an arbitrary fee: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Apply Fee**. 3. In the **Apply Fee** dialogue, choose **Other** from the dropdown. 4. Enter the amount and the reason for the fee. 5. Select **Apply Fee**. The fee will be applied to the current installment if the state of the current installment is `Pending` or to the next installment if the state of the current installment is `Late`. After applying an arbitary fee to an account, the amount will be displayed as Total Due until it is paid out, which will happen according to the defined [Payment Allocation Order](/docs/repayment-collection#repayment-allocation-order). :::note You can apply arbitrary fees to an account in any state except for `Closed`. ::: *** ## The order in which fees are paid All fee types, taxable or a non-taxable, are paid in the First In First Out (FIFO) order. When making a repayment, the fee that has been applied first on the schedule will get paid first. **Example** Three manual fees: Fee 1 is USD50, Fee 2 is USD100, and Fee 3 is USD20. All three fees are taxable. Steps: 1. Disburse loan. 2. Apply Fee 1. 3. Apply Fee 2. 4. Apply Fee 3. 5. Make a repayment of USD100. Result: Fee 1 is paid first, then half of Fee 2. *** ## Adjust fees or penalties To adjust a transaction involving fees or penalties that has been applied by mistake or with the wrong amount: 1. Open the loan account. 2. Select the **Transactions** tab. 3. On the right-hand side of the transaction row, select **Actions** > **Adjust**. 4. Enter the reason for the adjustment. 5. Select **Adjust Fee** or, if you are reversing a penalty, select **Adjust Penalty**. :::note If the repayment was late for long enough that several penalties were applied, then the adjustment should be made for each **Penalty applied** transaction, as described above. ::: :::warning Penalties can only be reversed *before* the repayment is entered. ::: *** ## Reduce fees or penalties Fees and penalties due can be reduced (or written-off) instead of reversed. To do this, select **More** > **Reduce Balance** > Choose **Fee** or **Penalty** > Enter the new amount due > Select **Reduce Balance**. This will result in the write-off of the difference between the original amount due and the new amount due. ![Reduce Balance screen with Reduce drop-down, new balance and account notes. Available buttons are Cancel and Reduce Balance.](@site/static/img/support/loans--reduce-balance-dialog.png) For Fixed Term Loans, there is a different way to reduce the balance: 1. Go to the account. 2. On the right-hand side of the screen, select **More** > **Edit Schedule**. 3. Edit (reduce) the amount of the fee. 4. Save your changes. ![Editing repayment schedule dialogue showing where you can adjust fees](@site/static/img/support/adjust-fees-fixed-term-loans.png) This will trigger a **Fee Due Reduce** transaction which is the equivalent of **Write-Off Fee** transaction (in Accounting). --- # Approving a Loan URL: https://docs.mambu.com/docs/approving-a-loan/ To approve a loan account, select the **Approve** button, and confirm the dialog box. This will change the account state to **Approved**, and it will be ready for disbursal as the **Disburse** button becomes visible. :::warning Before you can disburse a loan account, it has to be approved by a user with the `Approve Loan` permission. ::: ![Approve button on product Details tab](@site/static/img/support/loans--client-profile-loan-details.png) It is only possible to approve loans in the **Pending Approval** state, when a loan account is in **Partial Application** state it can be submitted for approval by clicking on the **Request approval** button and confirming. For more information, please see [Loan Account's life cycle and states](/docs/loan-account-life-cycle-and-states). :::note Once a loan account is approved, the loan parameters - such as amount, rate, terms, and so on - cannot be further edited; only custom field values and the account name can be edited after approval. ::: At approval, the system will validate additional constraints, such as: * Accounts must comply with the securities requirements. If set at product level, the required percentage of securities should be present on the account for it to be approved. * Line of credit restrictions (if applicable): the loan should be within the line of credit's date and amount limits. * User transaction limits. If the approval limit is set, the system will not allow users to approve loans that are over their allowed approval limit. ## Undoing a loan account approval If you want to undo the approval of a loan account, select **More** > **Undo Approve**. This will bring the account back to the `Pending Approval` state. --- # Arrears Settings URL: https://docs.mambu.com/docs/arrears-settings/ When [setting up a new loan product](/docs/setting-up-new-loan-products), you can control how a loan's days in arrears should be calculated in the **Arrears Settings** section. These settings affect anything that is derived from a loan's days in arrears, such as penalties, notification templates and reports. ## Arrears tolerance period You can define the number of days of tolerance. This allows loan repayments to be late while the account remains in "Active" state and do not count towards your Performance and Accountability Report (PAR). Some organizations use the arrears tolerance period to give field officers in remote areas - that are often offline - time to get back to a branch with internet access to log their work. The number of days you enter will determine the period that a loan account with late repayments will remain "Active". After this period, Mambu will automatically change its state to "In Arrears", in case there are late repayments. If you choose not to determine an **Arrears Tolerance Period**, enter a zero in the field. Mambu will automatically set the loan account state to "In Arrears" as soon as an installment is due and no payment has been received. The tolerance period is defined on the loan product level. When creating or editing a loan product, enter the number of tolerance days in the **Arrears Tolerance Period** field. You can also establish a minimum and maximum value for the period, which enables users to determine the arrears period at account creation within these constraints. ![Arrears Settings at Product Level with Arrears Tolerance Period (days), Arrears Days Calculated From and Non-Working Days in Arrears Tolerance Period and Penalty Calculation Method and Arrears Tolerance Amount (% of Outstanding Principal) and With a floor (minimum) options](@site/static/img/support/arrears-settings.png) ### Days in arrears indicator On loan accounts, as well as in custom views, you can see the number of days a loan is late and in arrears. The difference between these two counts is due to the **Days In Arrears** indicator being calculated based on the the arrears tolerance period, while the **Days Late** indicator is displayed even when the account is not yet in arrears - due to the arrears tolerance period. For example, a loan that has a two-day arrears tolerance period specified and where a payment is 87 days late has a **Days In Arrears** count of 85. ![arrears-tolerance-days-count](@site/static/img/support/arrears-tolerance-days-count.png) We will review some detailed examples of calculating **Days in Arrears** in the next section. For more information, go to [Working with overdue loans](/docs/working-with-overdue-loans). ### Counting the days in arrears Mambu has two options for counting the number of days in arrears. - **Date Account First Went Into Arrears**: from the date the account first went into arrears. This could stretch across several late installments, even if one or more of the earlier ones have since been repaid, provided that the account has not yet been put back into good standing. - **Date of Oldest Currently Late Repayment**: from the oldest currently-late installment, even if the account first went into arrears at an earlier date. ![Arrears Days Calculated From option in Loan Product setup](@site/static/img/support/arrears-days-calculated-from-loan-product.png) #### Example Consider a loan with the following expected schedule when the arrears tolerance period is zero: As shown by the list of transactions, this account went into arrears on two occasions: 1. On September 11, because the total expected EUR 2,041.67 on September 10 was not paid. A repayment of EUR 3,000.00 was entered on October 20 which paid in full the September installment but only partially the October installment. 2. On October 11, because the total expected EUR 958.33 on October 10 was not paid. The next repayment expected on November 10, also failed to be paid on time. ![Example: calculating Arrears Days – transactions](@site/static/img/support/calculating-days-in-arrears.png) Using the **Date Account First Went Into Arrears** method of counting the days in arrears, the account would be 81 days in arrears as of September 11: the number of days between September 11 (the due date) and November 30 (the current date). This is because the account first went into arrears on September 11 and had not been put back into good standing, even though the September installment has been paid. ![Calculating the number of days in arrears using the date account first went into arrears method](@site/static/img/support/date-account-first-went-into-arrears.png) Using the **Date of Oldest Currently Late Repayment** method of counting the days in arrears, the account would be 51 days in arrears as of October 11, because the oldest late repayment was the repayment due on October 11. ![Calculating the number of days in arrears using the date date of oldest currently late repayment method](@site/static/img/support/date-of-oldest-currently-late-repayment.png) ### Non-Working Days in Arrears Tolerance Period and Penalty Calculation In this setting, you may specify whether the day counter, before the loan is set in arrears, should include or exclude non working days as per your [holidays and non-working days](/docs/holidays-and-non-working-days) settings. ![Arrears settings - Non-Working Days method](@site/static/img/support/loans--arrears-settings.png) You can select: * **Include Non-Working Days**: All days will be taken into account when changing the account state from "Active" to "In Arrears". If the arrears tolerance period is seven days, Mambu counts all the days in the arrears tolerance period including weekends and holidays. Penalties are applied after the arrears and penalty tolerance period has passed, and are calculated from the due date, including non-working days and holidays. * **Exclude Non-Working Days**: In this case, Mambu checks what are the non working days (holidays and weekends) defined under **General Setup** > **Holidays**. Then Mambu counts the arrears tolerance period taking into consideration only business days. If the arrears tolerance period is seven days, loans will change their state from "Active" to "In Arrears" after nine days (considering that we start counting from Monday and we have two non working days on the weekend). Penalties are applied after the arrears and penalty tolerance period has passed, and are calculated from the due date, excluding non-working days and holidays. :::note When you choose to **Exclude Non-Working Days**, penalties for those non-working days are not calculated and thus not applied on the following days. ::: For more information, see [Loan Penalties Setup](/docs/loan-penalties-setup). *** ## Arrears tolerance percentage ### Arrears Tolerance Amount (% of Outstanding Principal) You can define the **Arrears Tolerance Amount (% of Outstanding Principal)** on the product level for your loan accounts. If the due amount exceeds a predefined percentage in relation to the outstanding loan balance, the loan account’s state will automatically change to "In Arrears". You can specify three optional fields under **Arrears Tolerance Amount (% of Outstanding Principal)**: * **Default**: the default tolerance percentage * **Min**: the minimum tolerance percentage * **Max**: the maximum tolerance percentage You can enter positive values with decimals to any of these fields. If you leave all three fields empty, the **Arrears Tolerance Amount (% of Outstanding Principal)** will not be taken into consideration for loan accounts created from this product. ### With a floor (minimum) In addition to **Arrears Tolerance Amount (% of Outstanding Principal)**, you can use the option **With a floor (minimum)**, where you can specify the minimum in absolute terms rather than as a percentage of the outstanding loan balance. :::note If you specify both an **Arrears Tolerance Amount (% of Outstanding Principal :::** and a value for **With a floor (minimum)**, the greater value of the two is taken into account for the loans created using this Loan Product.) If a partial payment that is above the **With a floor (minimum)** amount is made, the status of the installment changes to "Partially Paid" on the due date, not "Late". As an example, please consider the following loan: * A total of USD1,000 dynamic loan * Disbursement date: January 1, 2020 * Schedule: 5 monthly installments * Monthly repayments due on the 1st of each month * Days of arrears tolerance period: 2 days * Arrears floor minimum: USD100 * The arrears days calculation excludes non working days A partial repayment of USD120 was made on February 1, and no other repayments were made since. On April 28, the loan schedule looks as follows: ![arrears-tolerance-schedule-with-floor](@site/static/img/support/arrears-tolerance-schedule-with-floor.png) Since the account status in not **In Arrears** on the February 1, there is a bigger diference between the **Days in Arrears** and **Days Late** counters. In our example, this is how the day counters look on the April 28, 2020: ![arrears-tolerance-days-floor](@site/static/img/support/arrears-tolerance-days-floor.png) :::note The arrears tolerance **percentage** can be set on the **account** level (within the minimum and maximum specified for the product :::, whereas the **floor** can only be set on the **product** level and cannot be changed on account level.) *** ## Editing loan products to include arrears settings The values specified in **Arrears Tolerance Amount** are applicable only to newly created Loan Accounts. You can only edit or define these fields when the account is in a **Pending** state. Once the account state is changed to **Approved**, the fields cannot be edited anymore. Any changes made to the **Arrears Settings** of the loan product propagate to all loan accounts with **Pending** status based on this product, regardless of whether the changes were made before or after creating the account. The changes to the loan product **do not** affect accounts with the **Approved** status. --- # Audit Trail V2 URL: https://docs.mambu.com/docs/audit-trail-v2/ The complete Audit Trail V2 API documentation can be found here: [Audit Trail V2](/api/pages/audit-trail/welcome) --- # Audit Trail URL: https://docs.mambu.com/docs/audit-trail/ The audit trail capability tracks all activities that have been performed in the Mambu Core Banking system via the UI or API [v1](/api/pages/api-v1/welcome) and [v2](/api/pages/api-v2/welcome). Audit records are grouped per tenant. You can search and filter through stored events using a simple API or periodically pull batches of events into your own log management software for further analysis. We start storing events from the point that the audit trail feature is enabled. Events are stored for the same length of time as the one defined in your agreement. For more information, please contact your Customer Success Manager. :::warning The audit trail feature only covers the Mambu application. Additionally, configuration as code payloads are not covered by the audit trail feature. We recommend using version control to retain a comprehensive changelog for these payloads. Auditing for actions taken on add-on products, such as the Mambu Payment Gateway (MPG) or the Mambu Process Orchestrator (MPO), may be covered by their own logging and auditing solutions. ::: With audit trail you are able to: * Identify what Mambu application users have done and when they did it. * Choose who to audit and what type of information to audit. Some example use cases might be: * Investigate suspicious activity or potential fraud. * Detect actions performed by an unauthorized user. * Monitor and gather data about specific activities. * Generate compliance and audit reports from audit data. :::warning Please Be Aware Use of **Audit Trail** requires **API Consumers**, which is an Early Access feature. For more information, see [Authentication](#authentication) below. ::: ## Authentication To authenticate audit trail requests you must use an API key generated by an API consumer that has the Manage Audit Trail (`MANAGE_AUDIT_TRAIL`) permission assigned to it. For more information, see [API Consumers](/docs/api-consumers). ## Supported operations **Base URL**: `https://TENANT_NAME.mambu.com/api` | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/v1/events` | Get a list of events. | ## Headers Other than the authentication header with the API key, there are no other additional headers required. ## Parameters The following is a list of query parameters you can use to filter your requests. Name | Description | Required | | --- | --- | --- | | `FIELD_NAME[OPERATOR]`
`=FIELD_VALUE` | A filter using a LHS bracket with an operator. There can be more than one filter used per request. For a list of field names, see [Field Names](#field-names) below. For a list of available operators, see [Operators](#operators) below. | ✘ | | `from` | Allows you to offset results, the default is 0. Can be used in conjunction with the `size` parameter to return equally sized sets. Note that the number provided is **not inclusive**, so, for example, given a total results set of 100 events, `from=10` will return the 11th to the 100th event. For information about limits, see [Warnings](#warnings) below. | ✘ | | `size` | The number of event entries to return. If not specified, the default is 100. Can be used with the `from` parameter to page through a list of events in equally sized sets. For information on limits, see [Warnings](#warnings) below. | ✘ | | `sort_by` |The field name by which to sort the returned events. For a list of field names, see [Field Names](#field-names) below. If not specified the results will be sorted chronologically using the `ocurred_at` field. | ✘ | | `sort_order` | The order by which to sort the returned events using either `asc` (ascending) or `desc` (descending) order. If not specified, the default is descending order.| ✘ | ## Requests The following section shows sample requests using curl. For all examples, replace `TENANT_NAME` with your actual tenant URL. ### Sample request Get all UI login activities for today ```bash curl --location -g --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?event_source[eq]=UI&resource[contains]=login&occurred_at[gte]=2021-08-08T00:00:00.000Z' \ --header 'apikey: ' ``` `` is an API key from the audit trail API consumer. For more information about authentication, see [Authentication](#authentication) above. ### Sample response ```json { "events": [ { "occurred_at": "2021-08-09T09:47:04.664Z", "response_code": 200.0, "resource": "login", "event_source": "UI", "client_ip": "80.131.123.137", "request_method": "POST", "request_payload": "", "resource_fragment": "/servlet/login", "request_uri": "/servlet/login", "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36", "response_payload": "SUCCESS", "username": "johnsmith" } ], "from": 0, "size": 100, "totalItemsCount": 1 } ``` ### Additional sample requests `` is an API key from the audit trail API consumer. For more information about authentication, see [Authentication](#authentication) above. Get API requests with failed authorization ```bash curl --location -g --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?event_source[eq]=API&response_code[eq]=401&=' \ --header 'apikey: ' ``` Get the last ten clients viewed by user “johnsmith” ```bash curl --location -g --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?event_source[eq]=UI&occurred_at[gte]=2020-04-09T19:20:01.040Z&resource[eq]=client&username[eq]=johnsmith&request_uri[eq]=/desktop/dispatch/GetClient&size=10' \ --header 'apikey: ' ``` Page through all events in batches of 10 1. ``` curl --location --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?from=0&size=10&occurred_at[gte]=2021-08-11T11:00:00.000Z' \ --header 'apikey: ' ``` 2. ``` curl --location --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?from=10&size=10&occurred_at[gte]=2021-08-11T11:00:00.000Z' \ --header 'apikey: ' ``` 3. ``` curl --location --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?from=20&size=10&occurred_at[gte]=2021-08-11T11:00:00.000Z' \ --header 'apikey: ' ``` Notice that in this last example we are using a filter on the `occurred_at` field. This is important as, if no constraints are used and the default descending chronological order is applied, any new events matching your query will be included in the index and possibly cause your sets to intersect. Fixing the time at a given point is one way to ensure new events are not included in your results and your sets contain only unique events. ## Parameter components ### Field Names |Event fields|Description|Supported operators| |----------------|---------------|----------------------------| |`event_source`|The events that are supposed to be audited fall within the following categories: `API`, `UI`|`eq`, `ne`, `in`| |`request_uri`|The part of the request's URL after the base URL and up to the query string|`eq`, `ne`, `startsWith`, `in`, `contains`| |`request_method`|HTTP request method (`GET`, `POST`, `PUT`, etc)|`eq`, `ne`, `in`| |`request_payload`|The raw request data as a string, with sensitive information removed (see details in note below). Parameter may be empty. |`eq`, `ne`, `startsWith`, `in`, `contains`| |`user_agent`|The value of HTTP user agent header|`eq`, `ne`, `startsWith`, `in`, `contains`| |`resource`| **For API requests**, this value is obtained from parsing the URL. e.g for /api/clients" the resulting value is "clients" |`eq`, `ne`, `startsWith`, `in`, `contains`| |`resource_fragment`|**For API requests** this holds the request URI
**For UI operations** this holds the raw URL hash|`eq`, `ne`, `startsWith`, `in`, `contains`| |`username`|The user who carried out the action or the name of the API consumer (may be empty)|`eq`, `ne`, `startsWith`, `in`, `contains`| |`client_ip`|IP address from http request or X_FORWARDED_FOR header if present|`eq`, `ne`, `startsWith`, `in`| |`response_code`|HTTP response code|`eq`, `ne`, `in`, `gt`, `gte`, `lt`, `lte`| |`occurred_at`|The timestamp, in UTC, when the event has been generated (when creating queries on this field the provided values must be in ISO8601 standard)|`eq`, `ne`, `in`, `gt`, `gte`, `lt`, `lte`| |`response_payload`|The raw response payload with sensitive information removed (see details in note below). A response payload is not included with every record. |`eq`, `ne`, `startsWith`, `in`, `contains`| ### Operators |Operator|Description|Example| |------------|----------------|------------| |`eq`|Equals - exact match, applies to any type of fields|`username[eq]=demo@mambu.com`| |`ne`|Not equals, applies to any type of fields|`username[ne]=demo@mambu.com`| |`gt`|Greater than, applies to numeric or date fields|`occurred_at[gt]=2018-05-01`| |`gte`|Greater than or equal, applies to numeric or date fields|`occurred_at[gte]=2018-05-01`| |`lt`|Less than, applies to numeric or date fields|`occurred_at[lt]=2018-05-01`| |`lte`|Less than or equal, applies to numeric or date fields|`occurred_at[lte]=2018-05-01`| |`startsWith`|Starts with, applies to string fields|`username[startsWith]=demo`| |`in`|Element in list (exact match), applies to any type of fields|`username[in]=`
`user1@mambu.com,user2@mambu.com`| |`contains`| This operator can be used with various content types. `"key":"value"` represents a search element. The order of the key and the value matters, for example, using the element `"mykey": "myvalue"` is not the same as `"myvalue":"mykey"`. The operator works with multiple elements that are delimited by ',' .The order of the elements doesn’t matter, for example `request_payload[contains]=`
`"key1":"value1","key2":"value2"`will return the same results as `request_payload[contains]=`
`"key2":"value2","key1":"value1"`. |`request_payload[contains]=`
`"provisionedThroughFederation":`
`true, "detailsLevel":"BASIC"`| ## Warnings ### Data retrieval limits Given a set of filter query parameters, you can only retrieve 10,000 entries. The combination of the values of the `size` parameter and the `from` parameter must not exceed 10,000 or else you'll receive a `400 Bad Request` status code with an error message such as: `"message": "From (10) and size (10000) combination exceed 10000, the maximum allowed window. Default size is 100"` The maximum value of the `size` parameter is 10,000. The maximum value of the `from` parameter is 10,000. If you want to retrieve entries that are past the last 10,000 entries retrieved then you must use the filter query parameters to alter your request. For example you can use the `occurred_at` parameter and pass in an operator in order to narrow your query. #### Example In the following example we show how you can use the filter parameters to change your requests and retrieve different sets of events. Suppose that you want to get a simple list of all the latest events that have happened in your tenant. With the following request you would retrieve the 10,000 latest entries: ```bash curl --location --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?size=10000' \ --header 'apikey: ' ``` Suppose the events retrieved are from the 4 August, 2021 until the 18 August, 2021. If you wanted to retrieve events before the 4th August, 2021 then you could change your request by using the `occurred_at` filter query parameter and passing in an operator. For example: ```bash curl --location -g --request GET 'https://TENANT_NAME.mambu.com/api/v1/events?size=10000&occurred_at[lte]=2021-08-04T00:00:00.000Z' \ --header 'apikey: ' ``` This could, for example, retrieve events from the 4 August, 2021 until the 13 July, 2021. ### User-Agent header When audit trail is enabled, you **must** provide a `User-Agent` header for **all requests to any endpoint**, or the request will fail with the error message: ```json { "returnCode": 4, "returnStatus": "INVALID_PARAMETERS", "errorSource": "The user agent cannot be null when the Audit Trail feature is enabled" } ``` Note that if you are using a REST client like Postman or Curl, this header is probably provided automatically. However, if you generate a request to the API, you must provide it yourself. The `User-Agent` header provides information regarding the browser and operating system (such as the browser version), and information about the library or tool issuing the request (such as the client Java version). It is generally used to assist with debugging problems. ### Invalid characters in a header or path When using basic authentication, the requests you make to any of our APIs must be RFC 7230 compliant. If you're using basic authentication and your request has an invalid character in either the header or the path, then you will receive a `400 Bad Request` status code and this request will not be logged in audit trail. Invalid characters are any characters that are not included in ASCII. We recommend validating your requests or using a well tested HTTP request library in your integrations. However if you experience any issues with repeated bad requests, please contact us through [Mambu Support](/docs/mambu-support). #### Example The example below will result in a `400 Bad Request` status code because one of the headers includes the `á` character which is not in the ASCII. ```bash curl --location --request GET 'https://TENANT_NAME.mambu.com/api/clients' \ --header 'Accept: application/vnd.mambu.v2+json' \ --header 'Content-Type: application/json' \ --header 'á: value' \ --header 'Authorization: Basic ' \ --data-raw '' ``` ## Security The following information is removed from request payloads when using audit trail: ``` PASSWORD, PAGINATION_DETAILS, FETCHING_INFO, MOBILE_PHONE, EMAIL_ADDRESS, ADDRESSES, BIRTH_DATE, MOBILE_PHONE1, MOBILE_PHONE2, FIRST_NAME, LAST_NAME, HOME_PHONE, MIDDLE_NAME, NOTES, GROUP_NAME, ADDRESS_LINE_1, ADDRESS_LINE_2, ADDRESS_LATITUDE, ADDRESS_LONGITUDE, DESCRIPTION, TITLE, TEXT, ASSET_NAME, LOAN_NAME, NAME, POST_CODE, COUNTRY, REGION, GENDER, IBAN ``` --- # Making Requests with Mambu Apps URL: https://docs.mambu.com/docs/authenticating-requests/ The application that communicates with a Mambu App may need to be able to do the following to complete requests: * Authenticate requests that come from the Mambu App. * If the application needs data from the Mambu Banking Engine, make API calls to the Mambu API. When these actions are possible, Mambu App requests are submitted as a web form and the returning results from the application are rendered in the App’s iframe window in the Mambu UI. :::note We recommend always using HTTPS for all endpoints. This ensures that the signed request is secure in transit. ::: ## Authenticating requests To ensure that communication between the Mambu App and the application is secure, an App Key is used to sign requests. Both the Mambu App and your application need to have the same secret App Key to be able to hash and authenticate requests. ![The input field where you add the App Key](@site/static/img/support/mambu-apps-access-964x326.png) ### How request are authenticated When an App communicates with an application, a signed request is sent to the URL listed as an endpoint. This request has two parts separated by a period using the following template: `.` Both parts contain a JSON of the request parameters, which are contextual information about where the Mambu App sent the request from. This information may include which client the Mambu App is in, which tenant sent the request for multi-tenant Apps, and other contextual information to help complete the request on the application end. The difference in the parts is in how they are encoded or hashed: * `PART1` of the request contains the JSON in a [HMACSHA256](https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.hmacsha256) hashed signature, created using the App Key. * `PART2` contains the Base64-encoded JSON of the request parameters. To check that `PART1` and `PART2` match, you need to hash `PART2` using HMACSHA256 and compare it to `PART1`. If `PART1` matches `PART2`, the application can be sure the request was made by an authenticated Mambu App. `PART2` can be decoded using Base64 to get extra parameters from it. ## Getting Mambu data using the Mambu API Some applications may require data from the Mambu Banking Engine. For example, an application that returns credit scoring information from third-party providers would need to know the name of the client and their details to return their credit score to the Mambu App window. In this case, they should fetch information from the Mambu API - for more information, see our [API Reference](/api/). To access the Mambu API, we recommend using [API consumers ](/docs/api-consumers)to [generate API keys](/docs/api-consumers#generating-api-keys). Your application can then store the API key details and use them in its logic to complete the request. --- # Authorization Holds URL: https://docs.mambu.com/docs/authorization-holds/ *Authorization holds* are the result of successful payment card authorizations. There are two types of authorization holds: * Debit (DBIT) holds: decrease the available balance of a card account. * Credit (CRDT) holds: have no impact on the available balance. You can process authorization requests, authorization advices, incremental authorizations, authorization reversals, and balance inquiries via the Cards API. For more information, see [Cards](/api/api-v2/cards/cards) in our API Reference. For more information on the permissions needed to manage authorization holds setup, see the [Permissions](/docs/permissions) article. Authorization holds have no impact on the ledger or the total balance of a deposit account. ## Authorization hold states Authorization holds can be in one of the following statuses: `PENDING`: Active hold, decreasing the available balance. `SETTLED`: Not active, released during the processing of a related payment card transaction. `EXPIRED`: Not active, marked as expired during automated cron job process. `REVERSED`: Not active, marked as reversed as a result of the processing of a reversal instruction or a decline notification. You can retrieve either an array of [all authorization holds](/api/api-v2/deposits/get-all-authorization-holds/) for a given deposit account or [details on a specific hold](/api/api-v2/cards/get-authorization-hold-by-id) on a given card by its ID. Card authorization holds are distinct from transaction holds, which may be applied to any deposit transaction. For more information, see [Transaction Holds](/docs/transaction-holds). The following table describes the different types of messages that pass between the card issuer and Mambu, depending on the type of authorization initiated. | Card message Type | Debit Cards Availability | Credit Cards Availability | | --- | :---: | :---: | |Debit Authorization Request | YES | YES | | Credit Authorization Request | YES | NO | | Debit Authorization Advice | YES | NO | | Credit Authorization Advice | YES | NO | | Balance Inquiry | YES | YES | | Full Authorization Reversal | YES | YES | | Partial Authorization Reversal | YES | YES | ### Authorization requests Authorization requests are a part of the Dual Message Schema, the purpose of which is to perform an authorization before sending related clearing transaction. Debit authorization is used to check the card and the account, that there is enough account balance for a cash withdrawal, purchase of goods and services, or other debit type of operation. The request body parameter `advice` must be set to `FALSE` to enable balance check and separate the authorization request from the authorization advice. Credit authorization is used to check the card and the account in order to execute a refund, cashback or other type of credit operation. [Authorization requests](/api/api-v2/cards/create-authorization-hold) can only be performed via [Mambu API v2](/api/api-v2/cards/cards). Each authorization hold request in Mambu will have a reference number. Once an authorization hold is created, it has the status `PENDING` until it is settled, reversed, or expired. ### Authorization advices If authorization happens on behalf of the issuer, without checking whether the card holder has sufficient funds to cover a given transaction, third-party systems use authorization advice to inform about the result of such authorizations. There can be negative or positive advice. Mambu supports positive authorization advice. [Authorization advice](/api/api-v2/cards/create-authorization-hold) creates a hold on a card account without checking the available balance. The request body parameter `advice` must be set to `TRUE` to disable the available balance check. The final authorization advice contains the final hold amount. Usually it is not clear whether the final hold amount is higher or lower than the initial amount. To resolve this porblem, you can change the hold amount while calling the [dedicated cards PATCH authorization hold API](/api/api-v2/cards/patch-authorization-hold). ### Incremental authorization Authorization holds with a `PENDING` status can be [increased](/api/api-v2/cards/increase-authorization-hold) by making an API request and supplying the card token (`cardReferenceToken`) and the authorization hold reference (`authorizationHoldExternalReferenceId`) along with the amount used to raise the held amount. ### Authorization reversals Mambu supports both full and partial authorization reversals. After receiving a partial reversal, the referenced authorization hold with a `PENDING` status can be [decreased](/api/api-v2/cards/decrease-authorization-hold) by making an API request and supplying the card token (`cardReferenceToken`) and the authorization hold reference (`authorizationHoldExternalReferenceId`), along with the amount to decrease the held amount. If the amount used is equal to or larger than the held amount, the hold is fully reversed and the hold is given a `REVERSED` status. You can also fully reverse a `PENDING` authorization hold by making a [delete](/api/api-v2/cards/reverse-authorization-hold) request and supplying the card token (`cardReferenceToken`) and the authorization hold reference (`authorizationHoldExternalReferenceId`). ### Balance inquiry Using a card token, you can also get account balances. The response of the [Get account balances](/api/api-v2/cards/get-account-balances) request contains the following information: the available balance, the total balance, the credit limit, the account currency, the account ID, and the card type. The available balance and the ledger balance are also returned in the response of each successfully created authorization hold or card transaction. ### Authorization Holds Configuration :::warning We strongly recommend that you use an end-to-end test to test any configuration changes in your sandbox environment before implementing them in your production environment. The test should check that the hourly `AUTHORIZATION_HOLDS_EXPIRATION` cron job correctly sets authorization holds to expired. To perform a test on holds in the past contact us through [Mambu Support](/docs/mambu-support) so that we can assist you with manipulating the data in the database. ::: The authorization holds configuration determines the expiration period for authorization holds in days. The default value is seven days but it can be changed. You may also specify different expiry periods for specific merchant category codes (MCC). You may configure authorization holds settings either through the Mambu UI or via the API. For more information, see [Authorization Holds Configuration](/docs/configuration-as-code-for-authorization-holds). To change the default expiration period for authorization holds: 1. On the main menu, go to **Administration** > **Financial Setup** > **Authorization Holds**. 2. Next to **Default period before expiration**, enter the number of days after which you want the authorization holds to expire. The value must be between 1 and 36,525 days. 3. Select **Save**. ![Setting-an-expiration-date-for-authorization-holds](@site/static/img/support/authorization-holds-add-catogory-code.png) To add an expiration period for an MCC: 1. On the main menu, go to **Administration** > **Financial Setup** > **Authorization Holds**. 2. Select **Add**. 3. Enter a value for the **Merchant Category Code**. 4. Enter a value for the **Days to Expiration**. The value must be between 1 and 36,525 days. 5. Select **Save**. Mambu authorization holds support the custom expiration period. You can set expiration period in days while creating a hold in the request body parameter `customExpirationPeriod`. The `PENDING` debit authorization hold can be updated using the [Update authorization](/api/api-v2/cards/patch-authorization-hold). ### Hourly authorization holds cron job The hourly cron job `AUTHORIZATION_HOLDS_EXPIRATION` runs automatically and marks any authorization hold requests on which a settlement action has not been taken before the expiration period has elapsed. For example, if the expiration period set for authorization holds is set to 14 days, then any authorization holds created or updated more than 14 days ago are candidates to be expired. When an authorization hold expires, its state changes from `PENDING` to `EXPIRED` and the hold amount no longer affects a client's available balance. For more information about cron jobs at Mambu, see [Automatic End of Day Actions](/docs/automatic-end-of-day-actions) and [Hourly jobs](/docs/automatic-end-of-day-actions#hourly-jobs). If you change your authorization holds configuration, the new configuration will take effect with the next `AUTHORIZATION_HOLDS_EXPIRATION` cron job to run. Holds made directly on deposit accounts via account ID do not expire. For more information, see [Transaction Holds](/docs/transaction-holds). --- # Automated EOD Account Exclusion Processing URL: https://docs.mambu.com/docs/automated-eod-account-exclusion-processing/ This document provides an overview of the automated process for excluding broken accounts from Mambu's End-of-Day (EOD) processing. When an account is broken, it can cause the EOD process to fail. This disrupts customer services that rely on the EOD success webhook. To solve this, we've automated the process of identifying and excluding broken accounts from EOD processing. This new mechanism automatically detects problematic accounts and skips them, allowing the EOD to complete successfully without manual intervention. This is a crucial step towards our long-term goal of automatically "healing" broken accounts. ## How it works The automated process is triggered by specific appraisal failure exceptions that indicate a broken account. * **Initial failure**: The first time an account causes an EOD failure, Mambu logs the issue and sends an EOD failure webhook to the customer, as usual. * **Automatic exclusion**: On subsequent EOD runs (which retry every hour), the system checks for the logged issue. If the account is on the "broken" list, it is automatically skipped. This allows the EOD process to finish successfully, while still keeping a record of the original failure. ## Frequently Asked Questions (FAQ) ### How will customers know if an account has been automatically excluded? Mambu is designed to notify customers. If a new "broken" loan account is found, the End-of-Day (EOD) process will initially fail. When this happens, customers will receive a webhook notification, just as they do now. The Mambu system will then automatically retry the EOD process within the next hour. This time, the broken account will be excluded, and the EOD will be successful. Additionally, as soon as the Mambu EOD process fails for the first time, we will open a Salesforce case and inform customers about the specific broken account(s). This automation is in place to ensure that our teams can handle these issues efficiently without manual intervention, and your Mambu EOD process can continue. ### What happens to the accounts that are excluded? When an account is excluded, we open a Salesforce case and pass it to the respective team for further investigation. They will work to fix the issue with the account. Once the problem is resolved, the account will be included back into the Mambu EOD process as part of their standard operational procedures. ### Could an infrastructure issue cause all accounts to be excluded from the EOD? No. The Mambu EOD auto-exclusion logic is specifically built to only exclude accounts that fail due to very specific appraisal errors. These errors are caused by schedule failure exceptions like: * `NegativePrincipalForRepaymentException` * `InconsistentScheduleWithLoanAmountException` * `UnableToAllocateAmountAfterSeveralAttemptException` This ensures that only genuinely broken accounts are excluded, and not healthy ones affected by broader system issues. ### What happens to an account while it is excluded from the EOD? The Mambu EOD process primarily appraises an account, which means it applies interest, penalties, and other necessary calculations. While an account is excluded, these operations will not be performed. This is the same as what would happen if the account was broken anyway. However, once the account is fixed and re-included, Mambu will automatically apply all pending interest, penalties, and fees, ensuring that the account is fully up to date. --- # End of Day Processing and Cron Jobs URL: https://docs.mambu.com/docs/automatic-end-of-day-actions/ By default, Mambu runs a daily series of automated tasks outside of business hours and an hourly series of additional processing tasks. These are grouped into a general category called End-of-Day processing (EOD processing): * **End-of-Day processing (EOD processing)**: These tasks ensure that all account states, days in arrears, penalties, and fees are up to date and consistent with any transactions that have been posted. These tasks are executed by *cron jobs*, or scheduled tasks. Accounting, reconciliation, and related tasks are carried out by *daily* and *hourly* cron jobs, depending on the task. All EOD processing jobs run on both production and sandbox tenants. There is no downtime while these scheduled tasks execute. EOD processes may also be configured to run at a manually-scheduled time or triggered by API. For more information, see [Manual end of day processing](#manual-end-of-day-processing) and [Manual end of day processing via the API](#manual-end-of-day-processing-via-the-api) below. ## Sequence of scheduled tasks 1. At midnight (00:00), as determined by your time zone settings, you pass the accounting cutoff, and all further transactions are logged to the next calendar day in the ledger. See [Accounting Cutoff](#accounting-cutoff) below for more information. 1. Every hour, Mambu checks to see if we have run daily jobs on the data of the most recent accounting day. * If not, the daily jobs run: 1. Account jobs (first execution) 2. Early organization jobs 3. Loan jobs, savings jobs 4. Account jobs (second execution) 5. Late organization jobs * If so, we skip to hourly jobs. 1. Hourly jobs run. ## Accounting Cutoff The *accounting cutoff* specifies the end of the accounting day. Any transaction made before the cutoff of a given day and after the cutoff of the preceding day will be considered to have occured "during that day" **only** for accounting purposes. If you have the Early Access **Accounting Cutoff** configuration feature enabled, then you can configure your accounting cutoff time. By default, if no specific accounting cutoff is set (that is, if the field is empty), then the accounting cutoff is at midnight as determined by your organization's configured time zone. For more information about time zones, see [Organization Contact Details and Time Zone](/docs/organization-contact-currency-and-timezone). To set the accounting cutoff time: 1. On the main menu, go to **Administration** > **Financial Setup** > **EOD processing**. 2. Select **Automatic** in the dropdown box labeled **End Of Day Processing**. 3. Enter the time at which accounting should be cutoff in the **Accounting Cut Off Time** field. All transactions after this time will have the next day as their [Journal Entry Date](/docs/booking-date-vs-value-date). ![Scheduling Accounting Cutoff Time in Mambu UI](@site/static/img/support/scheduling-eod-processing-2224x952%281%29.png) ## Daily jobs Daily jobs are executed if they are not already in progress or completed. Daily jobs are executed sequentially in this order: 1. Account jobs (first execution) 2. Early organization jobs 3. Loan jobs, savings jobs 4. Account jobs (second execution) 5. Late organization jobs Note that that account jobs are executed twice. ### Account jobs Account jobs are executed twice as part of the daily jobs execution. This is necessary to support certain business scenarios, such as those involving backdated or adjusted transactions. This may result in unexpected behaviour in rare cases. For example, when disbursing a loan where the first repayment date is in the past or on the current day, Mambu will collect the loan repayment with two transfer transactions rather than just one. | Name | Description | | --- | --- | | `AUTOMATED_TRANSFERS` | Automated transfers from deposit settlement accounts to loan accounts, as per loan account schedule. | | `UPDATE_SAVINGS_WITH_PRODUCT`
`_SETTINGS` | Updates deposit accounts with any changes made to underlying Deposit Product Settings. | | `UPDATE_LOANS_WITH_PRODUCT`
`_SETTINGS` | updates loan accounts with any changes made to underlying Loan Product Settings. | #### Appraisal per account Mambu performs account appraisals on a per-account basis. In other words, we run through all the steps for a single account and then move on to the next account. If EOD processing fails for a single account for any reason, Mambu still moves on to the next account. We then attempt to complete EOD processing for the failed accounts every hour in case the error has a temporary cause. However, if the account appraisal continues to fail, Mambu’s technical support will be alerted and will manually repair the account. ### Early organization jobs Early organization jobs focus on general ledger entries, making sure that they reflect all transactions, including any which may have been made on the current date, but backdated to have a booking date in the past. | Name | Description | | --- | --- | | `RESET_GL_JOURNAL_ENTRY`
`_SUMMARIES_INFO` | Resets all the information related to journal entry summary items in order to be able to recreate them from scratch. | | `GENERATE_GL_JOURNAL_ENTRY`
`_SUMMARIES` | Generates the GL journal entries summary items for the accounting entries logged since the last EOD job was executed. | | `UPDATE_JOURNAL_ENTRIES_FOR`
`_EARLY_INTEREST_ACCRUAL` | Updates the journal entries reflecting accrued interest before the accrual takes place. | #### Detailed description of steps The accounting summaries include **all** general ledger entries since the initialization of your Mambu system is automatically regenerated daily. First, all existing summaries are deleted by executing the `RESET_GL_JOURNAL_ENTRY_SUMMARIES_INFO` job. They are then recreated from scratch by executing the `GENERATE_GL_JOURNAL_ENTRY_SUMMARIES` process. The summaries are generated by taking into consideration all the General Leder (GL) journal entries logged during the day, grouped in a number of buckets, as determined by: * The GL account for which the entries were logged, * The branch of the loan / savings account for which the financial,transactions triggering the journal entries were logged - this is helpful in order to be able to filter by branch * The type (debit / credit), and * The entry date of the financial transaction triggering the journal entries. This is helpful in order to have a timeline for our accounting reports (basically, seeing how the balance sheet was looking on a given day). The balance of a summary is determined by the sum of the amounts logged along with the journal entries grouped using the aforementioned buckets. The formula used is Debit **-** Credit. If the result is positive or zero, the type of the summary will be debit, and if the result is negative, the type will be credit. ### Loan accounts jobs The next batch of jobs concern loan accounts. Some examples include: * Making sure that any changes to interest or tax rates have been applied, * Marking loans as *in arrears* if a payment was expected on the current day, or the grace period has expired, or * Managing the application of fees, penalties and accrued interest. | Name | Description | | --- | --- | | `AUTO_CLOSE_PAID_OFF_LOANS` | Automatic closure of loan accounts with zero balances, based on the Loan Product Dormancy settings. | | `AMOUNTS_AMORTIZATION` | Fee amortization in accounting. | | `INTEREST_RATE_UPDATE` | Updates Interest Rate based on Index Interest Rate changes. | | `TAX_RATE_UPDATE` | Update tax rate based on Tax Rate changes. | | `PERIODIC_PAYMENT_UPDATE` | Updates periodic payment. | | `CREATE_REVOLVING_CREDIT`
`_DUE_REPAYMENTS` | Creates repayment schedule for Revolving Credit loan accounts. | | `LOCK_CAPPING_CHECKER` | Checks if capping constraints have been exceeded and pass the loan account into locked capping state if necessary. | | `LOAN_INTEREST_APPLY` | Application of interest accrued. | | `LATE_LOAN_CHECKER` | Sets the loan accounts to "In Arrears" state. | | `PAYMENT_DUE_FEES_APPLY` | Application of due fees. | | `PENALTIES_APPLY` | Application of any penalties. | | `AUTO_REDRAW_REPAYMENT` | Automatically redraws due repayment. | | `AUTO_LOCK_ARREARS_LOANS` | Locks the loan accounts that have been in arrears for a specific period of time as defined in Loan Product setup. | | `DUE_AMOUNTS_UPDATE` | Updates all amounts due based on any interest, penalties and fees applied for that day. | ### Saving accounts jobs Savings accounts jobs run against deposit accounts. Similar to loan accounts jobs, these will manage application of accrued interest, fees, and penalties as well as mark accounts as dormant if the product is configured to automatically set accounts as dormant after a period of inactivity. | Name | Description | | --- | --- | | `SAVINGS_ACCOUNT_APPRAISER` | | | `AUTO_DORMANT_INACTIVE`
`_SAVINGS_ACCOUNTS` | Sets deposit accounts as Dormant as defined in Deposit Product Settings. | ### Late organization jobs The late organization jobs include jobs which are run to add notifications to queues. For example, if you have set up notifications to let customers know a repayment is due or about a scheduled disbursement, the notification message will be generated at this time and added to the queue to be sent at the opening of business. This set also includes some system-related jobs such as enforcing password rotation for Mambu users. | Name | Description | | --- | --- | `UPDATE_JOURNAL_ENTRIES`
`_FOR_LATE_INTEREST_ACCRUAL` | Updates journal entries reflecting the accrued interest after the accrual takes place. | | `END_OF_DAY_CLOSURE` | Performs end of day accounting closures, after which the [Accounts Updated](/docs/automatic-end-of-day-actions#eod-completion-notification) event is sent.| | `UPCOMING_REPAYMENTS_CHECKER` | Searches for all the repayments which are in Pending or Partially Paid state and trigger reminder Notifications using templates (check the due dates equal to today plus a configured number of days (how many days before that due date) and create notifications). | | `ACCOUNT_IN_ARREARS_CHECKER` | Triggers notifications after a configured number of days since the account is passed into arrears state. | | `UPCOMING_DISBURSEMENT_CHECKER` | Triggers notifications for Approved accounts with a configured number of days before the expected disbursement date (loans and tranches). | | `ENFORCE_USER_PASSWORD_RESET` | Resets user passwords if the period defined in "Internal Controls" is up. | | `ORGANIZATION_SNAPSHOT` | Creates a snapshot of all indicators for organization. | :::note For the current status of daily actions, please see [Scheduled jobs summary](/docs/mambu-data-dictionary#scheduledjobsummary). For the status of the latest job, make a GET request to [/backgroundprocess/latest](/api/api-v2/backgroundprocess/get-latest-by-type), specifying the type as `CRON_JOBS`. The endpoint will return the last-started job of `CRON_JOBS` type alongside additional information, such as `state`, `start date`, and `end date` - if it is available. ::: ## Hourly jobs Hourly jobs are executed after daily jobs. | Name | Description | | --- | --- | | `SEND_QUEUED_NOTIFICATIONS` | Checks for queued notifications and schedule them for sendout. | | `AUTHORIZATION_HOLDS_EXPIRATION` | Expires any authorization hold requests on which a settlement action has not been taken before the expiration period has elapsed. For example, if 14 days is the expiration period set for authorization holds, then any authorization holds created or updated 14 days ago are candidates to expire. When an authorization hold expires, its status changes from `PENDING` to `EXPIRED` and the hold amount no longer affects a client's available balance. For more information, see [Card Transactions](/docs/card-payments-and-authorization-holds) and [Configuring authorization holds settings](/docs/card-payments-and-authorization-holds#configuring-authorization-holds-settings). | :::note SMS notifications are not sent at midnight, but starting at 9:00 am in your organization's configured time zone. ::: ## EOD Completion Notification End-of-Day (EOD) process completion is one of several system events that can trigger an automated notification. For a complete list of triggers, see [Event triggers](/docs/event-triggers). This notification is designed for system-to-system communication and can be delivered via Webhook or the Streaming API, as detailed in our [Notifications overview](/docs/notifications-overview). ### Configuring the Notification To receive this notification, create a webhook and configure the following: * **Target**: End of Day Processing * **On Event**: Accounts Updated For setup instructions, see [Defining a new Webhook](/docs/webhooks-defining-a-new-webhook) and [Streaming API](/docs/streaming-api). ### Delivery Conditions The EOD completion notification is sent once all accounts have been updated. This occurs regardless of whether the processing was entirely successful or if some failures were encountered. ### Template Parameters Whether you use a [Webhook](/docs/webhooks-defining-a-new-webhook) or the [Streaming API](/docs/streaming-api), your notification template can include several [placeholders](/docs/placeholders) to provide specific details: | Name | Description | | :--- | :--- | | **ENCODED_KEY** | The unique identifier for the EOD background process | | **END_DATE** | The date and time when the EOD process finished | | **START_DATE** | The date and time when the EOD process began | | **STATE** | The final state of the process: “COMPLETE“ or “FAILED“ | | **TOTAL_FAILED_ACCOUNTS** | Total number of accounts that failed processing. A value of “-1“ indicates a major failure | | **FAILED_DEPOSITS_ACCOUNTS** | Number of deposit accounts that failed processing. A value of “-1“ indicates a major failure | | **FAILED_DEPOSITS_ACCOUNT_KEYS** | A list of keys for failed deposit accounts. This list is capped at the first 20 failures | | **FAILED_LOANS_ACCOUNTS** | Number of loan accounts that failed processing. A value of “-1“ indicates a major failure | | **FAILED_LOANS_ACCOUNT_KEYS** | A list of keys for failed loan accounts. This list is capped at the first 20 failures | :::note * We recommend configuring EOD webhook notifications to improve process monitoring and ensuring all available placeholders are included in your templates. * The **Accounts Updated** event specifically signals that account states have been updated. It does not indicate the completion of all daily jobs, as some tasks unrelated to account states may still be running. To monitor the status of all daily jobs, use the Background Process endpoints. For more information, see [Get the ID of a currently-running job](#get-the-id-of-a-currently-running-job). ::: ## Manual end-of-day processing You may execute EOD processes manually instead of having them run automatically every night. Manual execution guarantees that Mambu will not run account appraisals every night. You may trigger manual EOD processing at any time. The EOD process will always run on the snapshot of the data that was taken at midnight (00:00) of the current date. In other words, the EOD process is always processing the data of the previous day. For example, if the EOD process starts on December 7th, at 23:00 then the snapshot that was taken on December 7th at 00:00 will be used. That snapshot will contain all the data of the previous day (December 6th), however it won't contain any of the data of the current day (December 7th). To run manual EOD processing from Mambu: 1. Make sure you have the **Manual EOD Processing** feature enabled - see [Mambu Release Cycle- How do we identify the stage of a feature?](/docs/mambu-release-cycle#how-do-we-identify-the-stage-of-a-feature) for instructions. If you need it enabled, please contact you Customer Success Manager. 2. On the main menu, go to **Administration** > **Financial Setup** > **EOD Processing**. 3. In the **End of Day Processing** dropdown, select **Manual**. 4. Select **Run Now**. ## Manual end of day processing via the API To run manual EOD processing using the API, please refer to the [Crons](/api/api-v2/crons_eod/crons-eod) documentation in our API v2 Reference. :::note Triggering the EOD processing manually will run both the hourly and daily jobs. If the daily jobs already ran for the day, then only the hourly jobs will run. Remember to run them before closing accounting books, to make sure that all the accounts are up-to-date. ::: ## Delaying EOD processing There is no mechanism to configure a delay for automatic EOD executions. Switch to Manual EOD execution can be used as a one-time alternative to prevent Automatic EOD executions. To do that: 1. Make sure you have the Manual EOD Processing feature enabled - see [Mambu Release Cycle- How do we identify the stage of a feature?](/docs/mambu-release-cycle#how-do-we-identify-the-stage-of-a-feature) for instructions. If you need it enabled, please contact your Customer Success Manager. 2. On the main menu, go to **Administration > Financial Setup > EOD Processing**. 3. In the **End of Day Processing** dropdown, select **Manual**. (do not click “Run Now”). :::note This step can be performed in advance on the same day after previous EOD has finished, before next EOD. ::: 4. Click **Save**. :::warning As long as End of Day Processing is set to Manual, Automatic EOD will not be executed. Once the required delay is elapsed, enable back Automatic EOD execution: ::: 1. From the main menu, go to **Administration > Financial Setup > EOD Processing**. 2. In the **End of Day Processing** dropdown, select **Automatic**. 3. Save changes. 4. EOD will run automatically in the next hour. ## Cancelling EOD processing Under certain unusual circumstances, you may wish to cancel a running EOD process. Specific cron jobs cannot be terminated, but if a group of EOD processing jobs is taking a long time to complete, they may sometimes be terminated via API. :::warning If you terminate EOD processing jobs, you are responsible for ensuring that the jobs are re-run. If you are using manual EOD processing, you must reinitiate the job. If you are using automatic EOD processing, the cancelled group of jobs will re-run automatically at the next scheduled time. ::: To cancel EOD processing, use the Background Process endpoints. For more information, see [Background Process](/api/api-v2/backgroundprocess/backgroundprocess) in our API Reference. To access the Background Process endpoints, your user or API consumer must have Admin access rights or the **Manage EOD Processing** (`MANAGE_EOD_PROCESSING`) permission. For more information, see [Creating a User - User Rights](/docs/creating-new-users#user-rights-section). ### EOD process cancellation requests Manually-triggered EOD processing jobs with the `MANUAL_CRON_JOBS_TRIGGER` type and automatically triggered EOD processing jobs with the `CRON_JOBS` type may be cancelled under either of the following conditions: * The state of the currently-running cron job is `QUEUED`; **or** * The state of the currently-running cron job is `IN_PROGRESS`, and its execution time has already taken longer than the longest of the last five EOD processing jobs of the same type that have been run. Cancelling EOD processing has two steps: getting the ID of a currently running job and sending the cancellation request. #### Get the ID of a currently-running job The first step is to retrieve the ID (encoded key) of the group of cron jobs by making a `GET` request to `/api/backgroundprocess/latest`, specifying the `type` query parameter as either `CRON_JOBS` or `MANUAL_CRON_JOBS_TRIGGER` depending on which EOD processing mechanism you have set up. The endpoint will return the last-started group of jobs of the specified type and indicate whether or not it is still executing. We recommend making two `GET` requests: one with `type=CRON_JOBS` and another with `type=MANUAL_CRON_JOBS_TRIGGER` to be certain you are getting any possibly-running job. If you request a background process with a type that has never been used in your instance, you will get an error informing you that there was `No background process found by specified type.` The following example shows a request for data on the currently running job with the `CRON_JOBS` type: ```json { "encodedKey": "402881647fb680c8017fb68c29f00470", "type": "CRON_JOBS", "state": "QUEUED", "creationDate": "2022-03-30T09:00:00Z" } ``` ```json { "encodedKey": "402881647fb680c8017fb68c29f00470", "type": "CRON_JOBS", "state": "CANCEL", "creationDate": "2022-03-23T11:31:53Z", "startDate": "2022-03-23T11:31:54Z", "endDate": "2022-03-23T11:31:58Z" } ``` This response indicates that the set of EOD Processing jobs has been stopped. Be sure to manually re-initiate the jobs if necessary. --- # Backwards Compatibility URL: https://docs.mambu.com/docs/backwards-compatibility/ This page gives the full list of backwards compatibility changes, as far back as 2018. For more information on our user agreements regarding backwards compatibility, refer to [Mambu Release Cycle - Breaking changes](/docs/mambu-release-cycle#breaking-changes). | Change | More information | Reference ID | Backwards compatible until | |---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|-----------------------------------------|------------------------------------------------------------------| | Swagger v2 support will be fully decommissioned. | Mambu is deprecating and removing Swagger v2 (OpenAPI v2) specification files and endpoints. These are currently used for API documentation rendering, SDK generation, and contract testing.

Customers must migrate to OpenAPI v3 endpoints within a 3-month grace period. | CON-1 | | | Mambu Payment Gateway (MPG) will be fully decommissioned. | Due to the acquisition of Numeral enabling us to offer advanced payment solutions, we will be discontinuing development and support of Mambu Payment Gateway

We will send out detailed communications to all customers who are currently using MPG with the timeline and suggestions for alternative solutions, to ensure that this does not affect your business operations. | | | | Mambu Process Orchestrator (MPO) will be fully decommissioned. | As part of our ongoing efforts to simplify and enhance our platform, we will be removing MPO completely.

We will send out detailed communications to all customers who are currently using MPO with the timeline and suggestions for alternative solutions, to ensure that this does not affect your business operations. | | | | Audit Trail has been upgraded to V2.

This upgrade introduces a new `/v2/` endpoint for Audit Trail, as well as a number of breaking changes and new features.

For more information on Audit Trail V2, refer to this page: [Audit Trail V2](/api/pages/audit-trail/welcome. | The breaking changes introduced in V2 comprise the following:

| | Refer to the breaking change communications we will send to you. | | Search has been enhanced across both the UI and Search API.

Consequently, your old search methods and queries may no longer work. | For more information on the new search capabilities, refer to [Mambu Search](/docs/mambu-search).

Certain searches in both the UI and Search API use prefixes instead of substrings, to take full advantage of new table indexes. The following entities were modified:

For instance, when attempting to retrieve a client using the UI or Search API, we search the text input across the following fields: client ID, first name, middle name, last name, and the IDs of the client's documents.

The `Type` field is now mandatory in search queries to specify the entity being searched. This change will also impact the `GET/search` endpoint.

Some queries have been modified to use case-sensitive searches. In these cases, the first character of the query is still case-insensitive. The following columns have been affected:

**ID****Name****First name and Last name****Username**| - | January 2025 | | Mambu is enhancing the interest rate change management capabilities in Deposits products while maintaining backwards compatible options for a definite period. | [Interest Rate Management Enhancements](/docs/interest-rate-management-enhancements) | - | Undetermined | | Mambu is extending the IP whitelisting feature to include capabilities beyond the cloud banking platform.

Consequently, whitelisted IP addresses will now apply universally to all Mambu capabilities with the exception of MPO. (e.g. Cloud banking platform, Audit Trail, Payments, Streaming API, etc). | [Access Preferences](/docs/access-preferences) | - | July 2024 | | Mambu is moving towards returning 409 response code instead of 102 response code, when there already is an in progress call with the same idempotency key. | [Idempotency](/api/pages/api-v2/responses) | - | June 2024 | | We are introducing limits to custom field definitions and custom field values.

This limitation only applies to the number of custom fields values linked to an entity (the actual value it holds. I.e. “Zimbabwe”), and not to the number of custom fields definitions (the custom field you create. I.e. “Country of Residence”). | [Custom Fields](/docs/custom-fields) | - | Q3 2024 | | We will be issuing the **Accounts Updated** event when all the accounts have been updated. Previously the **Account Updated** event coincided with the completion of the end-of-day job. This unnecessarily prolonged the notification due to the inclusion of jobs unrelated to updating the accounts status.

The completion of the daily job can be observed by querying the Background Process endpoints for the state of the `CRON_JOBS` job. | [End of day processing](/docs/automatic-end-of-day-actions) | EOD-90 | January 2024 | | We are removing the hold check when posting card transactions where the state of the referenced authorization hold is other than **Pending** (**Settled**, **Reversed**, or **Expired**).

Once posting a card transaction, the state of such a hold will not be changed and the transaction will be successfully posted. | Affected endpoint: [POST /cards/``/financialtransactions](/api/api-v2/cards/create-card-transaction/) | CARDS-1670 | July 2023 | | Whenever a credit transaction is reversed and funds are not available as part of the deposit account total balance, a reversal debit transaction will be executed using the technical overdraft of that account. | Affected endpoint: [POST /cards/``/financialtransactions/``:decrease](/api/api-v2/cards/decrease-authorization-hold) | CARDS-1768 | July 2023 | | For customers that have federated authentication enabled, branch assignment for users will no longer be performed using the Mambu UI or API v2, instead it must be performed from their identity provider (IdP). | [Managing Users under Federated Authentication - Branch assignment](/docs/managing-sso-provisioned-users#branch-assignment). | CIAM-2668 | November 2023 | | We made the product category field required for all loan and deposit products. To edit or create a loan or deposit product, you have to assign it a product category. We advise that you revisit your product configurations and assign the right product category where needed. | - | ADM-3031 | March 31, 2023 | | We enabled negative interest rates on deposits on all Mambu tenants. The feature also changes the way accounting entries are generated for interest accruals on Current Accounts. From now on, each interest accrual type will create separate journal entries instead of a net amount.

This only occurs within one period of overdraft interest, where positive interest has accrued. | - | DPS-49 DPS-53 | February 27, 2023 | | Upgrade to latest AWS Application Load Balancer (ALB) security policy requiring forward secrecy and strong protocols and ciphers. | We continuously improve our product as well as our product security. In order to provide a secure communication channel and keep high security standards, we are announcing the intention to make scheduled update of the AWS Application Load Balancer (ALB).

Since this update cannot be done while maintaining backwards compatibility, we would like to let you know that we intend to update the AWS Application Load Balancer for all Mambu Capabilities.

**What is the impact?**

We will switch all our load balancer security policies to the latest version of ALB; this includes the Mambu core, new capabilities, MPO and MyMambu.

This update might break existing customer integration and the usage of Mambu app with outdated browsers as *ELBSecurityPolicy-FS-1-2-Res-2019-08* is the most restrictive policy available till date. This policy supports TLS 1.2 only and includes only ECDHE (PFS) and SHA256 or stronger (384) ciphers. | IAM-356 | March 2021 | | Update on the data access model for GET/POST:search APIs | We want to ensure that the data visibility model provided by the branch assignment for each user works consistently across all interfaces.

This impacts all READ (GET or POST:Search) operations done via API, both 1.0 and 2.0, for the following entities:

To better understand the change, let’s take two examples, one of the current behavior and one of the new behavior:

**Current behavior:**

Given a non-admin user with Mambu and API access rights,
And the user is assigned to Branch A
When the user retrieves all deposit accounts against all Branches
Then all deposit accounts from all branches will be returned.

**New behavior:**

Given a non-admin user with Mambu and API access rights,
And the user is assigned to Branch A
When the user retrieves all deposit accounts against all Branches
Then only deposit accounts for Branch A will be returned.

Please see below the associated ticket numbers for each change:

**API 2.0**

NTF-142 - Releases all changes related to `GET /POST:Search` endpoints for Clients and Groups

CORE-2775 - Releases all changes related to `GET /POST:Search` endpoints for Loan Accounts

DEP-1639 - Releases all changes related to `GET /POST:Search` endpoints for Deposit Accounts

**API 1.0**

NTF-142 - Releases all changes related to `GET /POST:Search` endpoints for Clients and Groups

CORE-2785 - Releases all changes related to `GET /POST:Search` endpoints for Loan Accounts

DEP-1639 - Releases all changes related to `GET /POST:Search` endpoints for Deposit Accounts| NTF-133 | February 5, 2021 | | Change for Users with restricted branch access via API 2.0 across Mambu | Mambu has made a change to `API GET request: /api/loans/` when an ‘accountState’ filter is used (for example: `/api/loans?accountState=PENDING_APPROVAL` or `/api/loans?accountState=ACTIVE`). This API call is used to retrieve all loan accounts with the given state and currently returns accounts at all branches even for users who have restricted branch access.

Currently, when running a `GET` API call for any state of the loan account, we do not perform any branch validations. As an effect, regardless of a user's branch access, the `GET` API call for loan accounts of any state would return all matching accounts for all branches.

In order to correct this behaviour, we have introduced filtering of the results, according to the branches to which the user has access. Running a `GET` API call will now return loan accounts from only those branches that the user has access to.| CORE-1843 | September 24, 2020 | | Apply Read permission standards on API 1.0 `GET Branches` endpoints | With the introduction of [Granular Administrator Permissions Standards](/docs/permissions#granular-administration-permissions) and **granular permissions for Branches with Mambu V9.54**, you can now access and use `Branches` via Mambu UI and Mambu API 2.0, only if you have specific permissions to your user account or you have a user type Administrator.

As the design of API 1.0 does not support adding this new behavior on top, we would like to let you know that **we will be requesting _View_ permission in order to access the following endpoints starting with the week on November 12th 2020**: This gives you 3 months to prepare the transition to this new behavior and ensure none of your integration relies on access without standard permission authorisation to these endpoints.| ADM-2011 | November 12, 2020 | | Apply Read permission standards on API 1.0 `GET Centre` endpoints. | With the introduction of [Granular Administrator Permissions Standards](/docs/permissions#granular-administration-permissions) and **granular permissions for Centres with Mambu V9.54**, you can now access and use `Centres` via Mambu UI and Mambu API 2.0, only if you have specific permissions to your user account or you have a user type Administrator.

As the design of API 1.0 does not support adding this new behavior on top, we would like to let you know that **we will be requesting _View_ permission in order to access the following endpoints starting with the week on November 12th 2020**: This gives you 3 months to prepare the transition to this new behavior and ensure none of your integration relies on access without standard permission authorization to these endpoints.| ADM-2083 | November 12, 2020 | | Replacing Default Sort Criterion `lastModifiedDate` with `creationDate` for Paginated Lists via API 2.0 across Mambu. | When retrieving paginated lists of clients, deposit or loan accounts via API 2.0, Mambu might return the pages with missing and duplicate entries. By default the retrieved lists are currently sorted by “lastModifiedDate”, which is a mutable field. Between two API calls (to retrieve different pages of the same list), some accounts or clients could be modified and therefore they would change order in the retrieved pages. In certain integrations relying solely on an entity's position in the list, this could lead to missing entries and duplicates.

To create predictable and consistent lists, we redesigned our API 2.0 GET endpoints to sort retrieved lists across Mambu by `creationDate` — an immutable field. This change affected the following endpoints:

| DEP-1580; CORE-2721; CUS-2438; CUS-2445 | September 30, 2020 | | Apply Read permission standards on API 1.0 `GET Transaction Channels` endpoint. |With the introduction of [Granular Administrator Permissions Standards](/docs/permissions#granular-administration-permissions) via V9.48 and V9.49, you can now only access and use transaction channels via Mambu UI and Mambu API 2.0, only if you have specific permissions to your user account or you have a user type Administrator.

As the design of API 1.0 does not support adding this new behavior on top, we would like to let you know that we are requesting View permission in order to access the following endpoints starting with the release of [Mambu V9.63](https://community.mambu.com/t/mambu-release-notes-v9-63-0/2171) from September 19th, 2020.| ADM-1958 | September 18, 2020 | | Apply Read permission standards on API 1.0 `GET Roles` endpoint. | With the introduction of [Granular Administrator Permissions Standards](/docs/permissions#granular-administration-permissions) via V9.48 and V9.49, you can now only access and use roles via Mambu UI and Mambu API 2.0, only if you have specific permissions to your user account or you have a user type Administrator.

As the design of API 1.0 does not support adding this new behavior on top, we would like to let you know that we are requesting _View_ permission in order to access the following endpoints starting with the release of [Mambu V9.63](https://community.mambu.com/t/mambu-release-notes-v9-63-0/2171) from September 19th, 2020: | IAM-815 | September 18, 2020 | | Enforce task visibility based on branch access. | We have updated our visibility policy for tasks in Mambu. More specifically, we have restricted users to view only tasks that are associated with a branch that they have access to.

The task view rights update comes in to help ensure data privacy and that users will be able to see only data from the branches that they are assigned to. For example, right now a user could view a task unrelated to their clients that might contain sensitive information.

If you want to learn more on tasks and visibility rights, please refer to our [updated support page](/docs/tasks#finding-and-completing-tasks).| TCS-1779 | May 20, 2020 | | Enforce "View User Details" permission for APIs. |The original design of the APIs assumed that an API user should have access to user information by default. We have since added the “View user details” permission to restrict view rights in the user interface, and now we are extending this to cover the APIs as well.

We will update both versions of our APIs to enforce the “View user details” permission, bringing them in line with the behavior of the UI. This means that in order to read user data (except the password) via API, you must have a user that is configured as follows:

Any user without these permissions will no longer be able to read user data via our APIs.| IAA-227 | March 20, 2020 | | Mambu-SSO Role Mapping on user provisioning. | Starting with September 2019, given your organization is using Federated Authentication, you can only manage Roles assignments to users directly from the SSO.

If you had any access issues with Mambu-SSO Role Mapping, please post your question in the [Mambu Community](https://community.mambu.com/) to get an answer from our Product team or contact tech support.

Read more in our [Mambu-SSO Role Mapping on User Provisioning.](/docs/managing-sso-provisioned-users) support article.

| IAA-24 | August 31, 2019 | | Mambu Platform TLS 1.0 and 1.1 restriction | Due to several weaknesses found in TLS 1.0 and 1.1, many websites and internet services are starting to require the use of TLS 1.2. Here at Mambu we take security very seriously and as such we will update the Mambu platform to make use only of TLS 1.2 going forward.

Mambu will first restrict TLS 1.0 and 1.1 on all Sandbox environments, then, after 6 weeks, the restriction will be enforced on all Production environments.

**This requires your action, otherwise, you won't be able to connect to Mambu and you are at risk for integrations failures.**


*An email with the exact date when TLS 1.0 and 1.1 will be restricted will be sent to Mambu Champions.* | APP-712 | April 8, 2019 | | Android App TLS 1.0 and 1.1 restriction. | TLS 1.0 and 1.1 restriction for the platform is also applicable for Mambu's Android App.

The update will have no impact on Android devices running an OS version 5.0 and above. For devices running the OS version 4.4 may encounter issues, as not all devices with with version have a native support for TLS 1.2. Lower versions of Android OS are not supported by the Mambu Android application.

To combat possible issues with Android devices running on OS version 4.4 we strongly recommend that you update your [Google Play Services](https://play.google.com/store/apps/details?id=com.google.android.gms) to the latest version and check the compatibility with your device manufacturer.

| MOB-401 | April 8, 2019 | | Custom Field Set ID Update. | API 2.0 brings a new structure for exposing custom field data as being native to the resource. Due to this, we have both custom field sets and Mambu native fields on the same level of the JSON structure. As to avoid any unpleasant events where a native field would have the same value as a custom field set, we will automatically append a prefix to any custom field set that you create.

This will be visible in the custom field set ID when transmitted via APIs 2.0.

Please see the below example:



| API-1721 | December 2018 | --- # Basic Jasper report for Journal Entries URL: https://docs.mambu.com/docs/basic-jasper-report-for-journal-entries/ ## Business case Export Journal Entries from Mambu. ## Technical concepts Usage of pagination, default and dynamic values for report parameters. ## Sources * [`jrxml` template report ](@site/static/files/JournalEntries.jrxml) ## Preview ![Result of a Jasper report of Journal Entries](@site/static/img/support/Screen%20Shot%202020-10-16%20at%204.00.32%20PM.png) *** --- # Blocking Funds in Deposit Accounts URL: https://docs.mambu.com/docs/blocking-funds-in-deposit-accounts/ Blocking funds in an account essentially means you prevent clients from withdrawing or transferring a specified amount. Clients can still withdraw any remaining funds and receive deposits including their paycheck, but the freeze stops withdrawals or transfers over a certain amount from going through. Therefore, a set amount deposited stays in the account and later gets transferred to the creditor. :::warning When you block and seize funds in deposit accounts, the available balance becomes the total balance minus the blocked amount. However, interest is accrued based on the total balance, not on the available balance. ::: ## Reasons why financial institutions block funds There are several reasons why financial institutions might need to block clients' funds: * Creditors seek judgment against bank clients. * Unpaid taxes, child support, student loans or fines. * Account holder passes away, so the funds are blocked while assessing who the recepient is. * Transaction disputes. * Payments and clearance. ## Blocking funds To use this feature, you must have administrator rights or the **Block and Seize Funds** (`BLOCK_AND_SEIZE_FUNDS`) permission. The feature is available via Mambu API v2. You can block any amount, even larger than the available balance on the account. The blocked amount reduces the available balance, therefore the client can only withdraw or transfer the remaining amount. To block a certain amount of money on a client's account, you must make a block request by making a `POST` request to the [`/deposits//blocks`](/api/api-v2/deposits/create-block-fund/) endpoint. Each block request in Mambu has a reference number and impacts the account’s available balance. Once a Block Funds request is created, it has **Pending** status until it is settled or unblocked. :::warning You can block funds in accounts that are in the `Active`, `Active in Arrears`, `Locked` or `Dormant` states. The account continues to accrue interest as long as the blocked amount is in the `Pending` state. ::: ## Retrieving blocked funds To view how much money is blocked in a deposit account, make a `GET` request to the [`/deposits//blocks`](/api/api-v2/deposits/get-all-blocks/) endpoint. This `GET` request retrieves the sum of all blocked amounts against the specified deposit account. ## Seizing funds To seize a blocked amount, make a `POST` request to the [`/deposits//seizure-transactions`](/api/api-v2/deposits_transactions/make-seizure) endpoint. To view the seized transaction on the UI: 1. Open the deposit account. 2. Click the **Transactions** tab. 3. Find the **Seized Amount** type transaction that you want to view and, on the right hand side of the screen, click on **Actions** > **View**. 4. In the **Deposit Account Transaction** window, view details about the seized amount and the total balance. ![View the seized transaction on the UI](@site/static/img/support/View-seized-amount.png) ## Partial seizure When authorities are seizing large amounts to collect outstanding debt, you can control the amount you block each month to make sure you provide account holders subsistence income that is transferred to a so-called "Protection Account". To support this use-case, we enabled three behaviours in Mambu: 1. Blocking amounts larger than the available balance on the account. 2. Transferring partial amounts to separate deposit accounts (managed with permissions). 3. Partial seizures to collect funds as they enter the account and collect outstanding debt over time. ## Unblocking funds In case you made a mistake or the creditor informed you that the debt was recovered, you can unblock a previously blocked amount by making a DELETE request to the [`/deposits//blocks/`](/api/api-v2/deposits/unblock-fund/) endpoint. :::warning You can only unblock funds that are in `Pending` state and in accounts that are in `Active`, `Active in arrears`, `Locked` or `Dormant` states. ::: --- # Blocking SEPA Direct Debits URL: https://docs.mambu.com/docs/blocking-sepa-direct-debits/ ## Example Use Case A client discovers a charge on their account that they do not recognise, the payment is identified as a recurring SEPA Direct Debit and the client wants to ensure that they will not be charged again while they contact the creditor to investigate further. ## Prerequisites - The specific deposit account must exist in the system. ## Steps 1. Identify the Creditor Mandate ID from a previous direct debit payment initiated by this creditor. This can either be by using our [API](https://api.mambu.com/payments-api/#search-messages-findsepamessages) or the Mambu Payment Gateway (MPG) UI. 2. Use our API to create a [blocking rule](https://api.mambu.com/payments-api/#tocscreateblockingrule) for the client's account blocking any further SEPA Direct Debit collection requests using the identified Mandate ID. `POST /api/v1/accounts//blocking-rules` ```json { "creditorMandate": { "creditorSchemeIdentification": { "identification": { "iban": "DE13439339003030393", } }, "mandateRelatedInformation": { "mandateIdentification": "ABC123" } }, "product": "SEPA_DIRECT_DEBIT" } ``` 3. If another PACS.003 collection request is received for this account for the blocked Mandate, the MPG will immediately generate a PACS.002 MS02 response message indicating that the debtor has prohibited transactions initiated by this creditor. Payments for other SEPA DD Mandates, which can also include other payments for the same merchant, will not be affected. ![SEPA Direct Debit Rejection Flow](@site/static/img/support/SEPA_direct_debit_rejection_flow.png) :::note It is also possible to block all SEPA Direct Debit mandates for a client by sending a request to the Blocking Rules API without providing a specific Creditor Mandate (see example below), in this case, all payment collection requests for this client’s account will be rejected. `POST /api/v1/accounts//blocking-rules` ```json { "product": "SEPA_DIRECT_DEBIT" } ``` ::: --- # Booking Date vs Value Date URL: https://docs.mambu.com/docs/booking-date-vs-value-date/ Mambu allows you to select a journal entry booking date different from the value date of transactions. ## Available transaction dates * **Creation Date**: The timestamp for when the transaction is created in the system. * **Value Date**: The date based on which assets either become available to the account owner (in the case of a credit entry), or cease to be available to the account owner (in the case of a debit entry). Interest, penalty, and arrears calculations are also based on this date. In Mambu, this is refered to as the account Transaction Date. * **Booking Date**: The date and time when an entry is posted to an account on the account servicer's accounting books. In Mambu, this is referred to as the journal entry date. ### Examples You may need to select a different booking date for journal entries in some instances: 1. When there is a correction that must be made on a past transaction and there is an accounting closure. In this situation, the correction should allow the value date to be in the closed period, whereas the booking date of the journal entry may be after the closed period. 2. When there is a check sent based on the date on which you want to submit the transaction (Value Date) vs. the date when the check is received in your bank account (Booking Date). ## Permissions In order to specify a different booking date for loan or deposit transactions, you will need the following Accounting permissions: * **Booking Date Loans Journal Entry** (`BOOKING_DATE_LOANS_GL`) * **Booking Date Deposits Journal Entry** (`BOOKING_DATE_SAVINGS_GL`) ## Booking Date input for manual journal entries When entering manual journal entries, you may select the **Booking Date (Entry Date)** of the entry. ![New Journal Entry screen with Booking Date (Entry Date) field filled in](@site/static/img/support/accounting--new-journal-entry.png) :::note The entry date of transactions registered on an account and the corresponding journal entries are identical, unless a different booking date is specified upon the transaction creation. ::: In the **Journal Entries** view, you can always see both the **Booking Date (Entry Date)** and the **Value Date (Entry Date)(Transaction)** of any given journal entry. ![Transactions table showing the booking date and the value date](@site/static/img/support/accounting--journal-entries-transaction-table.png) *** ## Booking date input for transactions With the permissions mentioned above, you can specify a different booking date when creating transactions. The field is made available in the user interface, as it can be seen in the below examples, and can also be used via the APIs. ![Apply a Repayment screen with Value Date and Booking Date fields](@site/static/img/support/accounting--apply-a-repayment.png) Booking date input is available for adjustment transactions as well: ![Adjust Repayment screen with Adjustment booking date dropdown](@site/static/img/support/accounting--adjust-repayment.png) ## Transaction Types Only the following transaction types allow a booking date input: ### Loans: * Disbursement * Fees * Repayment * Adjustment Made ( the adjustment transaction for Repayment) * Payment Made * Payment Made Adjustment ( the adjustment transaction for Payment Made) ### Deposits: * Withdrawal * Withdrawal Adjustment * Deposit * Deposit Adjustment ## Booking date impact on triggered transactions Some transactions trigger subsequent transactions in the same account or in other accounts. In these scenarios, Mambu will carry over the booking date of the original transaction that triggered the others. ### Example: Funding Accounts repayments Assuming a borrower makes a repayment, and the repayment has following dates: | Date Type | Date | | --- | --- | |Creation Date|`08-04-2018`| |Value Date|`08-01-2018`| |Booking Date|`08-03-2018`| The triggered Loan Repaid transaction on the funder accounts will carry the booking date values, as follows: | Date Type | Date | | --- | --- | |Creation Date|`08-04-2018`| |Value Date|`08-03-2018`| |Booking Date|`08-03-2018`| The same is applicable for any other similar scenarios, such as disbursements that have triggered fees. When the disbursement has a booking date that differs from the value date, any fee that is triggered by the disbursement (for example a Disbursement Fee) will carry the booking date input for the disbursement. ## Booking date impact on re-applied transactions via backdating or bulk adjustment When you backdate transactions, you must first adjust all the transactions that exist after the backdating date. New transactions are posted for the adjusted transactions, and custom field values are copied over from the original transaction to the new transaction. If you need to both backdate and input a different booking date for the backdated or adjusted transaction, the booking date of the re-applied transactions will have the same value as the the booking date of the original transaction. ## Booking date input under accounting closure Mambu allows introducing backdated transactions on an account after an existing accounting closure. The booking date of the backdated transaction must be after the accounting closure date. There are also use cases when an adjustment (reversal) has to be made on an account before an existing accounting closure date. For such scenarios, Mambu allows you to perform the adjustment and choose a different booking date for the adjusted transaction. ![Adjust deposit window with original date and Backdate options displayed](@site/static/img/support/accounting--adjust-deposit.png) You can choose a different booking date for adjusted transactions only if you have the **Rectify adjustment after Accounting Closure** (`RECTIFY_ADJUSTMENT`) permission. :::note When there is a different booking date selected for an adjusted transaction, the original value date is kept. ::: ### Example Let's consider there is an accounting closure for `30 Jun 2018`, for a loan account with several repayments where the last repayment is on `28 Jun 2018`. * On `1 Jul 2018`, you adjust a repayment made on `25 May 2018` and input `1 Jul 2018` for the booking date of the adjustment transaction. * Then the adjustment is permitted and the journal entry booking date for the adjustment transaction is `1 Jul 2018` and the value date of the adjusted transaction is `25 May 2018`. --- # Branches and Centres URL: https://docs.mambu.com/docs/branches-and-centres/ A *branch* in Mambu is the default label for an organization's subdivision. Often branches represent: * A geographical subdivision of an organization. * A product line. * Any other entity that represents a subdivision of an organization. A *centre* is the default label for a subdivision of a branch. It can be considered a sub-branch. Each branch can have multiple centres assigned to it. The terminology *branch* and *centre* are the default labels used for these concepts. For more information about changing these labels, see [Labels](/docs/labels). Clients and groups can be assigned to branches and centres. Mambu users can be assigned to branches but they cannot be assigned to centres. ## Branches The main reasons to use branches are: * **Reporting and client assignment**: branches allow you to assign clients to a branch. And you can also collect branch-specific reporting for example to view how many clients are assigned to a specific branch. For more information about assigning clients to branches, see [Create an individual client](/docs/create-an-individual-client). * **Limiting user access per branch**: you can decide which users have access to information under certain branches. For more information, see [Creating a User - Access Rights](/docs/creating-new-users#access-rights). * **Limiting products offered per branch**: you can decide which loan products or deposit products are available in which branches. For more information about limiting loan products, see [Setting Up New Loan Products - Product availability](/docs/setting-up-new-loan-products#product-availability). For more information about limiting deposit products, see [Setting Up New Deposit Products - Product availability](/docs/setting-up-new-deposit-products#product-availability). * **Branch-specific accounting**: you can create balance sheets or profit and loss statement for individual branches. For more information, see [Branch-level accounting reports](/docs/accounting-reports#branch-level-accounting-reports). ## Creating a branch To create a new branch: 1. Go to **Administration** > **Organization** > **Branches**. 2. Select **New Branch**. 3. In the **Creating A New Branch** dialog, enter all the necessary information. See below for more information on the fields. 4. Select **Create Branch**. :::note Branches cannot be deleted, they can only be deactivated. ::: ![Creating a new branch dialog with all form fields](@site/static/img/support/managing-your-organization--creating-a-new-branch.png) ## Fields for branches Fields with a green outline are required fields. Fields with a grey outline are not required. ### General General fields for branches include: * Branch Name (required) * ID (required) * Address (optional) ### Contact Contact fields include: * *Phone Number * Email Address ### Notes You may enter free text notes if desired. ## Editing a branch To make any changes in your organization's branches: 1. Go to **Administration** > **Organization** > **Branches**. 2. In the list of branches, find the branch you would like to edit and select **Actions** > **Edit** . 3. In the **Editing Branches** dialog, make your changes. 4. Select **Save Changes**. ## Deactivating a branch You can deactivate a branch even if active accounts are still associated with it. Deactivating or reactivating a branch can be performed only by users with **Edit Branch** permissions. Deactivated branches can be visually identified by a **deactivated** marker after the name of the branch across Mambu and this means you can still search or pull reports for the deactivated object. :::note A branch cannot be deactivated if it has active **centres**. ::: To deactivate a branch: 1. Go to **Administration** > **Organization** > **Branches**. 2. In the list of branches, find the branch you would like to deactivate and select **Actions** > **Deactivate**. 3. Select **Deactivate**. If you have deactivated branches, you can view them by selecting the **Show deactivated Branches** check box. ![Branches view, where all branches activated and deactivated are displayed.](@site/static/img/support/managing-your-organization--branches-list.png) ## Setting holidays for a branch Branch-specific holidays allow granular holiday management, these work in conjunction with general holidays with loan schedules of clients belonging to each branch. To set up branch-specific holidays: 1. Go to **Administration** > **Organization** > **Branches**. 2. In the list of branches, find the branch you would like to set a holiday for. 3. Select **Actions** > **Set Holidays**. 4. Select **Add Holiday**. 5. In the **Add A Holiday** dialog enter all the required information. 6. Select **Apply Changes**. ## Managing multiple branches If your organization is configured with more than one branch and you have the necessary user permissions, you can easily keep track of everything that happens in each branch, assign staff and clients to different branches, and limit user access to a single branch. ### Branch selector You may easily configure which branch's data are displayed in Mambu using the branches selector in the top toolbar: ![All Branches dropdown](@site/static/img/support/managing-your-organization--branch-selector-navigation.png) **All Branches** is selected by default. If you select a specific branch in the dropdown box, the following changes will occur: * The **Dashboard** will show the activities and indicators for the selected branch only. * When you navigate to the relevant pages, you will see only the clients, groups, savings, loans, and transactions for the specified branch. * The **Search Box** will only return requested values for the specified branch. * **Reporting pages** will only report data associated with the specified branch. :::warning You may only select branches in the dropdown box that you have permission to access. ::: ## Centres A **centre** is a subdivision of a branch. Each branch can have multiple centres. Centres are not widely-used, but can be helpful, depending on your needs. Clients may be assigned to a centre, which can be useful if you wish to collect centre-specific reporting. For more information about assigning clients to branches, see [Create an individual client](/docs/create-an-individual-client). ## Creating a centre To create a new centre: 1. Go to **Administration** > **Organization** > **Centres**. 2. Select **New Centre**. 3. In the **Creating a New Centre** dialog, enter all the required information. 4. Select **Create Centre**. ## Deactivating a centre You can deactivate a centre even if active accounts are still associated with it. Deactivating or reactivating a centre can be performed only by users with **Edit Centre** permissions. Deactivated centres can be visually identified by a "deactivated" marker after the name of the centre across Mambu and this means you can still search or pull reports for the deactivated object. To deactivate a centre: 1. Go to **Administration** > **Organization** > **Centres**. 2. In the list of centres, find the centre you would like to deactivate and select **Actions** > **Deactivate**. 3. Select **Deactivate**. If you have deactivated centres, you can view them by selecting the **Show deactivated centres** check box. ## Weekly Meeting Day If your credit officers visit the clients on a specific day weekly to collect repayments, defining the Weekly Meeting Day will ensure that when creating new accounts for those clients, Mambu will automatically reschedule the first repayment to the next possible day. :::warning If you are using a monthly schedule with all repayments falling on the same day of the week you can change the product's settings to a repayment frequency of 4 weeks to reflect that. ::: ## Viewing organizational structure To see the list of all of your organization's branches, centers, and users: 1. Go to **Administration** > **Organization** > **Branches**. 2. From the list of branches, select the branch you want to view. 3. Here you will be able to see general information, comments and a list of activities associated to the branch. --- # Branding URL: https://docs.mambu.com/docs/branding/ ## How to set the organization logo and icon Mambu's logo and icon can be replaced with your own. ![Branding screen from where the Organization Logo and Icon can be changed](@site/static/img/support/managing-your-organization--organization-branding.png) To update the icon and logo: 1. Go to **Administration** > **General Setup** > **Branding**. 2. Select the **Set Icon** or **Set Logo** button and upload your icon or logo file. - The icon will replace Mambu's icon on the top left-hand corner of the screen. For best results please use a 16*16 pixel .png file, or a bigger, square file, which would be re-sized by Mambu. - The logo will replace Mambu's logo in the login and unlock screens. For best results it is advisable that the image is a 300*50 pixel .png image with a transparent background. --- # Call an external service when the database changes to Read-Only mode URL: https://docs.mambu.com/docs/call-an-external-service-when-the-database-changes-to-read-only-mode/ ## Business case A 3rd party system is used to add and modify data in real time using Mambu's REST APIs. In certain cases, such as during regular scheduled maintenance or for updates, the database may be switched to read only mode. In a '_fire and forget_' style implementation this could cause data to be lost as the sending system will have no persistent records. Using a webhook that is triggered when the database access state changes, you could queue calls or pause this system until write access has been reenabled. ## Configuration ![webhook_showcase_example_data_access](@site/static/img/support/webhook_showcase_example_data_access.png) ***
Ask the Mambu Community

If you have a question about how anything works or have come across something you haven't seen explained here, get in touch with our community of fellow users and Mambuvians where someone will lend a hand.

Ask a question about Notifications in Mambu

* If you don't already have an account you will be prompted to create one when you first visit the site.

--- # Card Transactions and Authorization Holds URL: https://docs.mambu.com/docs/card-payments-and-authorization-holds/ Most bank clients today expect to be able to function in a fully cashless way, using debit and credit cards to make and receive payments as well as make direct withdrawals from debit accounts and cash advances against credit. Mambu fully supports industry standard [authorization hold](https://en.wikipedia.org/wiki/Authorization_hold) flows for card payments and allows you to request, adjust, reverse and settle holds against Current Account and Revolving Credit type products. :::note All capabilities for configuring the flow between Mambu and your card acquirer are available [via API only](/api/api-v2/cards/cards). ::: :::warning Card authorization holds are separate from **transaction holds**, which may be applied to any deposit transaction. For more information, see [Transaction Holds](/docs/transaction-holds). ::: ## Requirements * You will need to have the **Cards** functionality enabled for your instance. * A card token reference must be associated with the account. :::note A *card token reference* is used to identify a credit or debit card without needing to always provide sensitive information such as the card number and, as such, is a shared reference between your Mambu tenant and your card issuer’s system.

For more on how to link a debit card using a card token reference, go to the [create card](/api/api-v2/deposits/create-card/ ::: endpoint for Deposit Accounts. For linking a credit card, find out more at the [create card](/api/api-v2/loans/create-card) endpoint for Loan Accounts.) ## Authorization In the card payments ecosystem, an *authorization* - also known as a card authorization, pre-authorization or hold processing - is initiated when a card holder makes a purchase. The process involves: - Confirming that the debit or credit card is valid. - Confirming that the business rules are met. - Confirming that the available balance on the cardholder's account is sufficient. - Placing a temporary hold on funds in the account The temporary hold ends when the merchant completes the transaction (clearing and settlement) or cancels it (reversal). The process starts with the merchant when the card holder makes the purchase, then the card acquirer processes the payment on behalf of the merchant and interacts with Mambu to do so. The interaction between the card acquirer and Mambu happens through messages to transfer information about the transaction. There are two types of messages: - **Single-message transactions** include all the information required to complete the transaction in one message. - **Dual-message transactions** split the information: the initial message at the time of purchase will contain the information required to make an authorization decision and a second message is sent later with details to clear and settle the transaction. ### Example: Authorization holds A common example is an authorization hold for a card transaction, when renting a car or hotel room. This is lifted if no incidental charges are incurred during the rental period. Industry best-practice recommends that authorization holds automatically expire if no action is taken after no more than seven days for debit card transactions and no more than 30 days for credit card transactions. See below for how to configure this for your Mambu instance. ## Configuring authorization holds settings :::warning We strongly recommend that you use an end-to-end test to test any configuration changes in your sandbox environment before implementing them in your production environment. The end-to-end test should check that the hourly `AUTHORIZATION_HOLDS_EXPIRATION` cron job expires the correct authorization holds. For more information, see [Hourly authorization holds cron job](#hourly-authorization-holds-cron-job) below. If, to perform your end-to-end test you have to set holds in the past, then please contact us through [Mambu Support](/docs/mambu-support) so that we can assist you with manipulating the data directly in the database. ::: The authorization holds configuration determines the expiration period for authorization holds in days. The default value is seven days however you may edit this value. You may also specify different expiry periods for specific merchant category codes (MCC). You may configure authorization holds settings either through the Mambu UI (see below) or via the API. For more information, see [Authorization Holds Configuration](/docs/configuration-as-code-for-authorization-holds). To change the default expiration period for authorization holds: 1. On the main menu, go to **Administration** > **Financial Setup** > **Authorization Holds**. 2. Next to **Default period before expiration**, enter the number of days after which you want the authorization holds to expire. The value must be between 1 and 36,525 days. 3. Select **Save**. ![Setting-an-expiration-date-for-authorization-holds](@site/static/img/support/authorization-holds-add-catogory-code.png) To add an expiration period for an MCC: 1. On the main menu, go to **Administration** > **Financial Setup** > **Authorization Holds**. 2. Select **Add**. 3. Enter a value for the **Merchant Category Code**. 4. Enter a value for the **Days to Expiration**. The value must be between 1 and 36,525 days. 5. Select **Save**. ### Hourly authorization holds cron job There is an hourly cron job called `AUTHORIZATION_HOLDS_EXPIRATION` which runs automatically and expires any authorization hold requests on which a settlement action has not been taken before the expiration period has elapsed. For example, if 14 days is the expiration period set for authorization holds, then any authorization holds created or updated 14 days ago are candidates to expire. When an authorization hold expires, its status changes from `PENDING` to `EXPIRED` and the hold amount no longer affects a client's available balance. For more information about cron jobs at Mambu, see [Automatic End of Day Actions](/docs/automatic-end-of-day-actions) and [Hourly jobs](/docs/automatic-end-of-day-actions#hourly-jobs). If you change your authorization holds configuration, the new configuration will be considered by the following `AUTHORIZATION_HOLDS_EXPIRATION` cron job run. :::warning Holds made directly on deposit accounts via account ID do not expire. For more information, see [Transaction Holds](/docs/transaction-holds). ::: ## Card transaction message types The table below describes the different types of messages that pass between the card issuer and Mambu depending on the type of authorization initiated. Each message type and how it is managed in Mambu is explained further in the text below the table. | Card message Type | Description | Debit Cards Availability | Credit Cards Availability | | --- | --- | --- | --- | | [Authorization Hold Requests](#authorization-hold-requests) | A request to authorize a transaction and hold money on the cardholder's account in a dual-message system, after verifying if the client has enough available balance. | ✔ | ✔ | | [Authorization Advice](#authorization-advice-financial-transaction-advice-and-reversal-advice) | This is a request containing details of an already confirmed transaction that results in holding money on the cardholder's account in a dual-message system, without verifying if the client has enough balance. | ✔ | ✘ | | Balance Inquiry | A request to obtain a cardholder's account balances. | ✔ | ✔ | | [Financial Transaction Requests](#financial-transaction-requests) | A single-message request to authorize a transaction with a given amount and immediately debit (clear) the cardholder’s account with a single request if it has sufficient available balance, is active, and is not currently blocked. | ✔ | ✔ | | [Financial Transaction Advice](#authorization-advice-financial-transaction-advice-and-reversal-advice) | A single-message request containing details of an already confirmed transaction that results in immediate debit (clearing) of the cardholder’s account, without verifying if the client has enough balance. | ✔ | ✔ | | [Reversal Request](#reversal-request) | Request to authorize a full or partial cancellation of an existing transaction, with account balance verification. | ✔ | ✔ | | [Reversal Advice](#authorization-advice-financial-transaction-advice-and-reversal-advice) | Request to authorize a full or partial cancellation of an existing transaction, without verifying the account balance. | | [Refunds Authorization](#refunds-authorization) | Request to authorize a refund (credit) transaction. | ✔ | ✘ | ## Authorization hold requests Authorization requests can only be performed via [API v2](/api/api-v2/cards/cards). Each authorization hold request in Mambu will have a reference number and will impact the account’s Available Balance. See [Impact on Account Balance](#impact-on-account-balance) for more info. Once an authorization hold is created, it has the `PENDING` status until it is settled, reversed, or expired. ### Retrieving authorization holds API requests can be used to retrieve either an array of [all authorization holds](/api/api-v2/deposits/get-all-authorization-holds/) for a given deposit account or [details on a specific hold](/api/api-v2/cards/get-authorization-hold-by-id) on a given card by its ID. Authorization holds will have one of four statuses: `PENDING`, `REVERSED`, `SETTLED` or `EXPIRED`. ### Impact on account balance When Authorization Requests are made and before they are settled (or not), the amounts under hold are accumulated under a Holds Balance. This balance is also used for [calculating the Available Balance](/docs/deposit-account-overview-details). #### Hold balance vs. Locked and Blocked balance Currently Mambu offers the option of locking a balance on a deposit account, when that balance is used as a guarantee for loans. This locked amount is no longer available for withdrawal. Similarly, you can create so called "Blocked Funds" that create a Blocked balance that can be seized by authorities. In such situations Mambu will not allow for a hold to be made over an already locked amount. **Example: Authorization request flow** For a deposit account with the following balances: * Booked balance or totalBalance of USD1,000.00 * Overdraft limit of USD1,500.00 * Locked balance of USD200.00 * Blocked balance of USD300.00 * Holds balance of USD100.00 The available balance is USD400.00. Read more on the computational formula [here](/docs/deposit-account-overview-details). :::note The overdraft limit is not taken into consideration when there is a positive locked balance. The account acts as if the overdraft has been disabled. ::: When performing an authorization request, if the requested hold amount plus the existing hold balance exceeds the account's available balance, then the authorization request is not permitted and the holds balance is not updated. | Hold Amount Request | Authorization Request Response | Holds Balance | Available Balance | Notes | | --- | --- | --- | --- | --- | | USD100.00 | success | USD200.00 | USD300.00 | The overdraft limit is not taken into consideration when there is a positive locked balance. | | USD400.00 | success | USD500.00 | USD0.00 | | | USD401.00 | fail | USD100.00 | USD400.00 | Despite the overdraft limit, the hold cannot be accepted as the booked balance may become lower than locked balance. So the locked balance is no longer covered and guarantees cannot be covered by an overdraft. | :::note As a loan can not be used as a guarantee for another loan, when an account has a Locked Balance, it acts as if the overdraft facility has been disabled. This means that the overdraft limit is no longer taken into account for the calculation of the Available Balance. ::: ### Incremental authorization holds Authorization holds with a `PENDING` status can be [increased](/api/api-v2/cards/increase-authorization-hold) or [decreased](/api/api-v2/cards/decrease-authorization-hold) by making an API request and supplying the Card Token Reference and Authorization Hold Request ID along with the amount with which to increase or decrease the held amount. A decrease of the same or more than the full amount of the hold will effectively reverse the hold. ### Clearing and settling authorization holds In dual-message networks, a clearing message from card acquirer updates authorization hold status and creates a financial transaction thereafter. In Mambu this request can be posted through [createCardTransaction endpoint](/api/api-v2/cards/create-card-transaction/) as financial advice and it always acts as a final clearing. Usually this message contains the request to debit or credit the full amount of a previously requested authorization hold from a cardholder’s account. However, It is possible that the final clearing amount will be different from the amount under the hold. In single-message networks, a transaction comes without prior authorization hold having been made at all. Debits will be recorded with the transaction domain code `Payments`, family code `Merchant Card Transactions` and sub-family code `Credit Card Payment`. Once the transaction has been completed, the authorization hold will be updated to include the transaction ID and have its status change to `SETTLED` for Final Clearing. If your card processing network also requires Partial clearings of the authorization holds, we recommend contacting Mambu Support to further discuss this use case. ## Authorization advice, Financial transaction advice, and Reversal advice In certain situations, transactions may be processed without being able to communicate with a card issuer’s system at that moment. For example, a system with no internet connectivity, such as an airplane in flight or when transactions are processed in a batch at the end of a business day. Such transactions are commonly known as _Offline Transactions_. These transactions are made using the same API request as a standard authorization hold, but with the **Advice** flag set to `"TRUE"`. This will cause the authorization to be made without validating the available balance and as a result can allow a cardholder to make a transaction for an amount over any defined limits, as well as allow for usage without the normal balance checks - causing an account to go into [Technical Overdraft](/docs/technical-overdraft/). ## Financial transaction requests For transactions such as ATM withdrawals or PIN Debits, which are routed via a single-message network, financial requests are used to authorize an amount and immediately debit the cardholder’s account with a single request. Financial transaction requests can only be made in the base currency of an account given that it has sufficient available balance, is active, and not currently blocked. :::note ATM withdrawals can also be reversed using the [dedicated API request](/api/api-v2/cards/reverse-card-transaction) ::: ## Reversal request You can reverse an authorization hold fully or partially using the [decrease endpoint](/api/api-v2/cards/decrease-authorization-hold) if the transaction is cancelled or the cardholder will be charged a lesser amount. A fully reversed authorization hold will receive the status `REVERSED` and will no longer affect the cardholder’s available balance. Partially reversed authorization holds will retain the `PENDING` status and their expiry period will be reset, effectively restarting it from the point at which the partial reversal was made. :::note You can also fully reverse a `PENDING` authorization hold by making a `DELETE` request. ::: ## Refunds authorization Once an authorization hold has been settled and money has already been debited from a cardholder’s account, it can no longer be reversed. It must be refunded by posting a new transaction for the full amount charged or, in the case of a partial refund, less than the originally charged amount. Currently this process requires creating a new authorization hold with credit amount and clearing it by using the [createCardTransaction](/api/api-v2/cards/create-card-transaction/) endpoint. Original Credit transactions can be posted in the same manner. :::note Any interest applied before the refund has been made will not be affected and should be considered separately. ::: --- # Transaction Processing URL: https://docs.mambu.com/docs/card-transaction-processing/ Using the Cards API, you can process transaction requests, transaction advices, and transaction reversals. There are two different models for how payment cards operate: * **Single Message Schema**: the requested amount is written off immediately by executing a transaction after a successful payment card authorization. This is achieved using [transaction requests](/docs/card-transaction-processing#transaction-requests). * **Dual Message Schema**: the requested amount is held after successful authorization and a transaction is executed only after receiving a confirmation as a clearing or settlement transaction. This is achieved using a combination of [authorization requests](/docs/authorization-holds) and [transaction advices](/docs/card-transaction-processing#transaction-advices). Clearing or settlement transactions can come in a file or in a batch and each transaction must be posted as a transaction advice. The transaction direction is determined using the dedicated parameter `creditDebitIndicator`: * `DBIT`: to debit a payment card account. * `CRDT`: to credit a payment card account. If the reference to an authorization hold is present and it is in `PENDING` state, the transaction direction is determined by the authorization hold type correspondingly: * A `DBIT` hold triggers a debit transaction, * A `CRDT` hold triggers a credit transaction. :::note If neither `creditDebitIndicator`, nor reference to a hold are present, the payment card account is debited by default. ::: The following table describes the different types of messages that pass between the card issuer and Mambu, depending on the type of transaction initiated. | Card message Type | Debit Cards Availability | Credit Cards Availability | | --- | :---: | :---: | | Debit Transaction Request | YES | YES | | Credit Transaction Request | YES | NO | | Debit Transaction Advice | YES | NO | | Credit Transaction Advice | YES | NO | | Full Transaction Reversal | YES | YES | | Partial Transaction Reversal | YES | YES | There are credit card flows that we currently do not support, but we are working on achieving parity. ### Transaction requests Transaction requests are posted to Mambu using a dedicated [Create card transaction](/api/api-v2/cards/create-card-transaction/) request. Request body parameter `advice` is used to determine if it is a transaction request or a transaction advice. If `advice` is `FALSE`, the request is considered a transaction request. If it is a debit transaction request, the available balance is checked: if the requested transaction amount doesn't exceed the available balance, a transaction is executed. Otherwise, the transaction request is declined due to insufficient funds. ### Transaction advices Transaction advices are posted to Mambu using a dedicated [API request](/api/api-v2/cards/create-card-transaction/) with the request body parameter `advice` equal to `TRUE`. This causes the authorization to be made without validating the available balance and can allow a cardholder to make a transaction for an amount over any defined limits as well as allow an account to go into [Technical Overdraft](/docs/technical-overdraft/). If a clearing transaction has been successfully matched to an authorization request, the reference to it can be filled in a request body parameter `externalAuthorizationReferenceId`. If an authorization hold is found and it is in `PENDING` state, it is released after a transaction is successfully executed. Such authorization hold doesn't impact the available balance anymore and is left in `SETTLED` state. Mambu supports multiple clearing transactions to one authorization hold. If a clearing transaction is one of multiple clearing transactions and is not the final one, it has to be marked as partial by setting the [API request](/api/api-v2/cards/create-card-transaction/) body parameter `partial` to `TRUE`. In this case the referenced hold will be decreased with the transaction amount and the remaining hold amount will stay in `PENDING` status. ### Transaction reversals You can reverse previously made transactions using the [Reverse card transactions](/api/api-v2/cards/reverse-card-transaction) endpoint. Debit transactions can be reversed in full or partially. Mambu makes sure that the sum of all reversed transactions does not go over the amount of the initial transaction. To reverse a credit transaction, you must use the exact amount. You can [get card transaction details](/api/api-v2/cards/reverse-card-transaction) using the card reference token and transaction external reference identifier. If a card transaction is partially or fully reversed, the information about each received reversal is returned in the response body. --- # Cards Introduction URL: https://docs.mambu.com/docs/cards-introduction/ *Cards* are payment instruments issued by the bank and electronically linked to one or more deposit or loan accounts belonging to the cardholder. We support both debit cards and credit cards depending on the selected product. ## Prerequisites Before you start using cards in Mambu, make sure you do the following: * [Set up a current account deposit product](/docs/setting-up-new-deposit-products) with technical overdraft enabled. * [Open a deposit account](/docs/creating-a-deposit-account). Mambu card services are based on card tokens. For more information, see [Token Management](/docs/token-management). Once you register a card token in Mambu you can post card authorizations and transactions. For more information, see [Authorization Holds](/docs/authorization-holds) and [Transaction Processing](/docs/card-transaction-processing). There are two possible ways to integrate payment cards in Mambu: cards API and end-to-end solution. ## Cards API You may call Mambu Cards API directly by posting an authorization request or a financial transaction. You need to integrate with payment card processing companies for card issuing. Registration of card token unlocks Mambu Cards API for payment card authorization and transaction processing. In this case, you are responsible for mapping payment card authorization and transaction messages to Mambu Cards API payloads. For more information, see [Cards](/api/api-v2/cards/cards) in our API Reference. ## End-to-end solution Our cards hub platform integrates with partners to provide end-to-end solutions for customers for both card issuing and card processing. For more information about existing Mambu integrations, see [Cards Integrations](https://ecosystem.mambu.com/connectors/marqeta/). --- # Carry forward balances at reschedule or refinance URL: https://docs.mambu.com/docs/carry-forward-balances-at-reschedule-or-refinance/ When a mortgage is rescheduled or refinanced, accrued interest that has not yet been applied is typically written off. The Carry Forward feature allows you to preserve the accrued interest amounts by transferring them to the new loan account, without needing to capitalize them. This ensures transparency for the customer and prevents the unintentional loss of owed interest, fees, or penalties for the lender. ## Prerequisites To use the Carry Forward functionality, the target loan account must meet the following conditions: * **Product type**: The target account must be a mortgage product (Dynamic Mortgage or Interest-Only loans). Non-mortgage products will not display carry-forward options. * **Repayment allocation**: The target product must have "Custom Repayment Allocation" enabled. This is mandatory as most carried-forward balances are repaid via custom repayments outside the standard schedule. For more information, see [Processing Loan Repayments](/docs/processing-loan-repayments#enter-a-custom-repayment). * **Account state**: Only "Active" or "Active in Arrears" accounts are eligible. Locked or Closed accounts cannot be rescheduled. ## Use cases * **Internal rescheduling**: Changing between Dynamic Mortgage and Interest-Only products or extending loan terms. * **Refinancing/rescheduling**: Increase the borrowings to the customer or Choosing to extend the term of the loan. ![Carry forward balances](@site/static/img/support/carry-forward-balances.png) ## Handling types of balances ### Principal and Arrears * **Current principal outstanding**: Equates to the total amount of principal that needs to be repaid. * **New account's schedule amoritized principal**: This amount is carried forward to the new account and amortized according to the updated schedule and terms. * **Principal in arrears**: This amount is transferred to a dedicated `CarryForwardPrincipal in Arrears` balance. This equates to principals from repayments that were in arrears at the time of the reschedule/refinance. It is not amortized on the new schedule and must be settled via custom repayments. :::note If the account is not in arrears at the time of rescheduling, the full current principal outstanding will be amortized on the schedule as there is no *Principal in arrears*. ::: ### Interest * **Regular interest accrued**: Added to the first installment of the new loan. It is applied and charged on the first installment's due date. * **Regular interest balance (applied)**: Carried forward to the CF Interest Balance. It is kept "off-schedule" and requires custom repayments. * **Interest from arrears balance & Interest from arrears accrued**: Mambu has the capability in regard to decouple interest from arrears. Based on the product configuration at the time of reschedule/refinance with carry-forward, this will be handled in different ways depending on the setup of the source and target products. * The following product configurations are supported. Each will have their specific way of dealing with the interest from arrears at the time of reschedule/refinance: * Decoupled -> Decoupled product * Non-decoupled -> Decoupled product * Decoupled -> non decoupled product * Non-decoupled -> non decoupled product ### Fees * **Scheduled fees**: Reclassified as Non-Scheduled Fee Balances on the new account. * **Interest-bearing fees (IBF)**: The balance is preserved to continue interest accrual on the new account. Any unapplied accrued interest on fees should be applied manually before rescheduling to avoid loss. ### Redraw Balance The Redraw Balance acts as a holding account for overpayments, reducing the interest-bearing principal. * **Net balance calculation**: Interest on the new loan is calculated on the Net Balance (Expected Principal - Redraw Balance). * **Product mismatch**: If you are rescheduling to a non-redraw product, the Principal Balance will automatically be reduced by the redraw amount. ## How does the new loan work? ### Repayment schedule * **The first installment**: Any "Interest Accrued" carried forward is included to the interest due in the first installment of the new loan. * **Total Due adjustment**: If the combined interest exceeds the planned installment amount (PMT), a new "Total Due" is calculated for that first installment. ### Account state and arrears * **Days in Arrears**: If the old loan was in arrears, the "Days in Arrears" count is carried forward. * **Returning to good standing**: The loan returns to an "Active" (non-arrears) state only once the Carried Forward Interest Balance and Principal in Arrears are paid in full. ### Accounting and Ledger implications Mambu employs a Mirror Booking logic for all income transactions (Interest and Applied Fees) during a reschedule: * **Reversal**: The total accumulated interest/income on the original account is reversed. * **Re-logging**: The consolidated amount (Legacy Accrual + Current Day Accrual) is logged as a new entry on the target account. * **Internal transfers**: Principal and Redraw balance transfers are captured within a single "Transfer" transaction to maintain portfolio & Portfolio Control GL integrity. ### Rules and validations * **Exclusive actions**: You must choose exactly one action per balance: Carry Forward, Capitalize, or Write Off. * **Backdating**: Backdated reschedules/refinances are not permitted. The transfer date must be the current date. * **Compound interest**: If the new loan uses compound interest, carried-forward accrued interest is included in the balance for future interest-on-interest computations. --- # Cash vs Accruals Accounting URL: https://docs.mambu.com/docs/cash-vs-accruals-accounting/ ## Accounting methodologies Mambu supports two main accounting methodologies you can choose from based on your internal operations: * Cash * Accruals based accounting The key difference between the two methodologies is the moment when income or expenses are recognized in the General Ledger (GL). You can select the methodology for each of your products independently. While cash accounting recognizes incomes or expenses only when a payment is made or received, accruals accounting recognizes them at the moment they accrue for the organization, regardless of whether a cash transaction occurs or not. To set the accounting methodology: 1. On the main menu, go to **Administration** > **Products**. 2. Find the product for which you want to set the accounting methodology and, on the right-hand side of the row, select **Actions** > **Edit**. 3. In the **Accounting Rules** section, select **Cash** or **Accrual** from the drop-down menu next to **Methodology**. If you select **None**, accounting will be disabled for this loan product. This means that transactions belonging to this specific product will not appear in journal entries. 4. If you select **Accrual**, the **Interest Accrued Method** option will be revealed. For more information, see [Interest accrued method in accounting](#interest-accrual-calculation-in-accounting) below. 5. Save the product. ![Accounting Rules - Methodology drop-down with None, Cash, and Accrual options](@site/static/img/support/accounting--accounting-rules-methodology-selection.png) ### Cash-based accounting With this methodology, **income** is recognised when cash is received that is, when a client actually pays a bill or interest and an **expense** is recognised when cash is paid, that is, when the organization pays a bill, not when the bill is received. **Example:** On May 1, 2010, Company A borrowed USD100,000 from our institution with a 12% yearly interest rate and pays off the loan in full at the end of June: **Journal entry on May 1, 2010** | | Debit | Credit | | -------------- | ------- | ------- | | Loan Portfolio | 100,000 | | | Cash | | 100,000 | **Payment received on June 30, 2010** | | Debit | Credit | | ---------------------------- | ------- | ------- | | Cash | 102,000 | | | Loan Portfolio | | 100,000 | | Interest from Loan Portfolio | | 2,000 | ### Accrual-based accounting Under accrual accounting, income and expenses are recognised when they are accrued, not when the money is actually exchanged. #### Income Income is recognized when **both** of the following conditions are met: * Income is **earned**: products are delivered or services are provided. * Income is **realised** (cash is received) or **realisable** (it is reasonable to expect that cash will be received in the future). #### Expenses Expenses are recognized in the period when they occur, and not only when they are paid. **Example:** On May 1, 2010, Company A borrowed USD100,000 from our institution with a 12% yearly interest rate and pays off the loan in full at the end of June: **Journal entry on May 1, 2010** | | Debit | Credit | | -------------- | ------- | ------- | | Loan Portfolio | 100,000 | | | Cash | | 100,000 | **Interest posted to account on May 31, 2010** | | Debit | Credit | | ------------------------------------------------------ | ----- | ------ | | Interest Receivable | 1,000 | | | Interest Income | | 1,000 | | ( USD100,000 x 12% x 1/12 = USD1,000 for this month ) | | | **Interest posted to account on June 30, 2010** | | Debit | Credit | | ------------------------------------------------------ | ----- | ------ | | Interest Receivable | 1,000 | | | Interest Income | | 1,000 | | ( USD100,000 x 12% x 1/12 = USD1,000 for this month ) | | | **Payment received on June 30, 2010** | | Debit | Credit | | ------------------- | ------- | ------- | | Cash | 102,000 | | | Loan Portfolio | | 100,000 | | Interest Receivable | | 2,000 | ## Interest accrual methods in accounting You can choose between **Daily** and **Monthly** interest accrual methods to determine when the interest accrued is booked for your loan product. To set the interest accrual method: 1. On the main menu, go to **Administration** > **Products**. 2. Find the product for which you want to set the interest accrued method and, on the right-hand side of the row, select **Actions** > **Edit**. 3. In the **Accounting Rules** section, select **Accrual** from the drop-down menu next to **Methodology**. 4. Next to **Interest Accrued Method**, select **Daily** or **Monthly** from the drop-down. If you select **None**, interest will not be accrued on this loan product. 5. Save the product. ![Interest Accrual Method in Accounting with Daily and Monthly options.](@site/static/img/support/interest-accrued-method-accounting.png) For **Monthly** accrual, the total accrued interest will be booked on the last day of every month at 23:59:59 (the time of the organization). For **Daily** accrual, the accrued interest will be posted daily at 00:00:00, the time of the organization, for the previous day. However, if you want the accrued interest for the current day to be posted at 23:59:59 on the current day, please get in touch with your Mambu Customer Success Manager and ask them to enable the daily accrual on the same day or **Interest accrual posted in current day** feature, which is in Early Access. By default, interest accrual is posted daily or monthly as an aggregated amount per loan/ deposit product and per branch. An option to post interest accrual per account (in addition to the aggregated amount) is available for loan products only. Every time the accrued interest is booked, the previous monthly journal entries will be reversed and the new ones with the current interest accrued will be logged. :::note If the method is changed on an active product from **Monthly** to **Daily** in the middle of the month, the journal entries will be reversed, to be in accordance with the newly selected method. The same applies when transitioning from **Daily** to **Monthly**: on the next End of Day Process execution, the daily journal entries will be reversed, adding monthly entries at the end of the month instead. ::: ## Interest accrual calculation in accounting :::note This functionality has been developed for **loan products** only. ::: By default, interest accrual is posted daily or monthly as an aggregated amount per loan product, meaning the sum of all interest accruals of each loan account of a specific product. If you would like interest accrual to be posted per loan account, follow the steps in this section. Under **Administration** > **Products** > **Actions** > **Edit** > **Accounting Rules**, select **Breakdown per Account** from the drop-down menu next to **Interest Accrual Calculation**, then click **Save Product** on the bottom right. ![Interest Accrual Calculation in Accounting](@site/static/img/support/interest-accrual-calculation-accounting.png) After this step, a new tab will appear under **Accounting** called **Interest Accrual Breakdown**. ![Interest Accrual Breakdown tab under Accounting](@site/static/img/support/interest-accrual-breakdown-accounting.png) The **Parent ID** of the breakdown entries corresponds to the **Entry ID** of the aggregated amounts under the **Journal Entries** tab. ![Parent ID under Interest Accrual Breakdown corresponds to Entry ID under Journal Entries](@site/static/img/support/parent-id-interest-accrual-breakdown-accounting.png) ![Entry ID under Journal Entries corresponds to Parent ID under Interest Accrual Breakdown](@site/static/img/support/parent-id-entry-id-journal-entries-accounting.png) You can change the **Interest Acrrual Calculation** setting at any time, even when the product is in use. If you no longer wish to have accrual reports on the account level, simply change **Breakdown per Account** back to **Aggregated Amount** under **Administration** > **Products** > **Actions** > **Edit** > **Accounting Rules**, select **Breakdown per Account** > **Interest Accrual Calculation**. --- # Using Centrify as your IdP URL: https://docs.mambu.com/docs/centrify-as-idp/ ## Setting up Federated Authentication with Centrify 1. Login to your Centrify admin account and go to **Web Apps** > **Add Web Apps** > **Custom** > **SAML** > **Add**. ![Add Web apps screen](@site/static/img/support/Screen%20Shot%202019-03-11%20at%2015.19.30.png) 2. Select the newly created application and go to _Trust_ ![Trust screen with Identity provider configuration and service provider configuration sections visible](@site/static/img/support/Screen%20Shot%202019-03-11%20at%2015.21.15.png) 3. In both the **Identity Provider Configuration** and the **Service Provider Configuration** sections select the **Manual Configuration** option and add the following configuration for Service Provider Configuration. 4. Assign a user to the application by adding permissions: ![permissions screen](@site/static/img/support/new%20-%20Screen%20Shot%202019-03-11%20at%2015.29.21.png) 5. In Mambu, navigate to **Administration** > **Access** > **Federated Authentication** and select the **Enable Single Sign-On** check box with the Manual Settings options selected as well. 6. Enter the **Name** you would like to use for your IdP. 7. Enter the **Single Sign-On Endpoint**, use the Single Sign On URL (Centrify Identity Provider Configuration section) 8. Download the Signing Certificate from the Identity Provider Configuration section 9. Enter the Certificate Fingerprint with the value of the following command: ```shell openssl x509 -noout -fingerprint -sha256 -inform pem -in ``` > Do not forget to replace the placeholders above with the correct certificate name / path. 10. For Issuer ID, enter the Entity ID from IdP Entity ID / Issuer (Centrify Provider Configuration section) ![Mambu Adminsistration screen with all relevant fields filled in](@site/static/img/support/new%20-%20Screen%20Shot%202019-03-11%20at%2015.28.09.png) 11. Select **Test SSO Connection** and enter the username and password of the assigned user account. 12. Once you are sure you have a successful setup, you can select **Save Changes**. ## Role assignment ![SAML Response settings screen](@site/static/img/support/Screen%20Shot%202019-03-12%20at%2010.30.29.png) To map the roles from IdP to Mambu and to have the user details such as email, first name, last name stored in Mambu, the following attributes must be added to the SAML Response: | Attribute Name | Attribute Value | |---|---| | Email | LoginUser.Email | | First Name | LoginUser.FirstName | | Last Name | LoginUser.LastName | | RoleID | LoginUser.RoleNames | `LoginUser.RoleNames` will contain the list of a user's roles names, the first of which will be used in Mambu. --- # Changing the interest rate URL: https://docs.mambu.com/docs/change-interest-rate/ You can change the interest rate at account level for the following loan products: * **Dynamic Term Loans** using the **Declining Balance Equal Installment** interest calculation method with either **Standard** or **Balloon** payment methods and all pre-payment recalculations. * **Dynamic Term Loans** with a fixed interest rate, using the **Declining Balance** interest calculation method, and **No Recalculation** set as pre-payment recalculation. * **Revolving Credit Loans** with a fixed interest rate. :::warning You may only change interest rates for revolving credit loans when **Interest Rate Source** is set to **Fixed Interest Rate**. When **Interest Rate Source** is set to **Index Interest Rate**, changing the spread on Revolving Credit loans is not currently supported. ::: The interest rate and the index rate can be changed in the Mambu UI or via the API. For more information on changing rates with the API, see [Change interest rate](/api/api-v2/loans/change-interest-rate) and [Create index rate](/api/api-v2/indexratesources/create-index-rate) in our API Reference. ## Fixed interest rates Fixed interest rates normally don’t change for the entire term of the loan. However, if you must change them after a period, you have the possibility to do so. You can increase or decrease the fixed interest rate at the account level for any `Active` or `Active in Arrears` accounts. To change the fixed interest rate: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Edit Interest Rate**. 3. In the **Editing Interest Rate** dialog, enter a new interest rate and select the date from which you want the interest to change. The date can be in the present, backdated, or in the future. 4. Save your changes. ![Revolving Credit loan, Edit fixed Interest Rate option available under More](@site/static/img/support/edit-interest-rate.png) ![Edit Interest Rate pop-up with New Rate and Value Date (Entry Date) options](@site/static/img/support/editing-interest-rate.png) You may change the interest rate multiple times. Mambu will always apply the most recent rate. Future changes of interest rates are visible on the effective date. After you change the interest rate, the effect on the schedule will be visible in the **Schedule** tab. :::note The **Interest Rate Changed** transaction is a non-financial transaction and cannot be reversed. For this reason, all backdated and current **Interest Rate Changed** transactions will be visible in the **Transactions** tab. ::: ## Index interest rates *Index interest rates*, also known as variable or adjustable rates, are calculated as the sum of a reference benchmark index interest rate and a specified spread or margin. As a result, index interest rates change when the benchmark index interest rate changes. You can manually change either one of these components with the following results: * When you change a **reference index rate**, all loan accounts using this reference are also changed. * When you change the **spread**, only the specific loan account you are updating will be affected. To change the interest reference, see [Customizing Index Interest Rates & Tax Rates](/docs/customizing-index-rates). To change the interest spread: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Edit Interest Spread**. 3. In the **Editing Interest Spread** dialog, enter a new interest spread and select the date from which you want the spread to change. The date can be in the present, backdated or in the future. 4. Save your changes. ![Revolving Credit loan, edit variable interest rate option available under More](@site/static/img/support/edit-interest-spread.png) :::warning You cannot change an interest rate to a time before an existing **Repayment** transaction or before an existing **Interest applied** transaction. To avoid validation conflicts, always ensure that index rate source updates are created before applying any account-level interest spread changes intended for the same value date. ::: ## Adjustable interest rates On the same loan account, you can have both interest rate sources and to switch from fixed interest rate to index interest rate and the other way around throughout the life cycle of the loan. You can set as many interest rate sources as you wish, which offers flexibility. --- # Profile and Password Management URL: https://docs.mambu.com/docs/change-your-password-and-edit-your-profile/ This article describes profile and password management for users with a Mambu password. If your organization has configured Mambu to use single sign-on (SSO) by enabling federated authentication, please see [Managing Users under Federated Authentication](/docs/managing-sso-provisioned-users) for information on managing your profile. Even if your organization has enabled SSO, note that some users will still have passwords in addition to their SSO login, such as admin users or users with API access rights. ## Editing your profile You can edit **First Names**, **Last Names**, **Title**, and **Email address**, as well as the **Mambu Display Language** you would like to use. You cannot edit **Username**. You must have the `CREATE_USER` or `EDIT_USER` permission to change your profile. To edit your profile: 1. In the top right corner of the page, select **your name** > **Edit Your Profile**. 2. Make the changes you want. 3. Select **Save User**. ![Edit your profile screen with all fields that can be changed for the profile, excluding the Username](@site/static/img/support/users-and-access-control--editing-user-demo.png) :::warning Please be aware If you change your **Mambu Display Language**, you must log out and then log back in to see the UI in the desired language. ::: For more information about the settings of your user account, see [Creating a User](/docs/creating-new-users). ## Changing your password To change your password: 1. In the top right corner of the page, click on **your name** > **Edit Your Profile**. 2. Under **User Access**, click **Reset Password**. 3. Enter the new password. 4. Enter it again to confirm. 5. Select **Save User** to save your profile. ![User access section, from where the password and the language can be changed](@site/static/img/support/reset-mambu-password.png) :::note You can change your own password but only administrators can change other users' passwords. ::: ## Resetting your Password If you forgot your password, you can easily reset it from the login screen. :::warning Please be aware To reset your password, you must have an email address associated with your Mambu account. If you wish to reset the password for an account that does not have a password configured, contact your administrator to update your profile with a valid email address. ::: To reset your password: 1. Go to your Mambu domain. 2. Click on "Lost your password?" 3. Enter your email. 4. Click **Reset Password**. ![Reset your password screen. An email will be sent to the provided email address . with a link to set the new password.](@site/static/img/support/users-and-access-control--password-reset-dialog.png) You will then receive an email with a link - simply follow the instructions in that email to reset your password. [![Password reset screen. In that the username and the new password have to be inserted.](@site/static/img/support/users-and-access-control--password-reset.png)](https://mambu2.document360.io/docs/%20https://s3.amazonaws.com/mambu-static/images/stories/pswd%20confirmation.png) You will now be able to login using your new password. ### Password requirements The following requirements are enforced for all passwords: * Must include six or more characters. We recommend at least eight. * Must include at least one letter and one digit. * May not contain your username, even if preceded or followed by other characters. * May not be the same as a previously-used password. You may also add or edit your password policy settings. The settings you may configure are: * Minimum password length. * Minimum number of numerical, special, or uppercase characters. * Number of previously used characters that cannot be resued in creating a new password. * Number of failed login attempts before a user is locked out of Mambu. For more information about how to configure these settings, see [Access Preferences](/docs/access-preferences). ## Access restrictions caused by multiple login failures ### Mambu UI For increased security to your account, if a password is entered incorrectly three times during login, Mambu will require the user to enter a captcha. [![Captcha login authentication. Besides the username and password, the user should enter a captcha.](@site/static/img/support/users-and-access-control--login-page.png)](https://mambu2.document360.io/docs/customer/portal/attachments/303810) :::warning Please be aware If you're an admin user, you may disable this requirement for a reset session by resetting the user's password, or by disabling and re-enabling that user's access to Mambu. ::: ### Mambu API If you make multiple incorrect attempts to login via API, you will be locked out for 45 seconds. --- # Changing Interest Rates on Active Deposit Accounts URL: https://docs.mambu.com/docs/changing-the-interest-rate/ Clients with deposit accounts can either receive credit interest for the amount they save, or they can be charged debit interest if their accounts go into overdraft. ## Credit interest rates Credit interest is the interest you owe your clients for the amount they keep in your bank or financial institution. ### Product level changes When you change the interest rate at the product level, the change will apply to the deposit accounts using that product. If you are making a change via the UI, you will be prompted to select whether this change should apply to either all existing and new accounts or to new accounts only. The change will be applied the next time the end of day processes are run. :::warning **Changing the interest rate in the middle of the period affects existing accruals** If you change the interest rate at the product level in the middle of the period, Mambu will recalculate existing accruals from the date when the interest has been applied the last time. Therefore, we recommend you to change the interest rate on the same date as the interest application date, or to use the [POST /deposits/\:changeInterestRate](/api/api-v2/deposits/change-interest-rate/) endpoint in API v2 for changing fixed rates at the account level instead. If you encounter any issues with this behaviour, please contact the Mambu Support Team. ::: | Interest Rate Terms | Availability | Impact on Accruals | | --- | --- | --- | | Fixed Interest Rate | ✔ | Will be recalculated with a new rate from the last interest application date. | | Index Interest Rate | ✘ | ✘ | | Tiered per Bands | ✔ | Will be recalculated with a new rate from the last interest application date. | | Tiered per Balance | ✔ | Will be recalculated with a new rate from the last interest application date. | | Tiered per Period | ✔ | Will be recalculated with a new rate from the last interest application date. | ### Account level changes | Interest Rate Terms | Availability | Impact on Accruals | Notes | | --- | --- | --- | --- | | Fixed Interest Rate | ✔
via API only | Accruals will be recalculated from the value date. |
  • can be backdated
  • cannot be post dated
    • | | Index Interest Rate | ✘ | N/A | N/A | | Tiered per Bands | ✘ | N/A | N/A | | Tiered per Balance | ✘ | N/A | N/A | | Tiered per Period | ✘ | N/A | N/A | ## Credit interest rate updates ### Fixed interest rates The interest rate at the account level is set, and remains fixed unless renegotiated or personalised for the client. To make changes via the API, make a POST request to the `/deposits/\:changeInterestRate` endpoint. For more information, see [Deposits - Change Interest Rate](/api/api-v2/deposits/change-interest-rate/) in our API Reference. With this endpoint, you can increase or decrease credit interest rates on individual Current, Savings and Fixed Deposit accounts within the product constraints. You can specify a new interest rate within the defined product constraints using the field `interestRate` and supplying the value date or date on which you want the change to be applied in an API body such as this: ```json { "interestRate": 1.2, "notes": "Rewarding client for loyalty.", "valueDate": "2020-04-26" } ``` Once executed, a non-financial transaction, "Interest Rate Changed", will be logged in the transaction history of the account with the new rate. When changing interest rates on individual deposit accounts, previously accrued interest will not be applied, it will be recalculated from the `valueDate` with the new credit interest rate. Mambu simply continues to accrue interest based on the rate and `valueDate` provided in the API call. You can retrieve all Interest Rate Changed transactions by making a GET request to the `/deposits/\/transactions` endpoint. For more information, see [Deposit Transactions - Get all transactions for a deposit account](/api/api-v2/deposits_transactions/get-all) in our API Reference. ### Index interest rates Changing the interest spread on credit index interest rates is not possible. For updates, please follow our release notes. ### Tiered per Balance, Tiered per Period, and Tiered per Band interest rates To change the interest rate at product level: 1. Open the deposit account. 2. On the right-hand side of the screen, select **More** > **Edit account**. 3. In the **Editing deposit account** form, under **Product**, take a note of the deposit product used to create the account. 4. Go to **Administration** > **Products** > **Deposits**. 5. In the list of deposit products, find the one you want to edit and select **Actions** > **Edit**. 6. Make changes to the tiered interest rates. 7. Select **Save Product**. 8. Before confirming, choose if you want your changes to apply to **All existing and new accounts** or to **New accounts only**. ![Confirm changes dialog where you can specify if you want your changes to apply to all existing and new accounts or To new accounts only](@site/static/img/support/edit-tiered-interest-for-deposits.png) To change the interest rate via API, make a POST request to the `/depositproducts/:batchUpdate` endpoint in API v2. For more information, see [Deposit Products - Batch Update](/api/api-v2/depositproducts/batch-update) in our API Reference. All accrued interest will be re-calculated at the new rate starting from the next day. If an account has USD20 of accrued interest, and the interest rate increases, then the amount of accrued interest will increase. When the interest is applied, the total amount of interest for the period is calculated as the sum of the daily interest calculated as above using daily interest, truncated to 20 decimal places. For more information, see [Truncating and rounding interest](/docs/truncating-and-rounding-interest-deposits). Mambu allows you to change positive interest rates at the account level. The [Tiered Per Bands](/docs/setting-up-new-deposit-products) interest calculation method also supports negative rates. Negative interest rates cannot be changed. ## Debit interest rates Debit interest is the interest your clients owe you for the use of an overdraft facility, expressed as an annual percentage of the amount the client is overdrawn. ### Product level changes When you change the debit interest rate at the product level, the change will apply only to all new deposit accounts created under that product and not to any existing accounts. To update the debit interest rate for existing accounts, make a PATCH request to the `/savings/` endpoint in API v1. For more information, see [Savings accounts -Edit existing savings account](/api/api-v1/savings/edit-existing-savings-account). There will be no transaction booked for the change of interest rate, but you would see the new rate updated in the **Details** tab of the Mambu web app. | Interest Rate Terms | Availability | Impact on Accruals | | --- | --- | --- | | Fixed Interest Rate | ✔ | Will be applicable only to the new accounts. | | Index Interest Rate | ✘ | N/A | | Tiered per Balance | ✔ | Will be applicable only to the new accounts. | | Tiered per Bands | ✔ | Will be applicable only to the new accounts. | ### Account level changes | Interest Rate Terms | Availability | Impact on Accruals | Notes | | --- | --- | --- | --- | | Fixed Interest Rate | ✔
    via UI and API | Will be recalculated with a new rate from the last interest application date. | | Index Interest Rate | ✔
    via UI or API | Spread can be updated. Accruals will be recalculated from the day of the change. Specific values for the index rate source can be managed under **Administration** > **Financial Setup** > **Rates**. For more information, see [Customizing Index Rates](/docs/customizing-index-rates). | Cannot be backdated or post dated. | ## Debit interest rate updates To change the debit interest rate at account level: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Adjust Overdraft Terms**. 3. In the **Adjust Overdraft Terms** dialog, under **Interest Rate**, update the interest rate. 4. Select **Save Changes**. ![Adjust overdraft terms dialogue with overdraft limit, interest rate, expiry date, and notes fields](@site/static/img/support/adjust-overdraft-terms.png) ## Backdating interest rate changes You can backdate credit interest rate changes on active accounts via API only. The same conditions apply as for the regular changes presented above. You can backdate interest rate changes on individual Current, Savings and Fixed Deposit accounts by making a POST request to the `/deposits/\:changeInterestRate` endpoint. For more information, see [Deposits - Change Interest Rate](/api/api-v2/deposits/change-interest-rate/) in our API Reference. Simply set a valueDate in the past and backdate interest rate changes. ```json { "interestRate": 1.2, "notes": "Rewarding client for loyalty.", "valueDate": "2020-03-26" } ``` Once executed, a non-financial transaction "Interest Rate Changed" will be logged in the transaction history of the account. You can retrieve all Interest Rate Changed transactions by making a GET request to the `/deposits/\/transactions` endpoint. For more information, see [Deposit Transactions - Get all transactions for a deposit account](/api/api-v2/deposits_transactions/get-all/) in our API Reference. --- # Choose Prepayment Recalculation Method at Repayment Time URL: https://docs.mambu.com/docs/choose-prepayment-recalculation-method-at-repayment-time/ When configuring dynamic mortgage products in Mambu, the user must specify the default prepayment recalculation method to be applied in the event of prepayments or overpayments. The two available options are *Reduce Amount Per Installment (RAI)* and *Reduce Number of Installments (RNI)*. For dynamic mortgage products, you also have the option to *choose the prepayment recalculation method at repayment time*. This provides increased flexibility as you are not solely constrained by the initial product selection, and the need to process all repayments in line with the choice of product type. This feature empowers users to make real-time decisions about how a specific prepayment impacts the loan schedule, offering enhanced flexibility and responsiveness to varying financial situations. For a detailed explanation of how Reduce Amount Per Installment (RAI) and Reduce Number of Installments (RNI) methods work, refer to the following page: [Prepayment Recalculation Methods](/docs/prepayment-recalculation-methods). ## How it works This new functionality introduces flexibility at the point of repayment, allowing for a one-time override of the default account-level prepayment recalculation method for a specific transaction. When posting a repayment for a dynamic mortgage account, the user will now see a dedicated checkbox. This checkbox enables the user to specify which prepayment recalculation method should be applied for that particular repayment. The available options to choose from will be **Reduce Amount Per Installment (RAI)** and **Reduce Number of Installments (RNI)**. ![choose repayment checkbox](/img/support/choose-repayment-checkbox.png) Here’s a breakdown of the logic: * **If the checkbox is not checked**: The repayment logic will proceed using the default prepayment recalculation method configured at the account level. The schedule will be recalculated based on this default setting. * **If the checkbox is checked, and the selected prepayment recalculation method is the same as the account's default**: The schedule will still be recalculated based on the default account prepayment setting. Essentially, selecting the same option as the default does not alter the outcome. * **If the checkbox is checked, and the selected prepayment recalculation method is different from the account's default**: For this specific pre/overpayment, the loan schedule will be recalculated based on the chosen method for this one repayment only. Subsequent repayments, unless another override is selected, will revert to using the account's default prepayment recalculation method. :::note This feature is exclusively available for Dynamic Mortgages (which involve both capital and interest repayments). It is not applicable to Interest-only loans, as these loans inherently operate solely with the Reduce Amount Per Installment (RAI) method. At present, this feature is not compatible with the [Principal Overpayment](/docs/principal-overpayment) feature. ::: ## API parameters used for prepayment recalculation selection Prepayment recalculation is available through the [`POST /loans//repayment-transactions`](/api/api-v2/loans_transactions/make-repayment/) endpoint with the `prepaymentRecalculationMethod` parameter. To choose one of the above prepayment methods, you can use the following values: * `REDUCE_NUMBER_OF_INSTALLMENTS_NEW` * `REDUCE_AMOUNT_PER_INSTALLMENT` --- # Client Custom Fields URL: https://docs.mambu.com/docs/client-custom-fields/ ## Business case Extract all the client specific custom field values grouped by client. Each new client will be displayed on a new page. ## Technical concepts Work with different types of [custom field definitions](/docs/custom-fields), grouping usage, and pagination. ## Sources * [jrxml template report](https://s3.amazonaws.com/mambu-notifications/Resources/ClientCustomFields.jrxml) * [resulting report](https://s3.amazonaws.com/mambu-notifications/Resources/ClientCustomFields.pdf) ## Preview ![first page of report with all custom fields for client "Anbar Antoun"](https://s3.amazonaws.com/mambu-notifications/Resources/ClientCustomFields.png) --- # Client Life Cycle URL: https://docs.mambu.com/docs/client-life-cycle/ This page describes the client life cycle. For general information on individual clients, see [Clients and Groups Overview](/docs/clients-and-groups-overview). The *client life cycle* describes the different states a client can be in, there are a total of six states: * Pending Approval * Inactive * Active * Rejected * Exited * Blacklisted The client state can be seen on the client detail page next to the **Client State** field. ![The Client State field on the client detail page](@site/static/img/support/clients-and-groups--client-detail-overview.png) :::note To perform any action related to clients, you need the proper permission from your administrator. ![Creating a user form with permissions related to clients selected](@site/static/img/support/permissions-related-to-clients.png) ::: ## Setting a new client's initial state You may set the initial state that clients have when they're created. You may choose between the pending approval state or inactive state. This setup is available under **Administration** > **General Setup** > **Internal Controls** > **New Client Initial State**. For more information, see [Internal Controls - New Client Initial State](/docs/internal-controls#new-client-initial-state). ![Set client's initial state](@site/static/img/support/internal-controls.png) ## Pending approval The pending approval state indicates that a client is under evaluation. This state can be used as an initial state if there is a process of approving the client that is separate from the process of approving a loan or deposit account. Or if you have a process of carrying out your credit checks outside of Mambu. When a client is in this state, it is not possible to create new accounts or process any loan or deposit applications for this client - they must first be approved. A client in this state can either be rejected or approved as a new client. A rejected client's state changes to rejected. An approved client's state changes to inactive. To reject or approve a client: 1. Go to the client detail page for the client you want to manage. 2. In the top right-hand corner, select either **Reject Client** or **Approve Client**. ![A client in pending approval state](@site/static/img/support/clients-and-groups--client-details-overview-pending-approval.png) ## Inactive The inactive state is for clients that have no active loans or deposit accounts. This state can be used as an initial state for new clients or it can be the state an existing client, that was previously in the pending approval state, enters after they have passed their evaluation and been approved. A client in this state can be activated, exited, blacklisted, or returned back to the pending approval state. A client will be activated if you create new accounts for them or process their loan or deposit accounts applications. To exit, blacklist, or return a client to the pending approval state: 1. Go to the client detail page for the client you want to manage. 2. In the top right-hand corner, select **More**. 3. Select either **Blacklist Client**, **Exit Client**, or **Undo Approve Client**. Selecting **Undo Approve Client**, changes the client state to pending approval. :::note The **Exit Client** and **Undo Approve Client** option will only be available if the client does not have any accounts. ::: ![A client in inactive state](@site/static/img/support/clients-and-groups--client-profile-overview-3.png) ## Active The active state is for clients that have at least one active or in arrears loan or deposit account. A client in the active state can either become inactive or be blacklisted. The client's state will automatically be set to inactive as soon as there are no active accounts associated with the client. To blacklist a client: 1. Go to the client detail page for the client you want to manage. 2. In the top right-hand corner, select **More** > **Blacklist Client**. ![A client in the active state](@site/static/img/support/clients-and-groups--client-profile-overview-11.png) ### In good standing Clients in good standing are clients in the active state who are complying with all their financial obligations and are not late with any payments. ## Rejected The rejected state is for clients that did not pass their evaluation while in the pending approval state. You may describe the reason for the rejection in comments. It is possible to reverse the rejection and set the client state to pending approval again. To undo a rejection: 1. Go to the client detail page for the client you want to manage. 2. In the top right-hand corner, select **More** > **Undo Reject Client**. ![A client in the rejected state](@site/static/img/support/clients-and-groups--client-profile-overview-5.png) ## Exited The exited state is for clients that don't have any active accounts. If a client is in this state then it is not possible to create new accounts for them, assign them as a guarantor, or add them to a group. Only inactive clients can be exited. There are several reasons why you might want to consider setting a client's state to exited. For example: if the client finished a loan cycle and doesn't apply for another loan immediately afterwards, you might want to keep that client's information in the system while also preventing other users from opening accounts for that client by mistake or assigning them to credit officers, or guarantors. Clients in this state might return to your organization in the future and it will be valuable to have all their history stored. You may also reverse a client's state from exited to inactive. To undo an exit: 1. Go to the client detail page for the client you want to manage. 2. In the top right-hand corner, select **More** > **Undo Exit Client**. ![A client in the exited state](@site/static/img/support/clients-and-groups--client-profile-overview-7.png) ## Blacklisted Any client in the `Pending approval`, `Inactive` or `Active` states can be blacklisted. If clients are blacklisted, you can no longer open new loan or deposit accounts for them. When blacklisting a client, you can add comments to describe why a client is blacklisted, which will be accessible to other users from your organization. After a client is blacklisted, with the proper [permissions](/docs/permissions#permission-descriptions) you can still: * Operate and transact on existing accounts. * Create, edit, and delete tasks linked to the blacklisted client. * Create, edit, and delete comments linked to the blacklisted client. * Upload, edit, and delete attachments. * Set up new, activate, and deactivate notifications. * Add new, edit, and delete clients' profile pictures. * Add new, edit, and delete clients' profile signatures. * Edit any of the client's custom field values. After a client is blacklisted, you can no longer: * Open new accounts. * Edit the client's details. * Add the client to one or more groups. * Assign a client the role of guarantor. It is also possible to revert the action of blacklisting a client. This will cause a client to go back to the state they had before they were blacklisted. To remove a client from the blacklist: 1. Go to the client detail page for the client you want to manage. 2. In the top right-hand corner, select **More** > **Undo Blacklist Client**. ![A client in blacklisted state](@site/static/img/support/clients-and-groups--client-profile-overview-9.png) --- # Client Types URL: https://docs.mambu.com/docs/client-types/ This page describes how to create, edit, and delete client types. For general information on individual clients and how they are used, see [Clients and Groups Overview](/docs/clients-and-groups-overview). Every individual client must be assigned a client type during the creation process. The client type **Client** is available by default. You may create custom client types or modify the default type to organize your individual clients as you wish. All existing client types are listed in the **Create** menu in the top bar. If your user has the **Change Client Type** (`CHANGE_CLIENT_TYPE`) permission, you may change the CLIENT type of an individual client. For example, you may have an individual client that has a client type of **Prospective Client** and once this individual client becomes an active client their client type can change to **Existing Client**. ![Create menu with default group type available](@site/static/img/support/clients-and-groups--client-types-administration.png) :::warning In Mambu we sometimes refer to *client types* as *client roles*. For example, in our Configuration as Code (CasC) implementation for client roles and group roles. ::: ## Creating client types In the example below we create a client type called **Student**. To create a new client type: 1. On the main menu, go to **Administration** > **General Setup** > **Client Types**. 2. In the **Type** drop-down, select **Client**. 3. On the right-hand side of the screen, select **Add Type**. 4. In the **Add Client Type** dialog box enter all the necessary information. We will cover all the configuration options in depth below. 5. Select **Add Client Type**. ![Save Client Type dialog](@site/static/img/support/clients-and-groups--save-client-type.png) Once you have created a new client type it will be available in the **Create** menu in the top bar. In our example, we created a client type called **Student** and it is available in the **Create** menu. ![Create menu in top bar](@site/static/img/support/clients-and-groups--create-menu-dropdown.png) ### Fields for Client Types | Name | Description | Required | | --- | --- | --- | | Name | The name for the client type. | ✔ | | ID | The unique identifier for the client type, particularly useful for API operations.| ✔ | | Description | The description for the client type. | ✘ | #### Client ID Template (optional) :::warning In Mambu you create ID templates to manage the identification document information you collect for your clients. These are a completely separate concept than the **Client ID Template** field that is part of setting up client types. For more information about ID Templates for identification documents, see [ID Templates](/docs/id-templates). ::: Provide a **Client ID Template** to define the ID number length and format that will be generated every time you create a new client. #### Allow opening accounts This option allows the client type to open accounts. Do not select this option if you need to collect required information for example for prospective clients. #### Allow as guarantor This option allows the client type to be a guarantor. When a loan is issued, the customer has to provide guarantees. Guarantees can be given in the form of securities such as collateral or someone can be assigned to be a guarantor. This option determines whether a client with this client type can be assigned as the guarantor for a loan. #### Require identification documents This option makes ID documentation mandatory for this client type. :::note ID documentation will only be mandatory if you have set up at least one ID template for which you have selected the **Mandatory for Clients** option. For more information, see [ID Templates](/docs/id-templates) and [Creating an Individual Client - Adding identification documents]( /docs/create-an-individual-client#identification-documents). ::: #### Show default address fields If you select the **Show default address fields** checkbox, then your group creation form will include the default address fields. Otherwise, you can use custom fields to model the address fields section, for more information, see [Custom fields for clients](#custom-fields-for-clients) below. ## Custom fields for clients When creating a client based on a client type, the client creation form contains default standard fields but you can set it up to also contain additional custom field definitions. For more in-depth information about managing custom field definitions, see [Custom Fields](/docs/custom-fields). For example, for a **Student** client type, you can create a custom field set with custom field definitions related to the student profile. To add custom field definitions to a client type: 1. Either create a new custom field set or select an existing custom field set. 2. Add new custom field definitions to the custom field set or edit existing custom field definitions within a custom field set. 3. In the **Usage** section of the **Editing Clients Custom Field** dialog, for each custom field definition, select the client type to which you would like to add the custom field definition. ![Creating Client Custom Field Dialog](@site/static/img/support/clients-and-groups--creating-clients-custom-field.png) ### Example You can create a **Student Profile** standard custom field set. To this custom field set, you can add custom field definitions that you will make available for your **Student** client type, such as: * Student ID number * University * Scholarship recipient Once you have created the custom field definitions you will see the Student Profile section in the client creation form with the respective custom field definitions. For more information about displaying fields by default or making fields required, see [Custom Fields - Usage Section](/docs/custom-fields#usage-section). ![Student Profile custom field set section in Creating client dialog](@site/static/img/support/clients-and-groups--student-profile-custom-field-set.png) ## Editing and deleting client types To edit or delete a client type: 1. On the main menu, go to **Administration** > **General Setup** > **Client Types**. 2. In the **Type** drop-down, select **Client**. 3. In the list of client types, find the one you want to edit or delete and select **Actions** and then **Edit** or **Delete**. :::note You can not delete client types that are in use. ::: --- # Clients and Groups Overview URL: https://docs.mambu.com/docs/clients-and-groups-overview/ The term *client* is used in different ways in Mambu. In general usage, a *client* refers to any customer of your organization. Clients are represented in Mambu with *accounts*. There are two types: *(individual) client accounts* and *group accounts*. A **client account** is used for any individual client, such as a person with an account at your bank. In this article, we will use the term *individual client* to refer to a client with a client account. A **group account** is used for a client that is not an individual person, such as a business or legal entity. Group accounts are also used for joint accounts. Like a client account, a group account may be associated with loans and deposits and perform various transactions. Individual clients may be added to groups as members. :::warning You may only blacklist individual client accounts. Blacklisting group accounts is not possible. Blacklisting can be useful when know your customer (KYC) checks fail or when you observe suspicious activity on any accounts. ::: ## Group members and roles You may add individual clients to a group account as members. Those individual clients may or may not themselves receive financial services from your organization. For example, you may have a group account representing a business, and wish to add individual clients to that group account to represent different employees of the business such as the CEO or accountants. You may create individual clients for those members and add them to the group account even if the CEO or accountants are not themselves individually customers of your organization. You may create *group role names* such as CEO, secretary, or treasurer and assign them to group members. For more information, see [Group Role Names](/docs/group-role-names). Using group role names can be useful for communication, as you may send SMS or email notifications to members with a specific group role. For example, you may wish to notify all accountants working for a particular group customer any time the balance of any account drops below a certain threshold. For more information about setting up SMS and email notifications, see [Communicating with Clients](/docs/notifications-overview). ## Client and group types Every individual client or group is assigned a *client type* or a *group type* when created. An example of a client type is student. An example of a group type is joint account. You can create as many individual clients or groups based off of the same client or group type as you like. The default client type is called **Client**, and the default group type called **Group**. You may create additional types, and the default types may be modified. Certain permissions may be assigned to accounts based on their type. For example, some types allow members to open their own accounts. For more information, see [Group Types](/docs/group-types) and [Configuring Client Types](/docs/client-types). If you want to create individual clients or groups based off of other client or group types, you must first set them up in your tenant. For more information, see [Client Types](/docs/client-types) and [Group Types](/docs/group-types). :::warning In Mambu we sometimes refer to *group types* as *group roles*. For example in our Configuration as Code (CasC) implementation for client roles and group roles. We also sometimes refer to *group role names* as *group roles*. It is important to be aware when the term *group role* refers to group type or when it refers to group role name, as these are two separate concepts. ::: ## Client and group creation and management Once you have set up any necessary client or group types in your tenant, you may use either the Mambu UI or API v2 to create and manage your individual clients or groups. For more information about client and group creation and management via the Mambu UI refer to the relevant articles in the User Guide and for information about the API v2 capabilities, see the relevant [Clients](/api/api-v2/clients/clients) and [Groups](/api/api-v2/groups/groups) endpoints in our API Reference. --- # Clients by State URL: https://docs.mambu.com/docs/clients-by-state/ ## Business case Represent as a pie the client portfolio spread by state. ## Technical concepts Usage of [dataset](http://community.jaspersoft.com/documentation/tibco-jaspersoft-studio-user-guide/v60/datasets), a pie chart in this case (many can be included that way) ## Sources * [jrxml template report](https://s3.amazonaws.com/mambu-notifications/Resources/ClientsByState.jrxml) * [resulted report](https://s3.amazonaws.com/mambu-notifications/Resources/ClientsByState.pdf) ## Preview ![example clients by state report displayed as pie chart](https://s3.amazonaws.com/mambu-notifications/Resources/ClientsByState.png) :::warning Please note Due to recent changes to the Jasper Reports library used in Mambu, the report may not be visible when using the preview function in the Mambu UI. However, you will be able to view the finished report by using the _export_ button and exporting to .pdf format. ::: --- # Closing a Loan With All Obligations Met URL: https://docs.mambu.com/docs/closing-a-loan-with-all-obligations-met/ When a client finishes repaying a loan, the account balance goes to zero due and you can close that loan account. To close a loan account: 1. Open the account. 2. On the right-hand side of the screen, select **Close**. 3. Optional: Add a comment. 4. Select **Close**. ![Closing a loan account when the account has all obligations met](@site/static/img/support/closing-a-loan.png) After closing the account, its state will change to `Closed` and it will be stored in the client's profile under the **Closed Accounts** tab. If you would like Mambu to automatically close loan accounts that have been fully paid, you can set up a [Dormancy period](/docs/internal-controls-for-loans#close-dormant-accounts) when setting up the loan product. ## Undo a loan closure To undo a loan closure, in the account overview page, on the right-hand side of the screen, select **More** > **Undo Closure**. The maximum number of days during which a loan closure can be undone can be set under **Administration** > **General Setup** > **Internal Controls**. For more information, go to [Internal Controls](/docs/internal-controls#whats-the-maximum-number-of-days-after-which-you-cannot-reopen-closed-loans). --- # Closing Accounts URL: https://docs.mambu.com/docs/closing-accounts/ ## Closing a deposit account with zero balance To close an account: 1. Open the deposit account. 2. On the right hand side of the screen, select **Close**. 3. In the **Changing Account State** dialog, add any notes about the reason you are closing the account. 4. Select **Change Status**. ![Close drop-down only with Close option](@site/static/img/support/close-deposit-account.png) *** ## Writing off a deposit account *Writing off* a deposit account takes the remaining balances coming from unpaid overdraft balance, unpaid negative interest due or unpaid technical overdraft off the portfolio, registering them as a loss. To write off a deposit account: 1. Open the account. 2. On the right-hand side of the screen, select **Close** > **Write Off**. 3. In the **Changing Account State** dialog, add any notes about the reason you are writing off the account. 4. Select **Change Status**. ![Write Off Deposit Account option under Close](@site/static/img/support/write-off-deposit-account%281%29.png) This will settle the remaining balances with a specific transaction type (Write off), and close the account, changing its state to **Closed (Written off)** . :::note You can also write off a deposit account via API 2.0. For more information, see our [API Reference](/api/api-v2/deposits/change-state). ::: *** ## Undoing a write-off You may need to revert the write-off action and change the state of the deposit account. To undo a write off: 1. Open the account. 2. On the right-hand side of the screen, select **More** > **Undo Write Off**. 3. In the **Changing Account State** dialog, add a comment about the reason you are undoing the write off. 4. Select **Change Status**. This will reopen the deposit account and revert the deposit write off transactions, so the account will go back to the state it was before the write off. :::note The option to undo the writing-off or to reopen a deposit account is available via API 2.0 as well. For more information, see our [API Reference](/api/api-v2/deposits/reopen). ::: --- # Compound Interest with Daily Rest URL: https://docs.mambu.com/docs/compound-interest-with-daily-rest/ In the UK banking environment, *compound interest with daily rest* is a prevalent method for calculating interest on various financial products, particularly mortgages and loans. This method ensures that interest is precisely accounted for based on the daily fluctuations of the outstanding balance. ## Component definitions * **Compound interest**: This refers to the calculation of interest not only on the initial principal amount but also on the accumulated interest from previous periods. Unlike simple interest, which is calculated only on the original principal, compound interest allows for interest to *compound*, or grow on itself. * **Daily rest (or daily compounding)**: This is the frequency at which accrued interest is added to your principal balance. With *daily rest*, interest is calculated each day based on the closing balance of the previous day. This balance already includes any interest that accrued and was added from that prior day's calculation. This continuous, daily addition means that the balance, which forms the basis for the current day's interest calculation, is constantly changing, leading to an exponential growth effect on your overall interest. ## Exponential calculation of interest The exponential nature of compound interest with daily rest arises because the balance on which interest is charged is updated every day. The following formulas are used to calculate interest: * **Daily interest rate**: The annual nominal interest rate is converted into a daily rate based on the actual number of days in the year . Daily IR = Annual Interest Rate/Number of Days in Year * **Daily interest accrual**: Each day, interest is calculated on the current outstanding balance. * *Daily accrued interest = Current Opening Balance * Daily IR* * *Closing balance for today = Opening balance + Interest accrued* * *Closing balance for today = Opening balance used in interest computation from tomorrow* * **Compounding effect over a period**: To determine the total amount after a specific number of days, the formula demonstrates its exponential growth: * *Opening balance * ((1+Daily IR)^(Number of days in interval)-1)* * This formula effectively shows how interest is earned on previously accrued interest over the specified period. ## Implications for Payment (PMT) calculation While interest is compounded daily, loan payments (PMT) in UK banking are typically scheduled monthly. The PMT calculation for a loan with daily rest compounding accurately factors in this daily accrual. * **PMT recalculation**: For loans with a fixed repayment schedule (e.g., [Declining Balance Equal Instalment ](/docs/payment-methods-for-dbei-loans)loans), the monthly PMT is calculated to ensure the loan is repaid over its term, accounting for the daily compounding. The interest component of each PMT will specifically reflect the actual interest accrued over the exact number of days in that month's payment period. * *PMT=PMT(Daily IR ,No of installments/12 * Days in year ,-Loan amount) * Days in year / 12* The following document shows some of the calculations for compound interest: --- # Configuration as Code Overview URL: https://docs.mambu.com/docs/configuration-as-code-1/ You can batch configure Mambu elements - such as organization details, custom field definitions, holidays, branches, user roles, and more - using *Configuration as Code* (CasC). This allows you to get or set multiple configuration settings for a supported element with a single API call per tenant. CasC allows you to quickly configure new instances, standardize and migrate configuration between tenants, and duplicate configuration settings for multiple sandboxes. This page offers a general introduction to CasC. For more information on using CasC for specific elements, see the CasC documentation for the specific elements you wish to configure. For more information about the YAML specification, see [YAML data serialization language](https://yaml.org/spec/1.2/spec.html) :::warning We recommend updating configuration with the API outside of working hours to avoid possible issues in the system. Do not change configuration for the same entity from the UI and via the API at the same time. ::: ## Basic operation CasC endpoints are part of the Mambu v2 REST API. For general information on how to use the API, see our [API Reference](https://api.mambu.com). Each CasC endpoint ends in the element name and `.yaml`, such as `/configuration/holidays.yaml` for the holiday endpoint. Note that if you use configuration files to construct your request, the file can have any name. Most CasC endpoints support two operations: * `GET`: Retrieves current configuration. * `PUT`: Overwrites the existing configuration with a new configuration. :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted, in most cases. Any exceptions will be noted in the CasC documentation for the specific endpoint. ::: We do not support `PATCH` updates to existing configuration. If you want to change an existing configuration, we recommend getting the existing configuration with a `GET`, modifying the returned YAML as you wish, and writing it back to the API with a `PUT` request. ### Authentication There are two ways to authenticate CasC requests: * An **API key** generated by an API consumer. For more information, see [API Consumers](/docs/api-consumers). * **Basic authentication** using a username and password. The API consumer or the user account has to have the **View Manage Configuration As Code** (`GET_MANAGE_CONFIGURATION_AS_CODE`) and **Update Manage Configuration As Code** (`PUT_MANAGE_CONFIGURATION_AS_CODE`) permissions to make `GET` or `PUT` requests to the CasC endpoints. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API Reference. ### Headers The following headers are required by most CasC endpoints. Any exceptions will be noted in the CasC documentation for the specific endpoint. #### GET request headers | Header | Value | | --- | --- | | `Accept` | `application/vnd.mambu.v2+yaml` | #### PUT request headers | Header | Value | | --- | --- | | `Accept` | `application/vnd.mambu.v2+yaml` | | `Content-Type` | `application/yaml` | ### Parameters Some fo the CasC endpoints also offer optional parameters. Any available parameters will be noted in the CasC documentation for the specific endpoint. ### Configuration format For the specific configuration format required by each CasC endpoint, see the "Configuration body example" section of the CasC documentation for the specific endpoint. ## Availability Not all elements support Configuration as Code. To view which elements are supported with this feature, see the list of individual articles for each CasC endpoint. --- # Accounting Rules Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-accounting-rules/ Accounting rules allows you to create general rules for your accounts such as setting automatic accounting closures that recur on a regular basis and defining rules for how to handle any transactions that affect General Ledger (GL) balances in two different branches. For more information about these types of rules, see [inter-branch transfer rules](/docs/inter-branch-transfer-gl-account). With *Configuration as Code* (CasC), you may batch configure your accounting rules configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for accounting rules supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/accountingrules.yaml` | Get current accounting rules configuration. | | `PUT` | `/configuration/accountingrules.yaml` | Write a new accounting rules configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/accountingrules.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/accountingrules.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @accountingrules.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@accountingrules.yaml” represents the absolute path of the file on your device. (Use “--data-raw” if you want to specify the YAML body inline). ### Configuration body example ```yaml --- defaultGlCode: "defaultGlAccountCode" automatedAccountingClosuresInterval: 7 customRules: - id: "ruleId1" leftBranchId: "branchId1" rightBranchId: "branchId2" glCode: "glCode1" - id: "ruleId2" leftBranchId: "branchId3" rightBranchId: "branchId1" glCode: "glCode2" ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `defaultGlCode` | String | Default GL account code. | ✔ | | `automatedAccountingClosuresInterval` | Number | Number of days between the execution of automated accounting closures. If this number is zero, no automated closure is performed. | ✔ | | `customRules` | List | Custom rules in which new accounting rules can be added between branches. | ✘ | | `id` | String | User-defined unique ID. Rules are ordered by ID in the YAML file. | ✔ | | `rightBranchId` | String | ID of the right branch of the rule. | ✔ | | `leftBranchId` | String | ID of the left branch of the rule. | ✔ | | `glCode` | String | The unique identifier of the account that is mapped to the financial resource. | ✔ | ## Replies from "@site/src/components/snippets/ConfigurationAsCodeStatusCodeWarningSnippet"; ## Validations With all use cases, a validation of the uploaded file will be done, ensuring the following: * Syntax is correct as per YAML standards and the template for holidays. * Minimum requirements indicates the line with the syntax error. * Content is correct. | Name | Validation | | --- | --- | | `defaultGlCode` | Can be null. If it is not null, it must be for an existing GL account that is in the organization's base currency. | | `automatedAccountingClosuresInterval` | Must be a non-negative whole number. Can be null or empty, in which case it will be considered zero. | | `id` | **Required**, must not exceed 32 characters in length, must be unique in the configuration. | | `leftBranchId` | Must be the ID of an existing branch, can’t be the same as `rightBranchId`. If empty, the rule will apply for “All Branches“, if that is a valid case in the configuration. | | `rightBranchId` | Must be the ID of an existing branch, can’t be same as `leftBranchId`. If empty, the rule will apply for “All Branches“ if that is a valid case in the configuration. | | `glCode` | Must be the GL Code of an existing GL account. | --- # Authorization Holds Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-authorization-holds/ Authorization Hold (also Card Authorization or Pre-authorization) is the practice of authorizing electronic transactions processed with a debit or a credit card and holding this balance as unavailable for the card-holder until either the merchant clears the transaction (settlement) or cancels it. By default, authorization holds will expire after a period of seven days, although this can be changed to reflect your organizations’s policies. You can also set different expiry periods for specific Merchant Categories, in which case this period will be used for holds requested for that specific Merchant Category code. For more information, see [Authorization Holds](/docs/authorization-holds#authorization-holds-configuration). With *Configuration as Code* (CasC), you may batch configure your authorization holds configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). :::warning We strongly recommend that you use an end-to-end test to test any configuration changes in your sandbox environment before implementing them in your production environment. The end-to-end test should check that the hourly `AUTHORIZATION_HOLDS_EXPIRATION` cron job expires the correct authorization holds. For more information, see [Hourly authorization holds cron job](/docs/card-payments-and-authorization-holds#hourly-authorization-holds-cron-job). If, to perform your end-to-end test you have to set holds in the past, then please contact us through [Mambu Support](/docs/mambu-support) so that we can assist you with manipulating the data directly in the database. ::: ## API Operations CasC for authorization holds supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/authorizationholds.yaml` | Get current authorization holds configuration. | | `PUT` | `/configuration/authorizationholds.yaml` | Write a new authorization holds configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/authorizationholds.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/authorizationholds.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @authorizationholds.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@authorizationholds.yaml` represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml --- defaultAuthorizationHold: daysToExpiration: 1 authorizationHolds: - mcc: 12171 daysToExpiration: 3 description: "12171 authorization hold" - mcc: 12176 daysToExpiration: 3 description: "12176 authorization hold" - mcc: 12179 daysToExpiration: 2 description: "" ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `defaultAuthorizationHold` | Authorization Hold Configuration | The authorization holds | ✔ | | `defaultAuthorizationHold.`
    `daysToExpiration` | Number | The number of days until expiration for the default authorization hold. | ✔ | | `authorizationHolds` | Authorization Hold Configuration | None | ✔ | | `authorizationHolds.mcc` | Number | The merchant category code of the authorization hold. | ✔ | | `authorizationHolds.`
    `daysToExpiration` | Number | The number of days until expiration for the authorization hold. | ✔ | | `authorizationHolds.description` | String | The description of the authorization hold. | ✘ | ## Replies from "@site/src/components/snippets/ConfigurationAsCodeStatusCodeWarningSnippet"; ## Validations | Name | Validations | | --- | --- | | `defaultAuthorizationHold.`
    `daysToExpiration` | The value must be between 1 and 36,525 days. | | `authorizationHolds.mcc` | The value must be unique. | | `authorizationHolds.`
    `daysToExpiration` | The value must be between 1 and 36,525 days. | | `authorizationHolds.description` | The description must not exceed 256 characters. | --- # Branches Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-branches/ A *branch* in Mambu is the default label for an organization's subdivision. Often branches represent: * A geographical subdivision of an organization. * A product line. * Any other entity that represents a subdivision of an organization. The terminology *branch* is the default label used for a subdivision. You can choose to change this label. For more information about changing this label, see [Labels](/docs/labels). For more information about managing your organization's branches, see [Branches and Centres](/docs/branches-and-centres). For the rest of this article we will refer to an organization's subdivision as *branch*. With *Configuration as Code* (CasC), you may batch configure your branches configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API operations CasC for branches supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/branches.yaml` | Get current branches configuration. | | `PUT` | `/configuration/branches.yaml` | Write a new branches configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/branches.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/branches.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @branches.yaml ``` `@branches.yaml` represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### Configuration example ```yaml branches: - id: "2" name: "Matola City" state: "ACTIVE" phoneNumber: "+7534987676" emailAddress: "matola@BofAlg.es" notes: "Is currently under construction to add an extra room that can be used for\ \ the meetings.

    Have six new computers for their staff." address: line1: "1 Bank Street" line2: "Old Town" city: "Matola City" region: "Matola" postcode: "10775" country: "Bankistan" holidays: - id: 13 name: "joe matola only day" dayOfMonth: 26 monthOfYear: 8 year: 2020 isAnnuallyRecurring: true - id: "demoBranchId" name: "Maputo Downtown" state: "ACTIVE" phoneNumber: "0049302345678" emailAddress: "petula.clark@downtown.com" notes: "Is located in the surroundings of the local market with a lot of potential\ \ to reach new clients." holidays: - id: 12 name: "only maputo holiday day" dayOfMonth: 30 monthOfYear: 7 year: 2020 isAnnuallyRecurring: true customFieldValueSets: - id: "_branches_grouped_cf_set" groupedCustomFieldValues: - index: 0 customFieldValues: - customFieldId: "cf_group_field_1" value: "group field 1" - customFieldId: "cf_group_field_2" value: "2" - index: 1 customFieldValues: - customFieldId: "cf_group_field_2" value: "500" - id: "_example_branch_custom_field_set" standardCustomFieldValues: - customFieldId: "cf_branch" value: "TRUE" ``` ### General attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | ID for the branch. | Yes | | `name` | String | Name of the branch. | Yes | | `state` | String | `ACTIVE` or `INACTIVE` | Yes | | `phoneNumber` | String | Phone number associated with the branch. | No | | `emailAddress` | String | Email address associated with the branch. | No | | `notes` | String | Notes for the branch. | No | | `address` | Address | Address associated with the branch. For a list of fields, see [Dependencies](#dependencies). | No | | `holidays` | Array | List of holidays associated with the branch. For a list of fields, see [Dependencies](#dependencies). | No | | `customFieldValueSets` | | List of custom field value sets and associated custom field values. For a list of fields, see [Dependencies](#dependencies). | No | ### Dependencies The CasC for branches configuration has three dependencies: `address`, `holidays`, and `customFieldValueSets`. #### address Every branch has one address associated to it with the following fields: | Name | Type | Description | Required | | --- | --- | --- | --- | | `line1` | String | First line of address. | No | | `line2` | String | Second line of address. | No | | `city` | String | City of address. | No | | `region` | String | Region of address. | No | | `postcode` | String | Postcode for address. | No | | `country` | String | Country of address. | No | #### `holidays` Every branch has a list of holidays associated to it. Each holiday has the following fields: | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | Number | ID of holiday. | Yes | | `name` | String | Name of holiday. | Yes | | `dayOfMonth` | Number | Day in the month of holiday. | Yes | | `monthOfYear` | Number | Month in the year of holiday. | Yes | | `year` | Number | The year of the holiday. | Yes | | `isAnnualRecurring` | Boolean | Whether the holiday recurs every year. | Yes | #### `customFieldValueSets` Every branch can have a list of custom field value sets with their associated custom field values. Custom field sets can either be `GROUPED` or `SINGLE`. The grouped custom field sets field is represented by an array of array of custom field values. The single custom field set field is represented by an array of custom field values. | Name | Type | Description | Required | | --- | --- | --- | --- | | `customFieldValueSets` | Array | A list of custom field sets and associated custom field values related to the branch. | No | | `id` | String | ID for grouped custom field set. | Yes | | `groupedCustomFieldValues` | array | List of groups of custom field definition IDs and custom field values associated to grouped custom field set. | No | | `index` | Number | Index of group of custom field definition IDs and custom field values in grouped custom field set. | Yes | | `customFieldValues` | Array | List of custom field definition IDs and custom field values in grouped custom field set. | Yes | | `customFieldId` | String | ID of a custom field definition in a grouped custom field value set. | Yes | | `value` | String | Custom field value in a grouped custom field set. | Yes | | `id` | String | ID for a single custom field set. | Yes | | `standardCustomFieldValues` | Array | List of custom field definition IDs and custom field values in single custom field set. | No | | `customFieldId` | String | ID for custom field definition in single custom field set. | Yes | | `value` | String | Custom field value in single custom field set. | Yes | ## Replies ## Validations The Mambu API runs validation to ensure the following: * Content is correct. * References are properly mapped and exist in the target system. * Branches properties are accurate. | Name | Input requirement | | --- | --- | | `id` | The ID length must not exceed 32 characters and the ID must be unique. | | `name` | The name length must not exceed 256 characters. | | `emailAddress` | The email address must be valid. A valid email address consists of an email prefix before the @ sign and an email domain after the sign. The email prefix must not exceed 64 characters. The email domain must not exceed 63 characters. The email address in total must not exceed 256 characters. | | `phoneNumber` | The phone number length must not exceed 256 characters. | | `address` | None of the address fields can exceed 256 characters. | For information on validation for the holidays fields, see [Holidays Configuration](/docs/configuration-as-code-for-holidays). ## Warnings There are three warning messages you can receive when you attempt to update the CasC for branches configuration file. 1. You cannot deactivate (disable) a branch that has active centres assigned to it. If you do not include a branch that has active centres assigned to it in the YAML file then you will get the following warning message: "Branch [ id - `BRANCH_ID`] could not be deactivated since it has active centre(s)." 2. If a branch does not have any active centres assigned to it and you do not include it in the YAML file then the branch will be deactivated (disabled). You will receive the following warning message: "Branch [ id - `BRANCH_ID`] has been deactivated." 3. If you try to deactivate a branch which is already deactivated then you will receive the following warning message: "Branch [ id - `BRANCH_ID`] could not be deactivated since it is already deactivated." --- # Centres Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-centres/ A *centre* is the default label for a subdivision of a *branch*, which is the default label for an organization subdivision. A centre can be considered a sub-branch. Each branch can have multiple centres assigned to it. If you wish, you may change the *centre* label. For more information, see [Labels](/docs/labels). For more information about managing your organization’s centres, see [Branches and Centres](/docs/branches-and-centres). For the rest of this article we will use the terminology *centre*. With *Configuration as Code* (CasC), you may batch configure your centre configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The scope of CasC for centres is limited to centres with references towards the linked objects. However, the configuration of linked objects will not be included, and they must be reconfigured separately. ## Dependencies The centres configuration has two direct dependencies: * The branch to which the centre is assigned. * The custom field definitions for which you can enter custom field values. Based on the custom field definition type, there may be several addition indirect dependencies, such as clients, groups, and users. ## API operations CasC for centres supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/centres.yaml` | Get current centres configuration. | | `PUT` | `/configuration/centres.yaml` | Write a new centres configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new configuration will be deleted. `PATCH` requests are not supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/centres.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/centres.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @centres.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@centres.yaml` represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the configuration inline. ### Example configuration ```yaml centres: - id: "DT1" name: "Down Town" assignedBranchId: "B1" state: "ACTIVE" meetingDay: "FRIDAY" notes: "All clients and officers gather in the market" address: line1: "line1" line2: "line2" city: "City" region: "Region" postcode: "789456" country: "Country" - id: "MP1" name: "Market Place" assignedBranchId: "B1" state: "ACTIVE" meetingDay: "FRIDAY" notes: "All clients and officers gather in the market" address: line1: "line1" line2: "line2" city: "City" region: "Region" postcode: "789456" country: "Country" customFieldValueSets: - id: "_grouped_set_id" groupedCustomFieldValues: - index: 1 customFieldValues: - customFieldId: "_cf_id_1" value: "value_group_1_1" - customFieldId: "_cf_id_2" value: "value_group_1_2" - customFieldId: "_cf_id_3" value: "value_group_1_3" - index: 2 customFieldValues: - customFieldId: "_cf_id_1a" value: "value_group_2_1a" - customFieldId: "_cf_id_2a" value: "value_group_2_2a" - customFieldId: "_cf_id_3a" value: "value_group_2_3a" - customFieldId: "_cf_id_3b" value: "client_id" - id: "_non_grouped_set_id" standardCustomFieldValues: - customFieldId: "_cf_non_grouped_1" value: "value_non_grouped_1" - customFieldId: "_cf_non_grouped_2" value: "value_non_grouped_2" - customFieldId: "_cf_non_grouped_3" value: "value_non_grouped_3" ``` ### General attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | The unique identifier of the centre configuration. | YES | | `name` | String | The name of the centre configuration. | YES | | `assignedBranchId` | String | The ID of the branch this centre was assigned to. | NO | | `state` | String | The state of the centre. Can be `ACTIVE` or `INACTIVE`. | YES | | `meetingDay` | String | The day of the week the centre meeting day will be set. | NO | | `notes` | String | Notes about the centre. | NO | | `address` | Address | The address of the centre. For a list of fields, see [address](#address). | NO | | `customFieldsValueSets` | Custom Field Value Set | Contains a list of custom field value configuration sets. For a list of fields for each set, see [customFieldsValueSets](#customfieldsvaluesets). | NO | ### `address` Every centre has one address associated to it with the following fields: | Name | Type | Description | Required | | --- | --- | --- | --- | | `line1` | String | First line of address. | NO | | `line2` | String | Second line of address. | NO | | `city` | String | City of address. | NO | | `region` | String | Region of address. | NO | | `postcode` | String | Postcode for address. | NO | | `country` | String | Country of address. | NO | ### `customFieldsValueSets` Every centre can have a list of custom field sets with their associated custom field values. Custom field sets can either be `GROUPED` or `SINGLE`. The grouped custom field sets field is represented by an array of array of values. The single custom field sets field is represented by an array of values. | Name | Type | Description | Required | | --- | --- | --- | --- | | `customFieldValueSets` | Array | A list of custom field sets and associated custom field values related to the branch. | NO | | `id` | String | ID for grouped custom field set. | YES | | `groupedCustomFieldValues` | array | List of groups of custom field definition IDs and custom field values associated to grouped custom field set. | NO | | `index` | Number | Index of group of custom field definition IDs and custom field values in grouped custom field set. | YES | | `customFieldValues` | Array | List of custom field definition IDs and custom field values in grouped custom field set. | YES | | `customFieldId` | String | ID of a custom field definition in a grouped custom field value set. | YES | | `value` | String | Custom field value in a grouped custom field set. | YES | | `id` | String | ID for a single custom field set. | YES | | `standardCustomFieldValues` | Array | List of custom field definition IDs and custom field values in single custom field set. | NO | | `customFieldId` | String | ID for custom field definition in single custom field set. | YES | | `value` | String | Custom field value in single custom field set. | YES | ## Replies ## Validations The Mambu API runs validation to verify the configuration request conforms to YAML syntax and the template for custom field definitions: * References must be properly mapped and exist in the target system. * Custom field definitions and custom field values must be accurate, including dependent custom field definitions. Minimum requirements show the line with the syntax error. Configuration values may be provided in any order. ### Basic fields validations | Name | Validation | | --- | --- | | `id` | The ID must not be blank and must be unique in the entire centres configuration. The length must not exceed 32 characters. | | `name` | The name must not be blank or exceed 256 characters in length. | | `assignedBranchId` | The branch with the given ID must exist and also be active. | | `state` | Must not be null. | | `meetingDay` | must not be null and also must not be one of the non-working days of the organization. | | `address` | The address field values must not exceed 256 characters in length. | ### Custom field sets and custom field definition validations | Name | Validation | | --- | --- | | `id` | The custom field set with the given ID must exist, the ID must not be empty, must not exceed 256 characters in length, and must be unique in the configuration. | | `standardCustomFieldValues` | The list of standard custom field values must not be empty. | | `customFieldId` | The ID must be unique in the standard custom field set. | | `value` | The validation depends on the custom field definition type. See [Custom field value validation](#custom-field-value-validation) for more details. | ### Custom field value validation The validations for the custom field values are based on the custom field definition type: | Type | Validation | | --- | --- | | Number | The value must be a valid number. | | Checkbox | The value must be a boolean. | | Date | The value must be a valid date in the format DD-MM-YYYY. | | Selection | The value must be a valid selection ID. | | Client Link | The value must be a valid client ID. | | Group Link | The value must be a valid group ID. | | User Link | The value must be a valid user ID. | ## Warnings Existing centres that are not included in configuration updates are deleted, unless the centre is assigned to a client or it has documents attached, in which case it cannot be deleted. Instead, it will be deactivated. When this occurs, the API returns a list of warning messages letting the user know which centres have been deleted and which centres were deactivated instead. If you successfully delete a centre, you will receive the following warning message: "Centre [ id = `CENTRE_ID`] has been deleted." If you try to delete a centre that is assigned to a client or that has documents attached, you will receive the following warning message: "Centre [id = `CENTRE_ID`] could not be deleted and was deactivated." --- # Client and Group Roles Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-client-and-group-roles/ A *client* models any customer that is just an individual. A *group* models any customer that is not an individual. You can specify particular *client roles* and *group roles*, which are also referred to as *client types* and *group types*. For more information, see [Clients and Groups Overview](/docs/clients-and-groups-overview). With *Configuration as Code* (CasC), you may batch configure your client and group role configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). :::note Although the path for this API is `/configuration/clientroles.yaml`, it is used for both client roles and group roles. ::: :::warning Do not confuse group roles in this article with the group roles names that can be assigned to members of a group, found in the Mambu UI under **Administration** > **General Setup** > **Group Roles**. ::: ## API Operations CasC for client roles and group roles supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/clientroles.yaml` | Get current client roles and group roles configuration. | | `PUT` | `/configuration/clientroles.yaml` | Write a new client roles and group roles configuration to Mambu. | ### Parameters To retrieve only client roles or only group roles when making a `GET` request, you may provide the `type` parameter with the value `CLIENT` or `GROUP`. The `type` parameter is not supported for `PUT` requests. The API determines whether updates affect clients or groups automatically, based on the contents of the `rolesConfiguration` in the configuration. Note that this has implications for how roles are deleted - for more information, see [Deleting client or group roles](#deleting-client-or-group-roles) below. ## Managing configuration files You may manage YAML configuration files in two ways: either include client roles and group roles in a single file, or store them separately in two files, one for group roles and one for client roles. ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/clientroles.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/clientroles.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @clientroles.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@clientroles.yaml` represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml rolesConfiguration: - type: "CLIENT" defaultRole: id: "default_role_id" name: "default_role_name" canOpenAccounts: true canGuarantee: true requireIdentificationDocuments: false useDefaultAddress: true roles: - id: "id_1" name: "Name_1" description: "Desc 1" idPattern: "@" canOpenAccounts: false canGuarantee: false requireIdentificationDocuments: false useDefaultAddress: false - type: "GROUP" defaultRole: id: "default_group_role_id" name: "default_group_role_name" canOpenAccounts: true canGuarantee: true useDefaultAddress: true roles: - id: "id_2" name: "Name_2" description: "Desc 2" idPattern: "##" canOpenAccounts: false canGuarantee: true useDefaultAddress: true - id: "id_3" name: "Name_3" description: "Desc 3" idPattern: "@#" canOpenAccounts: true canGuarantee: true useDefaultAddress: false ``` ### `rolesConfiguration` attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `rolesConfiguration` | List | List of all roles for available account holder types.| ✔ | | `type` | String | Defines the role type, it can either be `CLIENT` or `GROUP`. | ✔ | | `defaultRole` | List |The default role for the given type.|✔ | | `roles` | List |A list of roles for the given type, except the default role.| ✘ | ### `roles` attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | The ID used to identify an existing role in the system. If the ID doesn't match an existing role, a new role will be created.| ✔ | | `name` | String | The name of the client or group role. | ✔ | | `description`| String | The description for the role | ✘ | | `idPattern` | String | The ID pattern for the client or group role. | ✘ | `canOpenAccounts` | Boolean | Indicates whether new accounts for this client type can be created. | ✘ | `canGuarantee` | Boolean | Indicates whether the clients under this type can be used as guarantors. | ✘ | `useDefaultAddress` | Boolean | Indicates whether the default address section will be available. | ✘ | `requireIdentificationDocuments` | Boolean | Indicates whether identification documents must be provided for the client to be created. Does not apply for groups. | ✘ ### Deleting client or group roles When updating client or group roles, any existing client or group role that you do not include in the new configuration will be deleted. Note that you may not delete any client or group role that is currently in use. Because this endpoint is used to configure both client and group roles, if you entirely omit either role type, then the type you leave out will not be affected. That is, you may update only client roles or only group roles configuration without deleting the other type. For example, if you update `rolesConfiguration` with the type `CLIENT` only, then any existing client roles not included in the new configuration will be deleted, but your group roles will not be affected, and no group roles will be deleted. ## Replies from "@site/src/components/snippets/ConfigurationAsCodeStatusCodeWarningSnippet"; ## Validations ### `rolesConfiguration` | Name | Validation | | --- | --- | | `rolesConfiguration` |Doesn't accept empty or null elements in the list.| | `type` | It can appear only once in the file, all the roles for either `CLIENT` or `GROUP` must be defined under the respective configuration.| | `defaultRole` | The ID can not be changed.| | `roles` | Doesn't accept empty or null elements in the list. It can be empty if there are no roles except for the default role. | ### `roles` | Name | Description | | --- | --- | | `id` | It is unique per role type. Maximum of 32 characters. | | `name` | It is unique per role. Maximum of 255 characters.| | `description`| Maximum of 256 characters. | | `idPattern` | It can contain only alphanumeric characters, '#' numbers, '@' for letters or '$' for letters or numbers. Maximum of 32 characters. | | `requireIdentificationDocuments` | It can only be defined for roles with `type` CLIENT. | ## Warnings If you make an API call and we detect something we need to warn you about then you will receive a list of warnings with a descriptive message for each. For example, if you attempt to delete a client role that is in use then you will receive the error message `ClientRole [CLIENT, id_0] could not be deleted: Client role in use`. --- # Currencies Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-currencies/ Currencies are used to configure the currency type associated with monetary values in Mambu. For more information, see [Currencies](/docs/currencies). With *Configuration as Code* (CasC), you may batch configure your currencies configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). :::warning The CasC for currencies feature currently supports fiat currencies only. If you have access to cryptocurrencies or non-traditional currencies, they are not currently supported by CasC. For more information about crypotcurrencies and non-traditional currencies, see [Currencies](/docs/currencies). ::: ## API Operations CasC for currencies supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/currencies.yaml` | Get current currencies configuration. | | `PUT` | `/configuration/currencies.yaml` | Write a new currencies configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration You can get your current currencies configuration either for all time periods, from a specified start date. ### Retrieving all rates for all time periods ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/currencies.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic \' ``` `\` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### Retrieving rates for specified time periods To retrieve rates from a specific start date, use the `startDate` parameter in the `YYY-MM-DD` format. The midnight value of the configuration start date is determined by your organization's timezone. ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/currencies.yaml?startDate=2019-01-02' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic \' ``` `\` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. #### Sample response The following example shows a reply for a query with a start date value of the 2nd of January, 2019. ```yaml --- startDate: "2019-01-02" baseCurrency: code: "USD" name : "US Dollars" symbol: "`" symbolPosition: "BEFORE_NUMBER" digitsAfterDecimal: 2 type: "FIAT_CURRENCY" foreignCurrencies: - currency: code: "EUR" name: "Euro" symbol: "€" symbolPosition: "AFTER_NUMBER" digitsAfterDecimal: 2 type: "FIAT_CURRENCY" accountingRates: - startDate: "2018-01-02T00:00+11:00" rate: 100 - startDate: "2020-01-02T00:00+11:00" rate: 100 exchangeRates: - startDate: "2018-01-02T00:00+11:00" buyRate: 100 sellRate: 110 - startDate: "2020-01-02T00:00+11:00" buyRate: 200 sellRate: 210 ``` Note that in this example the returned accounting and exchange rates have a start date of the 2nd of January, 2018, and that this date falls **before** our specified query start date of the 2nd of January, 2019, as shown in the first line. This is because the returned values for accounting and exchange rates begin with the value that was **in effect** at the time of the query `startDate`. That value is reported along with its start date, which is the date the rate was added to Mambu. See the timeline below for an illustration. ![Timeline showing start date is before start date specified in parameter.](@site/static/img/support/casc_currencies_2.png) If you specify a query `startDate` value that lies **before** the start date of a foreign currency exchange or accounting rate - that is, before the currency was added to Mambu - you will receive a reply that begins with the earliest exchange or accounting rate that was entered into Mambu along with its start date. That date will be **after** the specified query `startDate`. See the timeline below for an illustration: ![Timeline showing start date is after start date specified in parameter.](@site/static/img/support/casc_currencies_3.png) ## PUT configuration ```bash curl -X PUT 'https://tenanturl.mambu.com/api/configuration/currencies.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic \' \ --data-binary @currencies.yaml ``` “@currencies.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml startDate: "2019-01-02" baseCurrency: code: "USD" name : "US Dollars" symbol: "" symbolPosition: "BEFORE_NUMBER" digitsAfterDecimal: 2 type: "FIAT_CURRENCY" foreignCurrencies: - currency: code: "EUR" name: "Euro" symbol: "€" symbolPosition: "AFTER_NUMBER" digitsAfterDecimal: 2 type: "FIAT_CURRENCY" accountingRates: - startDate: "2019-01-02T00:00+11:00" rate: 100 - startDate: "2019-01-05T00:00+11:00" rate: 100 exchangeRates: - startDate: "2019-01-02T00:00+11:00" buyRate: 100 sellRate: 110 - startDate: "2020-06-29T00:00+10:00" buyRate: 200 sellRate: 210 ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `startDate` | String | Date starting from which the configuration is applied and/or retrieved, based on the organization timezone. Can be null if all the data is retrieved or updated. |✘ | | `baseCurrency` | Currency configuration | Model representing the currency configuration. |✔ | | `foreignCurrencies` | Foreign Currency Configuration | List of all foreign currencies. Can be empty. Ordered by currency code, ascending. |✘ | #### Base currency attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `code` | String | The unique currency code. |✔ | | `name` | String | The currency name. |✔ | | `symbol` | String | The currency symbol. |✔ | | `symbolPosition` | String | The position of the currency symbol. The options are `BEFORE_NUMBER` and `AFTER_NUMBER`.|✔ | | `digitsAfterDecimal` | String | Number of digits that are supported for given currency.|✔ | | `type` | String | The type of currencies. Only `FIAT_CURRENCY` is currenlty supported. |✔ | #### Foreign currency attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `currency` | Currency configuration | Model representing the currency configuration. | ✔ | | `currency.code` | String | The unique currency code. | ✔ | | `currency.name` | String | The currency name.| ✔ | | `currency.symbol` | String |The currency symbol.| ✔| | `currency.symbolPosition` | String | The position of the currency symbol.| ✔| | `currency.digitsAfterDecimal` | String | Number of digits that are supported for given currency.|✔ | | `currency.type` | String | The type of currencies. Only `FIAT_CURRENCY` is currenlty supported. |✔ | | `accountingRates` | Accounting Rate Configuration | The accounting rate for the current currency and base currency. Ordered by start date, ascending.| Required only if **Accounting in Multicurrency** is enabled, not required otherwise.| | `accountingRates.startDate` | String | The accounting rate will apply starting with this date. | ✔ | | `accountingRates.rate` | Number | The accounting rate. | ✔ | | `exchangeRates` | Exchange rate configuration | The exchange rate for the current currency and base currency. Ordered by start date, ascending. | ✔ | | `exchangeRates.startDate` | String | The exchange rate applies starting with this date. | ✔ | | `exchangeRates.buyRate` | Number | The buy exchange rate.| ✔ | | `exchangeRates.sellRate` | Number | The sell exchange rate. | ✔ | ## Replies ## Validations | Name | Validation | | --- | --- | | `name` | Must have a maximum length of 256 characters. | | `symbol` | Must have a maximum length of 10 characters. | | `code` | The code can not be changed at update. It has the initial value set when the tenant was first created or provisioned. | | `accountingRates` | List cannot be empty if **Accounting in Multicurrency** is enabled. Existing accounting rates can not be edited or removed, they must be left as they were retrieved. Only new rates can be added. | | `accountingRates.startDate` | It must be greater than the previous rate start date. If it’s the first rate, it’s start date is compared with the configuration start date. | | `accountingRates.rate` | Must be between 0 and 2000000000000000 | | `exchangeRates` | List cannot be empty. Existing accounting rates can not be edited or removed, they must be left as they were retrieved. Only new rates can be added. | | `exchangeRates.startDate` | It must be greater than the previous rate start date. If it’s the first rate, it’s start date is compared with the configuration start date. | | `exchangeRates.buyRate` | It must be between 0 and 2000000000000000 | | `exchangeRates.sellRate` | It must be between 0 and 2000000000000000. It must be greater than the buy rate. | ## Warnings You will receive a list of warnings if you try to delete a foreign currency which is in use because those cannot be deleted. You will also receive warnings if a foreign currency does not have an accounting rate specified or an exchange rate specified. :::note Unlike the Mambu UI, you cannot omit the exchange rate or accounting rate when adding or editing a currency when making API requests. ::: --- # Custom Fields Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-custom-fields/ *Custom fields* are additional fields you can create in order to capture any additional information required for your business processes. Every custom field must be a part of a *custom field set*. A custom field consists of the custom field definition and the custom field value. The *custom field definition* is the custom field you create using either the Mambu UI or API which contains information such as its name, ID, type, and usage settings. The *custom field value* is the actual value that a custom field attached to an entity holds. For more information, see [Custom Fields](/docs/custom-fields). With *Configuration as Code* (CasC), you may batch configure your configuration containing custom field definitions via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for custom fields supports three operations. | Action | Endpoint | Description | | --- | --- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `GET` | `/configuration/customfields.yaml` | Get current configuration of custom field definitions. | | `PUT` | `/configuration/customfields.yaml` | Write a new configuration for your custom field definitions to Mambu. | | `GET` | `/configuration/customfields/template.yaml` | Get your custom field definition template in YAML. This is useful when configuring from scratch. | ## Requests For general information on CasC requests such as authentication and general headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### Additional headers You may send synchronous or asynchronous `PUT` requests. To use the endpoint asynchronously, you must provide two additional headers: * `X-Mambu-Async` with a value of `true`. * `X-Mambu-Callback` with the callback URL. You may wish to make asynchronous calls for unusually large requests, such as requests that include more than 300 custom field definitions. Note that we generally do not recommend making individual requests of that size, as a response may take 60 seconds or more. The expected status code in case of a successful asynchronous request is `202 Accepted`. When the update configuration operation is completed, a message will be posted to the provided URL with information about whether the updated request completed successfully or not. ## GET requests ### Get custom field sets and custom field definitions for all entities ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/customfields.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### Get custom field sets and custom field definitions for specified entities To get custom field sets and custom field definitions for specific entities, specify the desired entities using the `availableFor` query parameter. You may specify more than one entity. For a list of available values to pass to this parameter, see the relevant table in the [Custom Fields Configuration](/api/api-v2/configuration_customfields/get) endpoint in our API v2 Reference. The following example returns all clients and groups: ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/customfields.yaml?availableFor=CLIENT&availableFor=GROUP' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### Get your custom field definition template ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/customfields/template.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT requests ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/customfields.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @customfields.yaml ``` “@customfields.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. :::note When custom field sets or custom field definitions are not present in the YAML file, they are deactivated, they are not deleted. However when selections, usages, view, and edit rights of custom field definitions are not present in the YAML file, they are deleted. ::: ### Custom field set and custom field definition example The following example shows a complete request for a custom field set and custom field definition of the free text type. ```yaml customFieldSets: - id: "_set_id" name: "set name" description: "set description" type: "SINGLE" availableFor: "CLIENT" customFields: - id: "field_id" type: "FREE_TEXT" state: "ACTIVE" validationRules: unique: false validationPattern: "##@@" displaySettings: displayName: "field name" description: "field description" fieldSize: "SHORT" usage: - id: "client" required: false default: false viewRights: roles: [] allUsers: true editRights: roles: - role_id allUsers: false ``` ### Custom field set attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | User-defined ID, globally unique | YES | | `name` | String | User-defined name of the custom field set, unique for each set type. | YES | | `description` | String | User-defined description of the custom field set. | NO | | `type` | String | Defines how the custom field set will be used in the UI and how the custom field values will be stored. For `SINGLE` set type the custom field set is displayed in the UI and can be used only once on one entity. For `GROUPED` set type the custom field set is allowed multiple times for the same entity. | YES | | `availableFor` | String | Indicates the entity associated with the custom field set. The options are `CLIENT`, `GROUP`, `CREDIT_ARRANGEMENT`, `LOAN_ACCOUNT`, `GUARANTOR`, `ASSET`, `DEPOSIT_ACCOUNT`, `TRANSACTION_CHANNEL`, `BRANCH`, `CENTRE`, or`USER`. | YES | | `customFields` | List | This section lists the custom field definitions associated with the custom field set. | NO | ### Custom field definition attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | User-defined ID, globally unique. | YES | | `type` | String | Supported input type. The options are `FREE_TEXT`, `SELECTION`, `NUMBER`, `CHECKBOX`, `DATE`, `DATE_TIME`, `CLIENT_LINK`, `GROUP_LINK`, or `USER_LINK`. | YES | | `state` | String | Indicates whether the field is active or inactive | YES | | `validationRules` | ValidationRules | Settings for field input validation. Available only if the type is `FREE_TEXT`. | NO | | `validationRules.unique` | Boolean | Indicates whether this field allows duplicate values or not. | NO | | `validationRules.`
    `validationPatttern` | String | Indicates if a validation is set in terms of expected character type/format. | NO | | `displaySettings` | DisplaySettings | Custom field definition display settings. | YES | | `displaySettings.`
    `displayName` | String | User-provided name of the custom field definition | YES | | `displaySettings.`
    `description` | String | User-provided description of the custom field definition. | NO | | `displaySettings.`
    `fieldSize` | String | Field display size in the UI. The options are `LONG` or `SHORT`. | YES | | `usage` | Usage | Information on what record types the custom field definition is available for. Defines the usage at record type level. The custom field definition is going to be available only for the record types that are referenced in the list by ID. Mutually exclusive with usage defined on custom field definition level by `required` and `default` fields. For selection custom field definitions that have a `dependentFieldId` set, the usage is inherited from the dependent field and must not be defined. For more information, see [Usage](#usage) below. | NO | | `usage.id` | String | Indicates the user defined ID of the associated entity. Must be an already existing id. | NO | | `usage.required` | Boolean | Defines if a custom field definition is required. | NO | | `usage.default` | Boolean | Defines if a custom field definition is used as a default. | NO | | `viewRights` | AccessRights | Response representation of the access rights for viewing custom field values for this custom field definition. If access rights are not specified, the custom field definition will be deactivated. | NO | | `viewRights.roles` | Array | Lists the IDs of the roles that have view rights for the custom field values of this custom field definition when it's not accessible by all users. The IDs must already exist. | NO | | `viewRights.allUsers` | Boolean | Indicates whether the custom field values for this custom field definition can be viewed or edited by all users if true or by the roles indicated by role IDs if false. | NO | | `editRights` | AccessRights | Response representation of the access rights for editing custom field values for this custom field definition. If access rights are not specified, the custom field definition will be deactivated. | NO | | `editRights.roles` | Array | Lists the IDs of the roles that have edit rights for the custom field values of this custom field definition when it's not accessible by all users. The IDs must already exist. If a role ID is specified for edit rights, it will automatically be added for view rights as well. | NO | | `editRights.allUsers` | Boolean | Indicates whether the custom field values for this custom field definition can be viewed/edited by all users if true or by the roles indicated by roles IDs if false. | NO | ### Selection custom field definitions A custom field definition with type `SELECTION` is referred to as a *selection custom field* and it has additional fields in the YAML file. There are two kinds of selection custom field definitions: regular selection custom field definitions and dependent selection custom field definitions. For more information about selection custom fields, see [Custom Fields - Selection custom field definition](/docs/custom-fields#selection-custom-field-definition). #### Example The following complete example shows a request for two selection custom field definitions, with the second one depending on the first. ```yaml customFieldSets: - id: "_set1_Users" name: "set1" description: "set 1 description" type: "SINGLE" availableFor: "USER" customFields: - id: "selection_1" type: "SELECTION" state: "ACTIVE" displaySettings: displayName: "selection 1" description: "selection without any dependent field" fieldSize: "SHORT" viewRights: roles: - "role_1_id" allUsers: false editRights: roles: [] allUsers: false selectionOptions: # this selection field doesn't depend on another selection, 'dependentFieldId' and 'selectionId' are not specified - availableOptions: - selectionId: "selection_1_option_1_id" value: "selection 1 option 1" - selectionId: "selection_1_option_2_id" value: "selection 1 option 2" score: 5 required: true default: true - id: "selection_2" type: "SELECTION" state: "ACTIVE" displaySettings: displayName: "selection 2" description: "selection field dependent on another selection field" fieldSize: "SHORT" viewRights: roles: - "role_3_id" - "role_2_id" allUsers: false editRights: roles: - "role_3_id" allUsers: false dependentFieldId: "selection_1" # id of the selection field that this field depends on selectionOptions: - forSelectionId: "selection_1_option_1_id" # id of the selection option from the dependent field availableOptions: - selectionId: "952379149" value: "option A" score: 5 - forSelectionId: "selection_1_option_2_id" # id of the selection option from the dependent field availableOptions: - selectionId: "487822627" value: "option B" score: 10 - selectionId: "215308065" value: "option C" score: 3 ``` ### Regular selection custom field definitions Selection custom field definitions include additional fields: ```yaml selectionOptions: - availableOptions: - selectionId: value: score: - selectionId: value: score: ``` | Name | Type | Description | Required | | --- | --- | --- | --- | | `selectionOptions` | CustomFieldSelectionOptions | Indicates that the field has predefined selections and only those can be used to as custom field values | NO | | `availableOptions` | CustomFieldAvailableOptions | List of custom field values that can be used in the saved field based on current master selection. | NO | | `selectionId` | String | System-generated ID of the predefined custom field value. | NO | | `value` | String | Predefined custom field value name. | NO | | `score` | Number | Custom field value selection score. | NO | ### Dependent selection custom field definitions Dependent selection custom field definitions have all the fields that a regular selection custom field definition has as well as a couple additional fields. ```yaml dependentFieldId: selectionOptions: - forSelectionId: availableOptions: - selectionId: value: score: - forSelectionId: availableOptions: - selectionId: value: - selectionId: value: score: ``` | Name | Type | Description | Required | | --- | --- | --- | --- | | `dependentFieldId` | String | The ID for the parent selection custom field definition that the dependent selection custom field definition depends on. | NO | | `forSelectionId` | String | The ID of a custom field value option from the dependent field. It is not mandatory, if the field does not depend on another field. | NO | :::note The `usage` for a dependent selection custom field definition is inherited from the parent selection custom field definition. If you try to specify a `usage` for a dependent selection custom field definition, you will get a validation error. ::: ## Replies from "@site/src/components/snippets/ConfigurationAsCodeStatusCodeWarningSnippet"; ## Managing configuration files There are two approaches regarding how you manage your configuration file(s) in the CasC for custom field definitions feature. 1. You can keep all custom field definitions in a single large YAML file. This strategy is recommended if you have less than 300 custom field definitions. 2. You can create one YAML file per entity. This can be specified with the `availableFor` parameter when you make your API call. For example, you can have one file for client custom field definitions, one for group custom field definitions and so on. This is the most granular way of organizing custom field definitions. :::warning Splitting custom field definitions of the same entity into multiple YAML configuration files will have undesired effects. For example, all the sets and fields not present in the file will be automatically deactivated. ::: ### Built-in custom field definitions and custom field sets Built-in custom field definitions and custom field sets are excluded from the configuration for the time being because they are created with the tenant provisioning and are not fully customizable. For example, in the clients entity there are some custom field sets and custom field definitions that are not fully configurable. These particular custom field sets and custom field definitions are not included in the CasC feature and they will not appear in the YAML file. ### Entities without additional custom field sets The guarantors and assets entities do not have custom field sets in the Mambu UI; in the YAML configuration file there will only be one default custom field set for each of these entities. You cannot add more custom field sets to these entities. You can only add, edit, and remove custom field definitions to the default custom field set. ## Usage There are two types of entities: those with dependencies, and those without dependencies. | Entities with dependencies | Entities without dependencies | | --- | --- | | Clients
    Groups
    Loan account
    Deposit account
    Deposit Product
    Transaction channel
    Transaction by Type | Asset
    Centre
    Credit arrangement
    Guarantor
    Branch
    User | The entities that have dependencies can either define `usage` at the resource level or the custom field definition level. The entities that do not have dependencies can only define `usage` at the custom field definition level. ### Usage defined at the resource level For entities that have dependencies you can define the usage for each entity type. For example: * **Clients**: there can be multiple client types within the clients entity. * **Groups**: there can be multiple group roles within the groups entity. * **Loan account**: there can be multiple loan products within a loan account. * **Deposit account**: there can be multiple savings products within a savings account. * **Deposit product**: there can be different usage settings per product type. * **Transaction channel**: there can be multiple options for transaction channels specified. * **Transaction by Type**: there can be different usage settings per transaction type. #### Example The following example shows a set available for clients that have a custom field definition with usage defined. The custom field definition is not available for client types not included in the usage list ```yaml customFieldSets: - id: "_set_id" name: "set name" description: "set description" type: "SINGLE" availableFor: "CLIENT" customFields: - id: "field_id" type: "FREE_TEXT" state: "ACTIVE" validationRules: unique: false displaySettings: displayName: "field name" description: "field description" fieldSize: "SHORT" usage: # usage defined on entity level, for each referenced entity id - id: "client_type_1_id" required: true default: true - id: "client_type_2_id" required: false default: true viewRights: roles: [] allUsers: true editRights: roles: [] allUsers: true ``` ### Usage defined at the custom field definition level For entities that do not have dependencies you can only define usage at the custom field definition level. For entities with dependencies you can choose to define usage at the custom field definition level by using the `required` and `default` fields. #### Example for an entity with dependencies The following example shows a set available for clients that has a custom field definition available for all existing client types, with the same usage settings. Considering that you only have two client types defined, the example will look like this: ```yaml customFieldSets: - id: "_set_id" name: "set name" description: "set description" type: "SINGLE" availableFor: "CLIENT" # has dependent entities: client types customFields: - id: "field_id" type: "FREE_TEXT" state: "ACTIVE" validationRules: unique: false displaySettings: displayName: "field name" description: "field description" fieldSize: "SHORT" viewRights: roles: [] allUsers: true editRights: roles: [] allUsers: true required: false # usage settings defined on custom field definition level for all existing client types default: true # usage settings defined on custom field definition level for all existing client types ``` :::note We will detect automatically if you have the same usage settings for a custom field definition that is available for all record types, and will replace the usage list with the usage settings at custom field definition level and vice versa. ::: #### Example for an entity without dependencies The following example shows a set available for branches that has a custom field definition with usage defined. ```yaml customFieldSets: - id: "_set_users_id" name: "set users name" description: "set description" type: "SINGLE" availableFor: "BRANCH" customFields: - id: "field1_users" type: "NUMBER" state: "ACTIVE" displaySettings: displayName: "field1" description: "field description" fieldSize: "SHORT" viewRights: roles: [] allUsers: false editRights: roles: [] allUsers: false required: true # usage defined on the custom field definition level default: true # usage defined on the custom field definition level ``` :::note If a field is required, it must also be default and if usage is not specified or empty, the field will be deactivated. ::: ## Validations Your input will be validated according to the same rules employed by the Mambu UI. During upload of a new configuration file, the following areas will be validated * Syntax is correct as per [YAML standards](https://yaml.org/spec/1.2/spec.html) and the template for custom field definitions. * Content is correct. * References to dependencies are all properly mapped and exist in the target system. * Custom field definition properties are accurate and correct, including dependent custom field definitions. --- # Group Role Names Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-group-role-names/ *Group role names* are used to determine specific roles for members within a group. For more information, see [Group Role Names](/docs/group-role-names). With *Configuration as Code* (CasC), you may batch configure your group role names configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for group role names supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/grouprolenames.yaml` | Get current group role names configuration. | | `PUT` | `/configuration/grouprolenames.yaml` | Write a new group role names configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. regarding authentication, ` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/grouprolenames.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/grouprolenames.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @grouprolenames.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@grouprolenames.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration example In this configuration, `id` and `name` are the only supported fields. ```yaml --- groupRoleNames: - id: "mng11" name: "Manager" - id: "grId2" name: "Group Role Name 2" - id: "grId133" name: "Group Role Name 3" - id: "grId4" name: "Group Role Name 4" ``` ## Replies ### Attributes and validations | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | Must not exceed 32 characters in length and must be unique in the configuration. | ✔ | | `name` | String | Must not exceed 256 characters in length. | ✔ | --- # Holidays Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-holidays/ *Holidays* and *non-working days* define on which days there will be no loan account installments. Holidays fall on specific dates in the year. Non-working days are days of the week which are regularly not considered work days. For more information about this topic, see [Holidays and Non-Working Days](/docs/holidays-and-non-working-days). Whereas non-working days apply to your entire organisation, holidays can be defined as either organisation-wide or for specific branches. The configuration as code for holidays feature only manages the organization-wide holidays. To manage branch-specific holidays, you must use the configuration as code for branches feature. For more information, see [Branches Configuration](/docs/configuration-as-code-for-branches). With *Configuration as Code* (CasC), you may batch configure your holiday configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for holidays supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/holidays.yaml` | Get current holiday configuration. | | `PUT` | `/configuration/holidays.yaml` | Write a new holiday configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/holidays.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/holidays.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @holidays.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@holidays.yaml` represents the absolute path of the file on your device. (Use “--data-raw” if you want to specify the YAML body inline). A `PUT` enqueues a background update of the affected accounts. To be notified when it finishes, subscribe to the `HOLIDAY_SYNC_COMPLETED` webhook event on the Administrative target. See [Event triggers](/docs/event-triggers) and [Create webhook templates](/docs/webhooks-defining-a-new-webhook). ### Configuration example ```yaml nonWorkingDays: - "TUESDAY" - "FRIDAY" holidays: - id: 1 name: " holiday 1" dayOfMonth: 11 monthOfYear: 01 year: 1995 isAnnuallyRecurring: "true" - id: 2 name: " holiday 2" dayOfMonth: 11 monthOfYear: 01 year: 1995 isAnnuallyRecurring: "true" - id: 4 name: " holiday 4" dayOfMonth: 9 monthOfYear: 7 year: 2029 isAnnuallyRecurring: "true" - id: 5 name: " holiday 5" dayOfMonth: 5 monthOfYear: 4 year: 2011 isAnnuallyRecurring: "true" ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `nonWorkingDays` | List | A list of the days of the week that are non-working days. | ✘ | | `holidays` | List | A list of holidays. | ✘ | | `id` | Number | The unique identifier of the holiday. | ✔ | | `name` | String | Name of the holiday. | ✔ | | `dayOfMonth` | Number | The day of the month of the holiday. | ✔ | | `monthOfYear` | Number | The month in the year of the holiday. | ✔ | | `year` | Number | The year of the holiday. | ✔ | | `isAnnuallyRecurring` | Boolean | Whether the holiday recurs every year. | ✔ | ## Replies from "@site/src/components/snippets/ConfigurationAsCodeStatusCodeWarningSnippet"; ## Validations With all use cases, a validation of the uploaded file will be done, ensuring the following: * Syntax is correct as per YAML standards and the template for holidays. * Minimum requirements indicates the line with the syntax error. * Content is correct. Configuration settings may be specified in any order. | Name | Input Requirements | | --- | --- | | `nonWorkingDays` | Should not contain duplicate keys. | | `id` | Mandatory, unique, between 1 and 2,147,483,647. | | `name` | Mandatory, not blank and between 1 and 256 characters. | | `dayOfMonth`| Must be between 1 and 31. | | `monthOfYear` |Must be between 1 and 12. | | `date` |Must be between 1900 and 9999. | | Combination of `dayOfMonth`, `monthOfYear`, and `date` | Must represent a valid date. | | `isAnnuallyRecurring` | Must be `true` or `false`. | --- # ID Templates Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-id-templates/ An *ID template* is a representation of a type of ID document. For more information, see [ID Templates](/docs/id-templates). With *Configuration as Code* (CasC), you may batch configure your ID templates configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for ID templates supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/iddocumenttemplates.yaml` | Get current ID templates configuration. | | `PUT` | `/configuration/iddocumenttemplates.yaml` | Write a new ID templates configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/iddocumenttemplates.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/iddocumenttemplates.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @iddocumenttemplates.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@iddocumenttemplates.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml idDocumentTemplates: - id: "438499999" documentType: "Passport" issuingAuthority: "Government" documentIdTemplate: "#########" mandatoryForClients: false allowAttachments: false - id: "662323814" documentType: "ID Card" issuingAuthority: "Government" documentIdTemplate: "#########" mandatoryForClients: true allowAttachments: true ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | The ID of the template. | ✔ | | `documentType` | String | The type of the document. | ✔ | | `issuingAuthority` | String | The authority that issued the document. | ✔ | | `documentIdTemplate` | String | The document id template constraint. | ✔ | | `mandatoryForClients` | Boolean | Whether this template it's mandatory for all the clients or not. | ✔ | | `allowAttachments` | Boolean | Whether this template allows files to be attached or not | ✔ | ## Replies ## Requirements The endpoints do not accept empty configurations or null/empty entries in a configuration. | Name | Requirements | | --- | --- | | `id` | It must not be blank, must not exceed 32 characters in length, must be unique in the configuration, and must only contain letters and number. | | `documentType` | It must not be blank, must not exceed 256 characters in length. | | `issuingAuthority` | It must not be blank, must not exceed 256 characters in length. | | `documentIdTemplate` | It must not be blank, must not exceed 256 characters in length. | | `mandatoryForClients` | It must not be blank. | | `allowAttachments` | It must not be blank. | --- # Internal Controls Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-internal-controls/ With *internal controls* you can set up automatic controls for loans, such as the dormancy period, the number of days you want to wait before locking accounts in arrears or automatically locking accounts in arrears when interest, fees, and penalties are more than a percentage of the current principal balance or of the original principal amount. For more information, see [Internal Controls](/docs/internal-controls). With *Configuration as Code* (CasC), you may batch configure your internal controls configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for internal controls supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/internalcontrols.yaml` | Get current internal controls configuration. | | `PUT` | `/configuration/internalcontrols.yaml` | Write a new internal controls configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. regarding authentication, \ is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/internalcontrols.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/internalcontrols.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @internalcontrols.yaml ``` `@internalcontrols.yaml` represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Example configuration body ```yaml --- loanExposure: exposureType: "SUM_OF_LOANS" exposureAmount: 25000.00 assignmentConstraints: - "BRANCH" - "CENTRE" - "CREDIT_OFFICER" allowMultipleLoans: true allowMultipleGroupMemberships: true duplicateClientFieldsConfiguration: duplicateClientChecks: - "DOCUMENT_ID_AND_TYPE" - "HOME_PHONE" - "MOBILE_PHONE" - "EMAIL" - "FIRST_NAME_AND_LAST_NAME" - "LAST_NAME_AND_DATE_OF_BIRTH" duplicateClientConstraintAction: "ERROR" arrearsDaysBeforeWriteOff: 30 maxAllowedUndoClosurePeriod: 60 defaultClientState: "PENDING_APPROVAL" defaultLineOfCreditState: "PENDING_APPROVAL" groupSizeLimit: groupSizeLimitType: "HARD" minGroupSizeLimit: 10 maxGroupSizeLimit: 20 approvalDisbursalTwoManRuleEnabled: true availableDashboardSections: - "CLIENTS" - "CURRENT_TILLS" - "FAVOURITE_VIEWS" - "INDICATORS" - "LATEST_ACTIVITY" - "TASKS" - "UPCOMING_REPAYMENTS" ``` ## Replies ## Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `loanExposure` | Loan Exposure Configuration |Configuration for maximum exposure to a client |✔ | | `loanExposure.exposureType` | String | Type of maximum exposure to a client.|✔ | | `loanExposure.exposureAmount` | Number | Maximum amount. |Required when `exposureType` is not `UNLIMITED`. | | `assignmentConstraints` | List | List of required assignments for clients and groups, ordered alphabetically. |✔ | | `allowMultipleLoans` | Boolean | Option that shows if multiple loans are allowed or not. |✔ | | `allowMultipleGroupMemberships` | Boolean | Option that shows if a client can be member of multiple groups. |✔ | | `duplicateClientFieldsConfiguration` | Duplicate Client Fields Configuration | The duplicate client constraints configuration that are available in the administration and can be performed.|✔ | | `duplicateClientFieldsConfiguration.`
    `duplicateClientChecks` | List | Constraints regarding what fields can't be duplicate between two clients, ordered alphabetically.|✘ | | `duplicateClientFieldsConfiguration.`
    `duplicateClientConstraintAction` | String | Action to be taken if constraints exist and are not met. |✔ | | `arrearsDaysBeforeWriteOff` | Number | Number of days that are required before an account can be written off. |✔ | | `maxAllowedUndoClosurePeriod` | Number | Maximum of days we allow users to undo of close obligations met for an loan account. |✔ | | `defaultClientState` | String | The state that a client it's set when it's created. |✔ | | `defaultLineOfCreditState` | String | The state that a line of credit it's set when it's created. |✔ | | `groupSizeLimit` | Group Size Limit Configuration | Configuration for the group size limitations. |✔ | | `groupSizeLimit.groupSizeLimitType` | String | Group size limit type. The options are `HARD`, `WARNING`, and `NONE`. |✔ | | `groupSizeLimit.minGroupSizeLimit` | Number | Minimum group size.|Required when `groupSizeLimitType` is not `NONE`. | | `groupSizeLimit.maxGroupSizeLimit` | Number | Maximum group size. |Required when `groupSizeLimitType` is not `NONE`. | | `approvalDisbursalTwoManRuleEnabled` | Boolean | Requires separate users for approvals and disbursals. |✔ | | `availableDashboardSections` | List |List of available dashboard sections, ordered alphabetically. The options are `UPCOMING_REPAYMENTS`, `INDICATORS`, `LATEST_ACTIVITY`, `FAVOURITE_VIEWS`, `TASKS`, `CURRENT_TILLS`, and `CLIENTS`. |✔ | ### Validations | Name | Valid value range | | --- | --- | | `loanExposure.exposureAmount` | 0-2,000,000,000,000,000 | | `arrearsDaysBeforeWriteOff` | 0-2,000,000,000 | | `maxAllowedUndoClosurePeriod` | 0-2,000,000,000 | | `groupSizeLimit.minGroupSizeLimit` | 0-2,000,000,000 | | `groupSizeLimit.maxGroupSizeLimit` | 0-2,000,000,000 | --- # Labels Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-labels/ *Labels* refer to various element types in the Mambu UI. For example, client, group, and branch are default labels in Mambu. If you use different terminology to refer to these elements, you can change the labels. The default labels that can be changed are clients, groups, branches, centres, credit officers, interest, fees and loan. For more information, see [Labels](/docs/labels). With *Configuration as Code* (CasC), you may batch configure your labels via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for holidays supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/labels.yaml` | Get current label configuration. | | `PUT` | `/configuration/labels.yaml` | Write a new label configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/labels.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/labels.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @labels.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@labels.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example :::warning For brevity, we have only included two languages in the below sample response. However, your YAML file will include all of the languages specified in the YAML file. ::: ```yaml objectLabels: - language: "BURMESE" labels: - type: "BRANCH" singularValue: "ဘဏ်ခွဲ" pluralValue: "ဘဏ်ခွဲများ" - type: "CENTRE" singularValue: "စင်တာ" pluralValue: "စင်တာများ" - type: "CLIENT" singularValue: "ငွေချေးသူ" pluralValue: "ငွေချေးသူများ" - type: "CREDIT_OFFICER" singularValue: "ချေးငွေအရာရှိ" pluralValue: "ချေးငွေအရာရှိများ" - type: "FEE" singularValue: "အခကြေးငွေ" pluralValue: "ဝန်ဆောင်ခများ" - type: "GROUP" singularValue: "အုပ်စု" pluralValue: "အုပ်စုများ" - type: "INTEREST" singularValue: "အတိုး" pluralValue: "အတိုးများ" - type: "LOAN" singularValue: "ချေးငွေ" pluralValue: "ချေးငွေများ" - language: "CHINESE" labels: - type: "BRANCH" singularValue: "分行" pluralValue: "分行" - type: "CENTRE" singularValue: "中心" pluralValue: "中心" - type: "CLIENT" singularValue: "客户" pluralValue: "客户" - type: "CREDIT_OFFICER" singularValue: "信贷员" pluralValue: "信贷员" - type: "FEE" singularValue: "费用" pluralValue: "收费" - type: "GROUP" singularValue: "小组" pluralValue: "小组" - type: "INTEREST" singularValue: "利息" pluralValue: "利息" - type: "LOAN" singularValue: "贷款" pluralValue: "贷款" ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `language` | String | The language of the label it is for. | ✔ | | `labels` | List | A list of the values for each label. | ✘ | |`type` | String | The element type the label is for. | ✔ | | `singularValue` | String | The value for the label in singular form. | ✔ | | `pluralValue` | String | The value for the label in plural form. | ✔ | ## Replies ## Validations ### General validations With all use cases, a validation of the uploaded file will be done, checking the following: * Syntax is correct as per YAML standards and the template for holidays. * Minimum requirements indicates the line with the syntax error. * Content is correct. Configuration settings may be specified in any order. ### Content validations The submitted configuration is subject to the following validation: * All available languages must be present inside the configuration file. * There should be no duplicate object label pair. * All possible object label pairs have to be present inside the configuration file. ### Field validations | Name | Description | | --- | --- | | `language` | The language must not be blank, must be part of the available language list and must be unique in the entire labels configuration. | | `labels` | The list must not be null. | |`type` | The type must not be blank, must be part of the available type list and must be unique inside the labels list. | | `singularValue` | It is required, it must not be empty. | | `pluralValue` | It is required, it must not be empty. | --- # Organization Details Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-organization-general-details/ An *organization* is how we refer to your institution, including staff members and the different branches. For more information about your organization details, see [Organization Contact Details and Time Zone](/docs/organization-contact-currency-and-timezone). With *Configuration as Code* (CasC), you may batch configure your organization configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for organization details supports three operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/organization.yaml` | Get current organization configuration. | | `PUT` | `/configuration/organization.yaml` | Write a new configuration for your organization to Mambu. | | `GET` | `/configuration/organization/template.yaml` | Get your organization configuration template in YAML. This is useful when configuring from scratch. For formatting information for the fields, see [Attributes](#attributes) below for an example. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/organization.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## GET configuration template ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/organization/template.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/organization.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @organization.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@organization.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml institutionName: "Mambu" address: line1: "street address" city: "big city" region: "cloud country" postcode: "90210" country: "Countrystan" phoneNumber: "+420456978" emailAddress: "info@BofAlg.es" localDateFormat: "dd-MM-yyyy" localDateTimeFormat: "dd-MM-yyyy HH:mm:ss" decimalSeparator: "POINT" ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `address` | Address | Response representation of an address. | ✘ | | `decimalSeparator` | String | Symbol used to mark the border between the integral and the fractional parts of a decimal numeral. Must be one of `COMMA` or `POINT`. | ✔ | | `emailAddress` | String | The email address of the organization. | ✘ | | `institutionName` | String | The name of the organization. | ✘ | | `localDateFormat` | String | The format used to represent the date using ISO 8601 characters, for example `dd-MM-yyyy` for 31-05-2020 or `yy.MM.dd` for 20.05.31 | ✔ | | `localDateTimeFormat` | String | The format used to represent the time and date using ISO 8601 characters, for example `dd-MM-yyyy HH:mm:ss` for 31-05-2020 12:49:49 or `yy.MM.dd HH:mm:ss` for 20.05.31 12:49:49 | ✔ | | `phoneNumber` | String | The phone number of the organization. | ✘ | ## Replies from "@site/src/components/snippets/ConfigurationAsCodeStatusCodeWarningSnippet"; :::warning Validation errors report certain issues such as invalid date formats or unsupported decimal separators, but some fields, such as email address and telephone number, are not validated. ::: ## Validations Your input will be validated according to the same rules employed by the Mambu UI. During upload of a new configuration file, the following areas will be validated: * Syntax is correct as per [YAML standards](https://yaml.org/spec/1.2/spec.html). For example, indentation is valid, strings are enclosed in " quote " marks. * Content is correct as defined by the template. All required fields are supplied and there are no extra, unsupported fields provided. * References are all properly mapped and exist in the target system. * Organization properties are accurate and correct. --- # User Roles Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-roles/ *Permissions* allow users to view different types of information or to perform actions in Mambu. You can either assign individual permissions to users, or you can group permissions by creating a role and then assigning that role to a user. The user will then have all the permissions that are a part of that role. For more information see [Understanding Users, Roles, and Permissions](/docs/understanding-users-roles-and-permissions) and [Roles](/docs/roles). With *Configuration as Code* (CasC), you may batch configure your user roles configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API operations CasC for user roles supports three operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/userroles.yaml` | Get current user roles configuration. | | `PUT` | `/configuration/userroles.yaml` | Write a new user roles configuration to Mambu. | | `GET` | `/configuration/userroles/template.yaml` | Get your user roles configuration template in YAML. This is useful when configuring from scratch. For formatting information for the fields, see [General Attributes](#general-attributes) below for an example. | :::note Any existing selections, usages, view and edit rights of roles that are not included in a new configuration submitted to the API are deleted. Existing roles that are not included in configuration requests are deactivated or disabled. ::: :::warning Built-in user roles are excluded from configuration because they are created during tenant provisioning and are not fully customisable. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/userroles.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -u user:password ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### Get your user roles configuration template ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/userroles/template.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/userroles.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @userroles.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@userroles.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml --- roles: - name: "Mambu Support" id: "613343659" administrator: false teller: false creditOfficer: false support: true delivery: false accessRights: - "MAMBU" permissions: - "AUDIT_TRANSACTIONS" - "VIEW_COMMENTS" - "VIEW_CENTRE_DETAILS" - "VIEW_BRANCH_DETAILS" - "VIEW_COMMUNICATION_HISTORY" - "VIEW_LOAN_PRODUCT_DETAILS" - "VIEW_SAVINGS_PRODUCT_DETAILS" - "VIEW_CLIENT_DETAILS" - "VIEW_GROUP_DETAILS" - "VIEW_LINE_OF_CREDIT_DETAILS" - "VIEW_LOAN_ACCOUNT_DETAILS" - "VIEW_SECURITIES_DETAILS" - "VIEW_SAVINGS_ACCOUNT_DETAILS" - "VIEW_DOCUMENTS" - "VIEW_TASK" - "VIEW_INTELLIGENCE" - "VIEW_REPORTS" - "VIEW_CHART_OF_ACCOUNTS" - "VIEW_JOURNAL_ENTRIES" - "VIEW_ACCOUNTING_REPORTS" - "VIEW_INVESTOR_FUNDS_DETAILS" - "VIEW_USER_DETAILS" - "VIEW_ADMINISTRATION_DETAILS" - "VIEW_TRANSACTION_CHANNELS" - name: "roll" id: "STD_BA" administrator: false teller: false creditOfficer: true support: false delivery: false accessRights: - "APIS" permissions: - "VIEW_GROUP_DETAILS" - "CREATE_GROUP" - "EDIT_GROUP" - "CHANGE_GROUP_TYPE" - "MANAGE_GROUP_ASSOCIATION" - "EDIT_GROUP_ID" - "VIEW_LOAN_ACCOUNT_DETAILS" - "CREATE_LOAN_ACCOUNT" - "EDIT_LOAN_ACCOUNT" - "APPROVE_LOANS" - "DIBURSE_LOANS" - "APPLY_LOAN_FEES" - "ENTER_REPAYMENT" - "EDIT_REPAYMENT_SCHEDULE" - "APPLY_LOAN_ADJUSTMENTS" - "BACKDATE_LOAN_TRANSACTIONS" - "APPLY_ACCRUED_LOAN_INTEREST" - "POST_TRANSACTIONS_ON_LOCKED_LOAN_ACCOUNTS" - "EDIT_PENALTY_RATE" - "REQUEST_LOAN_APPROVAL" - "EDIT_LOAN_TRANCHES" - "REJECT_LOANS" - "WRITE_OFF_LOAN_ACCOUNTS" - "REVERSE_LOAN_ACCOUNT_WRITE_OFF" - "CLOSE_LOAN_ACCOUNTS" - "LOCK_LOAN_ACCOUNTS" - "WITHDRAW_LOAN_ACCOUNTS" - "DELETE_LOAN_ACCOUNT" - "SET_DISBURSEMENT_CONDITIONS" - "RESCHEDULE_LOAN_ACCOUNT" - "REFINANCE_LOAN_ACCOUNT" - "EDIT_LOAN_TRANSACTIONS" - "BULK_LOAN_CORRECTIONS" - "EDIT_INTEREST_RATE" - "UNDO_LOAN_ACCOUNT_CLOSURE" - "UNDO_REJECT_LOANS" - "UNDO_WITHDRAW_LOAN_ACCOUNTS" - "LINK_ACCOUNTS" - "EDIT_PRINCIPAL_PAYMENT_ACTIVE_REVOLVING_CREDIT" - "PERFORM_REPAYMENTS_WITH_CUSTOM_AMOUNTS_ALLOCATION" - "MANAGE_LOAN_ASSOCIATION" - "MAKE_WITHDRAWAL_REDRAW" - "VIEW_SECURITIES_DETAILS" - "CREATE_SECURITIES" - "EDIT_SECURITIES" - "DELETE_SECURITIES" notes: "notes" ``` #### General attributes The order of the user roles in the YAML configuration file will define the order in the Mambu UI as well. | Name | Type | Description | Required | | --- | --- | --- | --- | | `name` | [String] | A list of predefined access rights. | ✘ | | `administrator` | Boolean | Indicates whether this role is administrative. | ✘ | | `creditOfficer` | Boolean | Indicated whether this role will be associated with a credit officer user. | ✘ | | `delivery` | Boolean | Indicates whether this role will give delivery access. | ✘ | | `id` | String | User-defined ID, globally unique. | ✔ | | `name` | String | User-defined name, globally unique. | ✔ | | `notes` | String | User-defined notes for this particular role. | ✘ | | `permissions` | [String] | A list of predefined permissions. | ✘ | | `support` | Boolean | Indicates whether this role will give support access. | ✘ | | `teller` | Boolean | Indicates whether this role will give tellering access. | ✘ | ## Replies ## Validation :::warning Validation errors report a non-exhaustive list of errors, such as invalid date format or decimal separator not being one of the available types. However fields such as email address or telephone are not validated, and care should be taken to make sure this information is correct. ::: Validation performed by the API uses the same rules as the UI. Configuration validation checks: * Syntax is correct as per [YAML standards](https://yaml.org/spec/1.2/spec.html) and the user roles template. * Content is correct. * References are all properly mapped (and exist in the target system). * User roles properties are accurate and correct. --- # Transaction Channels Configuration URL: https://docs.mambu.com/docs/configuration-as-code-for-transaction-channels/ A transaction channel is a form of payment such as cash, POS device, receipt, check, bank and so on. Mambu ships with one predefined transaction channel — cash — but you can add other transaction channels as needed for your organization. For more information, see [Transaction Channels](/docs/transaction-channels). With *Configuration as Code* (CasC), you may batch configure your transaction channels configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for transaction channels supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/transactionchannels.yaml` | Get current transaction channels configuration. | | `PUT` | `/configuration/transactionchannels.yaml` | Write a new transaction channels configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. Unless they cannot be deleted in which case you will receive a warning. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/transactionchannels.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/transactionchannels.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @transactionchannels.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@transactionchannels.yaml” represents the absolute path of the file on your device. (Use “--data-raw” if you want to specify the YAML body inline). ### Configuration body example ```yaml --- defaultTransactionChannel: id: "cash" name: "Cash" state: "ACTIVE" loansConstraints: usage: "UNCONSTRAINED_USAGE" constraints: [] savingsConstraints: usage: "UNCONSTRAINED_USAGE" constraints: [] usageRights: roles: [] allUsers: true transactionChannels: - id: "63547" name: "Visa Card" state: "ACTIVE" loansConstraints: usage: "LIMITED_USAGE" constraints: - criteria: "PRODUCT" filterElement: "EMPTY" values: [] matchFilter: "ALL" savingsConstraints: usage: "UNCONSTRAINED_USAGE" constraints: [] glAccountCode: "66734" usageRights: roles: - "35436" allUsers: false - id: "837489" name: "Master card " state: "ACTIVE" loansConstraints: usage: "LIMITED_USAGE" constraints: - criteria: "PRODUCT" filterElement: "EMPTY" values: [] matchFilter: "ALL" savingsConstraints: usage: "UNCONSTRAINED_USAGE" constraints: [] glAccountCode: "68982" usageRights: roles: - "43643" allUsers: false - id: "83203" name: "BACS" state: "ACTIVE" loansConstraints: usage: "LIMITED_USAGE" constraints: - criteria: "AMOUNT" filterElement: "LESS_THAN" values: - "9999.99" matchFilter: "ALL" savingsConstraints: usage: "LIMITED_USAGE" constraints: - criteria: "AMOUNT" filterElement: "LESS_THAN" values: - "9999.99" matchFilter: "ALL" glAccountCode: "54323" usageRights: roles: - "1064356630" allUsers: false - id: "82352" name: "CHAPS" state: "ACTIVE" loansConstraints: usage: "LIMITED_USAGE" constraints: - criteria: "AMOUNT" filterElement: "MORE_THAN" values: - "10000.00" matchFilter: "ALL" savingsConstraints: usage: "LIMITED_USAGE" constraints: - criteria: "AMOUNT" filterElement: "MORE_THAN" values: - "10000.00" matchFilter: "ALL" glAccountCode: "63213" usageRights: roles: - "1108047100" allUsers: false ``` ## Attributes ### Transaction channel configuration attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `defaultTransactionChannel` | Transaction
    Channel
    Configuration |The default transaction channel. | ✔ | | `transactionChannels` | Transaction
    Channel
    Configuration |List of all transaction channels. |✘ | ### Transaction channel attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String |User-defined ID, unique in the configuration. | ✔ | | `name` | String |Name of the transaction channel. |✔ | | `state` | String | State of the transaction channel. The options are `ACTIVE` and `INACTIVE`. | ✔| | `loanConstraints` | List | A list of loan constraints for the transaction channel.| ✘ | | `loanConstraints.`
    `usage` | String | States the limited or unconstrained usage of the transaction channel. The options are `UNCONSTRAINED_USAGE` and `LIMITED_USAGE`. | ✔| | `loanConstraints.`
    `constraints` | Constraint
    Configuration | The loan constraints for the transaction channel. | Required if usage is `LIMITED_USAGE`, otherwise must be empty.| | `loanConstraints.`
    `matchFilter` | String |The match filter of the constraints. The options are `ANY` or `ALL`. | Required if usage is `LIMITED_USAGE`, otherwise must be empty.| | `savingsConstraints` | List | A list of savings constraints for the transaction channel. |✘ | | `savingsConstraints.`
    `usage` | String | States the limited or unconstrained usage of the transaction channel. The options are `UNCONSTRAINED_USAGE` and `LIMITED_USAGE`. |✔ | | `savingsConstraints.`
    `constraints` | Constraint
    Configuration | The saving constraints for the transaction channel. | Required if usage is `LIMITED_USAGE`, otherwise must be empty.| | `savingsConstraints.`
    `matchFilter` | String | The match filter of the constraints. The options are `ANY` or `ALL`. | Required if usage is `LIMITED_USAGE`, otherwise must be empty.| | `glAccountCode` | String | The code of the GLAccount of the transaction channel. | ✘| | `usageRights` | AccessRights | Response representation of access rights configuration. |✔ | | `usageRights.roles` | [String] | Lists the IDs in ascending order of the roles that have view/edit rights for this configuration when it's not accessible by all users. | Required if `allUsers` is `false`.| | `usageRights.allUsers` | Boolean | Indicates whether the configuration can be viewed or edited by all users if true or by the roles indicated by the `roles` attribute if false. | ✔ | ### Loan and savings constraint attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `criteria` | String | Specifies the criteria based on which the constraint will be applied. The options are `AMOUNT`, `TYPE`, and `PRODUCT`.| ✔| | `filterElement` | String |Specifies the operator of the constraint. The options are `EQUALS`, `EMPTY`, `NOT_EMPTY`, `MORE_THAN`, `LESS_THAN`, `BETWEEN`, and `IN`. | ✔ | | `values` | [String] |The values of the constraint. Depending on the type of constraint the list will contain a variable number of values. | Required for `EQUALS`, `MORE_THAN`, `LESS_THAN`, and `BETWEEN` filter elements. Not required for `EMPTY` and `NOT_EMPTY` filter elements. | ## Replies ## Validations With all use cases, a validation of the uploaded file will be done, ensuring the following: * Syntax is correct as per YAML standards and the template for holidays. * Minimum requirements indicates the line with the syntax error. * Content is correct. Configuration settings may be specified in any order. ### Transaction channel attribute validations | Name | Validation | | --- | --- | | `id` | The ID must not exceed a length of 32 characters and must not be duplicate. The default transaction channel ID cannot be changed. | | `name` | Maximum 256 characters in length. | | `glAccountCode` | The GL Account with the specified code must exist. | ### Access rights validations | Name | Validation | | --- | --- | | `roles` | The IDs specified in this list must not be blank or duplicate and must belong to an existing user role. | ### Constraint attribute validations | Name | Validation | | --- | --- | | `filterElement` |
    • `AMOUNT`criterion can only have `EQUALS`, `MORE_THAN`, `LESS_THAN`, `BETWEEN`, `EMPTY`, and `NOT_EMPTY` values.
    • `TYPE`criterion can only have `IN`, `EMPTY`, and `NOT_EMPTY` values.
    • `PRODUCT` criterion can only have `IN`, `EMPTY`, and `NOT_EMPTY` values.
    | | `values` |
    • It must be existing product IDs for `PRODUCT` criterion with filter element `IN`, either savings or loans, depending on the type of constraint.
    • It must have disbursment or repayment values for loans constraints with the `TYPE` criterion.
    • It must have deposit or withdrawal values for savings contrains with the `TYPE` criterion.
    | ## Warnings In case a transaction channel cannot be deleted, it will be deactivated and the following warning will be returned: `TransactionChannel [tr2] could not be deleted: The transaction channel cannot be deleted since it is used in a transaction.` --- # Configuring System Options URL: https://docs.mambu.com/docs/configurations/ To set up system options for all profit-sharing arrangements, navigate to the **Configuration > System Options** tab. Typically, there is one active **System Options** configuration listed. After making changes to **System Options** - the profit calculation process considers the latest modification in the **System Options** configuration. * To create various system options, choose **Create System Option.** * To modify existing options (excluding the Operating branch), click the **Actions** button, and then select **Edit**. * To modify existing option for the Operating branch, choose **Create System Option.** * To view existing options, click the **Actions** button, and then select **View**. * To delete existing options, click the **Actions** button, and then select **Delete**. ![Create System Option](@site/static/img/support/Create%20System%20Option.png) ## System Options parameters | **Parameter** | **Description** | **Required** | | --- | --- | --- | | Effective date | The date when the change should be implemented. | YES | | Operating branch | The branch list will be displayed and identifies the specific branch responsible for executing. Setting the branch does not directly impact the branches assigned to customer deposit accounts. | YES | | Profit period end non-business day | Specifies treatment for the end of a profit period coinciding with a non-business day. | YES | | Profit calculation balance | Identifies the specific account balance considered in profit-sharing calculations (Actual Balance, Average Balance, Minimum Balance). | YES | | Deduct bank profit upfront | Indicates if the bank's profit portion is subtracted upfront in profit-sharing calculations. Note: Default selection is “No”, field cannot be changed in EA. | YES | | Manual approval required | Specifies situations where manual approval by authorised personnel is required for the acceptance of calculated profit amounts. | YES | | Manual profit application required | Highlights scenarios requiring manual intervention for the application of calculated profit amounts. | YES | | IPS Accounts | Refers to the specific accounts managed or affected by IPS (GL accounts for Profit suspense and Reverse)| YES | --- # Configuring an Equal Installment Interest-Only Loan URL: https://docs.mambu.com/docs/configuring-an-equal-installment-interest-only-loan/ To set up a product with equal interest-only installments, select **Product Type: Interest Only Equal Installments Loan**. ![Equal installment interest only loan product type](/img/support/equal-installment-loan-product-type.png) For more information, see [Setting Up New Loan Products](/docs/setting-up-new-loan-products). This loan type has the following settings that should be configured: ## Interest Rate section ![Interest rate settings section](@site/static/img/support/loans--interest-rate-configuration-3.png) * **Accrue Late Interest**: This toggle allows or disallows the accrual of interest on amounts that are in arrears. This option should be enabled for interest to accrue on amounts that are in arrears. When the **Accrue Late Interest** checkbox is enabled, the **Decouple Interest from Arrears** checkbox will also become visible. For more details on this feature, refer to [Accrue late interest](/docs/interest-from-arrears#accrue-late-interest). * **Allow Adjustable Interest Rates**: An [Adjustable Interest Rate Loan](/docs/change-interest-rate#index-interest-rates), also known as a variable rate loan, is a type of loan where the interest rate applied varies over time. The rate changes are typically tied to a specific benchmark or index, which reflects prevailing market rates. Mambu supports interest-only loans with configurable adjustable interest rates. These rates can be set as fixed, indexed, or a combination of both. * **PMT Adjustment Threshold**: The **payment due** (also called **total due**) **adjustment threshold** determines whether the **total due** of the current installment is adjusted after an interest rate change or an overpayment. If the time interval between the interest rate change and the due installment is greater than the specified threshold, the **total due** is recalculated to reflect the new interest rate. Otherwise, the **total due** remains unchanged. * The **threshold days method** can be configured as **calendar days** or **working days** count. ![threshold days method](@site/static/img/support/loans--pmt-adjustment-threshold-settings.png) ## Repayment Scheduling section ![Repayment Scheduling section](@site/static/img/support/loans--repayment-scheduling-configuration-13.png) * **Payment Interval Method**: Supports the options to pay with either **Interval** or **Fixed Days of Month**. The current product does not support a grace period or other [rounding options](/docs/truncating-and-rounding-interest-loans) except for rounding of the repayment currency. ## Repayment Collection section ![Repayment Collection section](@site/static/img/support/loans--repayment-collection.png) * **Pre-Payments Acceptance**: If the product accepts pre-payments as a pre-payment recalculation method, the amount per installment is reduced. * For more information, see [Equal Installment Interest-Only Loans](/docs/equal-installment-interest-only-loans#pre-payments-and-over-payment-allocation-logic) * **Allow Custom Repayment Allocation**: For more information, see [Processing Loan Repayments](/docs/processing-loan-repayments#enter-a-custom-repayment). ## Arrears settings For more information, see [Arrears Settings](/docs/arrears-settings). ## Non-configurable settings This product type has some default settings that cannot be changed. They are visible but non-editable in the loan product create and edit forms: * **Interest type**: Simple interest * **Calculate interest using**: Principal and Interest * **Prepayment allocation**: On upcoming pending installment only * **Prepayment recalculation method**: Reduce Amount per Installment * **Apply interest on prepayment**: Manual * **Accrued interest posting frequency**: On repayment * **Payment allocation method**: Horizontal --- # Configuring Classes URL: https://docs.mambu.com/docs/configuring-classes/ Classes are the different classes of profit sharing within the same investment pool. For example, within a real estate investment pool you may have classes for customers who have deposited different amounts. You can: * Create new classes by selecting **Create Classes**. * Edit current options by accessing the **Actions** button and selecting **Create New Version**. * Examine existing options by choosing the **Actions** button and then selecting **View**. * Duplicate current configurations via the **Actions** button, selecting **Create New Class from this**. * Deactivate current options by clicking the **Actions** button and selecting **Deactivate**. * Delete current configurations by selecting the **Actions** button and then choosing **Delete**. ![Classes](@site/static/img/support/Classes.png) ## Class parameters | **Parameter** | **Description** | **Required** | | --- | --- | --- | | Effective date | The date when the change should be implemented. | YES | | Name | The name of the investment class. Include at least 3 or more letters or numbers, symbols cannot be used. | YES | | Status | Whether the class is currently active or inactive. | YES | | Description | Document additional details or context related to the class. | NO | | Include closed accounts | Whether or not to show closed accounts in the profit sharing calculations. ***NOTE***: default value - “No”, not editable for Early Access.| YES | | Weighting | The weighting parameter assigns relative importance to the investment classes for purposes of calculating the proportional profit distribution. If all classes have the same weighting or no weighting is applicable for the organization, then set this to 1 for each class.| YES | | Minimum weighting | Sets the lower limit for customising weights, ensuring a baseline significance for each factor.|NO| | Maximum weighting | Establishes the upper limit for customising weights, preventing any single factor from disproportionately influencing profit distribution. | NO | | Utilisation % | Indicates the percentage of resources actively engaged in investment activities. ***NOTE***: default value - 100%, not editable for Early Access. | YES | | Fixed rate rule | The account fixed rate rule that is used for profit sharing calculations. (Select option from drop-down: Always use fixed rate; Treat as minimum rate; Calculated rate) | YES | | Fixed rate | The account fixed rate that is used for profit sharing calculations (Fixed percentage). | YES | | Bank/Customer share | How the profit is shared between the Bank and the Customer. Bank share can be structured as either fixed or tiered. Able to specify a "from" and "to" amount. If the "to" amount is left empty, it indicates that it is unlimited. | YES | | Pool | The pool that this class applies to. | YES | --- # Configuring Expenses URL: https://docs.mambu.com/docs/configuring-expenses/ Expenses cover the different expense categories for the investment pool. For example, within a real estate investment pool you may have income categories for rental property expenses and another for business property expenses. You can: * Create different expense categories by selecting **Create Expense Category.** * Edit existing options by selecting the **Actions** button and then choosing **Create New Version**. * View existing options by selecting the **Actions** button and then opting for **View**. * Copy existing options by selecting the **Actions** button and then choosing **Create New Expense from This**. * Deactivate existing options by selecting the **Actions** button and choosing **Deactivate**. * Delete existing options by selecting the **Actions** button and then opting for **Delete**. ![Expense](@site/static/img/support/Expense.png) ## Expenses parameters | **Parameter** | **Description** | Required | | --- | --- | --- | | Effective date | The date when the change should be implemented. | YES | | Name | The name of the expense category. Include at least 3 or more letters or numbers, symbols cannot be used. | YES | | Status | Whether the expense category is currently active or inactive | YES | | Description | Document additional details or context related to the subject. | NO | | Account | Identifies the account associated with the expense. | YES | | Allocation method | Specifies the method employed for allocating profits (Select option from drop-down: Average balance; Number of accounts; Percentage) | YES | | Pools | The pools that are associated within the profit-sharing system. | YES | --- # Configuring Income URL: https://docs.mambu.com/docs/configuring-income/ Income covers the different income categories from the investments. For example, within a real estate investment pool you may have income categories for rental property income and another for business property income. You can: * Create different income categories by selecting **Create Income Category**. * Edit existing options by selecting the **Actions** button and then choosing **Create New Version**. * View existing options by selecting the **Actions** button and then opting for **View**. * Copy existing options by selecting the **Actions** button and then choosing **Create New Income from this**. * Deactivate existing options by selecting the **Actions** button and choosing **Deactivate**. * Delete existing options by selecting the **Actions** button and then opting for **Delete**. ![Income](@site/static/img/support/Income.png) ## Income parameters | **Parameter** | **Description** | **Required** | | --- | --- | --- | | Effective date | The date when the change should be implemented. | YES | | Name | The name of the income category. Include at least 3 or more letters or numbers, symbols cannot be used. | YES | | Status | Whether the income category is currently active or inactive. | YES | | Description | Document additional details or context related to the income category. | NO | | Account | Identifies the GL account associated with the income. | YES | | Income source | The source of the income. ***NOTE***: default value - Islamic finance, not editable for Early Access. | YES | | Allocation method | Specifies the method employed for allocating profits (Select option from drop-down: Average balance *(default)*; Number of accounts; Percentage). Will not have any impact if the pool:income relationship is 1:1. | YES | | Pools | The investment pools that are associated within the profit-sharing system. | YES | #### Allocation method 1. Average Balance (Default): This method calculates profit allocation based on the average balance of accounts over a specified period, typically a day or a month. It ensures that profit distribution reflects the overall balance of accounts during the defined period. 2. Number of Accounts: With this method, profit allocation is determined by the total number of accounts participating in the profit-sharing scheme. Each account receives an equal share of the total profit, regardless of individual balances. It provides a more egalitarian approach to profit distribution. 3. Percentage: This method allocates profit based on the percentage of each account's balance relative to the total balance of all participating accounts. Accounts with higher balances receive a proportionately higher share of the profit, reflecting their greater contribution to the pool of funds. --- # Content Editors URL: https://docs.mambu.com/docs/content-editors/ When defining the contents of automated email notifications, manual email notifications, or product documents, you have access to both a rich text editor and an HTML editor. For more information about these content types, see [Automated Email Notifications](/docs/automated-email-notifications), [Manual Email Notifications](/docs/manual-email-notifications), or [Product Documents](/docs/product-documents). The default editor is the rich text editor, however, you may switch back and forth from the rich text editor to the HTML editor whenever you like. ## Rich text editor The rich text editor provides an interface with clickable options for styling text using things like **bold**, _italic_ and ~~strikethrough~~, as well as to create links, bulleted, or numbered lists. ![notifications--notification-template-editor.png](@site/static/img/support/notifications--notification-template-editor.png) ## HTML editor The HTML editor shows your contents in HTML. This allows you to create much more complex content such as tables, add styling information to change fonts, colours and text sizes, or resize and add alternate text for embedded images. ![notifications--notification-template-html-editor.png](@site/static/img/support/notifications--notification-template-html-editor.png) ## Previewing Content In the case of email templates, you may preview the content by selecting **Preview** at the bottom. This will fill common placeholders with dummy data and provide you with an estimated length of the content. ![notifications--content-editor-preview.png](@site/static/img/support/notifications--content-editor-preview.png) ## Images To add an image, it must be accessible from a secure URL, preferably hosted in a fast CDN, and made publicly accessible, you cannot upload images directly to the document. To add an image: 1. Use the rich text editor and select the image option in the editor toolbar. 1. Enter the URL where the image is stored and save. After adding an image you may want to switch to the HTML editor in order to edit it further using HTML attributes, for example to adjust its size, position or add a clickable link. :::warning Images should always use a secure source. Some email clients will report security warnings, errors, or refuse to display images if they are not coming from a domain using `https`. ::: ## Branding and styling You can customize your CSS by using the `

    A heading

    A paragraph.


    ``` :::note Emails may appear differently on different devices, email clients and software. We recommend checking CSS support with tools such as [Campaign Monitor](https://www.campaignmonitor.com/css/). This can be especially if you want to support responsive design and make sure your emails look just as good on a mobile device as they do on a desktop. ::: To speed up loading of your webpage you can minify your css. There are free online tools such as [cssminifier](https://cssminifier.com/) that you can use for this. If the CSS is complex, for example, you are using different stylesheets for readers using mobile devices than desktop, then it must be in a separate file hosted on a secure, public server and imported using either: ```html ``` :::warning The rich text editor will reflect style choices but the generated preview will not. ::: or: ```html ``` :::note In the examples above we are calling two separate stylesheets just to emphasise the importance of making sure your emails take into account customers could be opening mails on a mobile or desktop device. Your implementation may contain all values in a single stylesheet, or indeed, provide styling for even more use cases, such as print or tablets. ::: ## Accepted tags, attributes and protocols Mambu validates your HTML content and only supports the following whitelist of accepted tags, attributes and protocols. Using a tag or attribute that is not found in the whitelist will result in that section of the document not being generated. **Allowed HTML Tags**: `a`, `b`, `em`, `i`, `u`, `h1`, `h2`, `h3`, `h4`, `h5`, `h6`, `hr`, `ul`, `ol`, `li`, `br`, `p`, `strike`, `blockquote`, `div`, `span`, `img`, `hr`, `tr`, `td`, `th`, `tbody`, `table`, `colgroup`, `col`, `thead`, `pre`, `small`, `s`, `sub`, `sup`, `style`, `link`, `dd`, `dl`, `dt`, `strong`, `caption`, `code`, `title` **Allowed HTML Attributes**: `href`, `target`, `class`, `style`, `title`, `src`, `span`, `align`, `name`, `id`, `height`, `width`, `rel`, `colspan`, `rowspan`, `cellpadding`, `cellspacing`, `alt`, `border`, `valign` **Allowed Protocols for `href` attibutes**: `http`, `https`, `mailto`, `ftp` :::note We do not support the use of JavaScript. ::: --- # Creating an Individual Client URL: https://docs.mambu.com/docs/create-an-individual-client/ Every individual client you create is created from a client type. Make sure to have set up any necessary client types before moving on to individual client creation. For more information, see [Client Types](/docs/client-types). Your user must have the `CREATE_CLIENTS` permission to create individual clients. All the available client types from which you may create an individual client are listed in the **Create** menu in the top bar. ## Creating a client To create a client: 1. On the top menu bar, select **Create** and then select the client type for the client you want to create. 2. Enter all the necessary information in the **Create a Client** form. See below for more details on the fields. 3. Select **Create Client**. ![Create button with the following options Client, Group, Loan Account, Deposit Account and User](@site/static/img/support/clients-and-groups--create-entity-dropdown-menu.png) ## General and Details sections The default **General** and **Details** sections appear in every client creation form for all client types. You may edit the fields included in the section by going to **Administration** > **Fields** > **Clients**. However, you cannot delete these fields. The **Email Address** and **Mobile Phone** fields are used for sending out client communications in Mambu via SMS or email. For more information, see [Communicating with Clients](/docs/notifications-overview). The **Preferred Language** setting sets the language used for all non-user defined fields in client communications such as reports, schedules, and account statements. By default, the preferred language is the same as your Mambu display language, but they may be separately controlled. For more information, see [Language Settings](/docs/language-settings). ![General and Details section in client creation form](@site/static/img/support/clients-and-groups--creating-a-client.png) ## Address section The default **Address** section will only appear on the client creation form if you have selected the **Show default address fields** checkbox for a specific client type. For more information, see [Fields for client types](/docs/client-types#fields-for-client-types). ![Address section in client creation form](@site/static/img/support/clients-and-groups--address-section.png) ## Custom fields Aside from the list of default fields, the client form can be expanded by adding custom field definitions. You can set up different custom field definitions for different client types. For more information, see [Custom fields for clients](/docs/client-types#custom-fields-for-clients) and [Custom Fields](/docs/custom-fields). ## Identification documents The identification documents form is a template-based form for helping you store identification documents for your clients, such as passports or drivers licenses. Each type of identification document is represented by an *ID template*. For more information about setting up and managing the available ID templates, see [ID Templates](/docs/id-templates). Identification documents can either be optional or required. Required identification documents are in the **Creating a Client** dialog by default and have a solid green rectangular outline indicating that they are required fields. To make identification documents required: 1. When managing the client type which you are basing the client you are creating on, you have to select the **Require identification documents** checkbox. 2. When managing the ID template of the identification type you want to require, you have to select the **Mandatory for Clients** checkbox. For more information on making identification documents required, see [Configuring Client Types](/docs/client-types) and [ID Templates - Mandatory for Clients](/docs/id-templates#mandatory-for-clients). You can also add optional identification documents, which are outlined with a grey dotted rectangular outline. ![Identification documents section in Creating a Client dialog with a required identification document and an optional identification document](@site/static/img/support/clients-and-groups--identification-documents.png) To add an optional identification document: 1. Select **Add ID Document**. 2. In the **Add Identification Document** dialog, use the **ID Template** dropdown to select the type of ID document you want to add. You may also have the option to select **Other** and add an ID document that is not based on a predefined template. For more information, see [ID Templates - Enabling other custom templates](/docs/id-templates#enabling-other-custom-templates). 3. Select **Add Document**. 4. Enter the **Document ID** following the Document ID Format and the **Valid Until** date. 5. (Optional) If the ID template allows for attachments then select **Attach File** to attach a file of the identification document. For more information, see [Linking attachments to ID documents](#linking-attachments-to-ids) below. The identification document will be saved when you select **Save Changes** once you have filled out the entire client creation form. ![Add Identification Document dialog](@site/static/img/support/clients-and-groups--add-identification-document.png) To remove an optional identification document select **Delete** . ### Document ID duplication Mambu will validate the **Document ID** number and give you a warning message if there is another client in the system with the same details. ![Document ID duplication warning message](@site/static/img/support/clients_duplicate_id.png) ### Linking attachments to IDs For each identification document recorded on a client, you can upload a copy of the document. In most cases, this will be a scanned image of the physical document. Each identification document recorded in Mambu can have up to five attachments. The uploaded attachment will be visible on the recorded identification document, in client profile overview, next to the identification document name, or in the client attachments tab. They can be downloaded, edited, or removed just like any other attachment. To add an attachment to a document: 1. Select **Attach File** in the identification document template. 2. Enter a title and a description for the file. If no title is provided then the title will be filled in with the filename. 3. Select **Choose File**. The maximum file size is 50 megabytes. 4. Select **Save Changes**. ![Uploading identification document. Maximum allowed size is 50 MB](@site/static/img/support/clients-and-groups--upload-document.png) :::note Identification document files can be attached only when the **Allow Attachments** checkbox is selected for the ID template. For more information, see [ID Templates - Allow Attachments](/docs/id-templates#allow-attachments). Encrypted PDF files will always be rejected, since they cannot be scanned by the system antivirus for malware. Empty files are not allowed. ::: ## Association section Every client can be associated with a single branch, centre, credit officer, and multiple groups. These associations are used for reporting, workflow management, and client account transactions - among other things. Internal control settings are available to determine whether clients should be associated with a branch, centre, or credit officer and also whether they may belong to more than one group. For more information, see [Internal Controls](/docs/internal-controls). ![Association section in client creation form](@site/static/img/support/clients-and-groups--association-section.png) ## Add a profile picture Adding photographs to your clients’ profiles allows you to match faces with names. These photos are displayed on the client's profile page. Profile pictures are visible to everyone who works with that client in the Mambu UI. To add a photo to a client's profile: 1. Open the client's profile. 2. Select **Clients** . 3. Click on **Choose Files** to access an image stored on your device. 4. Click on **Send**. 5. Save the changes. ![Update Client photo by selecting Clients.](@site/static/img/support/clients-and-groups--client-profile-overview.png) To edit or delete a photo, select the photo and then click the **Edit** or the **Delete** button and confirm. ## Add a client signature Signatures can be attached to clients' profiles and used for validation purposes. To upload a signature: 1. Open the client's profile. 2. Under the client's photo, select **signature**. 3. Click on **Choose Files** to upload a file from your computer. 4. Click on **Send**. 5. Save the changes. ![Add client's signature](@site/static/img/support/Add-client-signature.png) To edit or delete a signature, select the signature and then click the **Edit** or the **Delete** button and confirm. :::warning The maximum allowed size for the profile picture and signature upload is 50 megabytes. Images larger than 20 megabytes cannot be previewed and will need to be downloaded to be viewed. ::: ## Warnings Duplicate client checks are an internal control that you can manage. Depending on the settings you have set up for the duplicate client checks, you may receive a warning when creating clients that may be duplicates. For more information, see [Internal Controls - Duplicate Client Checks](/docs/internal-controls#how-can-you-make-sure-you-are-not-creating-a-client-that-already-exists). ![Duplicate client entries](@site/static/img/support/Duplicate-clients.png) --- # Creating a Deposit Account URL: https://docs.mambu.com/docs/creating-a-deposit-account/ Every deposit account you create in Mambu is an instance of a deposit product that has been created before. So, the terms that were set for the product will determine the new deposit accounts' terms and conditions. This allows you to keep all your accounts organised by the products they belong to. Thus you'll be able to compare the performance of your organization's products in the **Reporting** section in Mambu. Therefore, before you create a deposit account, make sure you have already [set up deposit products](/docs/setting-up-new-deposit-products). ## Regular deposit accounts There are different ways of creating a new deposit account for a client. You can either: 1. Click on **Create** > **Deposit Account** on the top menu bar > enter all the account's details > click on **Create Deposit Account**. ![Create button with options like Client, Group, Loan Account, Deposit Account and User](@site/static/img/support/deposits--create-entity-dropdown-menu.png) 2. Click on **New Account** > **New Deposit Account** on the right-hand side of the client's profile > enter all the account's details > click on **Create Deposit Account**. ![Client Profile with New Account drop-down.](@site/static/img/support/deposits--client-profile-overview.png) 3. Create an account using an API call. `POST /deposits` You can find further details about this call in our [API documentation](/api/api-v2/deposits/create/). :::note After the account is created, it needs to be approved before you can start logging transactions. After the first deposit is made, the account becomes active. ::: :::note For Savings Plan and Fixed Deposits, the interest will start being accrued as soon as the account becomes active, even if the maturity period hasn't been activated yet. ::: ### Maximum withdrawal amount Maximum amount that can be withdrawn in one transaction. Please note this is a limit per one withdrawal transaction as opposed to the overall overdraft limit which is defined in the Overdraft limit section. ### Recommended deposit amount In *Savings Account* or *Savings Plan* products, you can determine if there should be a recommended deposit. The amount entered here only serves as a guideline and not as a constraint. The client will still be able to make deposits that fall under or above this value. ### Withholding tax source It is a regulatory requirement in many countries that organizations offering deposit accounts have to pay taxes on the interest generated by those accounts and paid to clients. These are generally called withholding taxes because they are deducted from the interest paid to the client. Withholding tax can be enabled only when: * The **Interest paid into account** checkbox is selected. * Interest calculation method with positive interest rate is selected. Once you enable withholding taxes, you must specify the actual applicable withholding tax source when you open a new deposit account. To do so: * In the **Deposit Account Terms** section of the **Creating a New Deposit Account** form, under **Withholding Tax Source**, select the source you want to use for your deposit account from the list of existing sources previously defined under **Administration** > **Financial Setup** > **Rates**. For more information, see [Customizing Index Interest Rates & Tax Rates](/docs/customizing-index-rates). If you decide to change the withholding tax source after the account is active, you may do so via API v2 by making a `POST` request to the `/deposits/:changeWithholdingTax` endpoint. :::note During the lifecycle of the deposit account, you can remove the withholding tax source via API v2 using an empty string like: `{ "withholdingTaxSourceKey": "" }` Moreover, the changes made to the withholding tax source are stored and the history is available via `GET /deposits//withholdingtaxes?from=&to=&`. ::: After interest is applied on the account, Mambu will post a **Withholding Tax** transaction on the account, that will subtract the tax percentage of the applied interest, from the account balance. :::note * The **Apply Withholding Taxes** option can be disabled even if there are accounts opened using the product. If taxes are disabled, new accounts won't have applicable taxes, but the old accounts will retain them. * If the product has accounting enabled, then a "Taxes Payable" Liability GL Account has to be linked and will be used for booking the amount of taxes withheld and for the government. * The tax percent, source name, and amount are available as placeholders in your contracts, receipts and templates. ::: ## Deposit accounts with overdraft limits To create a new deposit account with an overdraft limit you need to follow the same steps as for any other deposit account and then add the specific terms for the overdraft. ### Overdraft limit This is the maximum amount a client will be able to withdraw from the overdraft account. The overdraft limit defined for a given account cannot be lower than the limit specified in the product setup constraints. The balance of the account can still go beyond this limit in case there's interest or fees added to it. ### Overdraft interest rate This option refers to overdraft products using fixed interest rate. This is the interest rate that will be charged if the account has a negative balance. ### Overdraft interest spread This option refers to overdraft products using index interest rate. This spread will be added to the index rate and the total will define the Overdraft Interest Rate that will be charged if the account has a negative balance. The interest spread can be customized at each account level within the limits defined in the product setup. Additionally, interest spread can still be changed when the account is active, by adjusting the overdraft conditions. :::note When a deposit is made to an overdraft account, interest will be paid first. ::: ### Expiry date After this date no more withdrawals will be possible, and the account will be set to `In Arrears` if it remains negative. --- # Creating a Group URL: https://docs.mambu.com/docs/creating-a-group/ Every group you create is created from a group type. Make sure to have set up any necessary group types before moving on to group creation. For more information, see [Group Types](/docs/group-types). Individual clients are added to a group as members. You may choose to assign group role names to clients. Group role names must be set up before you create or edit the group; for more information, see [Group Role Names](/docs/group-role-names). Your user must have the `CREATE_GROUP` permission to create groups. All the available group types from which you may create a group are listed in the **Create** menu in the top bar. ## Creating a group ![The create menu with group types displayed](@site/static/img/support/clients-and-groups--create-dropdown-menu.png) To create a group: 1. On the top bar, select **Create** and then select the group type you would like to create a group from. 2. Enter all the necessary information in the **Creating a Group** dialog. For more information, see [Fields for groups](#fields-for-groups). This includes assigning members to the group and assigning the group role names to those members. 3. Select **Create Group**. ![Creating a Group dialog](@site/static/img/support/clients-and-groups--creating-a-group.png) ## Fields for groups ### General details The **Group Name** must have a maximum of 255 characters. The **ID** is generated automatically upon creation of a new group. To modify the ID when creating or editing a group, you must have the `EDIT_GROUP_ID` permission. The ID must be unique. ### Adding group members To be part of a group, all members need to have a profile created as individual clients. To add a member to a group: 1. In the **Creating A Group** dialog, under **Group Members**, enter the name of the client you wish to add to the group. As you start typing the client's name, Mambu will automatically provide you with a list of matching names in the system so that you can simply select on the appropriate name in the list. 2. Select **Add Client To Group**. ![Adding John Smith as a member to a group.](@site/static/img/support/clients-and-groups--group-members.png) To remove a member from a group: 1. Hover your mouse over the members name to reveal the delete icon . 2. Select the delete icon . ![Deleting a member from a group.png](@site/static/img/support/Group%2014.png) There are two internal controls that determine whether clients may be in more than one group and the size limit for a group. These internal controls will affect your process of adding clients to a group. For more information, see [Internal Controls](/docs/internal-controls). #### Adding clients to a group upon client creation If you have the `MANAGE_CLIENT_ASSOCIATION` permission you can also add clients to a group as members when you create or edit the clients. In the **Creating A Client** dialog and the **Editing Client** dialog there is an **Association** section where you can assign a client as a member to a group. ![Association section from Creating A Client or Editing Client dialog, from where the clients can be added in specific groups.](@site/static/img/support/clients-and-groups--client-association-settings.png) For audit purposes, an activity will be logged when a client has been added to or removed from a group, which is shown in both the client and the group overview. ### Assigning group role names to group members You must set up any group role names necessary to use them during group creation. For more information, see [Group Role Names](/docs/group-role-names). To assign a group role name to a group member: 1. In the **Creating A Group** dialog, under **Group Roles**, select **Add Group Role**. 2. A row will appear with a **Group Roles** dropdown and a **Members** dropdown. The group roles in the **Group Roles** dropdown and the members in the **Members** dropdown are both displayed in alphabetical order. By default the first item in the list for both dropdowns in selected. 3. Use the **Group Roles** dropdown and the **Members** dropdown to select the group role name you want and the member you want to assign it to. ![Group Roles. Each group member can have a defined role.](@site/static/img/support/clients-and-groups--group-roles-assignment.png) To remove a group role name: 1. Find the row with the dropdowns specifying the member with the assigned group role name that you would like to delete. 2. Select the delete icon next to the row containing the two dropdowns. ### Address The address fields are available if you have selected the **Show default address fields** option for a group type. For more information, see [Fields for group types](/docs/group-types#fields-for-group-types). ### Contact Info The contact info section allows you to specify the mobile phone, home phone, email, and preferred language of a group. For more information about the preferred language, see [Client preferred language](/docs/language-settings#client-preferred-language). ### Assigning groups to branches, centres, and credit officers If you would like to assign a group to a specific branch, centre and credit officer then you can use the **Branch**, **Centre**, and **Credit Officer** fields in the **Association** section to do so. You user must have the `MANAGE_GROUP_ASSOCIATION` permission to have access to this section. ![Create Group - Association section with Branch, Centre and Credit Office](@site/static/img/support/clients-and-groups--create-group-association.png) ### Custom fields If you have set up custom field definitions for groups then you will have the option to enter custom field values for those as well depending on the availability settings for the group types. For more information, see [Custom Fields](/docs/custom-fields). --- # Creating a new credit arrangement URL: https://docs.mambu.com/docs/creating-a-new-credit-arrangement/ A *credit arrangement* is the maximum amount a client can take out in loans and overdrafts. It is similar in function to the *maximum exposure* defined in **General Setup** > **Internal Controls**. The main difference is that a credit arrangement can be extended separately and will be different per client, whereas the maximum exposure is a validation that is pre-set at the system level and is the same for all clients. A client or a group may have multiple credit arrangements, each linked to specific loan and overdraft accounts. Each credit arrangement can have its own constraints, including maximum credit exposure amount and validity dates. The parameters of all loan and overdraft accounts linked to a credit arrangement must be within those constraints. Mambu has added this functionality to give you additional flexibility in creating credit arrangements by combining multiple accounts, including loan and overdraft accounts, into one agreement. ## Create a new credit arrangement Credit arrangements can be defined for each client or group. To create a new credit arrangement: 1. Go to the client or group profile where you want to create a new credit arrangement. 2. On the right-hand side of the screen, select **New Account** > **New Credit Arrangement**. ![New Credit Arrangement option from New Account drop-down](@site/static/img/support/new-credit-arrangement.png) 4. In the **Creating a New Credit Arrangement** dialog, enter all the required information (more details on this below). 5. Select **Create Credit Arrangement**. ![Creating a new credit arrangment dialog.png](@site/static/img/support/Creating%20a%20new%20credit%20arrangment%20dialog.png) ### Amount and validity dates * **Amount**: The maximum exposure amount. * **ID**: Each credit arrangement will be given a unique, automatically generated identifier. The identifier template is predefined at the database level and can only be changed by the Mambu technical team. If you need assistance with this, please contact us through [Mambu Support](/docs/mambu-support). * **Starts From**: Each credit arrangement has a start date and accounts can only be disbursed (loan accounts) or activated (overdraft accounts) after this date. * **Valid Until**: Each credit arrangement has an end date and loan accounts can only be disbursed if the expected maturity, as per the schedule, is before this end date. Similarly, overdraft accounts can only be approved or added if the expiry date is before this end date. * **Notes**: Include any additional information about the credit arrangement. ### Exposure limits When creating a new credit arrangement, you must select the type of exposure limit against which the credit arrangement will be validated. The options available in the **Credit Arrangement Exposure Limit validated against** dropdown are: * **Original (approved) loan/overdraft amount**: The maximum credit exposure of all loan and overdraft accounts original loan amounts linked to the credit arrangement. The sum of original loan amounts and total overdraft limits may not be in excess of the credit arrangement amount. * **Current (outstanding) loan/overdraft balances**: The maximum credit exposure of all loan and overdraft accounts' current balances linked to the credit arrangement. The current outstanding loan/overdraft balance is the sum of all current loan accounts' balances and total overdraft balances. ### Loans in Multicurrency If you have the **Loans In Multicurrency** feature enabled, then you may also define the currency for the credit arrangement. The currencies available will be the ones you have set up for your tenant. For more information, see [Currencies](/docs/currencies). You will only be able to link loan and overdraft accounts that are in the same currency as the credit arrangement itself. ## Get the consolidated schedule of a credit arrangement You can get the schedule of all the accounts under a credit arrangement, ordered by installment due date, by making a `GET` request to the `/creditarrangements//schedule` endpoint. For more information, see [Get schedule](/api/api-v2/creditarrangements/get-schedule) in the API reference. ## Considerations when using credit arrangements The following considerations should be kept in mind when handling credit arrangements: * Clients and groups can have more than one credit arrangement. * Clients and groups may have some accounts linked to a credit arrangement and at the same time accounts outside of the credit arrangement. * Only the outstanding funds of the linked accounts are considered in the validations of the credit arrangement exposure limit. * Each new credit arrangement is given a default ID, which you can change when create or when you edit it. * Loans with multiple tranches will only have the first tranche dates validated against the credit arrangement constraints, since the other tranches are not firmly confirmed when the account is created. --- # Creating a New Loan URL: https://docs.mambu.com/docs/creating-a-new-loan/ Every loan account you create in Mambu is an instance of a loan product that has been created before. So, the terms that were set for the product will determine the terms and conditions for the new loan accounts. This allows you to keep all your accounts organised by the products they belong to. Thus you'll be able to compare the performance of your organization's products in the **Reporting** section in Mambu. Therefore, before you create a loan account, make sure you have already [set up loan products](/docs/setting-up-new-loan-products). There are different ways of creating a new loan account in Mambu. You can either: 1. Go to the top bar and select **Create** > **Loan Account** > enter all the account's details > select **Create Account**. ![Loan Account creation from Create button top bar.](@site/static/img/support/loans--create-dropdown-menu.png) 2. Select **New Account** > **New Loan Account** on the right-hand side of the client's profile > enter all the account's details > select **Create Account**. ![Loan Account creation from Clients' Profile](@site/static/img/support/loans--client-profile-overview.png) 3. Create a loan account via the API. For more information, see our [API Reference](/api/api-v2/loans/create) ## Account terms The loan amount and interest rate are automatically populated with the default values defined at the product level. You can leave them as they are or change the values but make sure they are within the defined constraints of the product. Enter the repayment frequency, the arrears tolerance period, and the arrears tolerance amount of your account. ## Disbursement details In this section, select the channel of the disbursement, the anticipated disbursement date, and the first repayment date of the loan. ### Offset of the first installment due date When you create a new loan, Mambu automatically sets the first repayment date after one repayment interval, meaning after 1 month, 2 weeks, and so on, from the disbursement date. In addition to this interval you can also have a default offset to the first installment due date. The offset limits are set at the product level and the validation will be done when you set the first repayment date either when creating the account or when disbursing it. ![Disbursement Details section from Loan Account creation with Channel drop-down, Anticipated Disbursement and First Repayment Date](@site/static/img/support/loans--disbursement-details.png) #### Example A loan with monthly repayments has an anticipated disbursement date on December 1, 2019. * Regular first repayment date, without a default offset: January 1, 2020. * With a 10 days default offset, Mambu will add 10 days to the regular first repayment date: January 11, 2020. * If the product has a minimum offset of 2 days, the first repayment date will have to be on or after January 3, 2020 (Image above). * If the product has a maximum offset of 20 days, the first repayment date can't be after January 21, 2020. Based on the account terms and anticipated dates, you can finally preview the schedule with the detailed repayments divided in principal and interest, total amounts due and how the balance evolves over the loan duration. ## Planned fees Planned fees are manual fees that can be set up in advance and added to the due date of future installments of all product types except for Revolving Credit. First you must define planned fees at the product level, then you can configure all the fees you wish to apply at the account level, in the **Planned Fees** section of the **Creating a new loan** form. To add the fees, simply enter the fee amount in the appropriate cell, then select **Apply to selected installments**. ![Theplanned fees section of the Creating a new loan form showing all the fees per installment](@site/static/img/support/planned-fees-loan-account.png) ## Loans with tranched disbursements When you create a new loan account using a product that accepts disbursement in multiple tranches, the amounts that are expected to be disbursed in each tranche must be specified in the **Tranches** section, with an expected disbursement date for each tranche. ![Tranches section at Loan Account creation with three tranches defined each with amount and anticipated disbursement](@site/static/img/support/loans--tranches-configuration-3.png) The repayment schedule calculated for a loan account with multiple disbursements will include the additional tranches as defined above, assuming that they will be released on the anticipated disbursement date: ![Schedule Preview section at Loan Account creation for the specified number of tranches and anticipated disbursement dates.](@site/static/img/support/loans--schedule-preview-7.png) The resulting loan account will have the information about pending tranches displayed in the **Overview** section and will be activated when the first tranche is disbursed by selecting the **Disbursement** button on the right-hand side of the account's overview page. In the **Schedule** tab at the loan account level, the principal and interest that are due will be displayed based on the tranches that were already disbursed, but you can always toggle the schedule view options under **Preview Schedule With**, to check what the schedule will look like after a future tranche will be disbursed. :::note You can add new tranches, delete existing tranches, and edit details - such as the amount or the disbursement date - in the same API v2 call. For more information, see [Loan Account Tranches](/api/api-v2/loans_tranches/loans-tranches). ::: ## Schedule preview In the **Schedule Preview** section, you can generate a preview of the expected repayment schedule by simply selecting **Preview Schedule**. ## Association Optionally, you can associate a loan account to a branch. In order to do that, you must have the **Manage Loan Association** permission. ![Association section with Maputo Downtown branch.](@site/static/img/support/loans--loan-association-settings.png) The branch to which the loan account is assigned can be viewed in the loan account overview page under the **General** section as seen in the below image. ![General details from Loan Account dashboard](@site/static/img/support/loans--loan-account-general-details.png) ## Solidarity group loans If you're opening an account for a solidarity group, this means that its members may receive different amounts and that their accounts will be tracked individually. In this case, you need to specify the amount that each member will receive. To do this enter the amount for each member. As you do this you can see that the amount that is still unallocated is updated at the bottom. For more information about solidarity groups, see [Loans for Groups](/docs/types-of-loan-groups). --- # Creating Deposit Accounts With Profit Sharing URL: https://docs.mambu.com/docs/creating-deposit-accounts-with-profit-sharing/ Accounts with profit-sharing capabilities are created in the same way as interest-based accounts. For more information on creating an account, refer to [Creating a Deposit Account](/docs/creating-a-deposit-account). Customer accounts are linked to Shari'ah-based products at creation, after which they will be visible in the list of accounts associated with the product. A product can have any number of linked accounts. To view the accounts linked to a product, in the **Products** section of **Profit Sharing**, click **Actions** > **View accounts**. ![view accounts](/img/support/view-accounts-profit-sharing.png) ## Common parameters The fields available in a Shari'ah-based account are restricted compared to an interest-based account. Users can enter the following fields, depending on the product type: * Product association * ID * Name * Maximum Withdrawal Amount * Recommended Deposit Amount * Whether the account permits technical overdrafts * Account Notes * Deposit account custom fields ## Shari'ah attributes The Shari'ah attributes can be added to the product in Profit sharing functionality (please check **Profit Sharing process** in **Configuration** section). --- # Creating a User URL: https://docs.mambu.com/docs/creating-new-users/ A *user* is anyone who accesses and uses Mambu via the UI or the API. Each user has a user account that stores the access credentials, the details of the person using the system, the role, and the permissions. A list of users can be found at **Administration** > **Access** > **Users**. The **Users** tab under **Administration** > **Access** and the **Users** option under the **Create** menu in the top bar are only visible if your user has the appropriate permissions assigned to them. For more information, see the [Permissions for managing users](#permissions-for-managing-users) section. ## Permissions for managing users The following permissions are required for you to be able to perform the relevant management actions on users: * `CREATE_USER` * `EDIT_USER` * `VIEW_USER_DETAILS` * `DELETE_USER` :::warning For security reasons, we recommend controlling which users have role and user management permissions. For more information, see [Limiting role and user management permission assignment](/docs/understanding-users-roles-and-permissions#limiting-role-and-user-management-permission-assignment). ::: ## Creating a user To create a user: 1. Either go to the top bar and select **Create** > **User**, or on the main menu, got to **Administration** > **Access** > **Users** and select **Create New User**. 2. In the **Create A New User** dialog, enter all the necessary information. For more details on the fields in the various sections of the form, see below. 3. Select **Save User**. ![Users screen. All defined users are displayed here](@site/static/img/support/users-and-access-control--users-list.png) ## General section | Name | Comments | Required | | --- | --- | --- | | First Name | Maximum length of 255 characters. | YES | | Last Name | Maximum length of 255 characters. | NO | | Title | Maximum length of 255 characters. | NO | | Role | If you assign a role, then the **User Rights** and **Permissions** sections of the form are pre-filled with the settings of the role, and you will no longer be able to manually edit them. For more information, see [Roles](/docs/roles).| NO | ## User Rights section ### Type Under the **User Rights** section, you can select an optional user **Type**. There are three options for types: **Administrator**, **Teller** and **Credit Officer**. A user that has one of these types has special characteristics that will be described below. ![User rights section from Create user view](@site/static/img/support/users-and-access-control--user-rights-assignment.png) #### Administrators Administrators have all permissions and can perform any action in Mambu. Only administrators can create or edit other admins. Selecting the **Administrator** checkbox removes the **Permissions** section from the **Creating a New User** form. Administrators have all the permissions of the credit officer and teller user types. Administrators also have additional access permissions in Mambu that are not available to non-administrators and which cannot be assigned as granular permissions. For example, administrators have access to the usage rights settings of saved custom views. For more information, see [User types and saved custom views](/docs/custom-views#user-types-and-saved-custom-views). Regular users can be granted certain administrator rights by either assigning a role or assigning granular permissions under the **Permissions** section. #### Credit officers Credit officers have the option of having clients and groups assigned to them, this relationship allows for better reporting and client management. #### Tellers Tellers have access to the teller module. Special tellering permissions give them access to the different actions available on this module, for example opening or closing tills, posting transactions on a till, and adding and removing cash from a till. ### Access Rights Under the **User Rights** section you can select the **Access Rights**. There are two different access rights types Mambu and API. #### Mambu The Mambu access type is for regular Mambu UI users. **Mambu** access allows the user to log in to Mambu via the regular web user interface, using their login credentials. #### API API access allows the user to authenticate and interact with Mambu using APIs. Like other user types, API users also require the necessary user permissions to perform a desired action. Transactions posted by API users are kept in the logs in the same way as user actions from regular users. For more information on API authentication at Mambu, see [Authentication](/api/pages/api-v2/authentication) in our API Reference. If you have federated authentication enabled, please see [Managing Users under Federated Authentication - API Users](/docs/managing-sso-provisioned-users#api-users) for information on how to create a user with API access. If you have API consumers enabled, you won't be able to add the `API` permission when creating a new user, but you may edit any existing user to add the permission. ## Permissions A user in Mambu may be assigned permissions either directly or through a role. However, a single user cannot be assigned permissions in both ways. If you do assign a role to a user, you may assign granular permissions to them. Note that some permissions are provided by roles that cannot be assigned directly to users. We recommend assigning permissions to users through roles because it allows for more control over access in Mambu. For more information, see [Access managed by role](/docs/understanding-users-roles-and-permissions#access-managed-by-role). To assign granular permissions to a user: 1. Select **Permissions**. 2. Check the boxes next to the permissions that you wish to assign to the user. 3. Select **Save User**. For more information, see [Understanding Users, Roles, and Permissions](/docs/understanding-users-roles-and-permissions) and [Permissions](/docs/permissions). ![User permissions. Each permission contains other permissions that have specific actions.](@site/static/img/support/users-and-access-control--permissions-configuration.png) ### Permissions for managing users The following permissions are required for a user to be able to perform the relevant management actions on a user account: * `VIEW_USER_DETAILS` * `CREATE_USER` * `EDIT_USER` * `DELETE_USER` If these permissions are not assigned to a user, that user will not be able to see the **Users** tab under **Administration** > **Access** and the **Users** option under the **Create** menu in the top bar. ## User Access Under the **User Access** section you can enter the information the new user will need to login to Mambu. ### Username (required) Usernames must be unique and they cannot be changed. ### Email The email address is required for using the "Forgot your password?" link in the login screen. The password recovery email will be sent to this address. The **Email** field is not yet required but we strongly advise to fill it in as it might become mandatory in the future. ### Password (required) When you create your password, the system will show you how safe it is. The minimum number of characters for your password is defined in **Administration** > **Access** > **Preferences**. The password must contain at least one digit and one letter. ### Two Factor Authentication For additional security, two factor authentication can be enabled for users that have Mambu UI access. Only Administrator users can setup two factor authentication for other users. To enable two factor authentication for a user select the **Two Factor Authentication** checkbox under **User Access**. Then, ensure that you add a mobile phone number in the [**Contact**](#contact) section. ![Enabling two factor authentication a new user.](@site/static/img/support/mpo-enabling-2fa-1530x708.png) When this setting is enabled, users will be sent an SMS on their registered mobile number, which they will need to enter in the Mambu login screen in addition to their password. An SMS gateway needs to be defined to be able to use two factor authentication. For more information, see [SMS Gateway Setup](/docs/sms-setup). ### Mambu Display Language This setting configures the language used to display menus and options in Mambu for the user. The default language selected is English. For more information on how to edit the Mambu display language and how it affects the language settings for your clients, communications, and more, see [Language Settings](/docs/language-settings). ![Change language drop-down](@site/static/img/support/users-and-access-control--user-access-settings.png) ## Contact Under the **Contact** section you can enter your mobile phone number and home phone number. ## Assigned To Users can be associated with a specific branch, allowing access to that branch and its clients and information. The **Branch** field defines the branch to which the user belongs. To assign the user to a branch, choose the branch from the list. Branch assignment is mandatory for users with the credit officer or teller user type. :::note If you have federated authentication enabled, then you must perform branch assignment using your identity provider (IdP). Branch assignment using the Mambu UI or API v2 is not possible. For more information, see [Managing Users under Federated Authentication - Branch assignment](/docs/managing-sso-provisioned-users#branch-assignment). ::: ## Access Rights The **Access Rights** section determines which branches a user can access. If the **Can access clients and accounts data for all branches** checkbox is selected then the user has access to this data for all branches. If the **Can access clients and accounts data for all branches** checkbox is not selected then you can select individual branches that the user will have access to. In order to select an individual branch select the branch from the **Branch** dropdown. The branch will then appear in the **Branch access** area. If the user is assigned to a branch, the assigned branch will appear pre-selected in the Branch access area. If your user is a Credit Officer then you will have an additional **Can access other credit officers clients** check box. This option gives the new user access to all clients and accounts assigned to: - The other credit officers in their assigned branch. - Credit officers who are not assigned to any branch. ![Assigned to and access rights sections for credit officer](@site/static/img/support/assigned_to_and_access_rights_for_credit_officer.png) Users who have access to more than one branch can switch between those branches using the Branch filter on the top left of the interface. Users who only have access to one branch, will have their default branch pre-selected in their Branch view and will not have the "All Branches" filter. For more information, see [Managing Multiple Branches](/docs/branches-and-centres). ## Transactions Limits For any user who doesn't have Administrator permissions, you can set maximum amounts on transactions. There are six different transaction types that you can set a limit to: Loan Approval, Loan Disbursement, Fee Application, Entry of Deposits, Withdrawals, and Repayments. To set a limit on transactions a user can perform: 1. Under **Transaction Limits**, select **Add Limit**. 2. Choose the transaction type from the dropdown menu. 3. Enter the limit amount for that transaction. ![Transaction limits can be set for Approve Loan, Disburse Loan, Apply fee, Make Deposit, Make Withdraw, Make Repayment](@site/static/img/support/users-and-access-control--transaction-limits.png) ## Custom fields If you need to capture additional information about the users, you can create custom field definitions under **Administration** and add them to the users' profiles when creating a new user. For more information, see [Custom Fields](/docs/custom-fields). ## Other users During the onboarding process we create some users to assist you with onboarding and support cases. For more information on the **Mambu Delivery** user, see [Mambu Delivery users while onboarding](/docs/mambu-support#mambu-delivery-users-while-onboarding). For more information on the **Mambu Support** user, see [Granting access to your account with the Mambu Support user](/docs/mambu-support#granting-access-to-your-account-with-the-mambu-support-user). --- # Creating Profit Sharing Accounts URL: https://docs.mambu.com/docs/creating-profit-sharing-accounts/ A Profit-Sharing Accounts is created in two places. Conventional Account parameters: These parameters are the same as those used in regular accounts Find more information here. Example - the Name, notes, custom field value etc. Profit Sharing Account parameters: Currently, it is not possible to configure these parameters. Example - Customer/Bank share %, Fixed or Capped rate rule etc. --- # Creating your Chart of Accounts URL: https://docs.mambu.com/docs/creating-your-chart-of-accounts/ The *Chart of Accounts (CoA)* is the basis of your organization's accounting. Here you will have all the accounts you need to keep track of the transactions taking place in your organization. The CoA also makes sure that transactions are organized logically in the general ledger (GL); so you can always access these accounts and identify if the books are unbalanced. ![The Chart of Accounts view with All, Assets, Liabilities, Equity, Income, and the Expenses tabs](@site/static/img/support/chart-of-accounts-view-3348x1240.png) You can create the CoA manually, or you can migrate an existing chart of accounts using an Excel template and our migration tool. For more information on this method, see our article on [importing your data from Excel](/docs/importing-your-data-via-excel). ## Chart of Accounts Structure The CoA is structured around two different types of GL accounts, called header and detail accounts. Detail accounts store the transaction balances. Whereas header accounts are used to group detail accounts into categories and have no transactions associated to them. For instance, **Current Assets** could be a header account and **Bank Account** would be one of its detail accounts. The **GL Code** of the accounts will determine which detail accounts are nested under which header accounts, and the overall position of a GL account in the CoA. ### Basic GL code principles * The digits of the GL code dictate the GL account hierarchy within the CoA. * The first digit shows the initial hierarchy and position, the second level of hierarchy and so on. * Header accounts sum up every other GL account starting with their same hierarchy level. | If a header account is | It will sum up detail/header accounts with codes | | --- | --- | | 10000 | 1xxxx | | 11000 | 11xxx | | 11100 | 111xx | :::warning The example above assumes that all header accounts are set to ignore trailing zeroes. See the [ignore trailing zeros](#ignore-trailing-zeros) section for more details on this option. ::: An example of GL code rules in a Chart of Accounts with a four-tier structure is given below. Header accounts are in orange:
    10000   Assets
    11000   Fixed Assets
    11001   Cars
    11002   Furniture
    12000   Short Term Assets
    12100   Cash
    12101   Cash Branch 1
    12102   Cash Branch 2
    12200   Bank
    12201   Bank 1
    12205   Bank 2
    ## Adding a new account To add a new account to your CoA: 1. On the main menu, go to **Accounting** > **Chart of Accounts**. 2. On the right-hand side of the screen, select **Add a New Account**. ![Chart of Accounts tab - Income Tab - Add a New Account button.](@site/static/img/support/accounting--chart-of-accounts-income-category.png) 3. Fill in the following information: * **Account Name**: Enter the name you want to have associated to the new account. The name should be short but clear so that other users know exactly which account it refers to. * **GL Code**: The general ledger code number for the account. This determines the position of the account in the heirarchy of the CoA. * **Type**: Choose whether the new account is an Asset, Liability, Income, Expense, or Equity. * **Usage**: Choose whether this will be a header or a detail account in your financial reports. Header accounts are used to organise and group any detail accounts under them for reporting purposes. * **Currency**: When the Accounting in Multicurrency feature is enabled, you can select the currency of the account. * **Allow Manual Journal Entries**: When enabled, you can manually add new journal entries to this account from the Journal Entries tab. This option is only available for detail accounts. * **Ignore Trailing Zeros in Reports Calculations**: See the [ignore trailing zeros](#ignore-trailing-zeros) section for more details on this option. This option is only available for header accounts. * **Description**: You can add any additional information you want to have associated to the new account. 4. After you've entered the information above, select **Create** and the new account will be added to your CoA. ![The 'Adding a General Ledger account' dialog box](@site/static/img/support/add-general-ledger-account-1428x1384.png) ## Ignore Trailing Zeros By default **Ignore Trailing Zeros** will be enabled, meaning that if you had a header account with the GL Code `9900`, balances from any detail accounts starting with `99`, for example `99023`, `9945`, or `990067` would be included when calculating totals for this Header Account. If the option is disabled, then the trailing zeros would not be ignored when matching to detail accounts so only the balance of the account `990067` would be summed up for this header. ### With Ignore Trailing Zeros enabled for header account Header account `9900` sums all accounts starting with `99`. | GL Code | Account Name | | | --- | --- | --- | | **Assets** | | | | 9900 | trailing zeros asset header | (41,000.00) | | 990067 | trailing zeros detail 3 | (16,000.00) | | 99023 | trailing zeros detail 1 | (12,000.00) | | 9945 | trailing zeros detail 2 | (13,000.00) | | | **TOTAL ASSETS** | **(41,000.00)** | ### With Ignore Trailing Zeros disabled for header account Header account `9900` only sums accounts starting with `9900`. | GL Code | Account Name | | | --- | --- | --- | | **Assets** | | | | 9900 | trailing zeros asset header | (16,000.00) | | 990067 | trailing zeros detail 3 | (16,000.00) | | ~~99023~~ | ~~trailing zeros detail 1~~ | ~~(12,000.00)~~ | | ~~9945~~ | ~~trailing zeros detail 2~~ | ~~(13,000.00)~~ | | | **TOTAL ASSETS** | **(16,000.00)** | Depending on how your Chart of Accounts is structured, you can decide which option works best for you when setting up your general ledger accounts. ## Editing Accounts You can edit an existing account at any time. You can change the name, description and code of the GL accounts. To do so, click on the icon next to the account you want to edit, make the changes, and click Save to save your changes. The changes will be reflected in all transactions which occurred before and after editing the account. ![Edit GL Accounts - pencil button found on each row.](@site/static/img/support/accounting--chart-of-accounts-list.png) :::note You cannot change the accounts' Usage or Type, meaning you won't be able to turn a Header account into a Detail account, an Asset into a Liability, or vice versa. ::: ## Deleting accounts You can delete an existing GL account by clicking the red minus sign next to it. ![Delete GL Accounts - minus button found on each row](@site/static/img/support/accounting--chart-of-accounts.png) :::warning You can only delete accounts which have never been used. This means accounts that have not been linked to any product and have no manual journal entries entered for them. ::: --- # Credit arrangement states URL: https://docs.mambu.com/docs/credit-arrangement-states/ A *Credit Arrangement* is a maximum amount a client (individual, group or company) can take out in loans and overdrafts. ## Set the initial state of a credit arrangement Credit arrangements can be set up to transition between the `Pending Approval` and `Approved` states. To set the initial state of a credit arrangement: 1. On the main menu, go to **Administration** > **General Setup** > **Internal Controls**. 2. Select the **New Credit Arrangement Initial State** to be either `Pending Approval` or `Approved`. 3. Select **Save Changes**. If you set the configuration above to `Pending Approval`, then all credit arrangements will be created with this state and will require user approval. You must have the **Approve Credit Arrangements** permission enabled in order to approve a credit arrangement. ## Pending approval These are the actions possible on credit arrangements in the `Pending Approval` state, and their corresponding permissions: | Action | Required Permission | | --- | --- | |Undo approval|**Undo Approval Credit Arrangement**| |Close (withdraw)|**Withdraw Credit Arrangements**| |Undo withdraw|**Undo Withdraw Credit Arrangements**| |Close (reject) |**Reject Credit Arrangements**| |Undo reject|**Undo Reject Credit Arrangements**| :::note A credit arrangement must first be approved before you can add accounts to it. You can't add accounts to a credit arrangements that is in the `Pending Approval` state. ::: Activities will be captured on the account every time a credit arrangement transitions between states. Rejecting or withdrawing a credit arrangement is only possible from the `Pending Approval` state. ## Approved A credit arrangment in the `Approved` state is considered an active credit arragnement. Active credit arrangements can no longer be withdrawn or rejected. It is also not possible to edit the terms of credit arrangements in the `Closed (Withdrawn)` or `Closed (Rejected)` states. :::warning Once accounts have been added to a credit arrangement, the credit arrangment can no longer be deleted. ::: *** --- # Currencies URL: https://docs.mambu.com/docs/currencies/ You can set up and manage your currencies via the Mambu UI at **Administration** > **Financial Setup** > **Currency** or via the [Currencies](/api/api-v2/currencies/currencies/) endpoint in API v2. You may define three types of currencies in Mambu: fiat currencies, cryptocurrencies, and non-traditional currencies. The CasC for currencies feature currently supports fiat currencies only. It does not support cryptocurrencies or non-traditional currencies. For more information, see [Currencies Configuration](/docs/configuration-as-code-for-currencies). For more information on the permissions needed to manage currencies, see the [Permissions](/docs/permissions) article. ## Fiat currencies *Fiat currencies* are internationally-accepted currencies that are usually issued by a government or central bank. They are included in the [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) currency list. You can define deposit products in multiple fiat currencies and perform transactions in those currencies. In order to support deposit products in different fiat currencies, you must first add all relevant currencies and set their respective exchange rates. ![Currency tab under Financial Setup in Administration screen.](@site/static/img/support/managing-your-organization--currency-management-table.png) ## Cryptocurrencies and non-traditional currencies *Cryptocurrencies* are digital currencies that can be used to buy goods and services, and which use a distributed ledger with strong cryptography to secure online transactions. Cryptocurrencies are usually built on top of blockchain technology. The cryptocurrency integration allows you to configure up to five cryptocurrencies in Mambu. These currencies are fully integrated with Mambu’s ledger capabilities, allowing you to create cryptocurrencies and track balances of client accounts - including balances and transactions per client. Mambu seamlessly integrates with external exchanges for crypto trading and external custody providers for blockchain access. *Non-traditional currencies* refers to alternative stores of value that are not covered by the fiat currency and cryptocurrency types, such as: * Defining and handling loyalty points, such as Amazon Coins or Starbucks Stars. * Pseudo-currencies used in markets with high inflation rates, such as the [Unidades de Inversion (UDIs)](https://en.wikipedia.org/wiki/Mexican_unidad_de_inversi%C3%B3n) used in Mexico for investments that are protected against inflation. ### Development status Cryptocurrencies and non-traditional currencies are currently in development. They are not yet available by default. Mambu plans to support a variety of cryptocurrencies such as coins, central bank digital currencies (CBDCs), and tokens. If you are interested in using either cryptocurrencies or non-traditional currencies or both, please contact your Customer Success Manager to discuss your requirements. ## Base currency Your organization will have one base currency, which must be a fiat currency. We will set it up with you during your initial onboarding. The base currency is distinguished from any other currencies in the Mambu UI with the label **BASE**. If you add additional fiat currencies, you must specify exchange rates and accounting rates with respect to your base currency. For more information, see [Exchange rates](#exchange-rates) below and [Accounting Setup](/docs/accounting-setup). ## Managing fiat currencies ### Adding a fiat currency You may add additional fiat currencies besides your base currency. To add a fiat currency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. Under **Currencies In Use**, select **Add Fiat Currency**. 3. In the **Add Fiat Currency** dialog, use the **Preset** dropdown to select the currency you would like to add. The list of currencies and their respective codes is in line with [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html). 4. In the **Add Fiat Currency** dialog, you may edit the name, symbol, and symbol position. See [Fields for fiat currencies](#fields-for-fiat-currencies) for more details. 5. Select **Save Changes**. ![Add Fiat Currency Dialog](@site/static/img/support/managing-your-organization--add-fiat-currency.png) Once a fiat currency is added, it is added to the **Currencies In Use** table at **Administration** > **Financial Setup** > **Currency**, with the type set to **Fiat Currency**. ### Fields for fiat currencies | Field | Description | Required | | --- | --- | --- | | Name | Name of the currency. Maximum length of 256 characters. | Yes | | Code | Code for the currency. Determined by the [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) predefined currency list. It is not possible to edit this value. | Yes | | Symbol | Symbol for the currency. Maximum length of 10 characters. | Yes | | Decimal Digits | The number of digits after the decimal. It is not possible to edit this value. | Yes | | Symbol Position | The position of the symbol. The options are before number or after number. The default is before number.| No | ### Editing a fiat currency You can edit the name, symbol, and symbol position of a fiat currency. To edit a fiat currency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. In the list of currencies, find the currency that has type **Fiat Currency** that you would like to edit. 3. Select **Actions** > **Edit**. 4. In the **Edit Fiat Currency** dialog, make any necessary changes. 5. Select **Save Changes**. ### Deleting a fiat currency You may only delete fiat currencies that have not been used in financial products or transactions. The base currency cannot be deleted. To delete a fiat currency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. In the list of currencies, find the currency that has type **Fiat Currency** that you would like to delete. 3. Select **Actions** > **Delete**. 4. In the **Delete** dialog, select **Delete**. ## Managing cryptocurrencies You can add, edit, and delete cryptocurrencies. ### Adding a cryptocurrency To add a cryptocurrency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. Select **Add Cryptocurrency**. 3. Enter all the necessary information, see [Fields for cryptocurrencies](#fields-for-cryptocurrencies) for more details. 4. Select **Save Changes**. ![Add Cryptocurrency dialog](@site/static/img/support/managing-your-organization--add-cryptocurrency.png) Once a cryptocurrency is added, it is added to the **Currencies In Use** table at **Administration** > **Financial Setup** > **Currency**, with the type set to **Cryptocurrency**. ### Fields for cryptocurrencies | Field | Description | Required | | --- | --- | --- | | Name | Name of the currency. Maximum length of 256 characters. | Yes | | Code | Code for the currency. Maximum length of 32 characters. Must only contain letters, numbers, and underscores. | Yes | | Symbol | Symbol for the currency. Maximum length of 32 characters. | Yes | | Decimal Digits | The number of digits after the decimal. Must be a number between 0 and 20. | Yes | | Symbol Position | The position of the symbol. The options are before number or after number. The default is before number. | No | ### Editing a cryptocurrency You may edit all the cryptocurrency fields except for the code. To edit a cryptocurrency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. In the list of currencies, find the currency that has type **Cryptocurrency** that you would like to edit. 3. Select **Actions** > **Edit**. 4. In the **Edit Cryptocurrency** dialog, make any necessary changes. 5. Select **Save Changes**. ### Deleting a cryptocurrency To delete a cryptocurrency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. In the list of currencies, find the currency that has type **Cryptocurrency** that you would like to delete. 3. Select **Actions** > **Delete**. 4. In the **Delete** dialog, select **Delete**. ## Managing non-traditional currencies You can add, edit, and delete non-traditional currencies. ### Adding a non-traditional currency To add a non-traditional currency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. Select **Add Non-Traditional Currency**. 3. Enter all the necessary information, see [Fields for non-traditional currencies](#fields-for-non-traditional-currencies) for more details. 4. Select **Save Changes**. ![Add Non-Traditional Currency Dialog](@site/static/img/support/managing-your-organization--add-non-traditional-currency.png) Once a non-traditional currency is added, it is added to the **Currencies In Use** table at **Administration** > **Financial Setup** > **Currency**, with the type set to **Non-Traditional Currency**. ### Fields for non-traditional currencies | Field | Description | Required | | --- | --- | --- | | Name | Name of the currency. Maximum length of 256 characters. | Yes | | Code | Code for the currency. Maximum length of 32 characters. Must only contain letters, numbers, and underscores. | Yes | | Symbol | Symbol for the currency. Maximum length of 32 characters. | Yes | | Decimal Digits | The number of digits after the decimal. Must be a number between 0 and 20. | Yes | | Symbol Position | The position of the symbol. The options are before number or after number. The default is before number. | No | ### Editing a non-traditional currency You may edit all the non-traditional currency fields except for the code. To edit a non-traditional currency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. In the list of currencies, find the currency that has type **Non-Traditional Currency** that you would like to edit. 3. Select **Actions** > **Edit**. 4. In the **Edit Non-Traditional Currency** dialog, make any necessary changes. 5. Select **Save Changes**. ### Deleting a non-traditional currency To delete a non-traditional currency: 1. On the main menu, go to **Administration** > **Financial Setup** > **Currency**. 2. In the list of currencies, find the currency that has type **Non-Traditional Currency** that you would like to delete. 3. Select **Actions** > **Delete**. 4. In the **Delete** dialog, select **Delete**. ## Exchange rates The *exchange rate* defines how much a currency is worth in the base currency. For each new fiat currency that you add, you must also set its exchange rate. Each exchange rate has a buy rate, a sell rate, and the date from which it is valid (**Date Set**). You may set the exchange rate either via the UI or the API. Note that when you configure the exchange rate with the UI, the date from which the exchange rate is valid is always set automatically, but it can be manually configured via the API - see below for more information. For permissions needed to manage *exchange rates* plase check Permission article. [Permissions article.](/docs/permissions) ### Setting an exchange rate via the UI :::note The exchange rate section is only visible in the Mambu UI once you have more than one currency set in your system. ::: To set the exchange rate via the UI: 1. On the main menu, go to **Administration** > **Financial setup** > **Currency**. 2. Under **Exchange Rates**, find the currency you're interested in and, on the right-hand side of the row, select **Actions** > **Set rate**. 3. Set the **Buy Rate** and the **Sell Rate** from the new currency to the base currency. 4. Select **Save changes**. When setting up an exchange rate via the UI, the date from which it is valid (**Date Set**) is automatically set as the time and day you set the exchange rate. The date-time format is determined by the organization settings you have set up. For more information, see [Organization Contact Details and Time Zone](/docs/organization-contact-currency-and-timezone). ### Setting an exchange rate via the API For more information on setting up an exchange rate via API, see [Update Currency Exchange Rate](/api/api-v1/currencies/update-currency-exchange-rate) in our API Reference for API v1. When setting up an exchange rate via the API, you may backdate the date from which the exchange rate is valid (**Date Set**), which is represented by the `startDate` parameter in the body of the API request. :::warning Once you set an exchange rate, you may no longer change the valid from date to an earlier date than the date that was set initially. This may have implications if you need to backdate transactions. ::: ## Setting up the accounting rate For information on setting up the accounting rate, [Accounting Setup](/docs/accounting-setup). --- # Custom fields and custom views for credit arrangements URL: https://docs.mambu.com/docs/custom-fields-and-custom-views-for-credit-arrangements/ A *credit arrangement* is the maximum amount a client - individuals, groups, or companies - can take out in loans and overdrafts. ## Adding custom field definitions Custom fields are additional fields you can create in Mambu to capture any additional information required for your business processes. You can create custom field definitions for credit arrangements which will appear in the forms you use to create and edit credit arrangements. For more information, see [Custom Fields](/docs/custom-fields). ## Custom views for credit arrangements :::warning To view credit arrangements menu items and custom views your user has to have the **View Credit Arrangements Details** (VIEW_LINE_OF_CREDIT_DETAILS) permission and you have to have the **Credit Arrangement** feature enabled for your tenant. ::: *Custom views* are used to generate reports on the fly and easily get filtered lists of information. Creating custom views allows you to display a custom interface within Mambu alongside built-in views for quick access. ### Saved custom views Saved custom views are accessible from menu items in the navigation bar. You can create a credit arrangement menu item and create saved custom views to assign to it. For more information, see [Menu Items](/docs/menu-items) and [Custom Views](/docs/custom-views). ![Credit arrangements menu item in navigation bar with a saved custom view](@site/static/img/support/credit-arrangements--credit-arrangements-saved-custom-view.png) ### Temporary custom views You can create temporary custom views for credit arrangements by using the **View** menu in the top bar. For more information, see [Temporary custom views](/docs/custom-views#temporary-custom-views). ![Credit arrangement option in view menu from top bar](@site/static/img/support/credit-arrangements--top-navigation-dropdown-menu.png) ### Example An example of a custom view for a credit arrangement is to set a filter to retrieve a list of clients where the consumed credit amount is more than USD49,999.00. This would mean they have an exposure of more than USD50,000.00. ![Credit arrangement custom view example](@site/static/img/support/image%20%281%29.png) --- # Custom Fields Quota Announcement URL: https://docs.mambu.com/docs/custom-fields-quota-announcement/ ## **Custom Fields Quota Announcement** ## Mambu is dedicated to enhancing the performance of our platform to provide an even better experience for our valued customers. As part of this commitment, we are implementing limits to [custom fields](/docs/custom-fields?utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz--9vUGDBA97uhJma-zullVoyjtMUFXkZ34juyeCJ205_kioDziehEuEROzEslZq8hVXBYMP) as a proactive measure that will not only safeguard system performance, but also effectively mitigate the potential risks of overloading it. These changes will ensure a more streamlined user experience. **What are the changes?** A core component of the Mambu platform is the custom fields functionality, which consists of: Custom field definitions: The field you create, such as 'Country of Residence' Custom field values: The actual value it holds, such as 'Germany'. We plan to introduce limits to the number of custom field values that can be linked to an entity. This limitation applies only to the number of custom field values linked to an entity, and not to the number of custom field definitions that can be configured. These changes will be effective starting from end of Q2 2024 in sandbox and beginning of Q3 2024 for production, ensuring a more efficient and streamlined user experience for everyone. | Entity | Maximum linked custom field values | | --- | --- | | Assets | 200 | | Branches | 200 | | Centres | 200 | | Clients | 200 | | Credit Arrangements | 200 | | Deposit Accounts | 200 | | Deposit Products | 200 | | Groups | 200 | | Guarantors | 200 | | Loans Accounts | 200 | | Transaction by Channel | 25 | | Transaction by Type | 25 | | Users | 200| **What are the actions you need to take?** The entities that already exist in the system will remain as they are and we will continue to support read operations for them. However, you won’t be able to update an entity that has exceeded the limit of custom field values attached to it, unless you remove linked custom field values to go below the limit. We advise that you re-audit all your entities and remove custom field values where your entities are linked to more than the allowed amount. --- # Custom Fields URL: https://docs.mambu.com/docs/custom-fields/ Custom fields are a powerful and flexible way to extend the core functionality of Mambu to reflect your specific business needs. A *field* is a value associated with a Mambu entity such as a client, group, or loan account. For example, the client entity includes several default fields for storing information about each client, such as *ID*, *Email Address*, and *Created* date. We refer to the fields we provide by default as *native fields*. For some entities, you may create *custom fields* to capture additional relevant information. Most custom fields are grouped together in *custom field sets*, and access to custom fields can be restricted to certain roles. ## Custom field definition and custom field value When it comes to custom fields, we distinguish between the custom field definition and the custom field value. The *custom field definition* is the custom field you create - using either the Mambu UI or API - which contains information such as its name, ID, type, and usage settings. For example, you can create a selection custom field for the clients entity called "Country of Residence". For more information on creating custom field definitions, see [Creating a custom field definition](#creating-a-custom-field-definition). The *custom field value* is the actual value that a custom field attached to an entity holds. For example, you may have a client called "Peter Piper" for whom the "Country of Residence" custom field definition contains the custom field value "Zimbabwe". ### Introducing Custom Field Values Quotas We are introducing limits to custom fields as a proactive measure that will safeguard system performance and effectively mitigate the potential risks of overloading it. These changes will be effective starting from end of Q2 2024 in sandbox and beginning of Q3 2024 for production, ensuring a more efficient and streamlined user experience for everyone. This limitation only applies to the number of custom field values linked to an entity, and not to the number of custom fields definitions that can be configured. These are the technical limits that will be applied per entity: | Entity | Maximum linked custom field values | | --- | --- | | Assets | 200 | | Branches | 200 | | Centres | 200 | | Clients | 200 | | Credit Arrangements | 200 | | Deposit Accounts | 200 | | Deposit Products | 200 | | Groups | 200 | | Guarantors | 200 | | Loans Accounts | 200 | | Transaction by Channel | 25 | | Transaction by Type | 25 | | Users | 200| #### What happens to the current custom field values? The entities that already exist in the system will remain as they are and we will continue to support read operations for them. However, you won’t be able to update an entity that has exceeded the limit of custom fields values attached to it, unless you remove linked custom field values to go below the limit. We advise that you re-audit all your entities and remove linked custom field values where your entities are linked to more than the allowed amount. ## Custom field management Custom field definitions and custom field values may be managed via the Mambu UI and Mambu API v2. Custom field value management: * In the Mambu UI, you may edit custom field values in various the various forms that they show up. For example, client custom field values will appear on a client detail page. * Via Mambu API v2, you may retrieve and manipulate custom field values using various endpoints. For more information, see [Using Custom Fields](/api/pages/api-v2/using-custom-fields) in our API Reference. Custom field definition management: * In the Mambu UI, go to **Administration** > **Fields**. * Via the API, use the [Custom Field Configuration API v2 endpoints](/api/api-v2/configuration_customfields/configuration-customfields). ## Custom field definition permissions To view, create, edit, and delete custom field definitions, you must have the appropriate permissions: * **View Custom Fields** (`VIEW_CUSTOM_FIELD`) * **Create Custom Fields** (`CREATE_CUSTOM_FIELD`) * **Edit Custom Fields** (`EDIT_CUSTOM_FIELD`) * **Delete Custom Fields** (`DELETE_CUSTOM_FIELD`) The **Fields** tab will only be visible if you have at least one of the custom field definition permissions. For more information, see [Permissions](/docs/permissions). :::note These permissions control your ability to view and modify the custom field definitions themselves, not the custom field values. For more information on managing which users can manage custom field values, see the [Configuring rights for roles](#configuring-rights-for-roles) section. ::: ## Entities with custom field definitions Custom field definitions can be created for the following entities: * Clients * Groups * Loan Accounts * Deposit Accounts * Deposit Products * Credit Arrangements * Guarantors * Assets * Branches * Centers * Users * Transaction by Channel * Transaction by Type :::note Custom field definitions for **transactions by type** are only available for transfers. No other transactions without transaction channels are supported. If you would like to have custom field definitions on more types of transactions, please contact us through [Mambu Support](/docs/mambu-support). ::: ![Administration screen with Fields tab selected](@site/static/img/support/managing-your-organization--custom-fields-configuration-3.png) ### Custom field definition granularity Some entities that support custom field definitions allow you to use granular usage settings to control in which forms they will appear based on the *type* of entity. For example, if you create a new custom field definition for clients called "Student ID", you may choose to make it a required custom field definition for student client types and an unavailable custom field definition for all other client types. For more information, see [Usage settings](#usage-setting-parameters). The table below lists which entities offer such custom field definition granularity: | Custom Field Entity | Optional granularity | | --- | --- | | Clients | Per client type. | | Groups | Per group type. | | Loan accounts | Per loan product. | | Deposit accounts | Per deposit product. | | Deposit products | Per deposit product type.| | Transaction by Channel | Per transaction channel. | | Transaction by Type | Per transaction. | ## Custom field sets Custom field sets allow you to group custom field definitions together. Each custom field definition is grouped by its custom field set in the relevant forms. :::note The guarantors and assets entities are the only entities that do not have custom field sets. ::: ### Creating a new custom field set To create a new custom field set: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to add a custom field set to. 3. Select the **Add** icon . 4. Enter all the necessary information. See below for more information on [fields for custom field sets](/docs/custom-fields#fields-for-custom-field-sets). 7. Select **Save Changes**. ![Create New Custom Field Set dialog](@site/static/img/support/managing-your-organization--create-new-custom-field-set.png) ### Fields for custom field sets | Name | Description | Required | | --- | --- | --- | | Name | The name for the custom field set. | Yes | | ID | The ID used to reference this custom field set using the API. If this field is left blank, an ID will be automatically generated. The ID always starts with an underscore. | No | | Type | **Standard** and **Grouped**. For more information, see [Custom field set types](#custom-field-set-types). | Yes | | Notes | Notes about the custom field set. | No | ### Custom field set types There are two types of custom field sets: standard and grouped. A standard custom field set can contain multiple custom field definitions. Each custom field definition will only appear once in the form. Therefore, you can store only one custom field value for a specific custom field definition. A grouped custom field set can contain multiple custom field definitions. Each custom field group can appear multiple times in the form. Therefore, you can store multiple custom field values for a specific custom field definition. #### Grouped custom field sets The following is an example of a grouped custom field set. Suppose you want to track information about a client’s bank accounts. You can create a **Bank Accounts Information** grouped custom field set with four custom field definitions: **Bank Name**, **Bank Branch**, **Account Number**, and **Account Type**. To add a new bank account, the user would select **Add Bank Accounts Information**, and a new empty subset containing the four required custom field definitions will be added. ![Example of the Bank Accounts Information group custom field set in the client creation form](@site/static/img/support/managing-your-organization--bank-accounts-information.png) If a grouped custom field set contains one or more required custom field definitions, Mambu will automatically add the whole subset of custom field definitions when a new client or account is created. Grouped custom field definitions can be used in contracts and notifications templates and can be indexed. For example, to include the first and second value for the clients custom field definition “Bank Account”, the template should contain `` and ``. :::warning Be aware of the following: * The only way to add or update custom field values in grouped custom field sets is by editing the entity. * Custom field values in grouped custom field sets cannot be used in custom views or edited directly in the **Overview** or **Details** screens or added with the **Add Field** option. ::: ### Rearranging custom field sets You can rearrange all the custom field sets except for the **General** and **Details** custom field sets, which are always the first two sets in the list. The order of custom field sets will affect the order in which these appear in forms in Mambu. To rearrange custom field sets: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to rearrange the custom field set for. 3. Select the **Custom View** icon . 4. Rearrange the custom field sets in the order you want. 5. Select **Save Changes**. ### Editing custom field sets To edit a custom field set: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to edit a custom field set for. 3. In the **Custom Field Set** dropdown, select the custom field set you want to edit. 4. Select the **Edit** icon . 5. Edit the custom field set. 6. Select **Save Changes**. ### Deleting a custom field set To delete a custom field set: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to delete a custom field set for. 3. In the **Custom Field Set** dropdown, select the custom field set you want to delete. 4. Select the **Delete** icon . :::note Only custom field sets that contain no custom field values can be deleted. ::: ## Creating a custom field definition All custom field definitions must belong to a custom field set, except for custom field definitions associated with guarantors and assets, which do not support custom field sets. Therefore, you must first create a custom field set and thereafter you may create custom field definitions. To create a custom field definition: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to create a custom field definition for. 3. In the **Custom Field Set** dropdown select the custom field set you want your custom field definition to belong to. 4. Select **Add Custom Field**. 5. Enter the information in the **General**, **Display**, **Usage**, **Rights**, and **Description** sections. For more on these sections, see (Fields for custom field definitions)[#fields-for-custom-field-definitions]. 6. Select **Create**. ![Adding a custom field definition in a custom field set.](@site/static/img/support/managing-your-organization--custom-fields-administration.png) ## Fields for custom field definitions ## General section | Name | Description | Required | | --- | --- | --- | | Name | The name for the custom field definition. | Yes | | ID | The ID used to access this custom field definition using the API. If this field is left blank, an ID will be auto generated. | No | | Custom Field Set | The custom field set you are creating a custom field definition for. | Yes | | Custom Field Set Type | The entity for which you are creating a custom field definition. This field will be pre-filled depending on which entity tab you selected when creating the custom field definition. | Yes | ## Display section This section describes the type of custom field definitions you can create. ### Available for all checkbox The **Available for all** checkbox allows you to set basic usage settings for entities that also support granular usage settings, and it is only available for these entities. For more information, see [Custom field definition granularity](#custom-field-definition-granularity) and [Basic and granular usage settings](#basic-and-granular-usage-settings). ![Example of Available for all checkbox selected which then enables basic usage settings](@site/static/img/support/managing-your-organization--custom-field-configuration.png) ### Custom field type There are nine types available for custom field definitions: free text, selection, number, checkbox, date, date and time, client link, group link, and user link. They each have the **Long Field** checkbox available. This option allows the UI to display long custom field value content more elegantly. However, it does not change the maximum length of a custom field value - which is 2048 characters. ### Free text custom field definitions A custom field definition with type *free text* allows you to create a manually enter a custom field value. ![The display section of the custom field creation form when selecting the free text type](@site/static/img/support/managing-your-organization--free-text-custom-field-display-configuration.png) #### Format The **Format** field allows you to specify an input mask for format validation. If left blank, any text can be entered. For example, if you want to collect British phone numbers, you could set the format to **+44##########**. #### Unique Value The **Unique Value** checkbox allows you to specify that the custom field value must be unique. If the custom field value already exists, Mambu will return the error `926 DUPLICATE_UNIQUE_VALUE` and will not allow the entity to be saved. For example, if phone numbers are being used for multi-factor authentication, you may want to require unique phone numbers. ### Selection custom field definition A custom field definition with type *selection* allows you to create a dropdown with multiple predefined options. A user can then select one of the predefined options. To add options to a selection custom field definition: 1. Next to **Label**, enter the option name. 2. Select the **Add** icon . :::warning You can create as many options as you need for a selection custom field definition. However, a maximum of 20 options are displayed in the Mambu UI. If you need to enter the custom field value of an option that is not displayed, then you must enter the value manually in the selection custom field definition bar and it will come up as a search option. ::: A possible use case for the selection custom field definition is if you need to capture information about a loan's source of funds. You could then use a predefined selection field to enter different custom field value options, such as `Local NGO`, `Individual Lender`, and so on. To move the options up or down according to the order you want them to be displayed, use the blue arrows. ![Selection custom field definition with options that have IDs](@site/static/img/support/image%20%281%29%281%29.png) #### Selection option ID When creating a selection option, you can enter an ID value, which must only consist of alphanumeric characters, dashes, and underscores. The value is displayed in angle brackets `<>` next to the option in the list. If no value is entered, then the system will automatically generate a nine character numeric ID for you. We recommend setting IDs for custom field value options if you are planning on migrating configurations across environments, such as using configuration files so your settings remain consistent. For more information, see [Custom Fields Configuration](/docs/configuration-as-code-for-custom-fields). :::note When using Mambu API v2, both the option value and the option ID of a selection custom field value option are returned. The option value can change; therefore, we recommend using the option ID when implementing integrations in your system. ::: #### Dependent custom field definitions The **Dependent Field** dropdown is only available if your custom field set contains another custom field definition that has the *selection* type. Use a **dependent custom field definition** if the custom field value of the selection custom field definition you are creating is dependent on a custom field value in another selection custom field definition. In this case, the custom field definition that your dependent custom field definition depends upon is called the **parent custom field definition**. An example of creating a dependent custom field definition is if you have a parent custom field definition called "Country" with two custom field value options: Poland and Greece. There could be a dependent custom field definition called "City" which has custom field value options "Warsaw" and "Krakow" when Poland is selected, but "Athens" and "Mykonos" if Greece is selected. Dependent custom field definitions inherit the usage settings - one of **Available**, **Required**, or **Default** - of their parent custom field definition. :::warning Parent custom field definitions must come before their dependent custom field definitions in the custom field definition order. You can change the order of custom field definition by clicking **Rearrange** from the custom field set list and using drag and drop to achieve the desired order. For more information, see the [rearranging custom field definitions](#rearranging-custom-field-definitions) section. ::: #### Scores on custom field values You can associate numeric values with each of the custom field value options available for selection custom field definitions including dependent custom field definitions. The score is displayed in brackets `()` next to the custom field value option in the list. When adding a custom field value with a score to an entity, the score will be displayed in brackets next to the field and a total score will be provided. This score is the sum of all scores in that custom field set. An example use case for this is calculating social performance indicators for your clients. ![Selection custom field with option Yes/No and score](@site/static/img/support/image%20%282%29.png) ### Number custom field definitions A custom field definition with type *number* allows you to create a field in which only numbers can be entered. For example, you may wish to create a custom field definition for the number of children in a household. ### Checkbox custom field definitions A custom field definition with type *checkbox* allows you to create a field where there are only two possible answers which indicate whether an option is chosen or not. For example, you may wish to create a checkbox custom field definition for loan accounts to generate a checklist of requirements needed for the approval process - such as Business data collected: (yes/no), House inspected: (yes/no), and so on. ### Date custom field definitions Allows you to store a date which will follow the format you have configured for your organization at **Administration** > **General Setup** > **Organization Details**. For more information, see [Managing organization details using Mambu UI](/docs/organization-contact-currency-and-timezone#managing-organization-details-using-mambu-ui). For example, you may want to store the expiration date for an identification document or you may want to store the date of birth for your individual clients. ### Date and Time custom field definitions Allows you to store both a date and time which will follow the format you have configured for your organization at **Administration** > **General Setup** > **Organization Details**. For more information, see [Managing organization details using Mambu UI](/docs/organization-contact-currency-and-timezone#managing-organization-details-using-mambu-ui). For example, you may want to create a custom field definition to capture the exact date and time that a loan officer contacts a client to follow up on a loan account's status. #### Client, Group, and User Link custom field definitions These custom field definition types allow for the selection of a client, group, or user that is already created in the system. The field allows you to search for any existing client, group, or user by name or ID. For example, if you have a client that was referred by another client, you could use the client link to store this information. ## Usage section This section describes usage settings available when creating a custom field definition. ### Usage setting parameters **Available**, **Default**, and **Required** are three adjustable usage settings which allow you to create four custom field definition usage types: unavailable custom field definitions, available custom field definitions, default custom field definitions, and required custom field definitions. | Custom field definition usage type | Available | Default | Required | | --- | --- | --- | --- | | Unavailable custom field definition | No | No | No | | Available custom field definition | Yes | No | No | | Default custom field definition | Yes| Yes| No | | Required custom field definition | Yes| Yes| Yes| :::note All default custom field definitions are also marked as **Available**. All required custom field definitions are marked as **Default** and **Available**. ::: ### Basic and granular usage settings Entities can either have basic usage settings or granular usage settings. For more information, see the [Custom field definition granularity](#custom-field-definition-granularity) section. The following entities support either basic usage settings or granular usage settings: * Clients * Groups * Loan accounts * Deposit accounts * Deposit products * Transaction by Channel * Transaction by Type The following entities only support basic usage settings: * Credit Arrangements * Guarantors * Assets * Branches * Centres * Users #### Basic usage settings Basic usage settings allow you to set the usage type of a custom field definition for an entity as a whole. All custom field definitions for these entities are available upon creation; therefore, you only have to edit the **Default** and **Required** usage setting. The credit arrangements, guarantors, assets, branches, centres, and users entities use basic usage settings. ![Usage for an entity with basic usage settings](@site/static/img/support/managing-your-organization--custom-field-usage-settings.png) To enable them to have basic usage settings you must select the **Available for all** checkbox in the **Display** section. After enabling basic usage settings for a custom field definition, any granular usage settings you may have set previously are not saved. #### Granular usage settings Granular usage settings allow you to specify the usage settings for certain item types within an entity. For example, a custom field definition for clients may be available for **Prospect** client types, but not for **Student** client types. ![Usage for a client custom field definition](@site/static/img/support/managing-your-organization--custom-field-usage-configuration.png) If you select the checkbox right under either of these settings - one of **Available**, **Required**, or **Default** - then this selects that setting for all the item types of that entity. Entities that use granular usage settings also allow you to filter custom field definitions in the custom field definitions list page by selecting an item type using either the **Filter for** or **Available For** dropdowns. ![Filter for dropdown allows you to filter custom fields by item type](@site/static/img/support/managing-your-organization--custom-fields-configuration.png) ### Custom field definition example In the example, we use an example custom field definition for the client entity called **Student ID Number** - which belongs to a custom field set called **Student Profile**. We will cover all the different usage setting configurations. #### Unavailable custom field definition Unavailable custom field definitions will not be visible on any relevant forms and you will not be able to add them to those forms. ![Custom field definition does not have any settings selected](@site/static/img/support/managing-your-organization--custom-field-usage-configuration-3.png) ![The Student ID Number custom field definition is not available in the form](@site/static/img/support/1%281%29.png) #### Available custom field definitions Available custom field definitions may be added to any relevant forms by selecting **Add Field** in the appropriate custom field set section. ![Custom field definition has available setting selected](@site/static/img/support/managing-your-organization--custom-field-usage-configuration-5.png) ![The Student ID Number custom field definition is available in the form to be added](@site/static/img/support/image%202.png) #### Default custom field definition Default custom field definitions are included in relevant forms by default. ![Custom field definition has available and default setting selected](@site/static/img/support/managing-your-organization--custom-field-definition-usage.png) ![The Student ID Number custom field definition is included in the form by default](@site/static/img/support/3%282%29.png) #### Required custom field definitions Required custom field definitions are included in relevant forms by default and have a green outline indicating they are mandatory. ![Custom field definition has available, default, and required setting selected](@site/static/img/support/managing-your-organization--custom-field-usage-settings-3.png) ![The Student ID Number custom field definition is a required field in the form](@site/static/img/support/4.2.png) :::note In both the Mambu UI and the Mambu API, a custom field set is required if you have at least one required custom field definition. This applies to both standard and grouped custom field sets. For example, if you have at least one required custom field definition in a grouped custom field set, then you must add at least one group with the required custom field definition filled in. ::: ## Configuring rights for roles In the **Rights** configuration section, you can define the roles with the right to enter custom field values for a particular custom field definition. These roles will be able to enter information for a custom field in the forms it appears in. :::warning This section only defines which roles will have access to enter custom field values. This does not affect which users can manage the custom field definition itself. For more information, see [Custom field definition and custom field value](#custom-field-definition-and-custom-field-value) and [Custom field definitions](#managing-custom-field-definitions). ::: ![Example of rights section with list of user roles](@site/static/img/support/managing-your-organization--custom-fields-rights-management.png) Selecting the checkbox under either the **View** or the **Edit** options will select those options for all the roles in the list. If a new role is created then this new role will also have view and/or edit rights to the custom field value. If the checkboxes under either the **View** or **Edit** options are not selected then you can select the specific roles for which you would like to assign view or edit rights for the custom field value. New roles will not have view or edit rights automatically assigned to them. If a role has edit rights then it automatically has view rights. The reverse is not true, you may grant view rights to a custom field value without assigning edit rights. :::warning If a user creating an item in an entity does not belong to a role that has edit rights to a custom field value, they will not be able to see or edit the custom field value, even if it is required. They will be able to save the item in the entity despite the missing required information. ::: ## Managing custom field definitions ### Editing, deleting, or deactivating custom field definitions To edit, delete, or deactivate a custom field definition: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to edit, deactivate, or delete a custom field definition for. 3. If relevant, select the custom field set you would like to edit, deactivate, delete a custom field definition for. 4. In the list of custom field definitions, find the custom field definition you would like to edit, deactivate, or delete and select **Actions** and then the relevant action. Editing a custom field definition will bring up the custom field definition form. Make any necessary changes and select **Save Changes**. Deactivating a custom field definition will not affect any existing custom field values entered for the custom field definition. You will no longer be able to enter any additional custom field value for this custom field definition. To view all the deactivated custom field definitions, select the **Show Disabled Fields** checkbox. You may only delete custom field definitions for which no custom field value has been entered. ### Rearranging custom field definitions To rearrange the order of custom field definitions: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the entity you would like to rearrange the custom field definitions for. 3. Select **Rearrange**. 4. Drag and drop the custom field definitions to the order you want. 5. Select **Save Changes**. Rearranging custom field definitions affects the order in which they appear in relevant forms. :::note For dependent custom field definitions, the dependent field must always be below the parent custom field definition in the order. ::: ![Rearrange custom field definitions. Change the order of the custom field definitions.](@site/static/img/support/managing-your-organization--arrange-custom-fields.png) ## Custom field definitions as placeholders The custom field definitions you create are also available as placeholders which you can include in your contracts, statements, or receipts. For example, if you create a custom field definition for "Occupation" and you want to include the stored custom field value in the client's contract. When creating the contract's template you will be able to choose the placeholder **Occupation** from the list and the corresponding custom field value will be automatically filled when the contract is printed for that specific client. For more information on how to use the placeholders in contract templates, see [Product Documents](/docs/product-documents). --- # Custom reports starting kit URL: https://docs.mambu.com/docs/custom-reports-starting-kit/ ## Overview Follow the examples below to get familiar with reports created over Mambu. Observe their requirements and results. Take a step further by importing and have them running on your own machine! ## Setup ![developer--jaspersoft-studio-report-designer-preview.png](@site/static/img/support/developer--jaspersoft-studio-report-designer-preview.png) * Make sure the [software requirements](/docs/software-requirements) were considered and a [data adapter](/docs/data-adapter) was created. * [Export the data](/docs/database-clone) from one of your developer or sandbox environments and [import it](/docs/import-database-clone) on your own machine. * Download any of the reports from below and open them in Jaspersoft Studio (**File Menu** > **Open File**). * Explore the sources (Design Tab) and preview them (Preview Tab) by using the data source that points to the previous database. *** ## Showcase * [Loans in Arrears](/docs/loans-in-arrears) * [Transactions per Account](/docs/transactions-per-account) * [Client Custom Fields](/docs/client-custom-fields) * [Clients by State](/docs/clients-by-state) * [Paginated Report](/docs/paginated-report) *** --- # Custom Views and API v1 URL: https://docs.mambu.com/docs/custom-views-and-api-v1/ ## Custom Views and Mambu API v1 Custom views are used to configure the Mambu UI, to quickly generate reports, and for data extraction with the Mambu v1 API. This document provides a guide to using custom views for data extraction - that is, filtering `GET` request results with the Mambu v1 API. For general information on custom views, see our [Custom Views](/docs/custom-views) article. In Mambu API v2, a similar data extraction functionality is provided by filtering query results using search endpoints. For more information, see "Sorting and filtering with Search Endpoints" in the [Pagination](/api/pages/api-v2/pagination) section of our API v2 Reference. ## Operations There are two general request types available related to custom views in API v1: * [Get entities filtered by a specified custom view](#get-entities-filtered-by-a-specified-custom-view) * [Get custom views for a specified user](#get-custom-views-for-a-specified-user) For all operations that require specifying a particular custom view, the custom view is identified by the *custom view encoded key*. You can retrieve the encoded key for a custom view by calling the [get custom views for a specified user](#get-custom-views-for-a-specified-user) endpoint, specifying your own user name to limit results to custom views you have access to. ## Get entities filtered by a specified custom view In API v1, custom views can be useful for filtering query results to retrieve a specified subset of information. For example, if you set up a custom view to show all loans in arrears, then you generate a `GET` request for all loans, and filter the results with that custom view's encoded key. The API will then return all loans in arrears. This operation may be used for any entity that has custom views available. See [API operations](#api-operations) below for more details. If you wish, you may further filter query results using pagination parameters. For more information on pagination parameters, see [Pagination](/api/pages/api-v1/pagination) in our API v1 Reference. :::note When getting a custom view, the roles that can see the view (`"roleKeys"`) are available in the `"viewRights"` JSON object. If you are using the roles that can see a custom view, please update to the new JSON structure, as the `roleKeys` array is deprecated. ::: ### GET queries with filtered results Send a `GET` query to the following endpoints to return all relevant entities that match the specified custom view. For example, a `GET` request to `/api/clients?viewfilter=1234` will return all clients who are included in the custom view with encoded key `1234`. | Entity | Endpoint | | --- | --- | | clients | `/api/clients?viewfilter=` | | groups | `/api/groups?viewfilter=` | | lines of credit | `/api/linesofcredit?viewfilter=` | | loans | `/api/loans?viewfilter=` | | loan transactions| `/api/loans/transactions?viewfilter=` | | deposits | `/api/savings?viewfilter=` | | deposit transactions | `/api/savings/transactions?viewfilter=` | | system activities | `/api/activities?viewfilter=` | For more detailed information on each specific endpoint, see the appropriate section of our [API v1 Reference](/api/pages/api-v1/welcome). ### viewfilter query parameter (required) All requests must include the required `viewfilter` path parameter, with a value set to the custom view `encodedKey`. ### resultType query parameter (optional) You may use the `resultType` query parameter to define what detail level you want to retrieve for your custom view results. The following values are supported for the optional `resultType` query parameter: | Value | Description | | -- | -- | | `FULL_DETAILS` | Returns all associated objects, such as custom field values and ID documents. | | `BASIC` | Returns a summary of the objects (default view). | | `SUMMARY` | Returns an object with the count for the custom view (number of items) and the totals for all custom view columns that accept totals. | ### Request examples #### Get results with full details of a loan custom view ```json [ { "encodedKey": "8a19aad77801888d017801f0dd841c1d", "state": "ACTIVE", "id": "190955698", "creationDate": "2021-03-05T10:31:05+0000", "lastModifiedDate": "2021-11-18T09:19:13+0000", "approvedDate": "2021-03-05T10:31:05+0000", "activationDate": "2021-11-18T09:19:13+0000", "firstName": "John ", "lastName": "Smith ", "mobilePhone1": "0044 6471372644", "gender": "MALE", "notes": "This is our client.", "loanCycle": 0, "groupLoanCycle": 0, "preferredLanguage": "ENGLISH", "clientRole": { "encodedKey": "8a194df577c9c1300177cf333078007c" } }, { "encodedKey": "8a19b9b77d6f89ce017d712371cb45c8", "state": "ACTIVE", "id": "711683516", "creationDate": "2021-11-30T13:58:08+0000", "lastModifiedDate": "2021-12-01T07:42:17+0000", "approvedDate": "2021-12-01T07:07:16+0000", "activationDate": "2021-12-01T07:42:17+0000", "firstName": "Mary ", "lastName": "Poppins", "notes": "", "loanCycle": 0, "groupLoanCycle": 0, "preferredLanguage": "ENGLISH", "clientRole": { "encodedKey": "8a194df577c9c1300177cf333078007c" } }, { "encodedKey": "8a19d7c27c7da1c4017c82b698435703", "state": "ACTIVE", "id": "544142722", "creationDate": "2021-10-15T07:30:45+0000", "lastModifiedDate": "2022-02-23T11:00:17+0000", "approvedDate": "2021-10-15T07:30:45+0000", "activationDate": "2022-02-23T11:00:17+0000", "firstName": "Poppy", "lastName": "Smith", "notes": "", "assignedBranchKey": "8a19d2417886f5be01788732e92b01e6", "loanCycle": 0, "groupLoanCycle": 0, "preferredLanguage": "ENGLISH", "clientRole": { "encodedKey": "8a19c63f7c49441e017c4a05834b0bd3" } }, { "encodedKey": "8a194df577c9c1300177cf3339630082", "filter": { "encodedKey": "8a194df577c9c1300177cf3339630084", "filterConstraints": [ { "encodedKey": "8a194df577c9c1300177cf3339630085", "dataFieldType": "NATIVE", "dataItemType": "CLIENT", "dataType": "ENUM", "dataFieldValue": "CLIENT_STATE", "filterElement": "IN", "value": "ACTIVE", "linkingOperator": "AND", "groupNumber": 10, "index": 0 } ] }, "columnConfiguration": { "encodedKey": "8a194df577c9c1300177cf333aad0087", "fieldColumns": [ { "encodedKey": "8a19dab27be82f7c017bed8863c208d8", "dataField": "FULL_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208d9", "dataField": "ID", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208da", "dataField": "CLIENT_STATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208db", "dataField": "CREDIT_OFFICER_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208dc", "dataField": "LOANS_BALANCE", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c508dd", "dataField": "DEPOSITS_BALANCE", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c508de", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" } ], "includeTotals": true, "includeTimestamp": false, "sortingOrder": "DESCENDING" }, "customConfigurationInfo": { "encodedKey": "8a194df577c9c1300177cf3339630086", "name": "Active", "dataViewType": "CLIENT", "indexInList": -1, "creationDate": "2021-02-23T14:02:57+0000", "lastModifiedDate": "2021-09-16T07:35:44+0000" }, "viewMode": "LIST", "parentMenuItemKey": "8a194df577c9c1300177cf3334e60080", "viewRights": { "encodedKey": "8a194df577c9c1300177cf3339630083", "isAccessibleByAllUsers": true, "roles": [] } }, { "encodedKey": "8a194df577c9c1300177cf333ab20090", "filter": { "encodedKey": "8a194df577c9c1300177cf333ab50092", "filterConstraints": [ { "encodedKey": "8a194df577c9c1300177cf333ab50093", "dataFieldType": "NATIVE", "dataItemType": "CLIENT", "dataType": "ENUM", "dataFieldValue": "CLIENT_STATE", "filterElement": "EQUALS", "value": "INACTIVE", "linkingOperator": "AND", "groupNumber": 0, "index": 0 } ] }, "columnConfiguration": { "encodedKey": "8a194df577c9c1300177cf333ab50095", "fieldColumns": [ { "encodedKey": "8a194df577c9c1300177cf333ac40097", "dataField": "FULL_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ac40098", "dataField": "ID", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ac40099", "dataField": "CLIENT_STATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ac4009a", "dataField": "CREDIT_OFFICER_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009b", "dataField": "TOTAL_BALANCE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009c", "dataField": "PENDING_LOAN_AMOUNT", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009d", "dataField": "APPROVED_LOAN_AMOUNT", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009e", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" } ], "includeTotals": true, "includeTimestamp": false, "sortingColumn": { "encodedKey": "8a194df577c9c1300177cf333ac40096", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" }, "sortingOrder": "DESCENDING" }, "customConfigurationInfo": { "encodedKey": "8a194df577c9c1300177cf333ab50094", "name": "Inactive", "dataViewType": "CLIENT", "indexInList": -1, "creationDate": "2021-02-23T14:02:57+0000", "lastModifiedDate": "2021-02-23T14:02:57+0000" }, "viewMode": "LIST", "parentMenuItemKey": "8a194df577c9c1300177cf3334e60080", "viewRights": { "encodedKey": "8a194df577c9c1300177cf333ab50091", "isAccessibleByAllUsers": true, "roles": [] } }, { "encodedKey": "8a194df577c9c1300177cf333acc009f", "filter": { "encodedKey": "8a194df577c9c1300177cf333acf00a1", "filterConstraints": [ { "encodedKey": "8a194df577c9c1300177cf333acf00a2", "dataFieldType": "NATIVE", "dataItemType": "CLIENT", "dataType": "ENUM", "dataFieldValue": "CLIENT_STATE", "filterElement": "EQUALS", "value": "PENDING_APPROVAL", "linkingOperator": "AND", "groupNumber": 0, "index": 0 } ] }, "columnConfiguration": { "encodedKey": "8a194df577c9c1300177cf333acf00a4", "fieldColumns": [ { "encodedKey": "8a194df577c9c1300177cf333ad900a6", "dataField": "FULL_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ad900a7", "dataField": "ID", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ad900a8", "dataField": "CLIENT_STATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ad900a9", "dataField": "CREDIT_OFFICER_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333adc00aa", "dataField": "CREATION_DATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333adc00ab", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" } ], "includeTotals": true, "includeTimestamp": false, "sortingColumn": { "encodedKey": "8a194df577c9c1300177cf333ad900a5", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" }, "sortingOrder": "DESCENDING" }, "customConfigurationInfo": { "encodedKey": "8a194df577c9c1300177cf333acf00a3", "name": "Pending Approval", "dataViewType": "CLIENT", "indexInList": -1, "creationDate": "2021-02-23T14:02:57+0000", "lastModifiedDate": "2021-02-23T14:02:57+0000" }, "viewMode": "LIST", "parentMenuItemKey": "8a194df577c9c1300177cf3334e60080", "viewRights": { "encodedKey": "8a194df577c9c1300177cf333acf00a0", "isAccessibleByAllUsers": true, "roles": [] } } ] ``` ## Get custom views for a specified user You can retrieve all custom views or custom views of a specific type for a specific user. ### API operations | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/api/users//views` | Get custom views for a particular user. | ### for query parameter (optional) You may use the `for` query parameter to define for which entity types you want to retrieve custom views. If the `for` query parameter is used, you may only retrieve custom views for one entity type at a time. | Parameter | Values | | --- | --- | | `for` | `CLIENTS`, `GROUPS`, `LINES_OF_CREDIT`, `LOANS`, `DEPOSITS`, `LOAN_TRANSACTIONS`, `DEPOSIT_TRANSACTIONS`, `SYSTEM_ACTIVITIES` | ### Get custom views request examples #### Get all custom views available for a user ```http GET /api/users//views ``` #### Get all CLIENT type custom views available for a user ```http GET /api/users//views?for=CLIENTS ``` ### Response example The below is a response example for the following `GET` request: ```http GET /api/users//views?for=CLIENTS ``` ```json [ { "encodedKey": "8a194df577c9c1300177cf3339630082", "filter": { "encodedKey": "8a194df577c9c1300177cf3339630084", "filterConstraints": [ { "encodedKey": "8a194df577c9c1300177cf3339630085", "dataFieldType": "NATIVE", "dataItemType": "CLIENT", "dataType": "ENUM", "dataFieldValue": "CLIENT_STATE", "filterElement": "IN", "value": "ACTIVE", "linkingOperator": "AND", "groupNumber": 10, "index": 0 } ] }, "columnConfiguration": { "encodedKey": "8a194df577c9c1300177cf333aad0087", "fieldColumns": [ { "encodedKey": "8a19dab27be82f7c017bed8863c208d8", "dataField": "FULL_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208d9", "dataField": "ID", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208da", "dataField": "CLIENT_STATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208db", "dataField": "CREDIT_OFFICER_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c208dc", "dataField": "LOANS_BALANCE", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c508dd", "dataField": "DEPOSITS_BALANCE", "dataItemType": "CLIENT" }, { "encodedKey": "8a19dab27be82f7c017bed8863c508de", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" } ], "includeTotals": true, "includeTimestamp": false, "sortingOrder": "DESCENDING" }, "customConfigurationInfo": { "encodedKey": "8a194df577c9c1300177cf3339630086", "name": "Active", "dataViewType": "CLIENT", "indexInList": -1, "creationDate": "2021-02-23T14:02:57+0000", "lastModifiedDate": "2021-09-16T07:35:44+0000" }, "viewMode": "LIST", "parentMenuItemKey": "8a194df577c9c1300177cf3334e60080", "viewRights": { "encodedKey": "8a194df577c9c1300177cf3339630083", "isAccessibleByAllUsers": true, "roles": [] } }, { "encodedKey": "8a194df577c9c1300177cf333ab20090", "filter": { "encodedKey": "8a194df577c9c1300177cf333ab50092", "filterConstraints": [ { "encodedKey": "8a194df577c9c1300177cf333ab50093", "dataFieldType": "NATIVE", "dataItemType": "CLIENT", "dataType": "ENUM", "dataFieldValue": "CLIENT_STATE", "filterElement": "EQUALS", "value": "INACTIVE", "linkingOperator": "AND", "groupNumber": 0, "index": 0 } ] }, "columnConfiguration": { "encodedKey": "8a194df577c9c1300177cf333ab50095", "fieldColumns": [ { "encodedKey": "8a194df577c9c1300177cf333ac40097", "dataField": "FULL_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ac40098", "dataField": "ID", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ac40099", "dataField": "CLIENT_STATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ac4009a", "dataField": "CREDIT_OFFICER_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009b", "dataField": "TOTAL_BALANCE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009c", "dataField": "PENDING_LOAN_AMOUNT", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009d", "dataField": "APPROVED_LOAN_AMOUNT", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333acc009e", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" } ], "includeTotals": true, "includeTimestamp": false, "sortingColumn": { "encodedKey": "8a194df577c9c1300177cf333ac40096", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" }, "sortingOrder": "DESCENDING" }, "customConfigurationInfo": { "encodedKey": "8a194df577c9c1300177cf333ab50094", "name": "Inactive", "dataViewType": "CLIENT", "indexInList": -1, "creationDate": "2021-02-23T14:02:57+0000", "lastModifiedDate": "2021-02-23T14:02:57+0000" }, "viewMode": "LIST", "parentMenuItemKey": "8a194df577c9c1300177cf3334e60080", "viewRights": { "encodedKey": "8a194df577c9c1300177cf333ab50091", "isAccessibleByAllUsers": true, "roles": [] } }, { "encodedKey": "8a194df577c9c1300177cf333acc009f", "filter": { "encodedKey": "8a194df577c9c1300177cf333acf00a1", "filterConstraints": [ { "encodedKey": "8a194df577c9c1300177cf333acf00a2", "dataFieldType": "NATIVE", "dataItemType": "CLIENT", "dataType": "ENUM", "dataFieldValue": "CLIENT_STATE", "filterElement": "EQUALS", "value": "PENDING_APPROVAL", "linkingOperator": "AND", "groupNumber": 0, "index": 0 } ] }, "columnConfiguration": { "encodedKey": "8a194df577c9c1300177cf333acf00a4", "fieldColumns": [ { "encodedKey": "8a194df577c9c1300177cf333ad900a6", "dataField": "FULL_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ad900a7", "dataField": "ID", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ad900a8", "dataField": "CLIENT_STATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333ad900a9", "dataField": "CREDIT_OFFICER_NAME", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333adc00aa", "dataField": "CREATION_DATE", "dataItemType": "CLIENT" }, { "encodedKey": "8a194df577c9c1300177cf333adc00ab", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" } ], "includeTotals": true, "includeTimestamp": false, "sortingColumn": { "encodedKey": "8a194df577c9c1300177cf333ad900a5", "dataField": "LAST_MODIFIED_DATE", "dataItemType": "CLIENT" }, "sortingOrder": "DESCENDING" }, "customConfigurationInfo": { "encodedKey": "8a194df577c9c1300177cf333acf00a3", "name": "Pending Approval", "dataViewType": "CLIENT", "indexInList": -1, "creationDate": "2021-02-23T14:02:57+0000", "lastModifiedDate": "2021-02-23T14:02:57+0000" }, "viewMode": "LIST", "parentMenuItemKey": "8a194df577c9c1300177cf3334e60080", "viewRights": { "encodedKey": "8a194df577c9c1300177cf333acf00a0", "isAccessibleByAllUsers": true, "roles": [] } } ] ``` --- # Custom Views URL: https://docs.mambu.com/docs/custom-views/ Custom views are used to configure the Mambu UI, to quickly generate reports, and to filter `GET` requests with the Mambu v1 API (see [Custom Views and API v1](/docs/custom-views-and-api-v1) for more information). We refer to a custom view as either a *view* or a *custom view*, these terms are interchangeable. Examples of custom views include: * Listing all the clients that are in an active state. * Listing all loan accounts that are 90 days in arrears. * Listing all the withdrawal transactions higher than USD700,000 - to review them for reporting purposes. There are two kinds of custom views: * **Temporary custom views**, which can be seen by selecting the **View** menu in the top bar and using the quick lookup. * **Saved custom views**, which are assigned to a menu item and are accessible through the navigation bar. Mambu comes with some predefined saved custom views that are available under predefined menu items. For more information about creating and managing menu items, see [Menu Items](/docs/menu-items). For an example of how to use the menu items and custom views features together to create customizable UI sections, see [Menu Items and Custom Views Showcase](/docs/menu-items-and-custom-views-showcase). :::warning You may only view and manage custom views for which you have the appropriate permissions. For more information on the permissions for each custom view type, see [Menu item types and permissions](/docs/menu-items#menu-item-types-and-permissions). For more information on permissions in general, see [Permissions](/docs/permissions). ::: ## Temporary custom views Temporary custom views are used for a one-time look up. They offer fewer actions than saved custom views; for example they cannot be saved, copied, deleted, or added to favourites. However, you can export temporary custom views to Excel. ### Creating a temporary custom views To create a temporary custom view through quick lookup: 1. In the top bar, select **View**. 2. Select the entity for which you would like to create a custom view. 3. In the **Quick Lookup** dialog, enter all the necessary information. For more information on the available fields, see [Fields for custom views](/docs/custom-views/#fields-for-custom-views). 4. Select **Apply**. ![View menu with available entities](@site/static/img/support/data-and-reporting--view-menu-dropdown.png) ### Editing a temporary custom view page To edit filters directly on the custom view page: 1. In the top left-hand corner of the custom view page, select **Edit** . 2. In the **Custom Filter** dialog either edit the existing filters or select **Add Filter** to add an additional filter. 3. Select **Apply**. To edit columns directly on the custom view page: 1. In the top right-hand corner of the custom view page, select **Edit Columns**. 2. In the **Edit Custom View Fields** dialog, make any of the necessary changes. 3. Select **Apply Changes**. ![Temporary custom view for the type Client](@site/static/img/support/data-and-reporting--clients-list-view.png) ## Saved custom views ### User types and saved custom views Only an administrator can view, create, edit, and save custom views. Administrators are users that have the **Administrator** type assigned to them. For more information, see [Creating a User - User Rights](/docs/creating-new-users#user-rights-section). #### Regular users As a regular user, you may only see custom views that you have created, that have been set by an administrator to be viewable by all users, or that have been set by an administrator to be viewable by regular users with a role that you have been assigned. Custom views that you create are viewable by you and any administrator. You can only edit or delete the custom views you have created. Regular users do not have access to the usage rights settings of a custom view. To access saved custom views, you may visit the **Manage My Views** page in two ways: * Select your profile name in the top right-hand corner of the top bar and then select **My Views**, or * Hover over the navigation bar until **Settings** is revealed and select it. Visiting **Manage My Views** through profile name: ![Visiting Manage My Views through profile name](@site/static/img/support/data-and-reporting--manage-my-views.png) Visiting **Manage My Views** through cog in navigation bar: ![Visiting Manage My Views through cog in navigation bar](@site/static/img/support/data-and-reporting--top-navigation-bar.png) #### Administrators If you are an administrator, you have access to the usage rights settings of a custom view. Here, you may set custom views to be either viewable for all users, or only viewable by users who created the custom view as well as the viewers who have been assigned the relevant roles. For more information, see [Usage Rights](#usage-rights). As an administrator, under the **Administration** menu item, you have access to a **Views** tab. This is where you can view, edit, or delete the saved custom views created by other users. Visiting custom view through administration: ![Visiting custom view through administration](@site/static/img/support/data-and-reporting--views-list.png) On the **Manage My Views** page you can only see a list of saved custom views created by your user or that are accessible to all users. ### Creating a saved custom view To create a new custom view assigned to a menu item: 1. Hover over the navigation bar until **Settings** is revealed and select it. 2. In the **Parent Menu** dropdown, select the menu item to which you would like to assign the new custom view. 3. Select **Create New View**. 4. Enter all the necessary information. For more information on the available fields, see [Fields for custom views](/docs/custom-views/#fields-for-custom-views). 5. Select **Save View**. ![Creating a New View screen with Name and Default View Display fields and Filter, Fields and User Rights sections](@site/static/img/support/data-and-reporting--creating-a-new-view.png) ## Fields for custom views ### Default View Display for saved custom views only The **Default View Display** dropdown allows you to choose the default view mode that the custom view will open in. The two available options are **List** and **Detail**. List is the default option. You can later change the view mode on a saved custom view page by selecting either **Custom View Detail** or **Custom View List** to toggle to the other view mode. ![Icon to toggle between viewing modes](@site/static/img/support/data-and-reporting--custom-views-toolbar.png) Temporary custom views can only be viewed in list view mode. #### List view mode The list view mode shows the information in rows and columns. It gives you all your selected columns, fully sortable with totals for quick data analysis, sorting, and reporting. It is represented by **Custom View List** on the custom view page. ![List View Option](@site/static/img/support/data-and-reporting--inactive-clients-list-view.png) #### Detail view mode The detail view mode shows a list without columns, but allows opening each object individually without leaving the view. It allows you to see your clients and accounts in context to the custom view and other accounts: edit fields, disburse loans, review accounts, and much more without having to open new tabs or lose context of what you’re looking at. It is represented by **Custom View Detail** on the custom view page. ![Details View Option](@site/static/img/support/data-and-reporting--client-detail-view.png) ### Filters In the **Filter** section you can define multiple filter conditions. Select **Add Filter** to add an additional filter. Select **Delete** to remove a filter. In the dropdown, selecting **Match All** displays results that match all the conditions. Selecting **Match Any** displays results matching at least one of the conditions. Filters can be based on native fields or custom field definitions. For different types of fields there are different filter conditions available: * Selection fields allow a single value to be selected per condition. * Date fields allow for date ranges or specific dates. * Alphanumeric fields allow for "starts with" or "equals" conditions. ### Fields In the **Fields** section, you define the columns of information displayed in the view. Both grouped and standard custom field definitions are available. Temporary custom views have default fields and you may also add additional fields. Saved custom views have no default fields, so you must select fields to view any information. To add fields, search for the desired field in the **Available Columns** dropdown and select the column name. To remove columns select **Delete** beside the column name. :::warning If you do not select any fields, then no results will be displayed in rows on the custom view page - even if your custom view retrieves results. If the retrieved results have no data to display for the selected fields, empty rows will be shown on the custom view page. ::: The **Sort By** dropdown allows you to select the field to sort results by and also whether to sort in ascending or descending order. Select the **Include Totals** checkbox to add a total to any field that is numeric. Select the **Include Timestamp** checkbox to add a timestamp to any date fields. ### Usage Rights The **Usage Rights** section of the Mambu UI is only available for saved custom views managed by admins. For more information, see [User types and saved custom views](#user-types-and-saved-custom-views). If you select the **All Users** checkbox, then all roles will be selected and any user that has the appropriate permissions assigned to them either directly or through a role will have access to the custom view. For more information on the different permissions necessary for the different custom view types, see [Menu item types and permissions](/docs/menu-items#menu-item-types-and-permissions). If you do not select the **All User** checkbox, then users will need to be assigned a role with appropriate permissions to allow them access to the custom view. Users will not have access to the custom view if they have the permissions directly assigned to them. ## Rearranging custom views To rearrange the custom views assigned to a particular menu item: 1. Hover over the navigation bar until **Settings** is revealed and select it. 2. In the **Parent Menu** dropdown, select the menu item to which the custom view you would like to rearrange are assigned. 3. Select **Rearrange Views** and then drag and drop the views in the desired order in the **Arrange Views** dialog. 4. Select **Save Changes**. ## Editing a saved custom view You can edit a custom view either by opening the **Edit View** dialog and altering the information in the available fields. Alternatively, you can go on the custom view page and use the filter and column options to edit the view. The saved custom views you can edit depend on your user type. For more information, see [User types and saved custom views](#user-types-and-saved-custom-views). To edit a custom view: 1. On the main menu, go to **Administration** > **Views**. 2. Using the **Parent Menu** dropdown, select the menu item you would like to edit. 3. In the list of views, find the one you want to edit and, on the right-hand side of the row, select **Actions** > **Edit**. 4. Make any necessary changes. If you use a non-English display language, enter the name of the view in your language. 5. Select **Save View**. ### Editing filters and columns on a custom view page To edit filters directly on the custom view page: 1. In the top left-hand corner of the custom view page, select **Edit** . 2. In the **Custom Filter** dialog either edit the existing filter(s) or select **Add Filter** to add an additional filter. 3. Select **Apply**. 4. To either save the changes or reset the view, select **Actions** in the top right-hand corner, and then select **Save Changes** or **Reset View**. To edit columns directly on the custom view page: 1. In the top right-hand corner of the custom view page, select **Edit Columns**. 2. In the **Edit Custom View Fields** dialog, make any of the necessary changes. 3. Select **Apply Changes**. 4. To either save the changes or reset the view, select **Actions** in the top right-hand corner, and then select **Save Changes** or **Reset View**. ## Copying a saved custom view There are two ways to copy a custom view: * Go to the page that lists all your custom views and find the custom view you want to copy and select **Actions** > **Copy View**. * Visit the custom view page and in the top right-hand corner select **Actions** > **Save View As**. When you copy a custom view, by default *(Copy)* will be appended to the original name. You can choose to edit this. Also, the custom view will be added to the menu item that the original custom view is assigned to. ## Adding a saved custom view to favourites Adding a custom view to favourites adds the view to the user's dashboard as a favourite view. Additionally, any favourite views will have the number of items (clients, loans, and transactions) displayed next to it. ![Your Favourite Views with example custom views added to favourites](@site/static/img/support/data-and-reporting--your-favourite-views-dashboard.png) There are two ways you can add or remove a custom view from favourites: * Go to the page that lists all your custom views and find the custom view you want to add to favourites, and select **Actions** > **Add to Favourites**. * Visit the custom view page and in the top left-hand corner next to the name, select or unselect the **star** icon. If the star is highlighted yellow, then it is a favorite view. If it is gray, then it is not a favorite view. ![Favourites start unselected and selected for a specific view](@site/static/img/support/Artboard.PNG) ## Deleting a saved custom view The saved custom views you can delete depend on your user type. For more information, see [User types and saved custom views](#user-types-and-saved-custom-views). There are two ways you can delete a custom view: * Go to the page that lists all your custom views and find the custom view you want to delete and select **Actions** > **Delete**. * Visit the custom view page and in the top right-hand corner select **Actions** > **Delete View**. ## Custom views and language settings You may configure the Mambu UI to display text in a language other than English by editing your Mambu Display Language. However, customized menu items and custom view tabs will **not be translated**, as they depend on the values you enter. As a result, it is best practice to use the language that most or all of your Mambu users are likely to use when setting up your custom views. Keep this in mind during planning and implementation. For more information, see [Language Settings](/docs/language-settings). ## Export to Excel All custom views can be exported to Excel to allow for the information to be used in further analysis, reports, or for any other reason. To export to Excel select **Export spreadsheet** . ![Export Excel Option](@site/static/img/support/data-and-reporting--data-view-actions-toolbar.png) :::note * The maximum number of rows that will be exported to Excel per request is 100,000. Filters can be used to break up extremely large views into smaller, exportable chunks. * Due to Excel limitations, numbers longer than 15 digits (including the decimal point) will be exported as text format. Manually changing the format from text to number in Excel could result in accuracy loss --- # Customer Service Portal URL: https://docs.mambu.com/docs/customer-service-portal/ The Customer Service Portal is a self-service portal that can be accessed at [https://mambu.my.site.com](https://mambu.my.site.com). :::note In February 2023, the URL to access the Customer Service Portal changed from **https://mambu.force.com** to **https://mambu.my.site.com**. ::: You can use the Customer Service Portal to: * Raise cases with Mambu support. * View dashboards and reports about cases. * Manage your sandbox. * View documents from Mambu. * Manage contact information. * View invoice related data. ## Accessing the Customer Service Portal You must use multi-factor authentication when accessing the Customer Service Portal. The first time you log in to the portal, you will have to choose the authenticator app that you will use on your mobile device. We recommend using the Salesforce Authenticator mobile app, however you may choose to use another authenticator app. :::warning Please be aware Once you have set up your authenticator app, you cannot change it. If you have any issues setting up multi-factor authentication, please contact us through the [Web Form for Support Cases](https://cloud.mambu.com/contact-support). ::: ![getting-started--choose-a-verification-method.png](@site/static/img/support/getting-started--choose-a-verification-method.png) ## Managing users During the onboarding process, our support team will create onboarding user accounts for you based on the available onboarding user types. For more information, see [Onboarding user types](#onboarding-user-types) below. After onboarding is completed, these onboarding user accounts are deleted and we will provision you with regular user accounts. For more information about the available user types for regular users, see [Regular user types](#regular-user-types). :::warning This section describes managing Customer Service Portal users only. For information on managing Mambu UI users, see [Authentication and User Management](/docs/understanding-users-roles-and-permissions). ::: ### Onboarding user types The available user types for onboarding user accounts. | User Type | Access | | --- | --- | | Onboarding Admin user |
    • Sandbox Management
    • Account Information
    • Edit all contacts
    • Documents
    • Product Documentation
    • Product Roadmap
    • Invoices
    • User login history
    • Account history
    • Contact history
    | | Onboarding Technical user |
    • Sandbox Management
    • Account Information
    • View all contacts
    • Edit their own contact
    • Documents
    • Product Documentation
    • Product Roadmap
    | | Onboarding Finance user |
    • Account Information
    • View all contacts
    • Edit their own contact
    • Documents
    • Product Documentation
    • Product Roadmap
    • Invoices
    | ### Regular user types The available user types for regular user accounts. | User Type | Access | | --- | --- | | Admin user |
    • Account information
    • Edit all contacts
    • View all support cases
    • Dashboards and reports
    • Sandbox Management
    • Invoices
    • Documents
    • Product Documentation
    • Product Roadmap
    • User login history
    • Account history
    • Contact history
    | | Technical user |
    • Account information
    • Sandbox Management
    • View all contacts
    • Edit their own contact
    • View all support cases
    • Documents
    • Product Documentation
    • Product Roadmap
    | | Support user |
    • Account information
    • View all contacts
    • Edit their own contact
    • View all support cases
    • Documents
    • Product Documentation
    • Product Roadmap
    | | Finance user |
    • Account information
    • View all contacts
    • Edit their own contact
    • Their own support cases
    • Invoices
    • Documents
    • Product Documentation
    • Product Roadmap
    | | General user |
    • Account information
    • View all contacts
    • Edit their own contact
    • Their own support cases
    • Documents
    • Product Documentation
    • Product Roadmap
    | ### Requesting new users To request a new CSP user, contact your Mambu Champion to discuss what level of access your new user needs and to determine what user type to request. The Mambu Champion can then [raise a support case](/docs/customer-service-portal#raising-a-support-case) through the Customer Service Portal to submit a user request. Once our team processes your request you will hear back from us. :::warning If a user is inactive for a period of six months, the user account will be deleted. ::: ## Accessing the Administrator section The Administrator section allows you to keep track on user login, account history and contact history changes. To access, please go to **More** **> Administrator**. ### User login history Onboarding administrators and regular administrators may access user login history, by using the navigation bar and going to **More** > **Administrator** > **User Login History**. ![CSP_New_User Login History.png](@site/static/img/support/CSP_New_User%20Login%20History.png) On the **User Log In History** details page, you may filter the user login history list by contact name, status, login start date, and login end date. You may also export up to six months of data at a time to CSV. The following table describes the available status types for a user login entry. | Status | Description | | --- | --- | | Success | The user succesfully logged in by using their password and then completing multi-factor authentication. | | Multi-factor Required | The user provided the correct password, however they have not succesfully completed multi-factor authentication. | | Invalid Password | The user entered the wrong password. | | Password Lockout | The user entered the wrong password, the maximum number of times, and has been locked out of the system. To unlock the user, please contact us through [Mambu Support](/docs/mambu-support). | ### Account History Onboarding administrators and regular admininistrators can access account history selecting **More** > **Administrator** > **Account History** in the navigation bar. ![New_CSP_Account Data History.png](@site/static/img/support/New_CSP_Account%20Data%20History.png) The **Account Data History** details page contains a change log of the Mambu Champion, the Mambu Support Champion, Secondary Mambu Champion, and the P1 Escalation Contact. In the **Account Data History** section you can see the new value, the old value, the date, and the owner of the change. ### Contact History Onboarding administrators and regular administrators can access contact history by seleting **More** > **Administrator** > **Contact History** in the navigation bar. ![Accessing Contact Data History in teh Client Service Portal](@site/static/img/support/contact-data-history-1600x570.png) The **Contact Data History** details page contains a change log of the Salutation, First Name, Last Name, Title, Department, Company, Phone, Mobile Phone, Email, and if the respective contact was marked as Left Company or not. In the **Contact Data History** section you can see the new value, the old value, the date, and the owner of the change. ## Accessing your account details To access your account details: 1. On the navigation bar, select **Accounts and Tenants** and then **Accounts Information**. 2. On the accounts overview page, select the **Account Name** for the account you want to view information for. :::note You can only view accounts on the accounts overview page that you have permissions to view. ::: ![New_CSP_Accounts and Tenants - Accounts Information.png](@site/static/img/support/New_CSP_Accounts%20and%20Tenants%20-%20Accounts%20Information.png) The account details page displays: * Your account information, including contact details for your Mambu Champions. * Mambu information, including contact details for your Customer Success Manager. * Links to your production and sandbox tenants. * Information about your SLAs. ![New_CSP_Accounts Details Page.png](@site/static/img/support/New_CSP_Accounts%20Details%20Page.png) ### Editing account information In the **Account Information** section of the Accounts Details Page, you can edit information that has the **Edit** icon next to it. ### Accessing tenant information The **Tenants** section lists your production and sandbox tenants. You can access it under **Accounts and Tenants** > **Tenants** Select **View All** to go to the tenants overview page. ![All Tenants List extended view](@site/static/img/support/All%20Tenants%20List.png) If you select a production tenant, you will go to the production tenant detail page and see relevant information and **Tenant Metrics**. If you select a sandbox tenant, you will see go to the sandbox tenants detail page and see relevant information and the **Sandbox Management** options. For more information, see [Sandbox Management](/docs/customer-service-portal#sandbox-management) below. ### Accessing SLA information In the **SLA Information** and **SLAs Table** sections you can view information about your SLAs. Select **View All** in the **SLAs Tables** section to go to the SLA overview page. ![New_CSP_SLA.png](@site/static/img/support/New_CSP_SLA.png) ## Raising a support case To raise a support case select **Cases** > **Raise a new case** from the navigation bar. In the **Contact Support Form** section, enter any necessary information. The information provided allows us to accurately process your case in accordance with the response times stipulated in the SLAs. As you enter information in the **Subject** field, we also recommend related articles from our [User Guide](/docs). ![New_CSP_Raise a new case](@site/static/img/support/New_CSP_Raise%20a%20new%20case.png) ## Sandbox Management A Mambu sandbox is a testing environment where you can test configurations, updates, and new products before making them available to your clients in your production tenant. For more information, see [Sandbox](/docs/sandbox). Sandbox management allows you to: * Reset a sandbox. * Clone production to sandbox. * Delete sandbox. To access **Sandbox Management** in the Custom Service Portal, on the navigation bar, go to **Accounts and Tenants**, then go to the **Tenants** section and select any sandbox tenant. ![New_CSP_Sandbox Management.png](@site/static/img/support/New_CSP_Sandbox%20Management.png) ### Cloning production to sandbox There are two options available for cloning production data to your sandbox: **Clone with Production Anonymized Client Data** and **Clone with Production Data**. These two options are described below. To clone production to sandbox: 1. In the **Sandbox Management** section, under **Clone Production to Sandbox**, select the type of data you would like to clone with. The two options are **Clone with Production Anonymized Client Data (Recommended)** and **Clone with Production Data**. 2. Select **Clone**. :::note For security and compliance reasons, when you clone your production data to sandbox, API keys are not copied over. You must create new API keys for your newly cloned sandbox environment. For more information, see [API Consumers - API keys](/docs/api-consumers#api-keys). ::: #### Clone with Production Anonymized Client Data When production data is cloned to your sandbox using this option, all the client-identifiable data is either anonymized or deleted. This is the default selection. The rules governing whether data is anonymized or deleted are based on the [GDPR Article 17](https://gdpr.eu/?s=right+to+erasure). For more information on how data is anonymized or modified when cloning in this way, see [Sandbox - Client data anonymization](/docs/sandbox#client-data-anonymization). #### Clone with Production Data When production data is cloned to your sandbox using this option, all settings and live data of the production tenant are replicated. Documents and attachments are not copied from one environment to another. :::warning This option may not be compliant with data handling regulations and requirements. If you select this option, it is fully your responsibility to ensure that you are in compliance with all applicable laws and regulations. ::: #### Duration How long it takes to create a sandbox depends on the amount of data you are cloning. For an empty sandbox, you will see a message confirming that the sandbox has been successfully created in a few seconds. If you select **Clone with Production Data** and **Clone with Production Anonymized Client Data (Recommended)**, this might take from a few minutes for smaller tenants up to several days for tenants with over 100Gb of data. :::warning For the duration of the cloning process, the target sandbox will not be available. The initial data available on the sandbox will be deleted as part of the cloning process, and replaced with the cloned data from production. ::: ### Deleting a sandbox To delete an existing sandbox and create a new one, simply refresh the sandbox. See [Sandbox Management](#sandbox-management) above. To delete a sandbox without creating a new one: 1. In the **Sandbox Management** section, under **Manage Your Sandbox**, select **Delete**. 2. Select **OK**. If you encounter any issues creating, cloning, or deleting a sandbox, please contact us through [Mambu Support](/docs/mambu-support). ## Invoices You may view the invoices provided your user type has access to this feature. For more information, see [User types](#onboarding-user-types) above. To view invoices, either: * In the navigation bar, select **Invoices**, or, * On the homepage, select **Invoice**. ![New_CSP_Invoices.png](@site/static/img/support/New_CSP_Invoices.png) You can use the table headings to sort the invoices. Invoices are sent by email to the billing contact of your organization. If you require information about an invoice that is not available on the Customer Service Portal, please reach out to the billing contact of your organization. The status of invoices on the Customer Service Portal may be delayed. If you require the most up-to-date status of an invoice, please contact us through [Mambu Support](/docs/mambu-support). ## Accessing Files To access documents that Mambu makes available for you, in the navigation bar, select **Files** > **All Files**. ![New_CSP_Files.png](@site/static/img/support/New_CSP_Files.png) You can access Sustainability Reports, which provide visibility into the climate impact of your cloud consumption in the past year, by selecting **Files** > **Sustainability**. You can access the Product Roadmap, which provides insights into Mambu deliverables, by selecting **Files** > **Product Roadmap** or through the home page, by selecting **Product Roadmap**. ## Providing feedback To provide feedback to our team: 1. On the home page, select **Portal Feedback**. 2. In the **Description**, enter any feedback. Optionally, select **Upload File** to add any supporting documents. 3. Select **Submit**. ![New_CSP_Portal Feedback.png](@site/static/img/support/New_CSP_Portal%20Feedback.png) --- # Customizing Columns URL: https://docs.mambu.com/docs/customizing-columns/ You can customize your own column configurations in Mambu UI such as **All Clients**, **All Groups**, **All Accounts**, **Journal Entries**, and **Transactions Lookup**. This allows you to get the specific perspective on your data that you need. Custom column configurations are referred to as **presets** in the Mambu UI. ## Selecting a column preset Each customizable page includes a button in the upper-right that allows you to access and manage column presets. If there is no default column preset for the page, the button will be labeled **Custom Columns**. If a column preset is available and has been configured as the default preset for the page, then the button will display the name of the active default preset. Each column preset that you have access to for a page is available from the dropdown of this button and you may use this button to select, create, edit, or delete any column preset. ![Custom Columns dropdown on a customizable page](@site/static/img/support/managing-the-mambu-ui--clients-page-header-with-custom-columns-menu.png) ## Creating a column preset To create a column preset: 1. Navigate to the page you want to customize. 2. Select **Custom Columns** on the top right. Note that this button may display the name of a default column preset instead of "Custom Column" - see [Selecting a column preset](#selecting-a-column-preset) for more information. 3. Select **New Column Preset** to open the creation dialog box. 4. Enter a name for the preset. 5. If you want the preset to be available to other Mambu users, select the **Shared** checkbox. 6. If you want the preset to be the default column display for the page, select the **Default** checkbox. 7. To add the columns you want to display: * Select the **Available Columns** drop-down menu and select a column you wish to add. * Select **Add Column**. * Repeat the process for every column you want to include. 8. You may re-sort the columns by dragging and dropping columns in the **Selected Columns** box. 9. You may sort items in the columns automatically in ascending or descending order by selecting the desired sort criterion in the **Sort By** dropdown menu and selecting either **Ascending** or **Descending** order. 10. You may configure displayed entries in the columns to display totals and/or timestamps by checking the relevant boxes. 11. When you are finished, select **Save Changes**. ![Example of a creating column preset dialog for the creating a new loan account page.](@site/static/img/support/managing-the-mambu-ui--creating-a-new-loan-accounts-preset.png) :::warning The available columns list includes both native fields and custom field definitions. For more information, see [Custom Fields](/docs/custom-fields). ::: ## Editing a column preset To edit a set of columns: 1. Navigate to the page you wish to customize. 2. Select the desired column preset as described in [Selecting a column preset](#selecting-a-column-preset). 3. Select **Edit Columns** on the right. 4. Make any desired changes as described in [Creating a column preset](#creating-a-column-preset). 5. When you are finished, select **Save Changes**. A shared column preset can be edited by any user. However, only the user that created the preset has access to the **Shared** checkbox that determines access to the preset itself. ## Deleting a column preset To delete a column preset: 1. Navigate to the page you wish to customize. 2. Select the desired preset as described in [Selecting a column preset](#selecting-a-column-preset). 3. Select **Edit Columns** on the right. 4. Select the **Delete** button and confirm to delete. A shared column preset can be deleted by any user, not just the user that created it. ![Edit Columns view with multiple sections and buttons like Cancel, Delete and Save Changes](@site/static/img/support/managing-the-mambu-ui--editing-loan-accounts-preset.png) --- # Customizing Index Interest Rates and Tax Rates URL: https://docs.mambu.com/docs/customizing-index-rates/ There are three different types of index and tax rates you can set up for managing your loan and deposit products: * Interest rates * Value-added tax rates * Withholding tax rates These values are configured under **Administration** > **Financial Setup** > **Rates**. The process of creating, updating, editing, and deleting index rates for each of these is the same. ![The Rates section under Administration > Financial Setup > Rates](@site/static/img/support/managing-your-organization--rates-section.png) ## Interest rate An *index interest rate* is an interest rate determined periodically by an external entity such as a central bank. It's a common practice in some organizations to fix their internal interest rate to an index interest rate. For more information on managing interest rates for your products and where index interest rates can be applied, see [Interest Calculation Methods in Loans](/docs/interest-calculation-methods-in-loans) and [Changing the interest rate](/docs/change-interest-rate). ## Value-added tax Many countries require organizations that offer loan accounts to pay taxes on the interest, fees, or penalty income generated on those accounts. These taxes are generally called *value-added taxes* (VAT), because they are collected on revenues. For more information on how VAT is applied when setting up loan products, see [Setting Up New Loan Products - Taxes](/docs/setting-up-new-loan-products#taxes). ## Withholding tax It is a regulatory requirement in many countries that organizations offering deposit accounts have to pay taxes on the interest generated by those accounts and paid to clients. These are generally called *withholding taxes* because they are deducted from the interest paid to the client. For more information about how withholding taxes are applied when setting up deposit products, see [Setting Up New Deposit Products](/docs/setting-up-new-deposit-products). ## Creating a new index rate To create a new index rate you first have to define the rate source and then you can specify the rate value(s). To create a new index rate: 1. On the main menu, go to **Administration** > **Financial Setup** > **Rates**. 2. Next to the **Rate Source** dropdown, select the **Add** icon . 3. Enter a **Name** (required), **ID** (optional), and **Notes** (optional). 4. Using the **Type** dropdown, select either **Interest Rate**, **Value Added Tax**, or **Withholding Tax** depending on the type of rate you're adding. 5. Select **Save Changes**. 6. Select either **Add Index Interest Rate**, **Add Value Added Tax**, or **Add Withholding Tax** depending on the type of rate you're adding. 7. Enter the **New rate** value and the **Valid From** date. 8. Select **Save Changes**. ![Create New Rate Source dialog](@site/static/img/support/managing-your-organization--create-new-rate-source.png) ## Updating index rates with new values When the index rate updates, you will need to update the value in your system and define from what date onwards you want to use the new value. To update an index rate with a new value: 1. On the main menu, go to **Administration** > **Financial Setup** > **Rates**. 2. Next to the **Rate Source** dropdown, select the rate source for which you want to update the index rate value. 3. Select either **Add Index Interest Rate**, **Add Value Added Tax**, or **Add Withholding Tax** depending on the type of rate you're updating. 4. Enter the **New rate** value and the **Valid From** date. 5. Select **Save Changes**. ![Store Rate dialog](@site/static/img/support/managing-your-organization--store-rate.png) The default behaviour is that the schedule is not updated until the validation date of new index rate. ### Automatically updating repayment schedules when interest rates change In certain countries banks are required to send new repayment schedules when the interest rate is changed. To facilitate this, we have implemented automatic updates for interest rate changes. Whenever a change in the interest rate occurs, the schedules of affected accounts will be recalculated at the next end of day job - without waiting for the `validFrom` date of the new interest rate. On the next day you will be able to see the updated repayment schedules of the accounts and send the new details to your clients. ## Editing index rates To edit the rate source of the index rate: 1. In the **Rate Source** dropdown, select the rate source you want to edit. 2. Select the **Edit** icon . 3. Make any changes in the **Edit Source** dialog. 4. Select **Save Changes**. To edit one of the index rate values for a particular rate source: 1. In the **Rate Source** dropdown, select the appropriate rate source. 2. In the list of index rate values, find the value you want to edit and select **Actions** > **Edit**. 3. Make any changes in the **Store Rate** dialog. 4. Select **Save Changes**. :::note Index rate values that are used by active accounts cannot be edited if the start date is in the past. ::: ## Deleting index rates To delete the rate source of an index rate and therefore all of its accompanying values: 1. In the **Rate Source** dropdown, select the rate source you want to delete. 2. Select the **Delete** icon . 3. In the **Delete** dialog, select **Delete**. To delete one of the index rate values for a particular rate source: 1. In the **Rate Source** dropdown, select the appropriate rate source. 2. In the list of index rate values, find the value you want to edit and select **Actions** > **Delete**. 3. In the **Confirm Deletion** dialog, select **Delete**. You will receive a warning if you attempt to delete rate sources for index rates that are currently in use. ![Warning dialog about deleting rate sources for index interest rates that are in use.](@site/static/img/support/managing-your-organization--delete-index-source-warning-dialog.png) :::note Index rate values that are used by active accounts cannot be deleted if the start date is in the past. ::: --- # Dashboard URL: https://docs.mambu.com/docs/dashboard/ The dashboard is the landing page you see when you log in to the Mambu UI. The dashboard is composed of *widgets*, which are sometimes called *dashboard sections*. The widgets available to a user are determined by the user's type and permissions, and by your organization's internal control settings. The available widgets are: - [Latest Activity](#latest-activity) - [Your Tasks](#your-tasks) - [Your Favourite Views](#your-favourite-views) - [Indicators](#indicators) - [Tellers](#tellers) - [Tellering](#tellering) - [Your Clients](#your-clients) - [Upcoming Repayments](#your-repayments) ![An example of a dashboard with the latest activity, indicators, and your tasks widgets](@site/static/img/support/managing-the-mambu-ui--dashboard.png) ## Widget access controls To be visible, a widget must be enabled in the **Internal Controls** tab of the **Administration** page. You will find a list of widgets that you may enable or disable in the **Available dashboard sections** list in the tab. For more information, see [Internal Controls](/docs/internal-controls). Some widgets have additional access requirements - they are indictated below in the relevant section. To edit the available dashboard sections: 1. On the main menu, go to **Administration** > **General Setup** > **Internal Controls**. 2. Scroll down to the **Available dashboard sections** list. 3. Select or deselect the widget you want to display. 4. Select **Save Changes**. ![Internal control for available dashboard sections with list of sections](@site/static/img/support/managing-the-mambu-ui--available-dashboard-sections.png) ## Widgets ### Latest Activity The **Latest Activity** widget shows a snapshot of the latest activities in the branches you have access to. For more information about activity tracking, see [Tracking Activities](/docs/tracking-activities). To customize your activity feed: 1. Next to the latest activity widget title, select **Settings** . 1. To add an activity type, use the **Activity Type** dropdown, select the activity type, and select **Add Activity Type**. 1. To remove an activity type, find the activity in the **Selected Activity Types** list, and select **Delete** . 1. Select **Save Changes**. ![Example of Latest Activity widget](@site/static/img/support/managing-the-mambu-ui--latest-activity-widget.png) ### Your Tasks The **Your Tasks** widget allows you to manage tasks. Tasks are used to plan and track work in Mambu. They are assigned to system users and can be linked to specific clients or groups. For more information about creating, editing, deleting, and filtering tasks see [Tasks](/docs/tasks). ![Example of your tasks widget](@site/static/img/support/managing-the-mambu-ui--your-tasks-widget.png) ### Your Favourite Views The **Your Favourite Views** widget displays a list of custom views that you have set as favorites. Custom views are used to configure the Mambu UI, to quickly generate reports, and to filter `GET` requests with the Mambu v1 API. For more information, see [Custom Views](/docs/custom-views). Any custom view that you select as a favorite will be automatically added to your favorite views list. For more information, see [Adding a saved custom view to favourites](/docs/custom-views#adding-a-saved-custom-view-to-favourites). To remove a favorite view from the widget: 1. Next to the favorite views widget title, select **Settings** . 1. Find the view you would like to remove and select **Delete** . 1. Select **Save Changes**. ![Example of your favourite views widget](@site/static/img/support/managing-the-mambu-ui--your-favourite-views-widget.png) ### Indicators For more information about the available indicators, adding, editing, and deleting indicators, see [Indicators](/docs/indicators). ### Tellers The **Tellers** widget is used to manage tills. For more information about how to open a till, add or remove cash, or close a till, see [Working with Tills](/docs/managing-tills-tellering-widget). To have access to the tellers widget, your account must have the necessary tellering permissions. For more information, see [Teller Users](/docs/teller-users) and [Permission - Tellering](/docs/permissions#tellering). ![Example of tellers widget](@site/static/img/support/managing-the-mambu-ui--tellers-dashboard.png) ### Tellering The **Tellering** widget is used to process transactions through a till. For more information, see [Processing Transactions via a Till](/docs/processing-transactions-via-a-till-tellering-widget). To have access to the tellering widget, your account must have the necessary tellering permissions and the **Teller** user type assigned. For more information, see [Creating a User - Type](/docs/creating-new-users#type) and [Teller Users](/docs/teller-users). ![Example of tellering widget](@site/static/img/support/managing-the-mambu-ui--tellering-till-transaction.png) ### Your Clients To have access to the **Your Clients** widget, an account must have the **Credit Officer** user type and assigned clients. For more information, see [Creating a User - Type](/docs/creating-new-users#type) and [Creating an Individual Client](/docs/create-an-individual-client). ![Example of your clients widget](@site/static/img/support/managing-the-mambu-ui--your-clients-widget.png) ### Your Repayments To have access to the **Your Repayments** widget, an account must have the **Credit Officer** user type as well as assigned clients with repayments to make. For more information, see [Processing Loan Repayments](/docs/processing-loan-repayments). --- # Data Adapter URL: https://docs.mambu.com/docs/data-adapter/ ## Create a connection between Jaspersoft Studio and MySql Server For Jasper reports to be compatible with Mambu, they must be built considering the structure of Mambu DB. This is achieved by having the database as a data source during the development process. To create and configure a Data Adapter: 1. Go to Jaspersoft Studio, Repository Explorer view 1. Right click on the Data Adapters root node and choose Create Data Adapter 1. Go with the Database JDBC Connection wizard 1. Then as part of the Adaptor configuration: - Name: Set a name for the adapter that relates to the database schema - Database Location tab: - JDBC Driver: com.mysql.jdbc.Driver - JDBC Url: jdbc:mysql://[your connection string]. Example: `jdbc:mysql://localhost:3306/local_mambu_database` - Username: The username set up during the MySql Server installation - Password: The password set up during the MySql Server installation - Driver Classpath tab: - Add a link to the mysql connector jar file (JDBC Driver for MySQL). Example: `[local_path]/mysql-connector-java-8.0.13-bin.jar` *** ## Video Tutorial Check out our video tutorial for creating and configuring a Data Adapter [here](https://youtu.be/wvCESSDUO1g). *** --- # Data Dictionary and API Standards URL: https://docs.mambu.com/docs/data-dictionary-and-api-standards/ ## Data Structures and Enums To dig deeply into all the possible data types, structure and meaning of enumerated values which can be returned, we suggest reviewing our [data dictionary](/docs/mambu-data-dictionary), which fully describes all publicly accessible objects, their relationships, and their fields. :::warning The schema defined in the [data dictionary](/docs/mambu-data-dictionary) covers the base Mambu database which can be exported following the procedure given [here](/docs/data-migration-overview). This may not include all data held in ancilliary services such as the payments gateway or MPO. ::: ## Dates For date values Mambu uses the [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601) standard. Date values are returned in the `yyyy-MM-dd'T'HH:mm:ssZ` format, for example: `2011-09-26T00:00:00+0000`. For data parameters without a time code the short version of the ISO 8601 standard: `yyyy-MM-dd` is used, for example `2011-09-26`. Mambu stores date/time values without any time zone offset. The dates captured automatically by Mambu are stored in UTC date and time and the ones specified (or that can be specified) by the user are stored in the organization's date and time. For further information, please consult the most recent [Data Dictionary](/docs/mambu-data-dictionary#time-stamps). :::note If the short version of the ISO 8601 standard is used, e.g. for birth dates, the time zone is assumed UTC and not the organization's time zone. ::: ## Numbers All numeric values are trimmed for trailing zeroes. Mambu stores decimals in high-precision but a value such as `50.010000000` will be returned as simply `50.01` in the JSON response for brevity. ## Identifiers Resources in Mambu such as Clients and Products often have two identifiers: IDs and encodedKeys. IDs are short codes in a general, organization level format (for clients, accounts, etc.) or an explicitly defined format (for products for example). encodedKeys are the Primary UUID keys in the datastore and are unchangeable after the object has been created. The APIs use both ids and keys as resource identifiers. ## Null values Null values are stripped from the responses. If a key is not found, it's value is `null`. ## Pagination List items are returned in the Mambu APIs with a default pagination limit of 50 and a max of 1000. Pagination can be specified using the `offset` and `limit` parameters for GET and POST requests as URL encoded parameters, which, when used returns a list. For example an offset of `5` and limit of `10` would retrieve items 6-15 in the list. The end of the list is reached when the request has fewer results than the limit or when an empty result array is returned. :::note Performance Recommendation When querying Mambu data, we recommend using a batch size of up to 100 records for optimum output. This is both performant and ensures easier troubleshooting for your integrations. ::: **GET 5 savings accounts starting with the 24th resulted entry** `GET /api/savings?branchId=2&limit=5&offset=24` **POST Search for the first 40 closed savings accounts** ```json POST { "filterConstraints":[ { "filterSelection":"ACCOUNT_STATE", "filterElement":"EQUALS", "value":"CLOSED" } ] } /api/savings/search?limit=40&offset=0 ``` ## Rates All rates (index, interest) are expressed as full numbers, not percentages. For example, an index rate of 10.50% is passed in JSON as 10.5. Example: ```json { "indexRate":{ "rate":"10.5" } } ``` *** --- # Data Lake Integration Guide URL: https://docs.mambu.com/docs/data-lake-integration-guide/ This guide will help you integrate your Mambu data lake with your AWS environment. For more information on the Mambu data lake, see the [Data Lake Overview](insights-mambu-data-lake.mdx). ## Prerequisites for your AWS Account Before you can integrate with your Mambu data lake, ensure your AWS environment meets the following general prerequisites: * **An active AWS account**: You must have an active AWS account to establish cross-account access. * **Basic AWS IAM understanding**: Familiarity with AWS Identity and Access Management (IAM) concepts such as IAM Users, IAM Roles, and Policies is beneficial for configuring access. * **Administrative access (for setup)**: Initial setup steps will require an IAM User or Role with sufficient administrative privileges within your own AWS account to create or modify IAM roles and policies. * **S3 Block Public Access**: Ensure that the [S3 Block Public Access](https://aws.amazon.com/s3/features/block-public-access/) settings in your AWS account (if they are enabled at the account level) do not inadvertently prevent the necessary cross-account S3 access. The specific IAM permissions required for each integration option will be detailed in the respective sections of this guide. ## Integration options This guide presents two options for integrating with your Mambu data lake: 1. [Direct S3 Access (Recommended for Basic/Development Access)](#integration-option-1-direct-s3-access-recommended-for-basicdevelopment-access) 2. [Direct data access with Delta Kernel](#integration-option-2-direct-data-access-with-delta-kernel) ## Integration option 1: Direct S3 access (Recommended for basic/development access) This option provides direct access to the underlying S3 bucket that houses your data. This method is straightforward to set up and is ideal for initial testing, direct data loading operations, or for tools that prefer accessing S3 paths directly. ### Required IAM Permissions To enable direct S3 access from your AWS Account to our Producer Data Lake Bucket (`s3://$bucket_that_we_will_share_with_you/`), you need to configure an IAM policy in both accounts. You will need an IAM role in your account that has permission to make S3 calls to our data lake bucket. For example, `$YourDataEngineeringRole` role is the example of the role we will create (you can name it whatever you like) 1. Log into AWS Account 2. Navigate to the IAM console. 3. Go to **Roles** and select your primary execution role (e.g., `$YourDataEngineeringRole`). 4. Go to the **Permissions** tab. 5. Click **Add permissions** > **Create inline policy**. :::note If your role is SSO-managed, you might not be able to attach inline policies directly. In such cases, these permissions must be granted via an AWS SSO Permission Set applied to the user/group that obtains this role. Consult your AWS administrator for this. For direct local testing, if you can't modify the SSO role, you'd typically create a *separate, modifiable IAM role* in your account with these permissions and ensure your SSO role has `sts:AssumeRole` on it. ::: 8. Click the **JSON** tab. 8. Paste the following JSON: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation", "s3:ListMultipartUploadParts", "s3:HeadObject", "s3:GetObjectVersion", "s3:GetBucketAcl", "s3:GetObjectTagging", "s3:GetObjectVersionTagging" ], "Resource": [ "arn:aws:s3:::$bucket_that_we_will_share_with_you", "arn:aws:s3:::$bucket_that_we_will_share_with_you/*" ] } ] } ```` 1. Click **Review Policy** and enter a policy name 2. Click **Create Policy**. This will create your initial direct S3 access integration. Below is a sample PySpark script to test this direct access using Apache Spark and Python: ```python from pyspark.sql import SparkSession DELTA_TABLE_S3_PATH = "s3a://$bucket_that_we_will_share_with_you/Gold/LoanProduct" print("Initializing SparkSession with Delta Lake support...") spark = ( SparkSession.builder.appName("MambuDataLake Demo") .config( "spark.jars.packages", "io.delta:delta-spark_2.12:3.2.1,org.apache.hadoop:hadoop-aws:3.3.2", ) .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") .config( "spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog", ) .getOrCreate() ) # --- Load and Process Delta Table --- print(f"Attempting to load Delta table from: ") df = spark.read.format("delta").load(DELTA_TABLE_S3_PATH) print(f"Record count: ") print("Schema:") df.printSchema() print("First 5 rows:") df.show(5) ``` ### What we will need from you To enable your access, we will need the Account ID of your AWS Consumer Account. This will allow us to grant necessary permissions in our Producer Data Lake bucket policy. To enable your access, we will need the following information from your AWS environment: * **Your AWS Account ID**: This is your 12-digit AWS account identifier. (e.g., 123456789012). * **The ARN of the IAM Role or User in your AWS consumer account that you wish to grant access to**: This role or user will be used by your applications (e.g., PySpark scripts, Athena, Glue) to access the data lake. (e.g., `arn:aws:iam::123456789012:role/YourDataEngineeringRole`). ### What you will need from us (Mambu Insights team) We will provide you with the specific details of your data lake bucket, which you will need to configure access from your side: * **Producer Data Lake S3 bucket name**: This is the name of the S3 bucket in our AWS account where your data is stored. (e.g., `$bucket_that_we_will_share_with_you`). * **Example Gold Layer data path**: A representative S3 path to a dataset in your Gold layer, which you can use for initial testing. (e.g., `s3://$bucket_that_we_will_share_with_you/Gold/DepositProduct`). ## Using the data lake with AWS Athena AWS Athena is an interactive query service that makes it easy to analyze data directly in Amazon S3 using standard SQL. It's serverless, meaning you don't need to manage any infrastructure, and you pay only for the queries you run. Athena integrates seamlessly with the [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/catalog-and-crawler.html), where your table schemas will be stored. To start using the data lake with AWS Athena, refer to the sections above for configuring your AWS environment and IAM permissions: * [Required IAM Permissions](#required-iam-permissions) * [What we will need from you](#what-we-will-need-from-you) * [What you will need from us](#what-you-will-need-from-us-mambu-insights-team) ### Producer account bucket policy configuration This policy resides on our data lake bucket and explicitly grants your Consumer account read access. 1. Log into AWS Account **710271915571**. This is the Producer account. 2. Navigate to the S3 console. 3. Go to **Buckets** and select `$bucket_that_we_will_share_with_you`. 4. Go to the **Permissions** tab. 5. Scroll down to **Bucket policy** and click **Edit**. 6. Replace your entire existing policy content with the following JSON: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::710271915571:root" // Allows our own account's root full control }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::$bucket_that_we_will_share_with_you", "arn:aws:s3:::$bucket_that_we_will_share_with_you/*" ] }, { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::$your_account_number:root" // Grants access to ANY authenticated principal in your Consumer Account }, "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation", "s3:ListMultipartUploadParts", "s3:HeadObject", "s3:GetObjectVersion", "s3:GetBucketAcl", "s3:GetObjectTagging", "s3:GetObjectVersionTagging" ], "Resource": [ "arn:aws:s3:::$bucket_that_we_will_share_with_you", "arn:aws:s3:::$bucket_that_we_will_share_with_you/*" ] } ] } ``` :::note This policy directly grants various read and metadata access permissions to any authenticated principal in your Consumer Account (`$your_account_number`). This is a broad policy for initial unblocking and testing. For production, you would typically scope this down to specific IAM roles or use Lake Formation. ::: 7. Click **Save changes**. :::important If you encounter errors saving related to **Block Public Access**, you may need to temporarily disable these settings at the bucket or account level: 1. Go to the **Block public access (bucket settings)** section in the **Permissions** tab. 2. Click **Edit** to uncheck **Block all public access** and save. 3. Remember to re-enable the settings after testing for security. ::: ### Consumer Account ($your\_account\_number) - IAM Role Permissions You will need an IAM role in your consumer account that has permission to make S3 calls to our data lake bucket. You would typically use the `AWSReservedSSO_data-insights-dev-pu_314b1b9d83b21963` role obtained via AWS SSO. 1. Log into AWS Account `$your\_account\_number` (Consumer Account). 2. Navigate to the IAM console. 3. Go to **Roles** and select your primary execution role (e.g., `AWSReservedSSO_data-insights-dev-pu_314b1b9d83b21963`). 4. Go to the **Permissions** tab. 5. Click **Add permissions** > **Create inline policy**. :::note If your role is SSO-managed, you might not be able to attach inline policies directly. In such cases, these permissions must be granted via an AWS SSO Permission Set applied to the user/group that obtains this role. Consult your AWS administrator for this. For direct local testing, if you can't modify the SSO role, you'd typically create a *separate, modifiable IAM role* in your account (`$your_account_number`) with these permissions and ensure your SSO role has `sts:AssumeRole` on it. ::: 6. Click the **JSON** tab. 7. Paste the following JSON: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation", "s3:ListMultipartUploadParts", "s3:HeadObject", "s3:GetObjectVersion", "s3:GetBucketAcl", "s3:GetObjectTagging", "s3:GetObjectVersionTagging" ], "Resource": [ "arn:aws:s3:::$bucket_that_we_will_share_with_you", "arn:aws:s3:::$bucket_that_we_will_share_with_you/*" ] } ] } ``` 8. Click **Review policy**. 9. Policy name: `ReadDataLakeProducerBucket` (or a descriptive name). 10. Click **Create policy**. ### Using the data lake with AWS Athena AWS Athena is an interactive query service that makes it easy to analyze data directly in Amazon S3 using standard SQL. It's serverless, meaning you don't need to manage any infrastructure, and you pay only for the queries you run. Athena integrates seamlessly with the AWS Glue Data Catalog, where your table schemas will be stored. ### 3.3.1 Required IAM Permissions (Your AWS Account) Your Athena execution role (which is implicitly assumed by Athena when you run queries) needs permissions to: * Run Athena queries. * Access the AWS Glue Data Catalog to retrieve table metadata. * Read data from our S3 Data Lake bucket. * Write query results to an S3 bucket in your account. You will typically use an existing IAM role that has the `AmazonAthenaFullAccess` managed policy attached, and then add custom permissions to access our data lake. 1. Log into AWS Account **$your\_account\_number** (Consumer Account). 2. Navigate to the IAM console. 3. Go to "Roles" and select the IAM role you use for Athena queries (e.g., the same role as above `$YourDataEngineeringRole` or a dedicated Athena execution role). 4. Go to the "Permissions" tab. 5. Ensure the `AmazonAthenaFullAccess` managed policy is attached. 6. Click "Add permissions" \> "Create inline policy". 7. Click the "JSON" tab. 8. Paste the following JSON: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject", "s3:GetBucketLocation", "s3:ListMultipartUploadParts", "s3:HeadObject", "s3:GetObjectVersion", "s3:GetBucketAcl", "s3:GetObjectTagging", "s3:GetObjectVersionTagging" ], "Resource": [ "arn:aws:s3:::$bucket_that_we_will_share_with_you", "arn:aws:s3:::$bucket_that_we_will_share_with_you/*" ] }, { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions", "glue:BatchGetPartition" ], "Resource": [ "arn:aws:glue:ap-southeast-1:710271915571:catalog", "arn:aws:glue:ap-southeast-1:710271915571:database/$databasename", "arn:aws:glue:ap-southeast-1:710271915571:table/$databasename/deposit_product", "arn:aws:glue:ap-southeast-1:710271915571:table/$databasename/loan_product" ] } ] } ``` Click "Review policy". Policy name: `AthenaCrossAccountDataLakeAccess` Click "Create policy". ### 3.3.2 Glue Data Catalog Setup (Your AWS Account) Athena queries data based on schemas defined in the AWS Glue Data Catalog. For Direct S3 Access, you will need to create or manage Glue tables in your Consumer Account (**$your\_account\_number**) that point directly to the S3 data in our Producer Account. Log into AWS Account **$your\_account\_number** (Consumer Account). Navigate to the AWS Glue console. #### Create a Database: * Go to "Databases" in the left navigation pane. * Click "Add database". * Database name: `mambu_gold_data` (or a name of your choice for your data catalog). * Click "Create". #### Create a Crawler to Discover Data & Schema: * Go to "Crawlers" in the left navigation pane. * Click "Create crawler". * Crawler name: `mambu-gold-data-crawler` * Click "Next". * Data sources: * Choose "Add data source". * Data source type: S3. * S3 path: `s3://$bucket_that_we_will_share_with_you"/Gold/` (the base path to your Gold layer in our Producer bucket). * Click "Add S3 data source". * Click "Next". * IAM role: Click "Create an IAM role". * IAM role name: `AWSGlueCrawlerRole-MambuGold` (or descriptive name). * Click "Create". (This role will automatically get permissions to access the S3 path you specified, *but only within its own account by default*). * **CRITICAL:** You need to manually edit this newly created IAM role to add cross-account S3 permissions to our Producer bucket. * Go to IAM console, "Roles", find `AWSGlueCrawlerRole-MambuGold`. * Attach a new inline policy (or managed policy) with the same S3 permissions JSON you attached to your Athena execution role in Section 3.3.1 * Click "Next". * Output configuration: * Database: Select `mambu_gold_data`. * Crawler schedule: Choose "Run on demand" for i... --- ### Maven/Gradle Dependencies ```xml io.delta delta-kernel-defaults 0.3.0 runtime org.apache.hadoop hadoop-aws 3.3.4 org.apache.hadoop hadoop-client 3.3.4 ``` ### Sample Code (MambuKernelReader.java) ```java package com.mambu; /** * An example showing how to use the Delta Kernel to read a Mambu Data Lake table. * This code connects to a table, reads its latest version, schema, and then * iterates through the data. */ public class MambuKernelReader { public static void main(String[] args) throws IOException { // 1. Configure S3 access. // This uses AWS environment variables for credentials by default. Configuration hadoopConf = new Configuration(); hadoopConf.set("fs.s3a.impl", "org.apache.hadoop.fs.s3a.S3AFileSystem"); hadoopConf.set("fs.s3a.endpoint", "s3.ap-southeast-1.amazonaws.com"); hadoopConf.set("fs.s3a.aws.credentials.provider", "com.amazonaws.auth.EnvironmentVariableCredentialsProvider"); // The table path in your S3 bucket String tablePath = "s3a://$your_data_lake_s3_bucket/Silver/loanproduct/"; System.out.println("🚀 Reading Mambu Table with Delta Kernel: " + tablePath); System.out.println("=".repeat(60)); // 2. Create a Delta Kernel Engine and Table object. Engine engine = DefaultEngine.create(hadoopConf); Table table = Table.forPath(engine, tablePath); // 3. Get the latest snapshot of the table to read its state. Snapshot snapshot = table.getLatestSnapshot(engine); StructType schema = snapshot.getSchema(engine); System.out.println("📊 Table Schema (first 10 fields):"); List fields = schema.fields(); for (int i = 0; i < Math.min(10, fields.size()); i++) { StructField field = fields.get(i); System.out.printf(" - %s (%s)\n", field.getName(), field.getDataType()); } if (fields.size() > 10) { System.out.println(" ... and " + (fields.size() - 10) + " more fields."); } // 4. Build a scan to read the table data. // This creates a plan to read all data from the latest snapshot. Scan scan = snapshot.getScanBuilder(engine).build(); CloseableIterator data = Scan.readData( engine, scan, snapshot.getSchema(engine), Optional.empty() // No filter predicate ); // 5. Iterate through the data. // The data is returned in columnar batches for efficiency. System.out.println("\n🔍 Reading data..."); int rowCount = 0; while(data.hasNext()) { FilteredColumnarBatch batch = data.next(); try (CloseableIterator rows = batch.getRows()) { while(rows.hasNext()) { // You can process each row here Row row = rows.next(); rowCount++; } } } System.out.println("\n✅ Successfully read " + rowCount + " rows from the table."); System.out.println("💡 Note: Data is read in efficient columnar batches using Parquet format."); } } ``` ## Integration Option 2: Direct data access with Delta Kernel --- # Data Management Overview URL: https://docs.mambu.com/docs/data-migration-overview/ This section describes how to import and extract existing data into and out of Mambu. ## Importing data The steps for importing data into Mambu are: 1. Carry out the required preliminary steps described in [Prerequisites](#import-prerequisites). 2. Plan and schedule your migration. For an API-based migration, contact your onboarding consultant for help with planning the migration. For more information, see [Getting help](#getting-help). 3. Extract the data from your legacy system. For more information, see [Extracting data](#extracting-data). 4. Prepare your data for submission to Mambu. 5. Submit your data to Mambu using one or both of these methods: * The recommended way via the Mambu APIs. * Using a provided Excel template. For more information, see [Disadvantages of using Excel-based import](#disadvantages-of-using-excel-based-import). 6. Mambu automatically validates your submission. 7. Review your submission, and make any necessary corrections. 8. Confirm your import to complete the migration. ### Disadvantages of using Excel-based import We recommend using the Mambu API, or using the API in addition to using the Excel-based import. Migration with our Excel template does not support some common cases, including: * Importing Dynamic Loan Schedules or Revolving Credit Loans. * Specifying a penalty rate per account at import. * Importing deposit accounts with different interest rates - all deposit accounts imported with Excel sheets use the Deposit Product default interest rate. * Importing Deposit Transactions, only the current balance. Despite these limitations, there are cases where it is better or easier to import data via Excel, such as when your old systems export data in a CSV file. Many of the limitations with the Excel method can be addressed using our APIs after the initial import. If you will be retrieving data from your legacy system using an API, it is usually easier to migrate via API. ### Getting help Generally speaking, you are responsible for preparing your data for import, but we do provide some help. When importing via Excel, we provide a template sheet and detailed instructions for how to enter data. If you are planning to migrate via API, please contact your onboarding consultant to request support. They can work with you to help determine the best strategy and APIs to use, depending on your needs. For more information on how to contact your onboarding consultant, see [Importing your Data via API - What We'll Need from You](/docs/importing-your-data-via-api#what-well-need-from-you). Be sure to plan your migration carefully. Based on the amount of legacy data you have, it can take time. If your organization is already live, we strongly recommend planning to reduce the risk of any performance impact, such as scheduling migration after business hours when possible. No migration process is risk-free, so be sure that all your data is appropriately backed up during the process. ### Import prerequisites To migrate data into Mambu, the following setup steps must be completed. These steps ensure that the necessary structure is in place for your data to be imported into our systems: * [Create Mambu users](/docs/creating-new-users) and assign them the appropriate [permissions](/docs/permissions) to access Mambu. * Add your organization's [branches](/docs/branches-and-centres). * Add any [custom field definitions](/docs/custom-fields) that you want to include in the forms. * Add the [loan](/docs/setting-up-new-loan-products) and [deposit](/docs/setting-up-new-deposit-products) products that you offer. Completing this setup in advance allows us to assign all imported clients and groups to the appropriate branches and credit officers, to fill all necessary custom field values, and to assign all accounts to the appropriate products. For more instructions on importing data into Mambu, see the remaining pages of this section. ## Extracting data Mambu offers four options for extracting data: * [Mambu Extract](/docs/data-migration-overview#mambu-extract) * [Streaming API](/docs/data-migration-overview#streaming-api) * [Database backup](/docs/data-migration-overview#database-backup) * [Mambu - Stitch Extract, Transform, and Load (ETL) integration](#mambu-stitch-etl-integration) ### Mambu Extract Mambu Extract provides near real-time data synchronization directly to a cloud managed object storage, enabling immediate availability for data-consuming systems. For more information, see the [Mambu Extract guide](/docs/mambu-extract). ### Streaming API The Streaming API is a system to system communication tool that uses a pull-based communication strategy to allow you to stream large amounts of data out of Mambu. For more information, see [Streaming API](/docs/streaming-api) in our User Guide and the [Streaming API Reference](/api/pages/streaming/streaming-index). ### Database backup Mambu users may download their entire data set at any time by performing a database dump using the Mambu API. #### Performing a database backup with the API For more information on how to complete a database backup using the API, see [Database Backups](/docs/database-backups) in our User Guide and [Database Backup](/api/api-v2/database_backup/database-backup) in our API Reference. ### Mambu Stitch ETL integration The Mambu - Stitch ETL integration allows you to move data from Mambu into your data warehouse or data lake. For more information, see [Stitch connector](https://ecosystem.mambu.com/connectors/stitch/) on our Ecosystem site. --- # Database Backups URL: https://docs.mambu.com/docs/database-backups/ Mambu allows users or API consumers that have the **Download Backups** (`DOWNLOAD_BACKUPS`) permission to perform database backups. We recommend performing database backups using the [Database Backup](/api/api-v2/database_backup/database-backup) Mambu API v2 endpoint, since certain parameter methods such as `tables` and `createBackupFromDate` are only supported in the API v2 endpoint. In this article, we provide database backup best practices. ## End of day jobs and database backup We recommend you initiate database backups after the accounts state has been finalised for the day. In order to be notified when this is the case, we suggest you set up an **Accounts Updated** webhook, for more information see [EOD Accounts Updated Notification](/docs/automatic-end-of-day-actions#eod-completion-notification) ## API operations The database backup endpoint in API v2 provides you with two operations. You may use the `triggerBackup` operation to generate a database backup. For more information, see [Database backup - trigger Backup](/api/api-v2/database_backup/trigger-backup/). Next, if the operation was successful, you may use the `downloadBackup` operation to download the database backup. For more information, see [Database Backup - download Backup](/api/api-v2/database_backup/download-backup/). ## Backup storage The generated database backup is kept for 30 days. After 30 days it is removed and you need to issue another API call to generate a new backup. ## Mambu Extract You should consider using [Mambu Extract](/docs/mambu-extract) rather than the API database backup method if you have the following situations: * If your database backup time reaches six hours. The hard limit is 24 hours. * If the extracted data needs to have a defined SLA or other important business requirements. Mambu Extract is generally faster and more reliable than API backups. ## Best practices When you trigger a database backup, you may define an optional `callback` URL in the request body which will be triggered when the backup process is complete. Additionally, you may define specific tables that you want to backup using the `tables` array in the request body. For a list of available tables, see [Data Dictionary](/docs/mambu-data-dictionary). Finally, if you have defined a list of tables using the `tables` array and all the defined tables have a `creationdate` you may also define a `createBackupFromDate` value in the body of your request. The `createBackupFromDate` value must be in the `yyyy-MM-dd'T'HH:mm:ssZ` format. We recommend: * If you have more than one terabyte of data, use the `tables` array and, if possible, the `createBackupFromDate` property when performing a database backup to avoid timeout errors. * Using API v2 to trigger the database backup instead of the Mambu UI. * Defining the `callback` URL in order to be notified when the backup process is complete. * Performing a database backup by defining specific tables using the `tables` array to decrease the execution time for the database backup and avoid timeout errors. * Defining a `creationBackupFromDate` value, in situations where all the tables defined have a `creationdate` value, to further decrease database backup execution time. * Allowing for at least 24 hours between database backups. * Checking the response payload received at your callback URL to determine if the database backup was successful or if any errors were encountered. If the database backup operation is successful, you will get a response payload at your callback URL similar to the following example: `{ "tenantId": "TENANT_NAME", "result": "COMPLETE", "domain": "TENANT_NAME.mambu.com" "fileName": "tenant-MANUAL-DATABASE-BACKUP" }` If the database backup operation is unsuccessful, you will get a response payload at your callback URL similar to the following example: `{ "tenantId": "TENANT_NAME", "result": "ERROR", "domain": "TENANT_NAME.mambu.com" }` If the operation is unsuccessful, we recommend you make another request. In case of multiple failed database backup operations, please contact us through [Mambu Support](/docs/mambu-support). Database backup will restart automatically in the case of a machine restart, unless a critical error was encountered. If this happens, the client will have to restart manually. :::note If you receive the error message: `The provided table list is invalid. Tables which cannot be filtered by date: [table list]`, this means that you have mixed up tables that can be filtered with the `createBackupFromDate` parameter with tables that cannot be filtered with this parameter. If this occurs, you can perform two separate backups: * Tables which can be filtered * Tables which cannot be filtered. ::: --- # Database clone URL: https://docs.mambu.com/docs/database-clone/ During the development process a Mambu database schema is required to be linked to the Jaspersoft Studio for the reports to be build with the correct data structure. This database is also useful for the developer to have some data to work with. Our recommendation is to obtain a local clone of the database (schema and data) of one of your testing environments (such as sandbox) and work with it directly. We support this kind of operation, but note that only users with administration rights can perform it. For more details on how to obtain a database dump, please see our article on [Exporting your data](/docs/data-migration-overview). *** --- # Deactivating, Reactivating and Deleting User Accounts URL: https://docs.mambu.com/docs/deactivating-reactivating-and-deleting-user-accounts/ A *user* is anyone who accesses and uses Mambu via the UI or the API. Each user has a user account that stores the access credentials, the details of the person using the system, the role, and the permissions. The role and the permissions determine what each user is allowed to access and do in Mambu. ## Deactivating a user You can deactivate users in Mambu. The deactivated user will no longer be able to log in to Mambu and no clients, branches, or tasks can be assigned to that user anymore. To deactivate a user: 1. On the main menu, go to **Administration** > **Access**. 2. Select the **Users** tab. 3. Locate the user in the list and then select on **Actions** > **Deactivate**. 4. Select **Deactivate**. ![User deactivation and the related pop-up that is displayed](@site/static/img/support/users-and-access-control--deactivate-user-confirmation-dialog.png) If the user is a credit officer with any groups or clients assigned to them, you will have to select an additional checkbox in the **Deactivate User** dialog in order to confirm you want to deactivate the user. ![Deactivate User dialog for a credit officer with clients or groups assigned](@site/static/img/support/users-and-access-control--deactivate-user-confirmation.png) ### Deactivating the Mambu Support user For information on disabling access to the Mambu Support user, see [Granting access to your account with the Mambu Support user](/docs/mambu-support#granting-access-to-your-account-with-the-mambu-support-user) in the Mambu Support section. ## Reactivating a user In Mambu you can reactivate users that have been deactivated. To reactivate a user: 1. On the main menu, go to **Administration** > **Access**. 2. Select the **Users** tab. 3. Select the **Show deactivated/locked users** check box. 4. Locate the user in the list and then select **Actions** > **Activate**. 5. In the **Re-Activate User** dialog, select **Activate**. :::warning Users will also be deactivated when there is an excessive number of incorrect login attempts. Administrators can reactivate these users using the instructions above. ::: :::note There is no visual indication of which users are deactivated in the list. The only way to determine whether a user is deactivated is by selecting **Actions** and seeing whether the **Activate** option is there. ::: ## Deleting a user For audititing and traceability reasons, a user cannot be deleted if: * The user is a Support or Delivery user. * The user is the last or only user on the system. * The user is referred to in a custom field as value. * The user has attached documents. * The user is assigned to clients. * The user is a teller user and is assigned to a till. * The user has no clients, groups or transactions associated with them. * The user has performed activities as an author. * The user has logged loan or savings transactions. * The user has made actions, such as logging in or made any API calls. If deletion is not possible because of this, we recommend deactivating the user instead. To delete a user: 1. On the main menu, go to **Administration** > **Access**. 2. Select the **Users** tab. 3. Locate the user in the list and then select **Actions** > **Delete**. 4. In the **Delete** dialog, select **Delete**. Only users with the **Delete User** permission will be able to delete users. --- # Defining Risk Levels URL: https://docs.mambu.com/docs/defining-risk-levels/ *Risk Levels* are user defined categories composed by an interval for number of days in arrears and a correspondent provision amount. Risk levels will be used to calculate the organization's portfolio at risk (PAR), based on the number of loans in arrears that fall into each level. Based on the Central Bank's legislation in your country, you can define risk levels and the correspondent percentage of provision for each. Mambu will then automatically calculate the provision given your current PAR and you can have access to this information at any time from your [Risk Report](/docs/risk-report). :::note Risk levels in Mambu cover both loans and deposit accounts with overdraft enabled. ::: ## Adding risk levels To create a new risk level: 1. On the main menu, go to **Administration** > **Financial Setup** > **Risk Levels**. 2. Select **Add Risk Level**. 3. Enter the name, days and percentage of provision. 4. Select **Save Changes**. ![Administration - Financial Setup - Risk Levels view](@site/static/img/support/managing-your-organization--risk-levels-table.png) *** ## Provisioning for healthy loans If you also need to consider the healthy loans for the provisioning calculation, you can do it by **adding a new risk level from 0 to 0 days**. This will ensure that all accounts which are not in arrears will also be included in the Risk Analysis reports and in the Aging Analysis risk levels. The Aging Analysis is a type of report in Mambu that allows users to see their PAR and the provision amount based on the risk levels defined previously. ![Store Risk level screen with Name, From, To (days) and Provision (percentage)](@site/static/img/support/managing-your-organization--store-risk-level.png) --- # Deleting a Loan URL: https://docs.mambu.com/docs/deleting-a-loan/ To delete a loan account you must have the **Delete Loan Accounts** (`DELETE_LOAN_ACCOUNT`) permission. You may delete a loan account that has been created by mistake or closed without ever being used, meaning it has never been disbursed and no other activities related to it have been logged in the system. :::note You can only delete loan accounts that have **no** transactions or activities (such as tasks associated to them. A reversed transaction is also considered a transaction.) ::: We recommend to only delete loan accounts when they have been created by mistake. Otherwise we recommend using the **Reject**, **Withdraw**, or one of the options under **Close**. To delete an account: 1. Open the account. 2. On the right-hand side of the screen, select **More** > **Delete**. 3. Confirm. You can also delete a loan account via API 2.0. For more information, see [our API Reference](/api/api-v2/loans/delete). --- # Deleting Accounts URL: https://docs.mambu.com/docs/deleting-accounts/ Deleting a deposit account removes it permanently. Except when created by mistake, we recommend that you close deposit accounts, not delete them. :::note A deposit account cannot be deleted once a transaction has been made on it. ::: To delete deposit accounts, you must be authenticated with a user type **Administrator** or have the **Delete Deposit Accounts** permission. To delete an account: 1. Open the deposit account. 2. On the right hand side of the screen, select **More** > **Delete**. 3. Confirm. ![Close drop-down only with Delete option](@site/static/img/support/Close-drop-down-only-with-delete-option.png) --- # Deposit Account Overview Details URL: https://docs.mambu.com/docs/deposit-account-overview-details/ Balance information can be retrieved from a deposit account via API v2 by using the [Deposit Accounts - getById](/api/api-v2/deposits/get-by-id) endpoint. The same information is also available in the UI account overview, under **Details**. ![Overview of a deposit account with information about balance, overdraft and so on](@site/static/img/support/deposit-account-balances.png) | Balance | Description | Product Type Availability | Notes | | --- | --- | --- | --- | | **Total Balance** | The balance based on all the completed financial transactions booked to the Ledger. | All | If positive, it represents the total balance owed by the client, or the liability. If negative, it represents the total receivable from the customer, such as the overdraft balance. | | **Available Balance** | Total Balance + Available Overdraft Limit - Current Authorization Holds Balance - Blocked Balance - Locked Balance | All | The balance created by subtracting completed financial transactions as well as for transactions to be potentially settled in the future from the total balance. | | **Available Overdraft Limit** | Overdraft Limit - Overdraft Amount Due | Current Accounts | Amount from the overdraft limit that has not been used yet and is included in the available balance. | | **Holds Balance** | The total amount of authorization requests, before they are settled or expired. | Current Accounts | When the hold as parameter value is `advice=true`, a card hold will be enforced if the balance is insufficient. This will cause the available balance to be negative and the account to go into arrears. | | **Locked Balance** | Amount set up to be used as a guarantee for loans. | All | The locked amount is not available for withdrawal, therefore it is not included in the available balance. When there is a locked balance, the overdraft limit is not taken into consideration. The account acts as if the overdraft has been disabled. | | **Blocked Balance** | Amount which is blocked when there is an ongoing investigation, to be potentially seized in the future. | All | The blocked amount is not available for withdrawal, therefore it is not included in the available balance. | | **Overdraft Amount Due** | It represents the principal amount or the receivable that Mambu uses to calculate overdraft interest. | All | | ## Holds ### Card authorization holds The card authorization holds are used to verify electronic transactions initiated with a debit or credit card. A current authorization hold amount is therefore the amount awaiting authorization, being as such unavailable for further withdrawals until either the merchant clears or cancels the transaction or the hold expires. For more information, see [Card Transactions](/docs/card-payments-and-authorization-holds). ### Transaction holds Transaction holds directly on deposit accounts are used to support Single Euro Payments Area (SEPA) instant payment flows, cheque and multicurrency settlements, and other scenarios where a hold needs to be posted prior to an actual transaction. For more information, see the [Deposit Accounts - createAuthorizationHolds](/api/api-v2/deposits/create-authorization-hold/) endpoint in the API Reference. --- # Deposit Account Life Cycle and States URL: https://docs.mambu.com/docs/deposit-accounts-life-cycle-and-states/ Each new deposit account has a life cycle consisting of the following states: ## Pending Approval This is the initial state when you open a new deposit account. This means that the deposit application is under evaluation and can be “Approved” or “Rejected” as the next step of the process, or it can be “Withdrawn” by the client. :::note In this state it is still possible to edit the deposit account terms, such as the interest rate. ::: ### Withdraw a deposit account application If the client or your organization decides to withdraw the request for a deposit account, you can do it only if the account is in the "Pending Approval" state. To withdraw a deposit account application: 1. Open the deposit account. 2. On the right hand side of the screen, click on **Close** > **Withdraw**. 3. Add any notes about the reason for the withdrawal. 4. Select **Change Status**. ![Close drop-down with Withdraw or Reject options.](@site/static/img/support/deposits--deposit-account-details-with-close-actions.png) *** ### Reject a deposit account application When a deposit account is still "Pending Approval" and the application hasn't fulfilled your organization's requirements, for instance, you can choose to reject it. To reject a deposit account application: 1. Open the deposit account. 2. On the right hand side of the screen, click on **Close** > **Reject**. 3. Add a comment about the reason for rejection. 4. Select **Change Status**. ![Close drop-down with Withdraw or Reject options.](@site/static/img/support/deposits--deposit-account-details-with-close-menu.png) *** ## Rejected If the deposit account application doesn’t pass the initial evaluation, you can [reject](/docs/rejecting-a-deposit-account-application) it. The account will be automatically closed and classified in Mambu as "Closed (Rejected)". The deposit applications will keep all their associated information, such as comments, notes or attachments, and remain associated to the client or group. This will allow organizations to have a record of all applications which were rejected with comments explaining why. :::note The application can be re-opened later, which will put the account directly to an “Active” state. ::: ## Withdrawn If clients change their mind and decide not to move forward with the deposit application, you can [withdraw](/docs/withdrawing-a-deposit-account-application) their application. The deposit account will be automatically closed in Mambu, and classified as "Closed (Withdrawn)". :::note The application can be re-opened later, which will put the account directly to an “Active” state. ::: ## Approved Once the deposit account application passed the evaluation, it can be “Approved”. To approve a deposit account, chick on **Approve**, add any comments you might have and confirm the state. At this stage, the client can still “Withdraw” the application. :::note Once approved, you can still adjust the recommended deposit amount and set a maximum withdrawal amount by using the relevant options under **More**. ::: :::note It’s possible to send back the application to “Pending Approval” state by selecting the **Undo Approve** option under **More**. ::: ## Active Once the client makes any transaction (deposit, withdrawal or transfer) on the account, it will become “Active”. :::note It’s possible to send back the deposit account application to “Approved” by using the **Undo Activate** option under **More**, as long as no transactions have been yet posted on the account. ::: ## Dormant If no deposits, withdrawals, or transfers have been performed for a period of time, the account can be automatically set to “Dormant” state. This allows to identify and report on dormant accounts, as well as implement other specific workflows such as contacting the clients who own the dormant accounts. The dormancy period is optional and can be defined at Product level. Once the account status is changed to “Dormant”, no more interest is accrued on the account and no automated transactions are posted on it (interest, fees, transfers, and so on). :::warning Once a transaction is performed on a dormant account (by an authorised user, the deposit account will automatically change state to “Active” and accrued interest will be recalculated for the dormancy period and applied to the account.) ::: ## Closed When the client wishes to close the deposit account that has zero balance, you can close the account and stored it under the client's profile as "Closed”. :::note The deposit account can be re-opened, and it will be sent directly to the “Active” state. ::: ## Locked In order to prevent any transactions from being performed on the account (deposits, withdrawals, transfers), you can lock it under **More**. The new state will be “Locked”. :::note Only the accounts that are in "Active", "Dormant" and "In Arrears" states can be locked. ::: :::note It’s possible to “Unlock the Account”, which will set the deposit account back to an “Active” state which allows you to perform transactions. ::: If you don't want to lock the entire account, but only to block a certain amount from being withdrawn or transferred, you can do it via API. For more information, see [Blocking Funds in Deposit Accounts](/docs/blocking-funds-in-deposit-accounts#blocking-funds). **Additional states applicable to Fixed Deposit Accounts and Savings Plans** ## Begin Maturity Period Once the opening balance quota is reached (defined under the Deposit Product settings), you can “Begin Maturity Period” for that account. The state of the deposit account will remain “Active”. :::note It’s possible to “Undo Begin Maturity Period” for the deposit account by opening the account and, on the right hand side of the screen, select **More** > **Undo Begin Maturity Period**. ::: ## Matured Once the deposit account reaches maturity, it will be stored in the system as “Matured”. :::note Once the matured account has zero balance, it is possible to close the account and it will be stored under the client's profile as "Closed”. ::: **Additional states and processes applicable to Overdrafts** ## In Arrears When a deposit account with an overdraft has a negative balance after the overdraft expiry date or the overdraft limit is decreased below the current negative balance, Mambu will automatically change its state to "In Arrears" until the deposited amount will cover the overdraft balance. When the overdraft balance is covered, the deposit account will be sent back to the “Active” state. ## Written-Off When repayments are no longer expected on a deposit account with an overdraft that is “In Arrears”, it can be closed and written-off. To write off a deposit account with an overdraft, select **Close** > **Write Off**. You can also add any notes you wish to this transaction that will be stored with the history of transactions for this account. The account will be stored in the client’s profile as “Closed (Written-Off)”. :::warning If you wish to undo writing-off the account, select **More** > **Undo Write Off**. ::: --- # Deposit Fees Setup URL: https://docs.mambu.com/docs/deposit-fees-setup/ Mambu supports three types of fees you can set up when creating a deposit product, which you can apply to deposit accounts later: * Arbitrary fees * Manual fees * Monthly fees ## Set up a new deposit fee To set up a new deposit fee: 1. From the main dashboard, go to **Administration** > **Products** > **Deposits**. 2. In the bottom-right corner, select **New Deposit Product**. 3. In the **Product Fees** section of the **Creating a New Deposit Product** form, on the bottom-right corner, select **Add Fee**. 4. Enter a name for the fee you are creating. 5. Select the type of fee you want to set up. 6. Enter the amount of the fee. 7. Enter a unique identification number (ID) for the fee you are creating. 8. For monthly fees, under **Applied Date Method**, choose the method for calculating the day when the fee will be applied. See an example in the following table. 9. Once you are done configuring your product, select **Save Product**. ![Product fees section of creating a new deposit product form](@site/static/img/support/deposit-product-fees-1320x848.png) ## Deactivating and reactivating fees If a fee is no longer applicable, you can deactivate it by selecting the small green square next to it and then saving your changes. When the fee is deactivated, the small green square will turn from green to grey - and vice-versa. ![Product fees section with activate and deactivate little square](@site/static/img/support/activate-deactivate-deposit-fees-1386x710.png) To reactivate a fee, follow the same procedure: select the grey square, then save your changes. ## Deleting fees Fees can only be deleted if they have never been applied to any account. This option is only available for specific cases where a fee was created by mistake and we strongly recommend you to use it with care. To delete a fee, select the green **Delete** button on the right-hand side, then save your changes. ![Deposit product fees section with the option to delete a fee by selecting the x green button next to it](@site/static/img/support/delete-deposit-fee-1382x700.png) For fees that have already been used in an account you must deactivate the fee in order to delete it afterwards. After you deactivate the fee, it will no longer be applied to any accounts created under that product. ## Arbitrary fees These are fees which can be applied manually to accounts at any point and with any given amount. To activate arbitrary fees, select the **Allow Arbitrary Fees** checkbox in the **Product Fees** section of the **Creating a new deposit product** form. ![Product fees section with Allow Arbitrary Fees check box selected](@site/static/img/support/arbitrary-fees-1280x296.png) :::note If you apply arbitrary fees, you will not be able to separate accounting or reporting based on the fee type. Moreover, getting the reason why the fee was applied when auditing will be difficult. We strongly recommend creating and applying manual fees for each scenario instead. ::: ## Manual fees These are fee where you already know the amount you want to apply. ![Product fees section with example of manual fee of five euros](@site/static/img/support/manual-fee-1382x696.png) ## Monthly fees These are fees that are automatically applied to the accounts after being set up in the deposit product. ![Product fees section with example of monthly fee of 0.8 euros](@site/static/img/support/monthly-fee-1378x818.png) In the following table, you can see the exact dates when fees are applied according to the **Apply Date Method** you choose. | Account Activation Date | Monthly from Activation | First Day of Every Month | |---|---|---| | October 1 |
  • First fee applied on November 1.
  • Next fees applied on the first of each subsequent month.
    • |
  • First fee applied on November 1.
  • Next fee applied on the first of each subsequent month.
    • | | October 16 |
  • First fee applied on November 16.
  • Next fee applied on the 16th of each subsequent month.
    • |
  • First fee applied on November 1.
  • Next fee applied on the first of each subsequent month.
    • | | October 31. |
  • First fee applied on November 30.
  • Next fee applied on the last day of each subsequent month (for February, the 28th or 29th).
    • |
  • First fee applied on November 1.
  • Next fee applied on the first of each subsequent month.
    • | For more information about how to apply or adjust fees, see [Managing Fees in Deposit Accounts](/docs/managing-fees-in-deposit-accounts). --- # Deposit Products Configuration URL: https://docs.mambu.com/docs/deposit-products-configuration/ A deposit product allows you to set up the parameters for a type of deposit that you wish to regularly offer. Deposit products are flexible and highly-customizable templates for creating individual deposit accounts. For more information, see [Setting Up New Deposit Products](/docs/setting-up-new-deposit-products). With *Configuration as Code* (CasC), you may batch configure your deposit products configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for deposit products supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/depositproducts.yaml` | Get current deposit products configuration. | | `PUT` | `/configuration/depositproducts.yaml` | Write a new deposit products configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any deposit product(s) not included in the new YAML configuration will be deleted if they have never been used. If the deposit product(s) have been or are being used, then they will be deactivated. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### Additional headers You may send synchronous or asynchronous `PUT` requests. :::warning If you have more than 100 deposit products, we recommend you make your request asynchronous. ::: To use the endpoint asynchronously, you must provide two additional headers: * `X-Mambu-Async` with a value of `true`. * `X-Mambu-Callback` with the callback URL. The expected status code in case of a successful asynchronous request is `202 Accepted`. When the update configuration operation is completed, a message will be posted to the provided URL with information about whether the updated request completed successfully or not. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/depositproducts.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic \' ``` `\` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/depositproducts.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic \' \ --data-binary @depositproducts.yaml ``` `\` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@depositproducts.yaml` represents the absolute path of the file on your device. (Use “--data-raw” if you want to specify the YAML body inline). ### Configuration example ```yaml --- depositProducts: - id: "product1" name: "A product with only the minimum fields defined" type: "FIXED_DEPOSIT" category: "UNCATEGORIZED" state: "ACTIVE" description: "A saving product with a fixed deposit where clients can put\ \ a certain amount in and lock it to collect interest until maturity 2-5 months\ \ later" newAccountSettings: idGeneratorType: "RANDOM_PATTERN" idPattern: "@@@@###" availabilitySettings: forGroups: true forIndividuals: true branchSettings: allBranches: true branches: currencySettings: currencies: - "USD" interestSettings: daysInYear: "E30_360" paidIntoAccount: true - id: "DSP" name: "Product example with all fields defined" type: "CURRENT_ACCOUNT" category: "UNCATEGORIZED" state: "INACTIVE" description: "Commonly used savings product" newAccountSettings: idGeneratorType: "INCREMENTAL_NUMBER" idPattern: "2" availabilitySettings: forGroups: false forIndividuals: false branchSettings: allBranches: true branches: [ ] currencySettings: currencies: - "EUR" - "RON" - "CNY" maturitySettings: maturityPeriodInterval: defaultValue: 5 minValue: 3 maxValue: 7 maturityPeriodUnit: "WEEKS" taxSettings: withholdingTaxEnabled: false creditArrangementSettings: requirement: "OPTIONAL" internalControlsSettings: dormancyPeriodDays: 10 recommendedDepositAmount: 100 maxWithdrawalAmount: 120 openingBalance: minValue: 10 maxValue: 30 defaultValue: 20 allowOffset: true feeSettings: allowArbitraryFees: false fees: - id: "feeForNewProduct" name: "Deposit Made" active: true amount: 120.9 amountCalculationMethod: "FLAT" trigger: "MANUAL" accountingRules: [ ] interestSettings: daysInYear: "ACTUAL_365_FIXED" calculationBalance: "END_OF_DAY" paidIntoAccount: true collectInterestWhenLocked: true maximumBalance: 10003 interestRateSettings: interestRateSource: "FIXED_INTEREST_RATE" interestRateTerms: "TIERED" interestRateTiers: - endingBalance: 500 interestRate: 10 - endingBalance: 900 interestRate: 5 accrueInterestAfterMaturity: true overdraftInterestSettings: allowOverdraft: true allowTechnicalOverdraft: true maxOverdraftLimit: 100 daysInYear: "ACTUAL_365_FIXED" calculationBalance: "END_OF_DAY" interestRateSettings: allowNegativeInterestRate: false interestRateSource: "FIXED_INTEREST_RATE" interestRateTerms: "TIERED" interestRateTiers: - endingBalance: 500 interestRate: 10 - endingBalance: 900 interestRate: 5 accountingSettings: accountingRules: - glAccountCode: "11001" financialResource: "DEPOSIT_REFERENCE" - glAccountCode: "10002" financialResource: "SAVINGS_CONTROL" - glAccountCode: "11003" financialResource: "INTEREST_EXPENSE" - glAccountCode: "10004" financialResource: "FEE_INCOME" accountingMethod: "ACCRUAL" interestAccruedAccountingMethod: "END_OF_MONTH" ``` ## Input requirements The below input requirements are in addition to any existing validations or input requirements for deposit products. The same deposit product requirements apply whether a deposit product is made via the UI, API v2, or through CasC. ### Basic fields | Name | Description | Required | | --- | --- | --- | | `id` | Must not be empty, must be unique and have a maximum length of 32 characters. | ✔ | | `name` | Must not be blank and must be between 1 and 256 characters. | ✔ | | `state` | Must not be null. | ✔ | | `type` | Must not be null and must be an existing value. | ✔ | ### Availability settings | Name | Description | Required | | --- | --- | --- | | `availabilitySettings` | Must not be blank. | ✔ | | `forGroups` | Must not be null. | ✔ | | `forIndividual` | Must not be null. | ✔ | | `branchSettings` | Must not be blank. | ✔ | | `branchSettings.allBranches` | Must not be null. | ✔ | | `branchSettings.branches` | If defined, must contain existing IDs for branches. | ✘ | ### New account settings | Name | Description | Required | | --- | --- | --- | | `newAccountSettings` | Must not be blank. | ✔ | | `idGeneratorType` | Must not be null. Must be either `RANDOM_PATTERN` or `INCREMENTAL_NUMBER`. | ✔ | | `idPattern` | Must not be blank. If the `idGeneratorType` is `INCREMENTAL_NUMBER`, then it must be a positive number. | ✔ | ### Currency settings | Name | Description | Required | | --- | --- | --- | | `currencySettings` | Must not be blank. | ✔ | | `currencies` | Must not be empty. All the currencies must already be defined. | ✔ | ### Internal controls settings | Name | Description | Required | | --- | --- | --- | | `internalControlsSettings` | Not mandatory. | ✘ | | `dormancyPeriodDays` | If defined, it must be between 0 and 1999999973982208. |✘ | | `maxWithdrawalAmount` | If defined, it must be between 0 and 1999999973982208. | ✘ | | `recommendedDepositAmount` | If defined, it must be between 0 and 1999999973982208. | ✘ | ### Interest settings | Name | Description | Required | | --- | --- | --- | | `interestSettings` | Not mandatory. | ✘ | | `interestRateSource` | Must be an existing interest rate ID. | ✔ | ### Fee settings | Name | Description | Required | | --- | --- | --- | | `feeSettings` | Not mandatory. | ✘| | `id` |Must not be blank.| ✔ | ## Replies --- # Deposits, Withdrawals and Transfers URL: https://docs.mambu.com/docs/deposits-withdrawals-and-transfers/ Mambu allows you to efficiently manage and work with your clients' deposit accounts. ## Entering a deposit To log a deposit from a client on a current or savings account: 1. Go to the account's overview page. 2. On the right-hand side of the screen, select **Deposit**. 3. Enter the amount and use the **Channel** dropdown to select the transaction channel. 4. Select **Make Deposit**. To backdate a deposit, select the **Backdate** checkbox option and enter the needed date. ![Screenshot 2018-12-24 at 10.22.39.png](@site/static/img/support/deposits--deposit-account-details.png) ## Deposits collection To make several deposits you can use the bulk deposit option. To do so you must create first the Deposits Collections menu item. For more details on creating this menu item, see [Menu Items](/docs/menu-items). To make a bulk deposit transaction: 1. In the main menu, go to **Deposit Transactions** > **Deposits Collections**. ![Deposits Transactions menu with Deposits Collections options](@site/static/img/support/deposits--deposits-navigation-menu.png) 2. Select the dropdown menus to filter deposits per branch, centre, credit officer and product by selecting **Filter**. A list with all the deposits following the criteria you chose will appear. The default values for Deposit Amount are the ones defined in those accounts. 3. To make several deposits without changing the original amount due and date, **check the correspondent boxes** > select **Post Deposits** > select **Make Deposits**. [![deposits--post-deposits-modal.png](@site/static/img/support/deposits--post-deposits-modal.png)](https://mambu2.document360.io/docs/customer/portal/attachments/714128) The value in the Post Deposits button gets updated every time you add a new deposit, so that you can always see the total amount. ## Making deposit transactions in bulk :::warning Please Be Aware This feature is in the pre-release phase and enabled for certain customers on request. If you would like to learn more about whether this feature may fit your current or upcoming needs, please talk to your Customer Success Manager or Solutions Engineer. ::: Apart from using the UI, you can also post deposit transactions in bulk using the [API](/api/api-v2/deposits_transactions/make-bulk-deposits/). While the deposits collection functionality allows you to post multiple transactions simultaneously it fails in full if one of the transactions fails. With the API each transaction is processed separately, this means that if one of the transactions fails, the rest of them continue to run and have their own status. There is a second [API endpoint](/api/api-v2/bulks/get-bulk-status) that allows you to see the status of a bulk transaction, identified by the bulk `ProcessKey` which gives the status of the bulk and shows all successful operations processed alongside. ## Making withdrawals To log a withdrawal from a client on a current or deposit account: 1. Go to the account's overview page. 2. On the right-hand side of the screen, select **Withdrawal**. 3. Enter the amount and use the **Channel** dropdown to select the transaction channel. 4. Select **Make Withdrawal**. Withdrawals on accounts that have a maturity period enabled are not possible. Only administrators and users with the `MAKE_EARLY_WITHDRAWAL` permission can do this action. ![Make withdrawal pop-up with Cancel and Make Withdrawal buttons.](@site/static/img/support/deposits--make-withdrawal.png) ## Making transfers You can make transfers from a deposit account to another deposit or loan account, including from deposit accounts on overdraft balance, if they are made in the same currency. When you make a transfer from an overdraft account, the transferred amount will be debited on the overdraft account at the accounting level and credited on the target deposit or loan account. Transfers can be made even if the current deposit account balance is positive, but will become negative or overdraft after the transfer is made. :::note If the Accounting in Multicurrency feature is enabled, transfers will be allowed as long as the accounting rules of the related products contain general ledger accounts set in the same currency. ::: ### Custom fields for transfers Transfers are the only transaction type made without using transaction channels to which you may assign custom field definitions. Custom field definitions are additional fields you can create in order to capture additional information required for your business processes. For more information, see [Custom Fields](/docs/custom-fields) and [Posting Transactions with Custom Fields](/docs/posting-transactions-with-custom-fields). ## Early withdrawals in fixed deposits In a fixed deposit account, after the maturity period is started, only administrators and users with the `MAKE_EARLY_WITHDRAWAL` permission will be able to withdraw the deposit. Other users will not see this option. ## Backdating deposits and withdrawals Some organizations, due to the nature of their operations, need to backdate deposits or withdrawals that occurred days before. For instance, during a collection in the field. You can backdate any deposits or withdrawals. When posting a backdated transaction before an existing one Mambu will: 1. Reverse all the transactions posted after the new transaction entry date - all transactions that have an entry date greater than the current transaction entry date. 2. Post the new transaction. 3. Repost all the adjusted transactions. On the Accounting side backdated deposits and withdrawals will be logged for the date they were backdated for. The same happens for repayments. :::warning Transfers cannot be backdated. ::: ## Viewing the history of deposits, withdrawals, and transfers Every deposit, withdrawal, transfer, or fee applied to an account will be stored under **Transactions** - as well as the method of payment used for each of them. All this information will remain available after the account is closed. ## Adjusting deposits, withdrawals, and transfers For more information about adjusting deposits, withdrawals, and transfers, see [Adjusting Transactions](/docs/adjusting-transactions). --- # Developer Handbook URL: https://docs.mambu.com/docs/developer-handbook/ ## Learning about Jasper You can use the following tutorials and user guides to learn about Jasper: * [Introduction to Jaspersoft Studio](http://community.jaspersoft.com/wiki/introduction-jaspersoft-studio) * [Designing a report](http://community.jaspersoft.com/wiki/designing-report-jaspersoft-studio) * [Report Structure](http://community.jaspersoft.com/wiki/report-structure-jaspersoft-studio) * [Getting Started & Tutorials](http://community.jaspersoft.com/project/jaspersoft-studio/resources) * [Jaspersoft Studio User Documentation](http://community.jaspersoft.com/documentation) ### Predefined Reports Jaspersoft offers a set of [examples and usage details](http://jasperreports.sourceforge.net/sample.reference.html) about reports packed into a project. These details cover the main available features case by case. [Download the project](http://community.jaspersoft.com/project/jasperreports-library/releases) and explore it to see how different widgets can be used and how your reports can look like. Follow the [tutorial](http://community.jaspersoft.com/wiki/jasperreports-library-first-steps) to get examples compiled and filled with data. ## Using Jasper with Mambu Furthermore, you can learn about using Jasper with Mambu in the following sections. ### Data Dictionary Creating Jasper reports requires working with the Mambu database. We maintain a [data dictionary](/docs/data-dictionary-and-api-standards) with the tables and the relations between them. Explore each table: from its purpose, to its columns, types, and required data. A few charts also offer an overview of the most common entities. We recommend exploring the dictionary before you start working with Jasper reports. ### Parameter Types Parameters are used as input values for reports. They can be used to filter the results of Jasper to pass some data to be included. Mambu supports the parameter types: * String * Date * Boolean * Integer * Decimal * Double To use them, you have to declare the Jasper parameter of the equivalent Java type (like `java.util.Date` for the Date type). The result will be seen when opening the report's overview, where the input will be rendered in the according widget, such as the **Date** widget. The type is used in the input validation process, each one allowing only the intended values. These parameters can also have a description, displayed in Mambu as a label, to be clear in purpose. ### Default Parameters Mambu offers support for a few predefined parameters. These parameters, when used in specific contexts, get automatically completed at runtime. For example, let's assume a `BRANCH_ID` parameter is built into the logic of a report and the report associated with the `Branch` category so that it is available at the branch level. When running the report from the context of a branch, from its overview, Mambu will populate the ID without further input required from the user. If the same report is run directly from the **Administration** panel, the ID will have to be added by the user, as there is no branch context there. The following preview shows a report containing both predefined and regular parameters or go further and try the [Transactions per Account](/docs/transactions-per-account) report example on your own. :::warning Parameters are case-sensitive and in most cases should be written in ALL_CAPS with underscore used to separate words instead of any spaces, eg. `INTEREST_APPLIED` and not `interest applied`. The names of the parameters should also be identical when declared in a Jasper report. For example the `BRANCH_ID` parameter should have the `P` signature. ::: Check out the supported list of predefined parameters by report type: * Clients/Groups * `CENTRE_ID`, `CENTRE_KEY / GROUP_ID`, or `GROUP_KEY` * Branches/Centres/Users * `BRANCH_ID`, `BRANCH_KEY / CENTRE_ID`, `CENTRE_KEY / USER_ID`, or `USER_KEY` * Loan Accounts/Deposit Accounts * `ACCOUNT_ID`, and `ACCOUNT_KEY` * `CLIENT_ID`, `CLIENT_KEY`, or `GROUP_ID, GROUP_KEY` * Loan Groups * `ACCOUNT_KEY` * `GROUP_ID`, or `GROUP_KEY` * Loan Transactions/Deposit Transactions * `TRANSACTION_ID`, or `TRANSACTION_KEY` * `ACCOUNT_ID`, or `ACCOUNT_KEY` * `CLIENT_ID`, `CLIENT_KEY`, `GROUP_ID`, or `GROUP_KEY` :::warning Do not include schema names when developing new Jasper reports. Due to security reasons, the system does not support schema names. ::: ### Allowed MySQL variables and functions Starting with Mambu v9.63, in order to add new mySQL variables and ensure these are allowed in running Jasper Reports, make sure you use the `mbu_` prefix. For example, if you want to add `@myvariable`, you need to name it `@mbu_myvariable`. All previously used variables have been verified and added to our 'Allowed variables' list and existing variables will continue to be supported. Most MySQL functions that are secure will be executable, for more information, see [MySQL Functions and Operators ](https://dev.mysql.com/doc/refman/8.0/en/functions.html) on the MySQL website. ### Allowed Java and Groovy classes Starting with Mambu v9.63, in order to ensure continuity for your Jasper Reports, make sure the Java and Groovy classes you use are included in the Jasper Reports' built-in functions or check that they are present in our 'Allowed List'. We have also put together a list of 'Allowed Java/Groovy classes'. This list can be found in [Jasper Reports built-in functions](http://jasperreports.sourceforge.net/sample.reference/functions/FunctionsReport.pdf). ```java java.lang.StringBuffer java.lang.Boolean java.lang.Double java.lang.Byte java.lang.Float java.lang.Integer java.lang.Long java.lang.Math java.lang.Number java.lang.Short java.math.* java.time.* java.text.* com.mambu.number2words.api.factories.NumberTranscriberFactory.* java.util.Date java.util.Locale java.util.Calendar java.util.UUID ``` ### Jasper report configuration The results are returned a pages of 10 000 items per page. To avoid the results being unexpectedly truncated, make sure to build a pagination algorithm when working with larger data sets. ### Supported Fonts Mambu currently supports the use of the following fonts: * Deja Vu Serif * Deja Vu Sans * Deja Vu Sans Mono * Myanmar3 (regular type only) * Sans Serif (default font, not available for export) These fonts display as expected when a Jasper report is exported to PDF or other file formats. :::note Jasper Studio uses two sets of fonts: fontName and pdfFontName. These settings are visible in the advanced section of the element. These fonts can be configured independently, which means that the report can render fine in a preview, but break when exporting to PDF if the font is not available. For more information about fonts, see Text Elements section of the [Jasper Reports Ultimate Guide](https://jasperreports.sourceforge.net/JasperReports-Ultimate-Guide-3.pdf). ::: ### Troubleshooting If you want to use a function, but you get a 'Not Allowed' error or you have any other issue in the Jasper Reports, please contact us through [Mambu Support](/docs/mambu-support). --- # Overview URL: https://docs.mambu.com/docs/developer-overview/ In keeping with our philosophy of composable banking, Mambu provides many ways to develop software to interact with our services and features. ## Mambu APIs Mambu offers a full suite of RESTful APIs to provide programmatic access to nearly every aspect of our banking software, typically with JSON or YAML requests. Our APIs include: - [API v2](/api/pages/api-v2/welcome): APIs for our core banking platform. - [API v1](/api/pages/api-v1/welcome): Our legacy core banking API. - [Mambu Payments Gateway API](https://api.mambu.com/payments-api/#welcome): For making and receiving payments, mapping accounts to IBAN, Anti Money Laundering, and more. - [Streaming API](/api/pages/streaming/streaming-index): An enterprise feature which allows customers to set up configurable event feeds that can be used to power your own banking ecosystem. - [MPO API](https://ecosystem.mambu.com/mpo/overview/): An enterprise package which acts as a middle layer between different systems to pull, process, and push data via APIs. MPO has its own independent Remote Procedure Call API. For more information, see [Mambu APIs](/docs/mambu-apis). ## Webhooks Mambu supports highly-configurable webhooks, which may be used as user-defined callbacks triggered when your specified conditions are met by the cloud banking platform. For example, you may configure a webhook to `POST` a custom payload to your application whenever a loan account goes into arrears. For more information, see [Webhooks](/docs/webhooks-overview). ## Configuration as Code Configuration as Code (CasC) allows you to quickly configure new instances, standardize and migrate configuration between tenants, and duplicate configuration settings for multiple sandboxes. With CasC, you can batch configure supported Mambu elements such as organization details, custom field definitions, holidays, branches, user roles, and more via the API. This allows you to get or set multiple configuration settings for a supported element with a single API call per tenant. For more information, see [Configuration as Code](/docs/configuration-as-code-1/). ## Jasper Reports JasperReports is a powerful open source reporting tool that has the ability to deliver rich content onto the screen, to the printer, or to a variety of supported file formats. Jasper reports can be built to work with Mambu using a few simple steps. For more information, see [Jasper Custom Reports](/docs/jasper-reporting-overview). ## Mambu Apps Mambu Apps allow partners and developers to extend Mambu's capability and to add value with little effort. Apps are defined in a simple XML file - the definition includes general information about the application as well as specific endpoints and extension point which define how the app is shown in Mambu. For more information, see [Building Apps](/docs/introduction-to-mambu-apps). ## Frequently Asked Questions **How do I develop and test my apps?** We highly recommend using our [Sandbox environment](/docs/sandbox). Every partner and paying organization has access to a second environment where they can freely develop and test against APIs. This gives you a safe environment where you can try out new APIs, test changes, and experiment with new ideas. **Do you have wrapper libraries?** Our APIs are constantly being improved to add endpoints and features, and we generally recommend using a lightweight API client to access our APIs. This will make it easier to update and customize your API usage for the operations you are interested in. However, we do provide an open source Java wrapper library in our [GitHub space](https://github.com/mambu-gmbh/Mambu-APIs-Java), and you may download SDKs in a variety of languages. For more information on our SDKs, see [Tenant API Reference](/api/pages/api-v2/details-level) in our API Reference guide. **How is version control handled?** We do not support versioning. However, APIs are backward-compatible for at least one release and we announce any changes with our release notes. This means you'll have up to six months to change over from any modified APIs. See [Mambu Release Cycle](/docs/mambu-release-cycle) for more information. **How are new features rolled out?** We are constantly adding more functionality and improving the performance of our APIs with every release of Mambu. You can stay up to date on new features with our release notes, which are published on our [Mambu Community site](https://community.mambu.com/c/release-notes/18). If you have any specific questions or requests about the API roadmap, please [contact us](http://www.mambu.com/contact). **How can I check if a Mambu server is available?** The `/healthcheck` endpoint is a convenient way to manually or automatically check the status of a specific Mambu server. If the Mambu server is available, it will return response code `HTTP 200 OK`. You can enter the URL into a web browser or call the API using your tool of choice. Our [status page](https://status.mambu.com) will also provide you with real-time information and metrics on all servers, more information can be found in our [Mambu status](/docs/mambu-status) support page. **What is the tenant URL and endpoint for checking availability?**: You can check availability at `https://TENANT_NAME.mambu.com/healthcheck` using the following request: ```curl GET https://TENANT_NAME.mambu.com/healthcheck ``` | Response Code | Text | Description | | --- | --- | --- | | 200 | OK | Server is functioning properly | | 500 | Internal Server Error |Server is not available | --- # Disbursing a Loan URL: https://docs.mambu.com/docs/disbursing-a-loan/ When a loan account has been approved, the loan is ready to be disbursed. Users with the **Set Disbursement Conditions** (`SET_DISBURSEMENT_CONDITIONS`) permission can add and change the disbursement details on inactive loan accounts. Users without this permission will not be able to change disbursement details, but will still be able to post the actual disbursement on the account. Disbursement details impacted by this permission are: disbursement fees, channel type and it's fields, anticipated disbursement date and first repayment date. :::note Disbursement details can currently be defined only for Dynamic and Fixed Term Loans and Payment Plans. ::: Before a loan is disbursed, the disbursement details are displayed on the account overview, in the **Disbursement Details** section, until the loan is active. The details can be changed after the loan is created and a full audit trail is kept for changes made. ## Disbursing a loan account 1. Open the loan account. 2. On the right hand side of the screen, select **Disburse**. 3. Use the **Channel** dropdown to select a transaction channel. 4. Choose the date of disbursement (leave blank if using the current date). 5. Choose the first repayment date (leave blank if you want Mambu to calculate it automatically). 6. Fill the additional transaction details fields (as applicable depending on the selected transaction channel). 7. Review and select optional disbursement fees, if applicable. * If there are optional disbursement notifications enabled, they will be shown at the bottom of the screen. Select the email or the SMS checkbox to send the notification. 8. Select **Disburse**. After being disbursed, the account's status is automatically changed from **Approved** to **Active** and you can now log transactions on it. ![Disbursement dialog with fields like Amount, Currency, Disbursement Date, First Repayment Date, Channel and Notes](@site/static/img/support/loans--disbursing-loan.png) :::note The disbursal details stay associated to the transaction and you can easily have an overview of all disbursements and their reference numbers under the **Transactions** tab. ::: ## Disbursing a loan to a deposit account When performing a disbursement, you have the option to select one of the client’s active deposit accounts as the target or recipient account for the loan amount **if** the deposit product and loan product related to these accounts have the same accounting rules. The available deposit accounts are listed at the end of the **Channel** dropdown list. If you select a deposit account as the channel for disbursement, Mambu will perform a transfer from the loan to the deposit account, logging a Disbursement transaction on the loan account and a Deposit transaction on the savings account. A few restrictions apply in this case: * transfers are only allowed into accounts with a positive balance (not when an account has an overdraft) * transfers are not allowed into fixed deposit accounts If the Loan was disbursed into a deposit account, this action can be undone by reversing the disbursement, which will then also reverse the deposit transaction. :::note To disburse to a deposit account, the user needs to have two permissions: **Disburse Loans** (`DISBURSE_LOANS` ::: and **Make Deposit** (`MAKE_DEPOSIT`).) ## Reversing a loan disbursement If a loan was disbursed by mistake and there are no other (non-reversed) transactions on the account, the disbursement can be reversed. To do so, on the right-hand side of the screen, select **More** > **Undo Disburse** > Add a note (optional) > **Change State**. As a result, the loan account will change back into the **Approved** state. --- # Documentation Changelog URL: https://docs.mambu.com/docs/documentation-changelog/ This page describes major changes or additions to the following customer-facing sites. For release notes for Mambu software, see [Release Notes](https://community.mambu.com/c/release-notes/18) on our Community forum. * [Mambu User Guide](/docs/) * [Mambu API Reference](/api/) (v1, v2, Payments, Streaming, Mambu Functions) * [Ecosystem Developer Documentation](https://ecosystem.mambu.com/) (Connectors and Mambu Process Orchestrator) Most recent changes are listed first. | When? | Where? | What changed? | | --- | --- | --- | | 21 Jan 2025 | [Audit Trail V2](/docs/audit-trail-v2) |Added new page for the Audit Trail V2 release. | | 02 Dec 2024 | [Adjustable Interest Rates](/docs/adjustable-interest-rates)| Added new page for the Adjustable Interest Rates feature. | | 28 Oct 2024 | [Mambu Search](/docs/mambu-search) | Added new page for the Magic Search feature release. | | 9 July 2024 | [Backwards Compatibility](/docs/backwards-compatibility) | Cleaned up backwards compatibility content and merged into one new page. |ß | 6 Sep 2022 | [Schedulers and holidays](https://support.mambu.com/docs/schedulers-and-holidays) | Added an article about configuring schedulers and holidays for Mambu Payment Gateway as well as what impact this will have on incoming and outgoing payments with a requested settlement date falling on a configured holiday, or arriving after the configured cut off time for a scheduler. | | 26 Aug 2022 | [Cards Introduction](/docs/cards-introduction)| Created a new section about Cards where we added a new overview page and rearranged and updated the existing information about cards. | | 20 Jul 2022 | [Notifications Overview](/docs/notifications-overview) | Created two new sections, Email and SMS, under the Notifications section and rearranged respective articles. Added a notifications overview page.| | 22 Jun 2022 | [Currencies](/docs/currencies) | Added information about support for cryptocurrencies and non-traditional currencies.| | 15 Jun 2022 | [Managing your Organization Overview](/docs/managing-your-organization-overview) | Added new Overview page for Managing your Organization section.| | 03 Jun 2022 | [Menu Items and Custom Views Showcase](/docs/menu-items-and-custom-views-showcase) | Added new showcase page with an example of how to use menu items and custom views.| | 31 May 2022 | Payment Glossary | Moved terms in the Payment Glossary to official [Glossary](/docs/glossary). Payment Glossary was removed.| | 26 Apr 2022 | [Mambu UI Management Overview](/docs/mambu-ui-management-overview) | Added new Overview page for Mambu UI Management section. | | 1 Apr 2022 | MyMambu | As of 1 April 2022, the MyMambu self-service portal is no longer available, and we have removed all relevant documentation. Going forward, please use the Customer Service Portal instead. For more information, see [Customer Service Portal](/docs/customer-service-portal). | | 29 Mar 2022 | [Custom Views and API v1](https://support.mambu.com/docs/custom-views-and-api-v1) | Revised and restored legacy guide to using custom views to filter `GET` requests with API v1. | | 18 Mar 2022 | [User Guide](https://support.mambu.com/docs/welcome) | As part of a comprehensive refresh to our User Guide, the first several sections have been reorganized for greater clarity. All old links should still work. | | 17 Mar 2022 | [Data Migration](/docs/data-migration-overview) | Section substantially revised. | | 11 Jan 2022 | [Known Issues](/docs/known-issues) | Added Known Issues page. | --- # Dynamic Mortgages URL: https://docs.mambu.com/docs/dynamic-mortgages/ Dynamic mortgage products are a type of capital repayment loan featuring equal installments and interest that is calculated on the **principal** + **interest** outstanding. These products share many characteristics with standard dynamic term loans that also have regular payments and interest calculated on **principal** + **interest**. Dynamic mortgages make use of the equal installments logic, which is common with standard Declining Balance Equal Installment (DBEI) loans. Dynamic mortgages support two types of interest calculation: **simple interest** and **compound interest with daily rest**. The method for calculating the monthly equal installments and the interest itself differs based on the interest type. Here are the formulas used: **Simple interest** * The **monthly equal installment** is calculated using the PMT function: `PMT=PMT(IR/12,No. of installments,−Principal balance)` * Interest is computed using the formula: `(Principal balance+Interest Balance ) * IR%/Day count convention * No. of days in the interval` * For subsequent interest computations, only interest that has been applied but not yet paid is considered. * If the *Decouple interest from arrears* option is set to `true`, the interest balance will not be included in subsequent interest calculations. This prevents issues with duplicated interest in arrears amounts. **Compound interest** * The **monthly equal installment** is calculated using the PMT function: `PMT=PMT(Daily IR ,No of installments/12*Days in year ,-Loan amount)*Days in year/12` * Interest is computed using the formula: `Opening balance *((1+Daily IR)^(Number of days in interval)-1)` For more information on compound interest, refer to [Compound interest with daily rest](/docs/compound-interest-with-daily-rest). ## Calculating schedules for dynamic mortgages with equal installments The schedule for a dynamic mortgage is calculated using the following steps: 1. **PMT calculation**: The monthly payment (PMT) is determined. 2. **Interest calculation**: Interest for the specific installment period is calculated. 3. **Principal calculation**: The principal portion of the payment is calculated by subtracting the computed interest amount from the PMT. For this loan type, the final installment serves as an adjustment installment. This means that you will have equal installments from the first until the (n-1)th installment. The last installment - the nth installment - is then calculated as the ***remaining principal balance** + **interest accrued for that specific period**. Typically, this final installment's total due amount will differ from the preceding equal installments. ## Adjustable interest rates and dynamic mortgages Dynamic mortgage loans are compatible with [adjustable interest rates](/docs/adjustable-interest-rates). This inherent flexibility allows lenders to configure a product that can incorporate multiple interest rate types, such as fixed and variable rates, enabling them to define as many distinct interest rates as needed. The variable interest rate, often referred to as an index interest rate within Mambu, is composed of two key elements: * A source value, such as the Bank of England base rate. * A spread, which is an additional percentage added to the source value. This structure provides a robust framework for managing fluctuating interest rates throughout the loan's lifecycle. For more information, refer to [adjustable interest rates](/docs/adjustable-interest-rates). Note that negative spread functionality is not supported for dynamic mortgages. ## Prepayment and overpayments in dynamic mortgages For dynamic mortgage products, prepayments and overpayments are generally allocated to the upcoming pending installment. The precise behavior of how an installment is marked as paid is governed by the product configuration setting, specifically whether the system is set to **mark an installment as paid when the principal expected or the full due amount is paid**. This configuration significantly influences the subsequent calculations and overall behavior at the schedule level. Dynamic mortgage products support the same prepayment recalculation methods as standard [Dynamic Term loans configured with Equal Installments](/docs/payment-methods-for-dbei-loans). These methods determine how an overpayment impacts the loan schedule and include: * **Reduce amount per installment**: When this method is selected at the account level and an overpayment occurs, the loan schedule is recalculated by adjusting (reducing) the Payment (PMT) of all remaining installments. * **Reduce number of installments**: If this method is chosen at the account level, an overpayment will lead to a schedule recalculation by reducing the total number of installments from the end of the loan term. ### Overpayment in principal balance The **overpayment in principal balance** configuration for dynamic mortgages does not have an installment allocation, unlike standard prepayments. Instead, the installment is allocated exclusively to the principal balance. This direct principal reduction triggers an immediate schedule recalculation, which then adjusts future payments or the loan term based on the prepayment recalculation method configured at the account level. For more information, refer to [Principal Overpayment](/docs/principal-overpayment). ## Custom repayments One of the most important features of dynamic mortgages is the **custom repayments** functionality. This is an advanced capability that extends the standard repayment process, allowing users to override the default payment allocation method configured at the product level. Custom repayments enable precise control over how funds are applied, allowing payments to be directed towards specific items such as: * Principal * Regular interest * Interest from arrears * Fees * Other configured items. This option becomes mandatory under specific circumstances: * Whenever **interest from arrears** is decoupled from the regular repayment schedule. * When other items, such as certain fees - such as non-interest bearing, interest-bearing - are decoupled from the standard repayment schedule. All balances that are decoupled from the regular repayment schedule are exclusively payable via custom repayments, providing the necessary flexibility for their settlement. Custom repayment API details can be found in the [`CustomPaymentAmount`](/api/api-v2/loans_transactions/make-repayment) request body. ## Unsupported loan functionality Dynamic mortgages do not support the following features: * Funding sources * Penalties * Fee amortization * Negative interest rates * Securities * Taxes on interest, fees --- # Repayment Schedule Options for Dynamic Mortgage and Interest-Only Equal Installment Loans URL: https://docs.mambu.com/docs/edit-schedule-mortgage-options/ :::note For more information on editing loan repayment schedules, refer to [Repayments Schedule Editing](/docs/repayments-schedule-editing). ::: The ability to edit repayment schedule options is enabled via the checkboxes in the Loan Product setup screen, under **Repayment Scheduling** > **Repayments Schedule Editing**. ![Adjust principal payment schedule](/img/support/adjust-principal-payment-schedule.png) To modify repayment schedules for a mortgage product, navigate to the **Loan Account screen** > **More menu** > **Edit Schedule**. This will open the **Editing Repayment Schedule** screen. ![Editing Repayment Schedule](/img/support/editing-repayment-schedule.png) This functionality allows users to: * Change the due dates of repayments. * Edit the expected principal amount within an installment (available for [Dynamic Mortgages](/docs/dynamic-mortgages) only). * Adjust the overall term of the loan. ## Bulk update of subsequent due dates in the UI To update the subsequent due dates in the UI starting from a specific point in time, you can select the downward pointing arrow next to a due date to apply that date to all following due dates. This feature is designed to respect the product-level configuration regarding due date handling, specifically whether due dates should remain fixed or be automatically shifted if they fall on a non-working day. ## Adjust principal payments The product setup includes functionality to adjust the principal amount scheduled for repayment within a specific installment. Since each payment comprises both interest and principal, the **Edit principal** feature allows users to set the exact principal amount to be repaid with a given installment. This change consequently impacts the total amount of that particular repayment. It is important to note that any increase or decrease in the principal component of one installment necessitates a corresponding adjustment to the principal in another installment, ensuring the total required principal is repaid over the full loan term. To edit the schedule (edit due date, edit principal, payment holidays) via the API, use the Edit Schedule endpoint: [Update loan account schedule](/api/api-v2/loans_schedule/edit-schedule) ## Change loan term To change the loan term via the UI: 1. In the **Editing Repayment Schedule** screen, click the **Change Loan Term** button to open a modal. 2. In this modal, you can enter the new loan term. A preview of the updated repayment schedule, including the new total amount due, will be generated immediately. 3. You can then choose to either save the change to apply the new schedule or reject the change, which will keep the original loan terms and schedule intact. To change the loan term via the API, use the Change Loan Term endpoint: [Change loan account term](/api/api-v2/loans/change-loan-term) --- # Editing a Loan Account URL: https://docs.mambu.com/docs/editing-a-loan/ Loan accounts can only be fully edited while they are still pending approval. After they have been approved, it is only possible to edit a loan account's name, branch, notes, or add custom field definitions. You can no longer edit the loan terms, such as the amount or the disbursement date. To edit a loan account: 1. Go to the loan account you want to edit. 2. On the right-hand side of the screen, select **More** > **Edit Account**. 3. In the **Editing Loan Account** form, make the changes you need. For more details on the fields in the various sections of the form, see [Creating a New Loan](/docs/creating-a-new-loan). 4. Select **Save**. ![More button drop-down menu with Edit Account option selected](@site/static/img/support/loans--loan-account-details-with-context-menu.png) ## Adding custom field definitions to a loan account Before you add custom field definitions to a loan account, you must configure custom field sets and custom field definitions from **Administration** > **Fields**. For more information, see [Custom Fields](/docs/custom-fields). You can add custom field definitions to a loan account at any point and regardless of the account's state. To add custom field definitions to a loan account: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Add field**. 3. In the **Add field** dialog, fill in the information about the custom field definition you are adding to the loan account, such as the field set, the name, and the custom field value. 4. Select **Add field**. ![Add field options from More drop-down menu](@site/static/img/support/loans--loan-account-details-with-more-menu.png) You can edit the loan account's custom field values at any point during its life cycle. --- # Editing Accounts URL: https://docs.mambu.com/docs/editing-accounts/ You can only edit deposit accounts' terms and conditions when the account isn't active yet. After accounts are approved and in the _Active_ state, only the name, notes and custom field values can be changed. To edit an account: 1. Open the deposit account. 2. On the right-hand side of the screen, click on **More** > **Edit Account**. 3. Make the changes by editing the name, custom field value, or notes. 4. Click on **Save**. ![Edit Deposit Account after the Approval of the deposit](@site/static/img/support/deposits--deposit-account-details-3.png) To enter a value for a custom field definition: 1. Open the deposit account . 2. On the right-hand side of the screen, click on **More** > **Add Field**. 3. Enter the custom field definition name and its value. 4. Click on **Add Field**. ![Add field option and Add field pop-up](@site/static/img/support/deposits--add-field-modal.png) --- # Editing and Customizing Repayment Schedules URL: https://docs.mambu.com/docs/editing-customizing-repayment-schedules/ The "Edit Schedule" option is available for a loan account under the **More** options button, if the setup at the product level allows for it. For more details, please see [Repayments Schedule Editing](/docs/repayments-schedule-editing) To be able to edit a repayment schedule, you must have the **Edit Schedule** permission. *** ## Editing Fixed Loan Schedules To edit the schedule for Fixed Loans: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Edit Schedule**. 3. Make the changes. 4. Select **Save changes**. ![Editing Repayment Schedule screen where Due Dates, Principal and Interest can be edited.](@site/static/img/support/loans--editing-repayment-schedule-3.png) :::note You cannot increase the total interest, only decrease it. After making interest reduction changes on Fixed loans, the interest posted on the account will not match the interest rate of the product. The manual editing will override the automatically calculated interest. ::: *** ## Editing Dynamic Loan Schedules To edit the schedule for Dynamic Loans: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Edit Schedule**. 3. Make the changes. 4. Optional: Preview the changes you make to the schedule by selecting **Recalculate**. 5. Click on **Save Changes**, which recalculates the schedule to reflect the changes and saves it immediately (with no option to review it before saving changes) :::note * You can't edit a schedule when the account is locked. * Paid installments and installments with Interest Applied transactions cannot be edited. * Partially paid installments (that don't have Interest Applied) can be edited. * You can't edit the schedule of a loan in the `Approved` loan account state. ::: ### Adjusting payment dates The due dates for the installments must begin after the disbursement date and be always in an ascending order. There can be multiple installments due in the same day. If the account is assigned to a Credit Arrangement, the last installment due date will be validated against the Credit Arrangement "Valid until date”. For Equal Installment loans: when the due date is changed, the original total due amount will not change (interest and principal will be adjusted accordingly, but the total amount will stay the same). ### Adjusting principal payment schedule Principal can only be moved between the installments. The total outstanding balance needs to be fully allocated at all times. It is therefore not possible to increase or reduce the total outstanding balance. The installment that has the principal edited and defined by the user will not be changed by any future recalculations made by Mambu. Installments with zero principal during the pure grace period cannot be edited. For Equal Installment loans: Principal on the last installment is not editable. When the principal is edited, the total due amount on the previous installments will not be changed, and only the next installments after the edited one will have equal installments recalculated (based on the remaining principal balance and remaining number of installments, including installments with custom principal). ### Adjusting the number of installments You can add more installments or delete existing ones; however, the total number of installments will be validated against the Minimum and Maximum installments allowed within the product constraints. If a new installments is added on a Declining Balance loan, the principal for this installment needs to be specified and adjusted manually. Installments with zero principal during pure grace period cannot be deleted. Only installments that don't have anything paid can be deleted. For Equal Installment loans: If a new installments is added and left with no principal, the principal will be calculated automatically after selecting the **Recalculate** button to keep the equal installment amount. However, if you fill in a principal, it will be considered custom. *** ## Editing Revolving Credit Loan Schedules After creating a new Revolving Credit loan account, you will have the option **Edit Schedule** under the **More** button, allowing you to edit the schedule while the account is in `Partial Application`, `Pending Approval` or `Active` (`In Arrears`, `Locked` included) states. Due dates in the Revolving Credit accounts are not always fixed, nor predefined for the full term of the loan at the moment when the contract is signed with the client. However, you can customize the schedule for Revolving Credit loan accounts to accommodate for such scenarios when the installment due dates are aligned with the clients’ salary pay dates, which effectively means that they may fall on different days each month. ### Schedule editing in Pending Approval state, no custom installment manually added ![Editing Repayment Schedule on Revolving Credit while in Pending Approval state.](@site/static/img/support/loans--editing-repayment-schedule.png) ### Schedule editing in Active state, custom installments manually added ![Editing Repayment Schedule on Revolving Credit - custom installment manually added](@site/static/img/support/loans--editing-repayment-schedule-5.png) #### If the account has installments due or already defined You can add or delete installments; however, the delete functionality is only available for installments that are manually added, it does not apply for installments added by the system. When adding a new installment, you can define the due date, while principal and interest due will be empty. They will be filled in when the installment will become due. Adding new installments before already paid installments will not be possible. #### If the account doesn't have installments due or defined An empty installment will appear by default. You will be allowed to add or delete installments, with the same constraints mentioned above. The installments will be shown in the Schedule, even if they do not have any principal and interest allocated, with `Pending` state as default. ### On End of Day processes, or when the disbursement is backdated The due and past-due installments will be populated with interest and principal. Installments will be added according to the **Fixed days of month** setting on the account, if there's still principal balance to be allocated, after the last custom installment due date. If a custom date installment was added before or after the date defined on the product (Fixed days of month), then Mambu will not add an additional installment. Installments will be marked as Grace if the installment is due or past-due but no principal or interest is allocated to it. For Dynamic Loans Declining Balance with Pre-Payments Recalculations methods set to either **No Recalculation** or **Recalculate the Schedule, Keep the Same Principal Amount**, if you click on the **Calculate Schedule** button under the **Schedule Preview** section, you will be able to edit or adjust the schedule directly, by changing the due dates, allocation of the principal, or adding and deleting installments. :::note The changes available will always depend on the product settings. Every change will be logged under **Activities**. ::: --- # Enabling Federated Authentication with Mambu URL: https://docs.mambu.com/docs/enable-federated-authentication-with-mambu/ There are two types of authentication available in Mambu, *Mambu login* and *federated authentication*. *Mambu login* is the default authentication system. You are provided with a username and password managed through our system. *Federated authentication* on the other hand allows users to connect to Mambu using Single Sign-On (SSO). With SSO, users authenticate through an Identity Provider (IdP) such as Okta, Azure Active Directory, Centrify, metOneLogin, or Google. Then they are able to access a variety of web applications without re-entering their username and password. The Mambu federated authentication feature is based on **SAML 2.0 (Security Assertion Markup Language**). :::warning Transitioning to federated authentication is irreversible. Administrators and users with API access will still have access to Mambu login however all other users will have to log in through their IdP. ::: *** ## How we implemented SAML 2.0 in Mambu Our implementation uses a SAML 2.0 redirect profile. All SAML requests are resolved via the user’s browser. **Steps:** 1. User wants to login to Mambu via IdP (a GET request is initiated to Mambu, SAML, or login endpoint). At our end, we prepare a SAML request that is sent to the user's browser. 2. The SAML request for login is sent to the IdP. 3. User logins to the IdP. 4. A SAML response is prepared at the IdP's end and sent to the user's browser. 5. The SAML response is posted to Mambu, SAML, or login endpoint. Depending on the SAML response (which is verified for authenticity) we either start a Mambu session or not. :::note All SAML 2.0 authentication requests made by the Mambu application to your IdP are signed. To download the certificate that allows you to verify the signature of Mambu requests, go to **Administration** > **Access** > **Federated Authentication** and select **Download**. ![Download signature button](@site/static/img/support/users-and-access-control--pem-certificate-download.png) We recommend consulting your IdP's documentation for more information on setting up the relevant configuration for IdP certificate signature verification. ::: ## General Setup :::note If you are using one of our most common IdPs then please refer to our step-by-step guides provided for [Google Apps](/docs/google-as-idp), [Azure Active Directory](/docs/entra-id-as-idp), [Centrify](/docs/centrify-as-idp), [OneLogin](/docs/onelogin-as-idp), or [Okta](/docs/okta-as-idp). Otherwise you can follow the more general steps below. ::: ### Step 1. Configure the IdP First, create a new Mambu SAML application in your IdP. This application will communicate with Mambu. If you regularly use sandboxes to test new features, it might make sense to already create an application for your Mambu Sandbox instance now, too. See [below](#using-sandboxes-with-federated-authentication) for more information on using federated authentication with a sandbox instance. ### Step 2. Assign Users to the SAML 2.0 Application Import the existing Mambu users in the IdP by getting the usernames from the database or create your Mambu users in the IdP of choice using the same username. We will map the existing users into the IdP based on their unique username and we will make sure they have the same level of access (permissions and roles) once you enable federated authentication. ### Step 3. Enable Federated Authentication in Mambu :::warning Please initiate the login from the Mambu login form. We do not support IdP-initiated login. Also, you must be an administrator to set up federated authentication. ::: 1. On the main menu, go to **Administration** > **Access** > **Federated Authentication**. ![Federated Authentication tab with Enable Single Sign-On check-box](@site/static/img/support/users-and-access-control--access-federated-authentication-settings.png) 2. Select the **Enable Single Sign-On** checkbox. 3. Enter all the necessary information: | Field | Description | Required? | | --- | --- | --- | | Name | Name for the IdP. Displayed on the "log in using your IdP" link provided in by Mambu. |✔ | | Single Sign-On Endpoint | SSO endpoint available from your IdP settings. Select the **Private Identity Provider** checkbox if your IdP is not publicly available.|✔ | | Certificate Fingerprint | When you set up your IdP, you will download a certificate. To get a SHA-256 fingerprint from this certificate, use the follow command: `openssl x509 -noout -fingerprint -sha256 -inform pem -in `. Replace the placeholder in curly braces with the actual path to your certificate file. |✔ | | Issuer ID | The URL that contains the domain name of the IdP. It must have the format `https://` or `http://`. |✔ | | ACS URL | The URL where your application is hosted. This field is required when using a reverse proxy, or when using an IdP with a dedicated environment. This will correlate the response with the original AuthRequest. It must match the ACS URL and Entity ID configured in your IdP. |✘ | ![Single Sign-On options screen](@site/static/img/support/image-20220302-160640.png) 4. Select **Test SSO Connection** to verify that setup is correct and the communication between Mambu and the IdP is successful. 5. Select **Save Changes**. In the **Confirm Federated Authentication Setup** dialog, select **Yes**. ![confirm federated authentication setup dialog](@site/static/img/support/image-20220302-160307.png) Now a SAML conversation is started between Mambu and the IdP. The setup of Single Sign-On is now complete. Once you enable the federated authentication feature, the Mambu login form will include a link at the bottom that allows you to log in with your IdP. The IdP name will be whatever text you entered in the **Name** field during setup. :::warning * When federated authentication is enabled, you can no longer create new users from the Mambu UI, and will have to create new users in your IdP. We will automatically provision new users into Mambu during their first login. * You may continue creating users with API permissions through the Mambu Users API, but they must have a role set up as well. ::: --- ## Using sandboxes with federated authentication To use a sandbox with federated authentication enabled, you will need to create a separate application in your IdP, such as a "Mambu Sandbox" application with its own certificate fingerprint and single sign-on endpoint. To create such an application, follow the same steps that you used to set up your production instance, as described in [General Setup](#general-setup). This is necessary because, if you do not, when you clone a production instance to a sandbox and try to log in using federated authentication, the login request will come from a different domain and will be rejected. Remember, you may not need to add all users to this application, just those who are going to be accessing the sandbox. Each time you clone your production instance to your sandbox, you will need to update the federated authentication settings to point to the Mambu Sandbox application you created in your IdP. In order to do this you will need to have at least one user with administrator permissions. To update the federated authentication settings: 1. On the main menu, go to **Administration** > **Access** > **Federated Authentication**. 2. Replace the cloned production data with the single sign-on endpoint, certificate fingerprint and Issuer ID for your Mambu Sandbox application. 3. Select **Save Changes**. ## Using SSO under a proxy To use SSO when the Mambu application is running under proxy, you need to do the following: 1. Configure the proxy to pass the `x-mambu-proxy-host` header to Mambu. The header should point to the proxy host and not the Mambu host. 2. If the proxy is configured to pass the proxy host in the `host` header to Mambu, this configuration should be removed. When the proxy is forwarding requests to Mambu the host header should be the Mambu host. ### Example If your Mambu instance is `https://mybank.mambu.com` and it is running under a proxy at `https://theproxyaddress.com`, the requests should be forwarded to Mambu with the following headers: - The `x-mambu-proxy-host` should be `https://theproxyaddress.com`. - The `host` value should be `https://mybank.mambu.com`. --- # Enabling Single Logout URL: https://docs.mambu.com/docs/enable-single-logout/ The Single Logout (SLO) feature is an optional part of federated authentication. With federated authentication a user can sign into Mambu using Single Sign-On (SSO) through an Identity Provider (IdP). Examples of common IdPs are Okta, Azure Active Directory, Centify, OneLogin, or Google. With SSO a user can sign into multiple web applications by only providing their username and password once. In this case, Mambu and these other web applications are referred to as Service Providers (SPs). The *Single Logout* (SLO) feature allows a user to log out of one SP ( i.e. web application) that they signed in to using SSO and then get logged out of all the other SPs that they had logged into during that same SSO session. This means a user can logout one time from one application and does not need to logout of multiple applications. ## How Single Logout works with Mambu and your IdP ![users-and-access-control--diagram-single-logout-flow-architecture.png](@site/static/img/support/users-and-access-control--diagram-single-logout-flow-architecture.png) 1. A user logs outs of the Mambu application. 2. Mambu generates a digitally signed **LogoutRequest SAML** message and returns it to the end-user’s browser. 3. The browser follows the redirect and requests the IdP’s SLO URL with the LogoutRequest in the query string. 4. The IdP determines the other SPs that support SLO, to which the end-user received SSO during the current logon session. The IdP then iteratively does the following for each participating SP: * Generates a new, digitally signed LogoutRequest. * Redirects the user’s browser to that SPs SLO endpoint. * Waits for a LogoutResponse from the SP, via the user’s browser. 5. Each SP terminates their own logon session for the end user after receiving and validating the LogoutRequest from the IdP. 6. The IdP terminates its own logon session and sends a final LogoutResponse message to the initiating SP (in our case, Mambu). This matches the original LogoutRequest that was sent in step #1. The response includes a flag telling the originating SP whether SAML SLO was either fully or only partially completed. 7. Mambu displays a login page to the end-user. *** ## How to Setup Single Logout in Mambu To enable single logout for an organization: 1. On the main menu, go to **Administration** > **Access** > **Federated Authentication**. ![users-and-access-control--single-logout-configuration.png](@site/static/img/support/users-and-access-control--single-logout-configuration.png) 2. Select the **Enable Single Logout** check box. 3. Download the certificate by selecting **Download**. 4. Select **Save Changes**. :::warning Please Be Aware The `Mambu Logout URL` field is pre-filled and cannot be edited. The downloaded certificate needs to be uploaded to the IdP configuration area (e.g: Signature Certificate). ::: To download the Mambu certificate that will be used to verify the authenticity of the signed LogoutRequest in the IdP: on the main menu, go to **Administration** > **Access** > **Federated Authentication** and then go to the **Logout** section. A session timeout in Mambu will not trigger a logout request to the IdP. *** --- # Enabling Ping Identity SSO URL: https://docs.mambu.com/docs/enabling-ping-identity-sso/ This guide will enable you to set up Ping Identity (PingID) in Mambu for Single Sign On. ## PingID SSO setup 1. If you don't have a PingID account, visit the [Ping Identity site](https://www.pingidentity.com/en/account/sign-on.html) to create a free account or log in to your existing one. 2. From your environment screen, select the relevant environment for SSO configuration. 3. Choose the **Build your own solution** option and select the appropriate cloud service for your organization. 4. On the left-side menu, click the *Connections* icon to create a new application. ![connections icon](/img/support/connections-icon.png) 6. Select **Advanced Configuration** and then choose the **configure** option for SAML. ![configure-saml.png](/img/support/configure-saml.png) 8. Populate the application name and description, then click **Next**. 9. Select the **Manually Enter** option and fill in the fields as follows. * **ACS URLS**: `https://.mambu.com/saml/login` * **Entity ID**: `https://.mambu.com/saml/login` * **Target Application URL**: `https://.mambu.com/saml/login` * **Assertion Validity**: 60 * Click the “Save and Continue” button. 10. Download the `.crt` Signing Certificate. 11. Create the mapping as indicated below and click **Save**. ![attribute-mapping.png](/img/support/attribute-mapping.png) 13. Enable the newly created application by selecting the toggle. ![enable-application.png](/img/support/enable-application.png) 15. Navigate to the **Configuration** tab of the new application and save the *ISSUER ID* and *SINGLE SIGNON SERVICE* values, as they will be needed for SSO configuration in Mambu. ## Mambu SSO setup 1. Log into Mambu and navigate to **Administration** > **Access** > **Federated Authentication**. 2. Select the **Enable Sign Sign-On** checkbox, ensuring the **Manual Settings** option is also selected. 3. Fill in the following parameters: * **Name**: This can be any chosen name and will be displayed on the Mambu login page for SSO login. * **Single Sign-On Endpoint**: This is the *SINGLE SIGNON SERVICE* value saved from the previous section. * **Certificate FingerPrint**: This is derived from the `.crt` certificate downloaded in step 7 of the Ping Identity setup. * Run the command `openssl x509 -noout -fingerprint -sha256 -inform pem -in ` from your terminal to generate the fingerprint. * **Issuer ID**: This is the *ISSUER ID* saved from the previous section. 4. Save the changes and click **Test SSO connection** to validate the SSO functionality. ## PingID user creation and group setup To use PingID SSO for Mambu login, you need to create users and assign them to groups in PingID. The groups in PingID should correspond to roles in Mambu. ### PingID group creation 1. Navigate to **Identities** > **Groups**. ![groups-pingid.png](/img/support/groups-pingid.png) 2. Select the **+** icon to create a new group and populate the fields appropriately. ![create-new-group-pingid.png](/img/support/create-new-group-pingid.png) ### PingID user creation 1. Navigate to **Identities** > **Users**. ![users-pingid.png](/img/support/users-pingid.png) 2. Click the **Add User** button and populate the user attributes as needed. ### Assign users to groups 1. In PingID, navigate to the user and click on the **Groups** tab to assign users to a group. 2. Click the **Add** button to select the group. 3. Select the group and **Save**. After completing these steps, visit your Mambu tenant, click the SSO link on the login page, and log in with any of the newly created PingID users. --- # End of Day Processing Configuration URL: https://docs.mambu.com/docs/end-of-day-processing-configuration/ End of Day (EOD) processing refers to the daily and hourly jobs that are executed usually at the end of each day in order to manage the data in your system properly. For more information about this topic, see [End of Day Processing and Cron Jobs](/docs/automatic-end-of-day-actions). With *Configuration as Code* (CasC), you may batch configure your End of Day Processing configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for end of day processing supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/endofdayprocessing.yaml` | Get current end of day processing configuration. | | `PUT` | `/configuration/endofdayprocessing.yaml` | Write a new end of day processing configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any optional configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/endofdayprocessing.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. :::warning If your `endOfDayProcessingMethod` is set to `MANUAL` then the configuration you will retrieve will not have the `accountingCutOffTime` specified. ::: ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/endofdayprocessing.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @endofdayprocessing.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@endofdayprocessing.yaml` represents the absolute path of the file on your device. (Use “--data-raw” if you want to specify the YAML body inline). ### Configuration examples ```yaml --- endOfDayProcessingMethod: "AUTOMATIC" accountingCutOffTime: "10:00:00" ``` :::warning The **Accounting Cut-Off** feature is an Early Access feature. If this feature is not enabled you will only be able to specify the accounting cut-off time via the API and not in the UI. For more information, see [Accounting Cut-off](/docs/automatic-end-of-day-actions#accounting-cutoff). ::: ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `endOfDayProcessingMethod` | String | The end of the day processing method. The options are `AUTOMATIC` or `MANUAL`. | ✔ | | `accountingCutOffTime` | String | The accounting cut-off time. The format is `hh:mm:ss`. | Required if `endOfDay`
    `ProcessingMethod`is `AUTOMATIC`, otherwise it is optional. | ## Replies --- # Using Microsoft Entra ID as your Identity Provider (IdP) URL: https://docs.mambu.com/docs/entra-id-as-idp/ This article provides instructions on how to set up Microsoft Entra ID (Entra) as an Identity Provider (IdP) for federated authentication. ## Set up an enterprise application 1. Sign in to [the Azure Portal](https://portal.azure.com) with an administrator account and from the Entra services list on the homepage select **Enterprise applications** > **New application**. 2. You must select **Create your own application** because Mambu is not one of the gallery applications. In the **Create your own application** dialog, provide a name for your new application and select **Create**. 3. Go to **Set up single sign on** > **SAML**. 4. In the **Set up Single Sign-On with SAML** screen, you must fill in the information for the **Basic SAML Configuration** section. The **Identifier** and **Reply URL** fields are required. ![Basic SAML Configuration information](@site/static/img/support/Step%202%20-%20enterprise-application%281%29.png) 5. Go to the **Attributes & Claims** section. You must edit each of the claims to remove the **Namespace** value, edit the **Name**, and in some cases edit the source attribute value. Refer to the table below for the correct values. The **RoleID** claim does not exist, you must select **Add new claim** to create it. | Claim name | Source attribute (value) | | --- | --- | | Email | user.mail | | First Name | user.givename | | Last Name | user.surname | | Language | user.preferredlanguage | | RoleID | user.assignedroles | | Unique User Identifier | user.mail | ![claims.png](@site/static/img/support/claims%281%29.png) You must also make sure to make the Unique User Identifier **Persistent**. ![Azure_Persistent_nameid.png](@site/static/img/support/Azure_Persistent_nameid%281%29.png) After you are done making the edits to the **Attributes & Claims** section, the section should look like the image below. ![Attributes and Claims section](@site/static/img/support/Step%202%20-%20enterprise-application%20copy.png) 6. Go to the **SAML Certificates** section and select to edit the section. ![SAML Certificates section](@site/static/img/support/saml.png) In the **SAML Signing Certificate** dialog, select the edit option and then select **PEM certificate download**. ![azure-samlcertificate.png](@site/static/img/support/azure-samlcertificate%281%29.png) 7. Create a SHA-256 certificate fingerprint from the PEM certificate, using the following command: ```shell openssl x509 -noout -fingerprint -sha256 -inform pem -in ``` Replace the placeholder in curly braces with the actual path to your certificate file. :::note You must have [OpenSSL](https://www.openssl.org/) installed in order for the command to work. ::: ## Enable federated authentication in Mambu UI To enable federated authentication in Mambu UI, go to **Administration** > **Access** > **Federated Authentication** and select the **Enable Sign Sign-On** check box. For more information, see [Enabling Federated Authentication with Mambu](/docs/enable-federated-authentication-with-mambu). ![Setting up federated authentication in Mambu UI](@site/static/img/support/users-and-access-control--federated-authentication-configuration.png) You must: * Enter the **Name** you would like to use for your IdP. You may choose whatever name you like. * Enter the SHA-256 certificate fingerprint you created while setting up your enterprise application in Entra into the **Certificate Fingerprint** field. * Enter the **Single Sign-On Endpoint**, this will be the **Login URL** on the **Set Up Single Sign-On with SAML** page. * Enter the **Issuer ID**, this will be the **Azure AD Identifier** on the **Set Up Single Sign-On with SAML** page. ![url.png](@site/static/img/support/url.png) ## User assignment Once you have created an enterprise application in Entra, you must also assign users to the application. To assign the first user to your application: 1. On the Entra homepage, go to **Enterprise applications** > Choose your enterprise application > **Users and Groups** > **Add user/group**. 2. Under the **Users** list, select **None Selected**. In the **Users** dialog, select the user you would like to assign. ## Role assignment In order for your users to be able to log into to Mambu UI using Entra as the IdP you must have assigned a Mambu role to them. To carry out proper role assignment: 1. Create a role in Mambu and make sure to select **Mambu** under **Access Rights** to grant access to the Mambu UI to this role. For more information, see [Creating a role](/docs/roles#creating-a-role). 2. Create an app role in Entra. On the Entra homepage, go to **Azure Active Directory** > Choose your directory (for example, Default Directory) > **App Registrations** > Choose your enterprise application > **App Roles** > **Create app role.** In the **Create app role** dialog, enter all the required information. The **Value** field must be the exact name of the role you created in Mambu. ![Create app role dialog in Azure AD](@site/static/img/support/create-role.png) :::note You may also create an app role by editing the **Manifest**. To do so, go to **Azure Active Directory** > Choose your directory (for example, Default Directory) > **App Registrations** > Choose your enterprise application > **Manifest** > edit the JSON accordingly. ![Create app role with application manifest](@site/static/img/support/manifest.png) ::: 3. Assign the Entra app role to a user. To do so, navigate from the Entra homepage to **Enterprise applications** > Choose your enterprise application > **Assign Users and Groups** > Select the checkbox next to the user's name > **Edit Assignment**. ![Editing assignment of users and groups](@site/static/img/support/assign-role-1.png) In the **Edit assignment** dialog, select the app role you created and select **Assign** to assign it to the user. ![Edit assignment dialog in Azure AD](@site/static/img/support/assign-role-2.png) :::note For more information about enabling single logout, see [Enabling Single Logout](/docs/enable-single-logout). ::: ## Branch assignment For each of your users, you must also define the branch they are assigned to in Entra. For more information, see [Managing Users under Federated Authentication - Branch assignment](/docs/managing-sso-provisioned-users#branch-assignment). The following are the main steps to perform branch assignment using Entra as your IdP: 1. Create a custom attribute in the **Attributes & Claims** section of your IdP configuration called `BranchID`. 2. For branch definition, in Entra you can either define the same branch ID for all the users assigned to a specific application or define a different branch ID for each user. If you want to all the users for a specific application to be assigned the same branch ID, then you may set the value of the `BranchID` attribute to a specific branch ID. In the example, we have set the value to **EMEA**. ![Azure_AD_define_branchid_application_level.png](@site/static/img/support/Azure_AD_define_branchid_application_level%281%29.png) If you want to define different branch IDs for each user, then you may set the value of the `BranchID` attribute to **user.department**. Next, in the **Department** field for each user you may define the branch ID you want to assign the user to. ![Azure_AD_define_branchID_user_level.png](@site/static/img/support/Azure_AD_define_branchID_user_level.png) --- # Equal Installment Interest-Only Loans URL: https://docs.mambu.com/docs/equal-installment-interest-only-loans/ To learn more about the various configuration options when setting up this loan type, refer to [Configuring an Equal Installment Interest-Only Loan](/docs/configuring-an-equal-installment-interest-only-loan). ## Overview Interest-only equal instalment loans that have an equal payment amount that consists only of the interest. In other words, the interest amount will be equalized no matter how many days are in the month or in between the payments. No principal is allocated on the repayments schedule; instead, the principal is kept in the principal balance at the account details level. For example: an organization may want to offer a buy-to-let loan where their end customer pays only the interest, and they want to ensure predictability and offer them an equal monthly payment. No principal will be collected until the maturity of the loan. Interest-only equal installment loans are set up so your regular payments cover only the interest that's built up. No part of your payment goes toward reducing the original loan amount. The full principal amount remains outstanding, tracked as the loan's principal balance. Usually, clients are expected to pay back this entire principal balance in full at the end of the loan term, through a separate payment. However, you can also choose to reduce the principal balance throughout the loan's life by making extra principal payments. This will then lower the total amount due for your remaining installments. A key feature of this loan type is that your total installment amount stays the same, even if the length of each repayment period varies (for example, different numbers of days in each month). Each monthly payment amount remains consistent. We achieve this by calculating the monthly total due as if all installments have a uniform number of days (for example, 30 days per month). However, the actual interest that accrues will reflect the exact number of days in each period. This real interest accrual is shown in the accrued interest balance and at the payment schedule level. This can create a difference between the actual interest accrued and your fixed installment amount. This difference will cause fluctuations in the closing balances of each installment, affecting the internal interest balance. ## Payment calculation The consistent monthly total due (PMT) for these loans is calculated using the following standard financial formula: `PMT = -((interest rate/12), NPER, PV, -FV , Type)` Where: * **PMT**: The monthly payment. * **Interest rate**: The **required** loan interest rate. * **NPER**: The **required** total number of payments for the loan. * **PV**: The **present value** throughout the loan lifecycle. This refers to the current closing balance of the loan at that point in time. This balance inherently includes any accrued interest amount, which can fluctuate due to overpayments or underpayments relative to the actual interest accrued. * **FV**: The **future value**, representing the principal amount outstanding at the close of the loan. * **Type**: The optional type. A value of '0' (or omitted) indicates payments are due at the end of the period. ### Example: interest accrual Consider a loan with a Day Count Method = Actual/365, where the installment duration varies based on the actual number of days in the interval, while the Total due remains fixed. **Loan amount**: 150000 **Interest rate**: 10% per annum **Number of instalments**: 5 **Disbursement date**: 01/01/2023 **First repayment due date**: 01/02/2023 * **Calculated Total Due (PMT)**: £1,250 (This is the fixed monthly payment derived from the PMT formula, assuming a standard number of days per month for scheduling purposes). * PMT = - ( 10%/12 , 5 , 150000, −150000 , 0) * Since the loan account is at its inception, its Present Value (PV) is equal to its Future Value (FV). **Instalment 1** (01/01/2023 until 01/02/2023): * Period duration: 31 days * Interest accrued: 150,000 * 10%/365 * 31 days = £1273.97 * Total expected (fixed PMT): £1250 In this instance, the customer's payment of £1,250 is less than the actual interest accrued (£1,273.97). The difference of £23.97 (£1,273.97−£1,250.00) will remain unpaid in the internal interest balance, causing it to increase. **Instalment 2** (01/02/2023 until 01/03/2023): * Closing balance after installment 1 repayment: £150,000+£1,273.97−£1,250.00=£150,023.97 * Period duration: 28 days * Interest accrued: £150,023.97×(10%/365)×28 days=£1,150.87 * Total expected (fixed PMT): £1,250.00 * Here, the customer's payment of £1,250 is more than the actual interest accrued (£1,150.87). This surplus will reduce the outstanding amount in the interest balance. * Previous interest balance = £23.97 * Interest balance after interest application on instalment 2 = £23.97+£1,150.87=£1,174.84 * Interest balance after repayment of instalment 2 = £1,174.84−£1,250.00=−£75.16 This example illustrates that while the scheduled payment remains constant, the actual interest accrued varies with the number of days in each period. This leads to fluctuations in the internal interest balance (positive when accrued interest exceeds the payment, negative when the payment exceeds accrued interest), ensuring that the borrower ultimately pays the exact interest accrued over the loan's lifetime. ## Supported interest types for interest-only loans Interest-only loans support different interest calculation methods that impact how the Interest Accrued Expected figure, which represents the actual interest anticipated to accrue over the specific period of an installment, is determined for each instalment. Below are the interest calculations for the supported interest types: * **Simple interest**: For simple interest, the Interest Accrued Expected is calculated directly based on: * The Closing Balance Expected at the start of the period * The annual interest rate * The exact number of days in the interval. ` Interest Accrued Expected=Closing Balance Expected×(IR/Days in Year)×Number of days in interval` * **Compound interest**: With compound interest, the calculation accounts for the compounding effect over the period, using a daily interest rate. * `Interest Accrued Expected=Closing Balance Expected×((1+Daily IR)^Number of days in interval−1)` Where: `Daily IR=Annual IR/Days in Year` ## Pre-payments and over-payment allocation logic * **Pre-payment**: An amount paid in advance which is smaller than the installment Total Due. * **Over-payment**: An amount paid in advance which is bigger than the installment Total Due. It is crucial to understand how repayments are allocated. Here's a breakdown of the different ways payments can be applied and their impact: ### Custom repayments on the principal This method allows you to apply funds exclusively to the loan's outstanding principal balance via custom repayments. * When a payment is made this way, it acts as a prepayment or overpayment directly reducing your principal. * Crucially, any upcoming scheduled instalment remains unaffected and will still need to be settled with its next regular repayment. ![custom-repayments-in-principal.png](/img/support/custom-repayments-in-principal.png) ### Regular repayments on upcoming installments When you make a repayment that is intended to cover or exceed a future scheduled installment: * If the prepayment is for a future installment, it will first be used to fully settle the Total Expected amount of that upcoming installment. * Any remaining amount from the prepayment, after covering the instalment, will then be allocated to the principal balance. ### Handling partial payments and excess funds * If your prepayment amount is less than the Total Due of the upcoming instalment, it will partially settle that installment. * If you then make a subsequent repayment for that same upcoming instalment and there's an excess amount beyond what's needed to fully settle it, this excess will be treated as an overpayment and allocated to the principal balance. ![partial-payments-excess-funds.png](/img/support/partial-payments-excess-funds.png) ### Impact on loan schedule * When an overpayment directly reduces the principal balance, the system recalculates the loan schedule to reflect this change. This results in a new Payment (PMT) being computed for the remaining installments, using the Reduce Amount per Instalment prepayment recalculation method. Consequently, your future regular payments will be adjusted downwards. * PMT adjustments are **solely dependent** on a principal overpayment. If prepayments are allocated only to an upcoming pending instalment without directly reducing the principal balance, the PMTs of the remaining installments will not be adjusted. The expected closing balance on your schedule is updated to reflect the actual closing balance after the overpayment. * Consequently, the expected interest accrued for all subsequent instalments will be recalculated. ### Interest-only schedules ![Interest-only schedules](/img/support/interest-only-schedules.png) The schedules for interest-only loans have distinct characteristics when compared to those of capital repayment mortgages, primarily due to how principal is managed and interest is calculated. Here are the key features of an interest-only loan schedule: * **No principal amortisation**: As previously described, the schedule for interest-only loans does not include any amortisation of the principal balance. This means the principal amount remains constant throughout the loan term on the schedule, with repayment typically expected at maturity. * **Interest-only specific columns**: To provide greater transparency and accuracy, two columns specifically for interest-only loans are included in the schedule: * **Interest Accrued Expected**: Calculates the anticipated interest based on the actual number of days within each specific instalment interval. * **Closing Balance Expected**: Displays the projected loan balance (Principal Balance + Interest Balance) after the timely repayment of each instalment. * **Calculation of Closing Balance Expected**: The calculation for the Closing Balance Expected is as follows: * **For installment 1**: It is derived from the initial Principal Balance plus the expected interest accrued for that period, minus the Total Due for the first installment. * `Closing Balance Expected Installment 1=Principal Balance+Interest Accrued Expected Installment 1−Total Due Installment 1`. * **For installments 2 onwards**: Calculated by taking the Previous Expected Closing Balance from the prior instalment, adding the Interest Accrued Expected for the current installment, and then subtracting the Total Due for the current instalment. * `Closing Balance Expected Installment =Previous Expected Closing Balance+Interest Accrued Expected Installment N−Total Due Installment N`. * **Impact of principal overpayments**: The Closing Balance Expected is dynamically updated to reflect any principal overpayments made. This reduction in the expected balance has a direct impact on subsequent interest computations, leading to a decrease in the total interest paid over the life of the mortgage. ### Do not accrue late interest option When **Do not accrue late interest** is enabled at the product level, the closing balance expected will not be updated in the case of late repayments. The subsequent interest computations are done based on the closing balance expected throughout the entire loan lifecycle, with the only exception being scenarios where the principal balance is decreased by overpayments. The **do not accrue late interest** feature was specifically implemented to support the Interest from Arrears Decoupling logic. It was crucial to prevent the duplication of interest amounts that would occur if interest were calculated both on the schedule (based on outstanding balances) and separately as interest from arrears (based on overdue total dues). However, the **do not accrue late interest** option can also be used independently, though it's important to note that when used this way, interest from arrears won't be computed at all. ## Broken interest / initial payment adjustment For more information, refer to [Initial Payment Adjustment](/docs/initial-payment-adjustment). ## Payment holidays For more information, refer to [Payment Holiday](/docs/payment-holidays). --- # Excel Migration Template URL: https://docs.mambu.com/docs/excel-migration-template/ This article is a reference guide to the Excel spreadsheet template we provide in the Mambu UI for migrating data from legacy systems into Mambu. For more information on migration, see [Data Management Overview](/docs/data-migration-overview). The migration template is pre-filled with fields corresponding to the information you may import into Mambu. The spreadsheet includes ten sheets, accessible at the bottom of the screen. The following sheets are used to hold data for migration: Clients, Groups, Accounts, Schedules, Transactions, and Chart of Accounts. The following sheets are pre-filled with information that has already been entered in Mambu: Branches, Credit Officers, Loan Products, Deposit Products. These pre-filled sheets are provided as a reference to use when you are adding data for migration. Any data you add to them will not be imported. Any custom field definitions you have set up for clients and groups will be reflected in the relevant sheets. ## General requirements * Your import spreadsheet must be 5 megabytes or smaller. If you need to import more data than you can fit in a file of that size, you must split the data into multiple submissions and import them separately. * Your file must have an XLSX file extension to be imported. Be sure the file is not in the XLS file extension. * When copying data into the spreadsheet, copy only the data. Do not add or include formatting or formulas in any cell. * Date cells must always use the format dd.MM.yyyy. Any other format will fail validation. * Input fields have set character limits. Fields that contain Entity IDs have a 32-character limit. Most other text fields have a 255-character limit. ## Clients This sheet is used to submit client data. It includes cells for any custom field definitions that you have previously created in Mambu. ![data-and-reporting--clients-excel-migration-template.png](@site/static/img/support/data-and-reporting--clients-excel-migration-template.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**Client ID**|The alphanumeric code corresponding to that client's existing ID.| |Group ID|The alphanumeric code for the group the client is a member of.| |Branch ID|The alphanumeric code for the branch the client is assigned to.| |Centre ID|The alphanumeric code for the centre the client is assigned to.| |Credit Officer username|The username of the credit officer with whom the client will be associated.| |Date Joined (dd.MM.yyyy)|The day, month and year the client joined your organization.| |**First Name**|The client's given name.| |Middle Name| The client's middle name.| |**Last Name**|The client's surname.| |Date of Birth (dd.MM.yyyy)|The day, month and year the client was born.| |Gender (M/F)|The client's gender, `M` for male or `F` for female.| |Address 1, Address 2, City, Zip, State/Province/Region, Country|Address information used to locate the client.| |Mobile/Cellphone|The client's mobile phone number.| |Phone|The client's phone number.| |Notes|Any additional comment you want to add.| |Individual Loan Cycle|The number of individual loans the client has already completed.| |Group Loan Cycle|The number of group loans the client has already completed.| |ID Type| The type of identification document, for example, passport, ID card, or any other official document.| |ID Number|The unique number of the ID document.| |ID Authority|The authority that issued the document, such as police or government.| |ID Valid Until (dd.MM.yyyy)|The expiration date of the document.| |Custom Fields|The last columns contain any custom field definitions that you previously created in Mambu. If it is a selection field, you must enter one of the required custom field values you specified when setting up the custom field definition, see [Selection custom field definition](/docs/custom-fields#selection-custom-field-definition).| ## Groups ![data-and-reporting--groups-migration-template.png](@site/static/img/support/data-and-reporting--groups-migration-template.png) Group ID and Group Name are mandatory fields. | Field | Description | | --- | --- | |Group ID|Alphanumeric and unique code used to identify the group.| |Branch ID|Alphanumeric and unique code of the branch that group is assigned to. |Centre ID|Alphanumeric code of the centre the group is assigned to.| |Credit Officer Username|Username of the credit officer the group is assigned to.| |Group Name|Name which identifies that group.| |Date Joined (dd.MM.yyyy)|The day, month, and year the group joined your organization.| |Address 1, Address 2, City, Zip, State/Province/Region, Country|Address information used to locate the group.| |Notes|Any additional comment you want to add.| |Group Loan Cycle|The number of loans the group has already completed.| ## Loan accounts :::warning Solidarity or Hybrid Group loan accounts cannot be imported into Mambu - we only support importing Pure Group loan accounts. For more information, see [Loans for Groups](/docs/types-of-loan-groups). ::: ![data-and-reporting--loan-accounts-export-table.png](@site/static/img/support/data-and-reporting--loan-accounts-export-table.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**Account ID**|Alphanumeric code which you can customize and that is unique for each loan account.| |**Client ID**|Alphanumeric code of the client the account is for.| |**Client Type**| The client type, either `C` for individual client or `G` for group. If you leave this empty, it will be individual client by default.| **Product ID**|The alphanumeric code of the loan product the account is associated with. The product ID is defined when you create the products and you can see it in the Loan Product sheet.| |**Date Applied**|Date when the client applied for the loan.| |**Date Approved**|Date when your organization approved the loan account.| |**Date Disbursed**|Date when the loan account was disbursed.| |**Repayment Start Date**|The day of the first loan repayment.| | # Grace Installments |The number of grace installments for the loan account, if any.| |**Loan Length (# Installments)**|The number of repayments of the account. The repayment period is set when you configure your loan products.| |Repayment Frequency:|How often the installments will be, in the number per repayment period. If, for example, repayment occurs once per month, you would enter `1`. If every 2 weeks, you would enter `2` and so on. The repayment period is set when you configure your loan products.| |Repayment Period (D/W/M/Y):|The unit of time used for the repayment frequency. If repayments will be made every 10 days, for instance, then the Repayment Period would be D (D=days, W=weeks, M=months, Y=years).| |Principal Interval:|If the principal amount should be paid in every installment, you would enter 1. If, for instance, principal would only be paid every 6 installments, enter 6.| |**Interest Rate**|The fee in percentage that is charged by your institution to borrowers for the use of a loan amount. When entering this information, you should only include the number. For an interest rate of 12%, for instance, enter `12`.| |**Loan Amount**|The original amount of the loan.| |Interest and Principal Paid|How much interest and principal has been paid. If nothing has been paid yet, enter `0`.| |Account State|The loan state: Active, Closed, Withdrawn, Rejected, Written Off, Pending Approval and Approved.| ## Loan Schedules You may import schedules for fixed loan accounts, but you **cannot import dynamic loan schedules** - they are always recalculated based on Mambu logic. ![data-and-reporting--loan-schedules.png](@site/static/img/support/data-and-reporting--loan-schedules.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**Account ID**|Alphanumeric code which you can customize and that is unique for each loan account.| |**Due Date**|The installment due date. Must be in ascending order for the same loan.| **Principal Expected**|Amount of principal expected for the installment. If nothing is expected yet, enter `0`.| |**Interest Expected**|Amount of interest expected for the installment. If nothing is expected yet, enter `0` and the interest will be marked as *Grace*.| |Fees Expected|Amount of fees expected for the installment. If nothing is expected yet, enter `0` and the principal will be marked as *Grace*.| |Penalty Expected|Amount of penalties expected for the installment. If nothing is expected yet, enter `0`.| ### Loan schedule notes 1. Mambu will use the interest, fees, and penalties specified in the import sheet, even if the product has other interest/fees/penalties settings. 2. If an imported loan has a schedule specified in the import sheet, do not generate another schedule. Use the one specified by the user. 3. Mambu will update the account dues and balances according to the imported schedule and the repayments states and paid amounts after the loan is imported. * Payment due fees are not applied on imported schedules. * Late fees are not applied on the schedule for the installments that are late at the time of import. ## Loan Transactions If you wish to recreate previous loan schedules and full transaction histories, you may import past transactions. ![data-and-reporting--loan-transactions-excel-migration-template.png](@site/static/img/support/data-and-reporting--loan-transactions-excel-migration-template.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**Account ID**|Alphanumeric code which you can customize and that is unique for each loan account.| |**Transaction Type**|Options include `DISBURSEMENT`, `REPAYMENT`, `FEE`, or `PENALTY`.| |**Date**|Date of the transaction.| |**Amount**|Depending on the transaction type, how much principal was paid / disbursed / fee applied / penalty applied.| |Notes|Any free text notes to be attached to the transaction.| ### Loan transaction notes 1. If a disbursement transaction is provided, the disbursement date and loan amount on the account sheet are ignored. If there are transactions defined for an account, a disbursement transaction is mandatory. 2. If any transaction is provided, the Interest and Principal Paid amount from the loan account are ignored. 3. If the account is fixed: * Fees will be applied on the first unpaid installment. If the whole schedule is paid, an error message will be shown. * Penalties will be applied on the first unpaid installment. If the whole schedule is paid, an error will be shown. 4. Fees can be applied regardless of the product's arbitrary fees setup. 5. Penalties: The product setup (rate and calculation method) are not considered when imported amounts are applied. 6. If taxes are enabled for the product they should be included in the amounts (interest/penalty/fee). 7. All transactions require a date. A date validation must be performed: * Disbursement goes before fee, penalty applied or repayment transactions * Transactions should be ordered by their date, in ascending order (older first) - the transactions will be posted on the account on the order from the import table. * The transactions must be posted in a sequence for an account (all transactions for account 1, then all transactions for account 2 etc. * Creation date will be the approval of import event date. 8. The total number of imported transactions will be shown in the Import Events table. 9. No accounting is logged for imported transactions. ## Deposit Accounts :::warning The dates for last interest calculation, latest interest storage, and latest account appraisal will be set to the time of the migration. ::: ![data-and-reporting--excel-migration-template-deposit-accounts.png](@site/static/img/support/data-and-reporting--excel-migration-template-deposit-accounts.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**Account ID**|Alphanumeric code which you can customize and that is unique for each client.| |**Client ID**|Alphanumeric code of the client the deposit account is for.| |**Product ID**|The alphanumeric code of the deposit product the account is associated with. The product ID is defined when you create the products and you can see the ID in the Deposit Product sheet.| |**Date Applied**|When the account was created.| |**Date Approved**|When the account was approved and activated. If accounts are imported with current balances, these balances will be reflected as deposit transactions with entry date same as the "Date Approved." | |Overdraft Interest Rate|The interest rate charged on overdraft accounts. Can be zero.| |Overdraft Limit|The maximum amount a client can withdraw from the overdraft account.| |Overdraft Amount Due|How much is due at the date of the import.| |Overdraft Interest Due|The amount of interest due at the point of the import.| |Overdraft Fees Due|The amount of fees due at the moment of the import.| |**Current Balance**|Account balance at the moment of the import. This balance will be imported as a Deposit transaction with an Entry Date that is the same as the "Date Approved" in the import file.
    Please note: if you pay interest to deposit accounts and at the moment of the import there is an interest amount accrued and not applied yet, you should include this in the current balance. After the import, Mambu will start accruing interest (if applicable) on the balance that has been imported, based on the product settings.| |Notes|Any additional comment you want to add.| ## Chart of Accounts ![data-and-reporting--chart-of-accounts-migration-template.png](@site/static/img/support/data-and-reporting--chart-of-accounts-migration-template.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**GL Code**|The number used to identify the account in the General Ledger.| |**Account Name**|The name so that you can identify the account.| |Date|The date AS-OF the GL account's balance in the Balance Column. This is ideally the date of the client's data cut off, ensuring a clean accounting record in Mambu.| |**Type (A/L/I/E/Q)**|Select if the account is an Asset, Liability, Income, Expense or Equity.| |Usage (D/H)|The category of the account: **D** for *detail*, or **H** for *header*.| | Balance | Balance of existing GL accounts at the moment of the import.\nBalances must follow the correct sign according to the type of account, as follows:\n- Asset: Debit (+) / Credit (-)\n- Expense: Debit (+) / Credit (-)\n- Liability: Debit (-) / Credit (+)\n- Equity: Debit (-) / Credit (+)\n- Income: Debit (-) / Credit (+)| |Notes|Any additional comment you want to add.| :::warning If balances are added for the GL sheet, debit amount and credit amount must be equal. ::: ## Centres ![data-and-reporting--centres-migration-template.png](@site/static/img/support/data-and-reporting--centres-migration-template.png) Mandatory fields are in **bold text** below. | Field | Description | | --- | --- | |**Centre ID**|Alphanumeric code which you can customize and that is unique for each centre.| |**Branch ID**|Alphanumeric code of the branch the centre is associated with.| |**Name**|The centre's name.| |Meeting Day|The day of the week when the clients who are associated to this centre meet with the credit officer. Use the initials of the appropriate day as they are shown. For instance, M for Monday, T for Tuesday and so on.| |Address 1, address 2, city, zip, state/province/region, country|Contact information of the centre.| |Notes|Any comments you want to have associated with the centre.| ## Data (for reference only) The sheets in this section are populated with data that is already stored in Mambu. They are provided as a convenience to make it easier to fill out other sheets. For example, when you are filling out the Client or Groups sheets, you will need to know the IDs of the branches some of the values are associated with. You can easily find that information in the provided Branches Data sheet. Any changes you make to these sheets will be ignored during import. ### Branches Data This sheet includes data you have previously entered about your organization's branches. Branch IDs are automatically generated when you create a new branch in Mambu. ![data-and-reporting--branches-data-template.png](@site/static/img/support/data-and-reporting--branches-data-template.png) ### Credit Officers This sheet includes data you have previously entered about your organization's credit officers. Credit Officer IDs are automatically generated when you download the template so that you can use it as a reference. ![data-and-reporting--credit-officers-migration-template.png](@site/static/img/support/data-and-reporting--credit-officers-migration-template.png) ### Loan Products The information displayed in this sheet includes the data you entered in the system when creating your loan products. Loan product IDs are not automatically generated - they must be defined when creating your loan products. ![data-and-reporting--loan-products-migration-template.png](@site/static/img/support/data-and-reporting--loan-products-migration-template.png) ### Deposit Products The information displayed in this sheet includes the data you entered in the system when creating your deposit products. Savings product IDs are not generated automatically - they must be defined when creating your deposit products. ![data-and-reporting--savings-products-migration-template.png](@site/static/img/support/data-and-reporting--savings-products-migration-template.png) ## ID consistency and validation In order to pass validation, the information in the sheets must be consistent. The following validations will be performed. ### Clients sheet validation The Group ID for clients who are members of a group, the Branch ID, the Centre ID, and the Credit Officer ID must correspond to the Group, Branch, Centre, and Credit Officer IDs in the following sheets: Groups, Branches, Centres, Credit Officers. ### Groups sheet validation The Branch, Centre, and Credit Officer IDs you provide here must match the corresponding values in the Branches, Centres, and Credit Officers sheets. ### Loan Accounts sheet validation The Client ID and the Product ID must match the corresponding fields in the Clients and Loan Products sheets. ### Deposit Accounts sheet validation The Client ID and the Product ID must match the corresponding fields in the Clients and Deposit Products sheets. ### Centres Sheet validation The Branch ID must match the ID in the Branches sheet. :::note Clients and credit officers do not need to be assigned to the same branch that their group is assigned to. ::: ## Custom fields If you have added custom field definitions to clients, groups, users, or accounts in Mambu, you will find a column for each field in the migration template. For the custom field definition types **Free Text**, **Number**, or **Selection**, enter the data as it should be displayed in Mambu. For **Checkbox** custom field definitions, enter `True` if the box should be checked and `False` if it should not. --- # Fair use policy URL: https://docs.mambu.com/docs/fair-use-policy/ Mambu applies reasonable usage limits on shared environments to ensure fair access for all users and prevent any individual user from monopolising the environment’s resources to the detriment of other users. By defining clear boundaries, such as maximum API call thresholds, Mambu mitigates the risk of the shared environment’s performance being negatively impacted by one user’s activities. These transparent guidelines allow users to use the platform fully while preserving system integrity and reliability for the entire user community. ## Fair use Mambu enforces fair usage policies to ensure that you receive consistent, high-quality service. Accordingly, the following activities are prohibited, including any attempt to do any of the following: * Reverse engineering, disassembling, or decompiling the SaaS, or parts thereof or any underlying code, methodology or intellectual property, or applying any other process or procedure to derive the code of any software included in the SaaS. * Causing a material detrimental impact on system performance, availability, or the user experience of other users. A material detrimental impact may include but is not limited to: * Excessive API request volumes that consume disproportionate system resources. * API usage patterns that cause significant latency increases. * Usage that negatively affects system stability or availability. * Usage that impairs other users’ ability to access or use the Mambu Platform effectively. ## API throttling Mambu is committed to providing reliable, high-quality services to our users. To maintain optimal performance in shared environments, Mambu reserves the right to implement API throttling measures when necessary to prevent service degradation for other users of the shared environment and to ensure fair usage, system stability, and optimal performance for all users. To maintain system integrity and performance, the following standard rate limits will be enforced for each of the following APIs: Environments: Ireland2 ### Loans | API | Requests per second limit | | --- |---------------------------| | `POST /api/loans/transactions:search` | 350 | ### Clients | API | Requests per second limit | |----------------------|---------------------------| | `PATCH /api/clients` | 25 | In cases where a user’s activity impacts the platform’s stability or the experience of other users, and where specific API limits have not yet been defined in this document, Mambu reserves the right to implement temporary throttling measures until the impact is mitigated. ## Monitoring and compliance Mambu reserves the right to monitor API usage to ensure compliance with this policy. Users may be required to provide additional information or documentation upon request. ## Notifications * **Proactive notifications**: Where possible, Mambu will attempt to notify customers before throttling. * **Reactive notifications**: In situations requiring immediate action to protect system stability, Mambu may implement throttling measures before notification. In such cases, Mambu will notify customers as soon as reasonably possible. ## Contact information For questions or concerns regarding this policy, please contact Mambu's support team at [support@mambu.com](http://support@mambu.com). --- # Fee Capitalization URL: https://docs.mambu.com/docs/fee-capitalization/ Fee capitalization allows lenders to incorporate the fee directly into the loan's principal balance. When a fee is added to a loan, lenders have the option to capitalize it instead of collecting it with the next installment. Once applied, the fee immediately becomes part of the outstanding principal. As a result, future monthly installments are recalculated to account for this increased balance. The main purpose of this feature is to ensure the fee is included in interest calculations and amortized over the entire loan term. This offers customers a streamlined way to add fees at various points during the loan, avoiding the need for complex and inefficient refinancing processes for frequent fee additions. To enable fee capitalization on an account, the fee must first be set up and configured at the product level. Once a fee is available at the product level, the decision to capitalize it is then made at the moment the fee is applied to a specific loan. This is done by selecting the **Capitalise** checkbox on the fee application screen. You can also choose to backdate fee capitalization transactions, which will consequently adjust the interest amounts calculated for the period between the fee's application date and the current moment. ![backdate fee capitalization](/img/support/backdate-fee-capitalization.png) Fee capitalization will adhere to the threshold functionality configured at the product level. The fee capitalization threshold shares the same operational parameters as those used for interest rate changes and overpayments: * PMT adjustment threshold (number of days) * Threshold days method (calendar or working days). Details about the threshold logic can be found here: [Payment Modification Thresholds (PMT Thresholds)](/docs/payment-modification-thresholds). ## Supported product configurations Fee capitalization is available for specific product types and fee structures: * **Supported loan products**: This functionality is available for [Dynamic Mortgages](/docs/dynamic-mortgages) and [Equal Installment Interest Only Loans](/docs/equal-installment-interest-only-loans). * **Supported fees**: Currently, only manual fees can be capitalized. * **Interest calculation compatibility**: Fee capitalization works with loans that have both simple and compound interest calculation methods. ## How it works When a fee is capitalised, a new Fee Capitalization transaction type is created to log the amount applied. This capitalised amount is then incorporated into the loan's principal balance. The interest computation will immediately reflect this new, higher principal balance. If the fee is applied between due dates, the interest calculation will be split into divisions: * **Division 1**: Calculates interest based on the principal balance before fee capitalization. * **Division 2**: Calculates interest based on the new principal balance after fee capitalization. If a fee capitalization transaction is posted as backdated, it will recalculate both the interest accrued and any interest from arrears accrued for the affected period. Monthly payments (PMT) will be recalculated to account for the increased principal: * **For interest-only loans**: PMT=PMT(IR/12, number of installments, closing balance after fee capitalisation, principal balance,0) * **For capital repayment loans (DBEI)**: PMT=PMT(IR/12, number of installments, closing balance after fee capitalisation) The total principal shown on the loan schedule will reflect the full principal balance amount, which includes the capitalized fee. --- # Fees Accounting URL: https://docs.mambu.com/docs/fees-accounting/ ## Linking Fees to GL Accounts ### For loan products When adding fees to a loan product that has accounting enabled, you have two options: 1. **Use product default accounts**: as defined in the "Accounting Rules" section; in this case, all fees are posted through the same accounts. 2. **Use specific accounts**: as defined for each fee; this is a better approach for more granular accounting for fees, as well as more detailed financial reporting on different income sources. If Cash Basis Accounting is used, then only a "Fee Income" account must be specified. Deposit Accounts only support Cash Basis Accounting. If Accrual Accounting is used, then fees will typically have three control accounts: * **Fee Receivable**: must be an Asset account; its balance will reflect the amount of fees charged (due) but not yet paid. * **Fee Income**: must be either an Income or a Liability account; its balance will reflect the amount of fees earned; a Liability account can be used as control for those fees that are collected for third parties (typically: insurance fees). * **Fee Loses**: must be an Income account that is definable per fee. The Fee Write Off GL account (expense account) will overwrite the Write off GL accounts defined in the Accounting section of the Loan Product if any GL is selected. For Disbursement Fees, only the "Fee Income" account can be specified, as this fee is "paid" immediately at disbursement, either by deduction from the loan amount or capitalization onto the loan, and there is no use for a Fee Receivable GL Account. ![Product Creation, Product Fees section with Name, Type, Fee Payment, Amount, Amortization Profile and Fee Income and Fee Receivable GL accounts.](@site/static/img/support/accounting--product-fees-configuration.png) Also, when accrual methodology is chosen, it is possible to amortize fees over time. For more information, see [Fee Amortization](/docs/loan-fees-setup#fee-amortization). ### For deposit products Mambu allows linking Product Fees to different GL accounts for deposits. When an Accounting methodology is selected for Deposit Products, the "Fee Income" accounting rule for each predefined fee will be available. You can select from the dropdown menu the GL account of your choice for each fee. When a different GL account is chosen besides the Default, the fees will be posted to the assigned GL account, as is currently done for loan accounts. ## Fees related transactions and their corresponding accounting entries ### Accruals Accounting Under **Accrual Accounting**, there are two types of transactions associated with fees: * **Fee Applied**: triggered by different events, manual or automated; in accounting, the Fee Applied Transactions generates an automated Journal Entry as follows: * DEBIT - Fee Receivable (Asset) * CREDIT - Fee Income (Income/ Liability) * **Repayment**: fees are always paid as part of a Repayment transaction; if a fee has been charged on the account, part of the next payment will be allocated to cover the outstanding fee due * DEBIT - Fund Source (or specific Transaction Channel GL) * CREDIT - Fee Receivable (Asset) ### Cash Accounting Under **Cash Accounting**, only one journal entry is posted: * **Fee Applied**: triggered by different events, manual or automated; in accounting, the Fee Applied Transactions generates an automated Journal Entry as follows: * DEBIT - Deposit * CREDIT - Fee Income (Income/ Liability) --- # Funding Sources - P2P Lending URL: https://docs.mambu.com/docs/funding-sources-p2p-lending/ ## Loan fractionalization *Loan fractionalization* in Mambu is a generic term describing the functionality whereby the loan account of one client (borrower) is financed directly from one or many accounts of other clients (investors or funders). This is also called *peer-to-peer (P2P)* lending or crowdfunding. If loan fractionalization is enabled, it will facilitate the capture of multiple funding accounts for a single loan account. It will then keep track of each individual funding account that contributes to a loan being disbursed and, as loan repayments are made by the borrower, return the funds to investors together with a fraction of the interest paid by the borrower. ## How does it work? To fully use fractionalised loan functionality, the following setup and actions need to be completed: 1. Create a deposit product of type “Funding Account”. 2. Create a loan product with Funding Sources enabled. 3. Create Funding deposit accounts for each investor. 4. Create a loan account with Funding Sources enabled for the borrower. 5. Disburse the loan account. 6. Post repayments on the loan account. ## General workflow The image below gives you a more detailed overview of the whole cycle from the moment the funds are added to the account until the account is closed. ## Funding account In order to use loan fractionalization, a new deposit product of type **Funding Account** has to be created: ![Creating a New Deposit Product view with Product Type Funding Account.](@site/static/img/support/loans--creating-a-new-deposit-product.png) Funding Accounts are very basic deposit accounts with limited functionality, and intended only for funding fractionalized loans and receiving their repayments. For that reason, the balance cannot go below 0 (overdrafts are not allowed), they do not have maturity periods, and it is not possible to accrue interest on the account. For more information about creating a deposit product, see [here](/docs/setting-up-new-deposit-products). ### Accounting links Deposit products with funding sources enabled can have the accounting methodology set to either “None” (disabled) or “Cash”. There are a limited number of Cash accounting links available for Funding Accounts, namely Transaction Source (asset), Savings Control (liability) and Fee Income (any GL account). Mambu will log journal entries on a Funding Account for the following transactions: 1. Deposit / Loan Repaid DEBIT Transaction Source CREDIT Savings Control 2. Withdrawal / Loan Funded DEBIT Savings Control CREDIT Transaction Source 3. Fee applied (relating to the Funding Account fees only, not to fees applied on loans it funds): DEBIT Savings Control CREDIT Fee Income On disbursement of the Loan Account funded from the investor’s account, a “Loan Funded” transaction is posted that creates the same journal entries as a withdrawal. Each repayment posted on the Loan Account, consisting of both Principal and the Funder Interest Commission, will create the same journal entries as a deposit. ## Fractionalized loan product In order to create fractionalized loans, the loan product must have Funding Sources enabled. This is currently possible for Fixed Term Loans and Dynamic Term Loans. Kindly note, that this functionality is not available for Fixed Term Loan with Payment Plan as Payments Method. ![Funding Sources section from Loan Product cration view with Enable Funding Sources checkbox, Organization Interest Commission text areas, Funder Interest Commission Allocation drop-down and Lock funds on Funding Account at Approval checkbox.](@site/static/img/support/loans--funding-sources-configuration.png) Organization Interest Commision is a part of the overall interest collected by the organization, and the remaining interest is spread across the loan’s investors. This section is where constraints can be set for the Organization Interest Commission rate, which are the organization’s default, minimum, and maximum spread of the total interest rate. The numbers entered here are used to constrain the rate when configured per individual loan account. Funder Interest Commission is the percentage that each investor receives, and represents the investor’s income based on their interest rate and the total invested amount in the loan account. Calculations of the Funder Interest Commission can use one of two different allocations methods: **Percentage of loan funding:** If the total interest rate on the account is defined, and investor’s interest should be calculated based on their contribution. **Fixed Interest Commissions:** If the investor’s and organization’s interest rates are defined, and should be used with the investor’s contribution to calculate the total interest rate of the account. **Percentage of loan funding** With this method, the Funder Interest Commision is calculated based on the Interest Rate defined on the loan account (less the Organization Interest Commission) and each investor’s share in funding the loan. For example, for a loan with these details: * USD5,000 total amount * USD3,000 funded by Investor A * USD2,000 by Investor B * 10% interest rate per year * 3% Organization Interest Commission The client will be charged using the interest rate of 10% per year. Of the total interest, the organization will receive 3%, and the investors will split the remaining 7% (10-3%) based on their contribution in funding the loan. Therefore Investor A, who provided 60% of the loan (USD3,000), will receive 60%*7% interest, and Investor B, who provided 40% of the loan (USD2,000), will receive 40%*7%. **Fixed Interest Commissions** This option defines the Funder Interest Commision (income from investing in the loan) per investor within product-level constraints with default, minimum, and maximum values. Different interest rates can then be set per investor at the loan account level. The interest rate for the account will be automatically calculated by the system once the loan is 100% funded, and will take into account the Organization Interest Commission, as well as the Funder Interest Commision of each individual investor: Account interest rate = Organization Interest Rate + (Investor A rate * Investor A contribution percentage) + (Investor B rate * Investor B contribution percentage)... For example, when opening a loan account with these details: * USD5,000 total loan amount * 7% Organization Interest Commission * 4% Funder Interest Commission for Investor A, who invested 3,000 * 3% Funder Interest Commission for Investor B, who invested 2,000 The interest rate of the loan account will be: 7% + (4%*3000/5000) + (3%*2000/5000) = 10.6% :::note The interest rate will show as unknown (“-”) f the loan is not yet 100% funded. ::: *Lock funds on Funding account at Approval* enables the funds being contributed by the investor to be locked on the Funding Account as soon as the loan account is approved, ensuring that they do not over-commit to multiple loans before disbursement, or withdraw from the account before the loan is funded. If this option isn’t selected, the funds are free to be pledged to other loans until disbursement of the funded account. For more information about the Loan Product creation, please go [here](/docs/setting-up-new-loan-products). ### Accounting links Loan products with Funding Sources enabled can have the accounting methodology either set to “None” (disabled) or “Accrual”. In fractionalized loans, there is no principal control account as the principal is directly disbursed from, and repaid to, investor accounts. Therefore, no journal entries will be posted on the loan account for the disbursement of the loan or repayment of principal, but will be posted directly on the funding account. Journal entries will be created for the following transactions only: 1. Interest applied (the amount of the Organization Interest Commission): DEBIT Interest receivable CREDIT Interest income 2. Fee applied: DEBIT Fee receivable CREDIT Fee income 3. Penalty applied: DEBIT Penalty receivable CREDIT Penalty income 4. Repayment entered: DEBIT Transaction Source CREDIT Interest/Fee/Penalty receivable More information on repayments can be found under “Repaying a fractionalized loan account”, below. 5. Interest reduced/written-off (Organization Interest Commission only): DEBIT Write-off expense CREDIT Interest receivable For more information, please see our article on [product rules under accrual accounting](/docs/linking-products-to-accounting#loan-product-rules-under-accruals-accounting). ## Funding accounts for investors Once a Funding Account is used to fund a loan, an additional “Funding” tab will be enabled. This will provide an overview of all loans funded by the account with the breakdown for each, indicating the original invested amounts, the remaining funds to be collected and interest earned on that account. This view also provides quick access to the associated loan accounts. ![Funding view with Remaining Amount.](@site/static/img/support/loans--deposit-account-funding.png) For more information please see our article about [creating deposit accounts](/docs/creating-a-deposit-account). ## Fractionalized loan account When creating or editing a loan account, the investors and their respective contributions can be added to the “Funding Sources” section. Any number of funding sources (investors and their accounts) can be added, with the only constraint that the total investment amount cannot exceed the loan amount. ![Funding Sources section at Loan Account Creation with Source, Account and Amount fields.](@site/static/img/support/loans--funding-sources.png) It is possible to add a Funding Source to a loan account, even if the investor’s account balance is less than their pledged investment amount. This allows them to deposit the required amount at a later date. Please note, however, that a loan cannot be disbursed until it is 100% funded. Once the account is created, an additional “Funding” tab will be enabled, providing an overview of all investors and their funding accounts, along with the total amounts that were used to fund the loan. From here it’s also possible to access details of each investor and their respective accounts. ![Funding view from Loan Account with Funds Amount and Funding percentage.](@site/static/img/support/loans--loan-account-funding-view.png) For more information, see [Creating a new loan](/docs/creating-a-new-loan). ## Disbursing fractionalized loan accounts At disbursement, a regular “Disbursement” transaction will be posted on the loan account and a “Loan funded” transaction will be posted in the corresponding funding accounts. Please note that a loan can only be disbursed once it has been completely funded and the corresponding funding accounts have had the required amounts deposited in them. For more information, see [Disbursing a loan](/docs/disbursing-a-loan). ## Repaying fractionalized loan accounts A “Repayment Entered” transaction is posted when a payment is made on the loan account. From the repayment amount, the returned principal is transferred to the investors’ funding accounts together with their part of the interest, as determined by the percentage of their investment and the Funder Interest Commission. This transaction will be reflected on the investments accounts as a “Loan Repaid” transaction. Let's take as an example a loan with the following details: * USD1000 principal * Funded by 2 investors with the Percentage of loan funding Funder Interest Commission Allocation method * Investor A funded USD300 (30%) * Investor B funded USD700 (70%) * 10% interest rate per year * 3% Organization Interest Commission Once the client pays the first instalment of USD108.33 (USD100 principal and USD8.33 interest): * The organization receives 3% interest spread from the collected interest, USD2.50 (=USD8.33 * 3% * 10%) * Investor A funded 30% of the loan and will collect USD30 principal (30% * USD100 collected) and USD1.74 interest (30% * (USD8.33 - USD2.50, collected by the organization) * Investor B funded 70% of the loan and will collect USD70 principal (30% * USD100 collected) and USD4.08 interest (70% * (USD8.33 - USD2.50, collected by the organization) Please note that any fees and penalties paid by the client will be recognised as the organization’s income. ![Deposit Account Transaction with General, Channel, Notes and Repayment sections.](@site/static/img/support/loans--deposit-account-transaction-details.png) To give another example, again using 2 investors but this time using the Fixed Interest Commissions allocation method: * USD1000 principal * 4% Organization Interest Commission * Investor A funding USD300 with 5% Funder Interest Commission * Investor B funding USD700 with 6% Funder Interest Commission * 9.7% interest rate per year (automatically calculated) When the client pays the first installment of USD171.41 (USD163.33 principal and USD8.08 interest): * The organization receives 4% interest spread from the collected interest, USD3.33 (=USD8.08*4%/9.7%) * Investor A, who funded 30% of the loan, will receive USD50.23, of which USD48.99 is principal (=30%*163.33) and USD1.24 is interest (=USD8.08*30%*5%/9.7%) * Investor B, who funded 70% of the loan, will receive USD117.82, of which USD114.33 is principal (=70%*163.33) and USD3.49 is interest (=USD8.08*70%*6%/9.7%) If there are amounts of principal and interest that can’t be returned to the investors due to allocation rounding, these amounts will be returned to the investors when the last payment is made by the borrower (when the principal balance is USD0). This guarantees that full amount of principal contributed by each investor will be returned to the funding the account, along with the correct percentage of interest. After the last payment allocation, the remaining interest (likely to be a very small amount) that cannot be equally spread across investors will be booked as organization income. If a “Repayment Entered” transaction is reversed, a “Loan Repaid Adjustment” transaction will then be created on the investor’s Funding Account. ## Rescheduling fractionalized loans Fractionalized loans can be rescheduled by selecting **Close** > **Reschedule** on the right-hand side of the loan account's overview page. As 100% of the funded amount is required, the outstanding interest, fee and penalty balances cannot be capitalized and will be written-off entirely. For the same reason, the principal balance cannot be partially or wholly written-off. The funding sources and their respective contributions cannot be changed, either. It is possible, however, to reschedule using a different loan product, provided that it also allows investor funding. Adjustments may also then be made to certain account terms such as the Organization Interest Commission and number of installments (with respect to the new product’s constraints), and the first repayment date can be set. :::note When rescheduling there may be a difference between the loan amount for the new account being created and the total remaining funds to collect. All the differences will be kept and transferred to the newly created account. Then, when the final repayment is made, a regularisation between the principal amount of the loan and the remaining funds to be collected will be carried out, which will settle the loan and cover all of invested funds. ::: --- # Glossary URL: https://docs.mambu.com/docs/glossary/
    Term Definitions

    Accepted Settlement Completed (ACSC)

    		 The status of a payment order when it is completed and the SEPA message has been sent to the callout URL.

    Accepted Settlement In Process (ACSP)

    		 The status of a payment order when it has been executed and the corresponding transaction has been posted in Mambu core.

    Accepted Technical Validation (ACTC)

    		 The status of a payment order when it has been accepted at the requested execution time.

    account

    		 A record of all the financial transactions of each of an organization's clients or an organization's assets, liabilities, equity, expenses, and income. In a loan account, Mambu stores all the information related to disbursements, repayments, interest rates, and withdrawals. In a deposit account, Mambu keeps track of all deposits, withdrawals, and the interest rates associated with it.

    account origination

    		 An upstream component type. Connectors that are part of this component type assist with onboarding new customers, providing access to tools like ID verification, and know your customer and anti-money laundering compliance.

    account servicing institution

    		 The financial institution that services the account owned by the account holder. In the context of payment orders, both the originator bank and the beneficiary bank are account servicing institutions.

    accrued

    		 The amount of interest or penalty that has not been paid by the borrower or received by the lender.

    active (account state)

    		 The status of an account that allows transactions like withdrawals, disbursements, or deposits. A loan account is considered to be active after being disbursed and a deposit account will become active after being approved. Both will remain active until they are closed.

    approved (account state)

    		 The status of an account after the approval of the account creation request.

    active (client state)

    		 The status of a client with open accounts in Mambu or a client with no open accounts at the moment but who remains eligible for financial services in an organization.

    administrator (admin)

    		 A user type in the Mambu UI and API with the most permissions associated with it, by default, users assigned with it can do any operation in Mambu.

    anti-money laundering (AML)

    		 A general term for policies, laws, and regulations to prevent financial crimes. Global and local regulators around the world create anti-money laundering (AML) policies and requirements. See also know your customer.

    API call node

    		 A type of node in a Mambu Process Orchestrator process that performs an external API call with parameters.

    API Reference

    		 The api.mambu.com site, containing all the information required to work with Mambu's APIs.

    arrears

    		 The status of an active loan account with one or more overdue payments. The Mambu platform lets customers define a specific arrears tolerance period or amount.

    assets

    		 Items owned by an organization and which have a monetary value associated to them for example, loans, equipment, or cash.

    automated clearing house (ACH)

    		 An alternate term for a clearing and settlement mechanism (CSM).

    backdate

    		 To log a transaction that happened on a date earlier than the date on which it took place instead of the current date.

    balance

    		 The amount of money left in an account after a transaction like a deposit, withdrawal, or repayment. It includes principal, interest, and any available overdraft limit.

    balance sheet

    		 A financial report that gives a Mambu customer information about their organization's assets, liabilities, and equity at a given point in time. It shows how the organization is performing as well as its value.

    bank

    		 A general term for a financial institution. Without additional context, "bank" might refer specifically to a traditional bank, or more broadly to nontraditionals and other types of financial institution.

    beneficiary

    		 The party that receives the funds moved in a payment order that is initiated by the originator.

    beneficiary bank

    		 The payment service provider (PSP) that processes the payment order received from the originator’s PSP.

    branch

    		 The default label for an organization's subdivision operating locally or having a particular function. Often branches represent a geographical subdivision of an organization or a product line. Each branch can have multiple centres assigned to it.

    business banking accounts

    		 Transactional accounts with typical banking capabilities, such as debit or credit cards, for business use.

    business deposits

    		 Savings accounts, term deposits, and similar products for SMEs or corporations. Examples include savings account, fixed deposit, and savings plan.

    business lending

    		 Loans made to businesses rather than individuals. See SME lending and commercial lending.

    call process node

    		 A type of node in a Mambu Process Orchestrator process that calls another process.

    centre

    		 The default label for a subdivision of a branch. It can be considered a sub-branch. Each branch can have multiple centres assigned to it.

    chart of accounts

    		 All of the general ledger accounts ordered by their type - assets, liabilities, equities, expenses, or income - and with standard codes associated to each.

    clearing and settlement mechanism (CSM)

    		 The institution(s) that route funds between accounts as part of a payment order. The clearing and settlement steps might be performed by the involved payment service providers as part of an existing arrangement, or by one or more third parties.

    client

    		 A single person or entity that is receiving services from a Mambu customer and has a client profile in Mambu. In other words, client refers to the customers of Mambu's customers.

    client ID

    		 A unique identifier that Mambu automatically assigns to clients when their profile is created.

    closed

    		 State of an account that doesn't allow transactions anymore. Mambu keeps a closed account associated to the client who owned it.

    code node

    		 A type of node in a Mambu Process Orchestrator process that executes a block of code.

    collateral

    		 An asset offered as part of a secured loan to be forfeited in case of default.

    collection order

    		 An order to transfer money between two bank accounts, initiated by the creditor, based on a pre-existent mandate given by the debtor. Also known as a direct debit transfer.

    commercial lending

    		 Complex loans for larger corporations often involving high-value principal with multiple credit lines. These loans are used to fund major capital expenditures, operational costs, and/or the purchase of equipment. Commercial loans often require collateral such as property or equipment.

    commercial mortgages

    		 Collateral-backed loans for commercial real estate.

    composable architecture

    		 A modular software design methodology consisting of small, self-contained, and easily interchangeable building blocks. An orchestration layer such as Mambu Process Orchestrator directs all interactions between components, providing flexibility and integration with other services.

    composable banking

    		 Mambu's value proposition using composable architecture to improve the delivery of financial solutions. See also fintech.

    condition node

    		 A type of node in a Mambu Process Orchestrator process that determines the routing of an object based on a condition. Possible conditions are: equal (=), not equal (!=), less than (<), greater than (>), and regex.

    Configuration as Code (CasC)

    		 A set of API endpoints that allows customers to batch configure Mambu entities using YAML. Using CasC, customers can quickly configure new Mambu tenants and standardize, version-control, and transfer configurations between tenants.

    connector

    		 Mambu functionality that allows customers to connect the Mambu cloud banking platform with vetted third-party services via the Mambu Process Orchestrator. Connectors can be built and maintained by Mambu or Mambu partners, and are used to process payments; onboard new customers; manage data and accounting; and more. Connectors might be described as “Integration as a Product.”

    consumer loans

    		 See purchase financing.

    copy task node

    		 A type of node in a Mambu Process Orchestrator process that copies a task in a different process.

    counterparty

    		 The opposite party in a payment order. For example, the beneficiary bank is the counterparty to the originator bank, and vice versa.

    credit (accounting)

    		 The value entered in accounts which shows a decrease in the assets or expenses or increases in the liabilities, revenue, and capital.

    credit arrangement

    		 The maximum amount a client (individual client or group) can take out in loans and overdrafts.

    credit cards

    		 See purchase financing.

    credit officer

    		 A user type in the Mambu UI and API whose responsibilities are directly related to the management of loan accounts from the application stage till the loan account is closed or withdrawn. Mambu allows users to assign clients to credit officers and keep track of their individual performance.

    credit union

    		 A cooperative financial institution that is owned and operated by its own members. Credit unions are mostly non-profit and typically provide traditional banking services within a specific community.

    creditor

    		 The party to which funds are deposited through a credit transaction.

    cryptocurrency

    		 A digital currency that can be used to buy goods and services, and which uses an online ledger with strong cryptography (typically a blockchain) to record and secure transactions.

    currency

    		 The form of money used by an organization.

    current account

    		 An account at a financial institution that supports deposits, withdrawals, and overdrafts. Debit cards can be connected to current accounts. See also daily banking accounts.

    custom field

    		 A type of additional field that can be created in Mambu UI (that is also accessible via the Mambu API) in order to capture any additional information required for an organization's business processes. Access to custom fields can be restricted to certain roles. Every custom field must be part of a custom field set. Compare with native field.

    custom field set

    		 A way to group custom fields.

    custom view

    		 A tool to generate reports on the fly and easily retrieve filtered lists of information in the Mambu UI. We refer to custom views as either view or custom view, these terms are interchangeable.

    customer

    		 An organization that consumes services from Mambu. Customers are associated with one or more instances.

    Customer Service Portal

    		The self-service website that allows Mambu customers to manage their support cases, view case reports and dashboards, update contact information, view invoices, perform sandbox operations, and access documentation.

    daily banking accounts

    		 Transactional accounts with typical banking capabilities, such as debit or credit cards, for personal use.

    debit (accounting)

    		 The value entered in accounts increasing the assets or expenses or decreasing the liabilities, revenue, or capital.

    debtor

    		 The party from which funds are withdrawn through a debit transaction.

    dedicated instance

    		 A Mambu instance that is dedicated to one Mambu customer and is performance-isolated from other customer instances, with all data and services logically and physically isolated. Compare with shared instance.

    delay node

    		 A type of node in a Mambu Process Orchestrator process that delays a task for a defined period of time.

    deposit

    		 The amount of money transferred to a client's deposit account. Mambu keeps track of the method used for the transfer such as cash, check, or bank transfer and stores this information in the history of transactions of that specific account.

    deposit account

    		 An account with an amount deposited by a client to earn interest according to the terms defined in the deposit product.

    deposit product

    		 A customizable Mambu template used to create individual deposit account instances. Each deposit product represents a collection of settings that differentiates the behavior of deposit accounts.

    detail account

    		 A category of accounts in the general ledger containing the transaction's balances.

    digital wallet

    		 A type of stored value account that allows for issuing and managing prepaid instruments.

    disbursement

    		 The act of releasing the loan amount to the borrower. Mambu identifies the loan account as active and can automatically calculate the loan repayment schedule once disbursed.

    domestic payment

    		 A payment where the beneficiary is within the same payment network operations region as the originator, using the same currency—for example, a SEPA payment.

    dormant

    		 The state of a deposit account. In this state no more interest is accrued on the account and no automated transactions can be posted to it.

    downstream data

    		 A component type for connectors that helps extract and load data into a customer's existing tools (general ledgers, data analytics platforms, etc).

    Early Access

    		 The stage in the Mambu release cycle, where a feature or capability is available to a limited number of Mambu customers upon their request.

    ecosystem

    		 See Mambu ecosystem.

    end client

    		 See client or user.

    end node

    		 A node used to end a Mambu Process Orchestrator process. There are two types: end: error node and end: success node.

    end user

    		 See client or user.

    end: error node

    		 A type of end node in a Mambu Process Orchestrator process that labels tasks with process errors.

    end: success node

    		 A type of end node in a Mambu Process Orchestrator process that labels successfully processed tasks.

    engine

    		 A core component of a complex software system, such as the Mambu cloud banking platform itself.

    entity

    		 A general term for a basic feature, construct, or object in Mambu. Examples include clients, groups, loan products, accounts, currencies, and branches.

    equity

    		 The organization's value which is property of the shareholders. It corresponds to the value of assets minus the liabilities.

    execution

    		 See payment execution.

    expense

    		 The value of assets that is used to sell an organization's services.

    federated authentication

    		 A form of authentication that allows users to log in to Mambu using single sign-on (SSO). User identities in this scheme are managed by an identity provider (IdP).

    fee

    		 A fixed price charged to a loan account.

    fiat currency

    		 An internationally-accepted currency that is usually issued by a government or central bank. It is included in the ISO 4217 currency list.

    field

    		 A stored value associated with a Mambu entity. For example, a client entity includes fields like ID, Client Type, and Creation Date. Fields can be native fields, which Mambu provides by default, or custom fields, which the user creates. “Field” might also refer to the container in the Mambu UI where a user edits a field.

    financial inclusion

    		 A broad term to describe the goal of making financial products and services available to all potential clients, regardless of location or income level. Microfinance institutions are a common solutions provider for financial inclusion.

    fintech

    		 Short for financial technology. A broad term for the industry of technology platforms that compete with traditional platforms to deliver financial products and services.

    fintech (organization type)

    		 A bank that offers one or more banking products and services without a physical branch network. The term might broadly include neobanks or specifically refer to smaller institutions that focus on selected product lines like remittance or deposits. See also traditional bank and nontraditional.

    fixed deposits

    		 As the name suggests, fixed deposits have a fixed term after which they should be withdrawn or closed. With this type of product, clients are able to make deposits until the minimum opening balance has been reached. At this point, you can begin the maturity period, during which they will be unable to deposit, but will be able to withdraw.

    foundation platform

    		 The conceptual component of the Mambu core (alongside the technical platform and product factory) that facilitates services such as output management, notifications, and operational reporting.

    function

    		 A collection of nodes that Mambu Process Orchestrator can use repeatedly in different processes.

    General Availability

    		 The stage in the Mambu release cycle where a feature or capability is available to all Mambu customers (provided there is compatibility with the cloud service provider).

    get from queue node

    		 A type of node in a Mambu Process Orchestrator process that receives tasks from the queue.

    GL code

    		 The number used to identify an account in the general ledger.

    grace period

    		 The period of time defined by the number of installments in which the loan repayments don't include interest. The grace period is defined when you're creating loan products.

    group

    		 A type of client composed of at least two members who also need to have an individual profile in Mambu.

    header accounts

    		 A category of account that is only used to group detail accounts of the same type.

    identity provider (IdP)

    		 A service for storing and managing user identities that allows you to connect to Mambu using single sign-on (SSO) when federated authentication is enabled.

    income

    		 The amount received by an organization for the services provided, sales, or profit from investments.

    Increase Last Installment (ILI)

    		 A Mambu setting for loan products used to determine what to do with interest in arrears. If Increase Last Installment is selected, Mambu will not adjust the overdue installments, which results in an underpayment of principal. The principal is then recouped in the final installment.

    incumbent

    		 See traditional bank.

    infrastructure

    		 The logical arrangement of Mambu's software environment that includes the Mambu core engine and offers networking, database, and other software services. The infrastructure hosts multiple instances that each include multiple tenants.

    installment

    		 A single scheduled payment for a loan. See also repayment.

    instance

    		 A logically distinct copy of Mambu's cloud banking platform hosting multiple tenants. Instances are associated with a single Mambu customer, and can be dedicated or shared with other customers.

    interest

    		 Money paid regularly at a defined rate to a lender or a savings account holder. The interest rate is typically expressed as an annual percentage of the principal, but can also be determined by an external standard.

    interest calculation method

    		 The formula used to calculate the interest on a loan or savings account.

    internal transfer

    		 See intrabank payment.

    international payment

    		 A payment where the beneficiary is from a different payment network operations region from the originator —for example, a SWIFT payment.

    intrabank payment

    		 A payment where both originator and beneficiary accounts are serviced by the same payment service provider.

    journal entries

    		 The records of all the transactions in an organization which have accounting implications. They can be automatic or manually entered.

    know your customer (KYC)

    		 The process of verifying information about clients before or during transactions with a financial institution to confirm their identity, suitability, and risk. KYC rules vary by country and region and are a part of anti-money laundering (AML).

    label

    		 The terminology used to refer to various entities and concepts within Mambu. Default labels may be edited and labels can be customized for each language available in Mambu.

    lease

    		 A form of financing in which an institution lends a physical asset or service to an individual or business client for defined payments and duration, sometimes with a provision to purchase the asset at the end of the contract. Leases can be issued by single-purpose leasing companies or by larger banks.

    leasing company

    		 A company that offers leases on physical assets or services. Unlike traditional banks or other financial institutions, leasing companies are single-purpose companies.

    lender

    		 The financial institution that offers loans to borrowers. Lenders might be single-purpose institutions or larger institutions that offer additional financial products, for example, traditional banks.

    lending

    		 The temporary giving of money or assets to a borrower (a loan) with an agreement that it will be repaid according to certain terms and conditions. Mambu offers a variety of lending products.

    liabilities

    		 What an organization owes to others both currently and in the future. For example, clients deposits are considered to be a liability as the amount will be returned to the clients.

    loan

    		 The amount that an institution lends to a client; or the loan account that corresponds to the loan and specifies the loan terms and conditions.

    loan account

    		 In Mambu, an individual account used to track the corresponding loan and client. Terms and conditions that you define when creating a loan product—interest rates, the repayment schedule, applicable fees, and so on—apply to all of the loan accounts created using that product.

    loan origination (connector type)

    		 A Mambu connector component type that provides tools for managing applications, credit decisioning, and responding when loans go into arrears.

    loan product (Mambu template)

    		 A customizable Mambu template used to define and create individual loan accounts.

    loan rescheduling

    		 An operation used in Mambu to refinance a loan (by changing the interest rate and capital amount), restructure it (by changing the payment frequency or term), or both.

    Mambu Apps

    		 An integration to create selectable frames in the Mambu UI that render an externally-hosted application’s data.

    Mambu Champion

    		 An employee at the organization that receives services from Mambu (one of Mambu's customers) who is designated as the primary contact for Mambu and its partners.

    Mambu cloud banking platform

    		 The collective functionalities of Mambu’s core banking software including the Mambu core, Mambu Process Orchestrator, connectors, and so on.

    Mambu core

    		 The central piece of the Mambu cloud banking platform representing Mambu software itself. The Mambu core consists of the foundation platform, technical platform, and product factory (including the deposit engine and lending engine). The Mambu core interacts with the rest of the Mambu ecosystem using Mambu Process Orchestrator.

    Mambu display language

    		 The language a user chooses to see displayed in Mambu.

    Mambu ecosystem

    		 The composable and modular framework that integrates the Mambu cloud banking platform and Mambu Process Orchestrator with third-party financial service providers.

    Mambu Payment Gateway (MPG)

    		 The component that facilitates one-time and recurring transactions using the Single Euro Payments Area (SEPA) scheme. It has its own interface for configuration, managing users, and auditing transactions, and its own suite of APIs for making, receiving, rejecting, and refunding standards-based payments.

    Mambu Process Orchestrator (MPO)

    		 The orchestration layer that enables Mambu customers to exchange data between the Mambu core and other API-enabled systems.

    Mambu UI

    		 The graphical user interface for Mambu itself.

    Mambu User Guide

    		 The support.mambu.com site, with comprehensive documentation about Mambu’s products, with a particular focus on the Mambu UI.

    MambuCast

    		 A webinar series produced by Mambu Partner Enablement to train Mambu partners on a variety of topics.

    maturity

    		 The date on which a fixed deposit becomes due, meaning that it won't continue to accrue interest and the clients can withdraw their money with the already accrued interest.

    menu item

    		 An option on the navigation bar in the Mambu UI. There are two categories of menu items: menu items with views and menu items without views. Views are also referred to as custom views, these terms are interchangeable.

    microfinance institution (MFI)

    		 A financial institution that serves individual or business clients who lack access to conventional financial services, typically low-income or geographically isolated clients. See also financial inclusion.

    modify task node

    		 A type of node in a Mambu Process Orchestrator process that updates a task in another process.

    mortgage

    		 A secured loan used either to buy real estate or to raise funds against the value of owned real estate. For the relevant Mambu product, see retail mortgage.

    mortgage with redraw facility

    		 A mortgage that allows the borrower to make payments higher than the minimum schedule requires. These additional payments can either be withdrawn at by the borrower at a later date or be applied to the interest due over the term of the loan.

    multi-tenancy

    		 The ability for a single Mambu software instance to support multiple tenants.

    native field

    		 A field in the Mambu UI (that is also accessible via the Mambu API) that is both part of an entity by default and is accessible to any user of that entity. Compare with custom field.

    neobank

    		 A bank that offers traditional banking products and services without a physical branch network. Neobanks might have a formal relationship with traditional banks or operate independently and compete with them. See also nontraditional and fintech (organization type).

    node

    		 A logical unit that executes an action. Nodes are used to create a process in the Mambu Process Orchestrator.

    Non-Production Preview

    		 The stage in the Mambu release cycle where a feature or capability is available to a limited number of Mambu customers chosen by Mambu.

    non-traditional currency

    		 An alternative store of value that a user can define in Mambu. Examples of non-traditional currencies include loyalty points, such as Amazon Coins, and pseudo-currencies, such as the Unidades de Inversion (UDIs) used in Mexico to protect investments from high inflation.

    nontraditional

    		 A smaller, newer financial institution that might offer lending or deposit services, but not both. Examples include e-commerces, telcos, and retail outlets that offer financial services like credit cards, buy-now-pay-later options, consumer lending, and so on. See also neobank and traditional bank.

    offset mortgage

    		 A mortgage that is linked to a savings account held by the same financial institution. The savings account balance is used to reduce, or “offset,” the mortgage interest that the borrower is charged.

    orchestration layer

    		 The software in a composable architecture system that exchanges data between architecture components. Mambu Process Orchestrator (MPO) is the orchestration layer between the Mambu core and third-party services. See also downstream systems and upstream systems.

    organization

    		 A Mambu customer, including staff members and the different branches.

    originator

    		 The party that initiates a payment order that is received by the beneficiary.

    originator bank

    		 The payment service provider (PSP) that services the originator's account. They receive the payment order instruction from the originator, in order to be executed and sent towards the beneficiary’s PSP.

    outstanding principal

    		 The amount of principal on a loan that remains to be repaid.

    overdraft

    		 A deficit in a bank account caused by withdrawing more money than the account holds. The institution that manages the account may charge fees or higher interest rates when an account is overdrafted.

    partner accreditation

    		 Mambu's program to train partners on working with Mambu and its customers. Accreditation is appropriate for sales and solutions partners, and also for services partners when partner certification is not yet available.

    partner certification

    		 Mambu's program to train partners to serve existing Mambu customers. Certification training includes lab components and a proctored exam and is intended for services partners who work directly with customers.

    Partner Enablement

    		 Mambu's organization for training current and future Mambu partners. Enablement products include partner accreditation and partner certification.

    payment execution

    		 The process of moving money from the originator account to the beneficiary account as specified in a payment order. When executing a payment, Mambu determines whether both accounts are in Mambu and selects the appropriate processing mechanism.

    payment network operations region

    		 A single country, multiple countries, or an economic bloc where payments are settled in the same manner, through the same mechanism.

    payment order

    		 An order to transfer money between two bank accounts: the originator account and the beneficiary account. Also known as a credit transfer.

    payment order initiation

    		 The process of submitting a payment order for subsequent execution.

    payment processing

    		 A connector component type that helps the Mambu cloud banking platform integrate with payment processing and transaction monitoring services.

    payment service provider (PSP)

    		 The financial institution that services an account sending or receiving a payment order. Terms like "bank" or "financial institution" might be used to describe a payment service provider.

    Mambu Payments Gateway API

    		 An API available through Mambu’s API Reference that allows customers to process domestic and international payments made via the Single Europe Payments Area (SEPA) payments scheme.

    peer-to-peer (P2P) lending

    		A lending platform that connects lenders with borrowers. Either party in peer-to-peer lending (P2P lending) might be a business or individual. The P2P lending platform does not lend money, but establishes loan terms and conditions.

    penalty

    		 A defined fee that an organization may charge to clients when a specific term of the loan contract is violated—most commonly, when the client is late repaying a loan.

    permission

    		 The authorization given to users that enables them to view a type of information or to perform an action in the Mambu UI or via the Mambu API. Permissions can either be assigned directly to users or assigned to them through a role.

    personal deposits

    		 Savings accounts and term deposits for individuals.

    personal lending

    		 Interest-bearing personal loans for individual use. Personal loans can be secured or (in most cases) unsecured, meaning they are not backed by collateral. Examples include microfinancing, payday loans, cash advances, and car and boat loans.

    prepaid card account

    		 A type of stored value account that allows issuers to store monetary value onto prepaid cards. A prepaid card is not linked to a bank account.

    Prepayment Recalculation Methods

    		 A Mambu setting to adjust how to handle prepayment of a loan, regarding recalculating the loan principal and repayment schedule.

    principal

    		 The original amount borrowed for a loan or deposited in an interest-bearing account, excluding interest, fees, and penalties. See also outstanding principal.

    process

    		 A series of actions built in Mambu Process Orchestrator from individual nodes.

    product

    		 Any specific type of loan or deposit that an organization creates for its clients. Any loan account or deposit account will be part of a product, so the terms and conditions defined when a product is created will then be used to set the constraints of the account.

    product actions

    		 Actions that represent the transactions that are automatically logged by Mambu, once products are linked to general ledger accounts.

    product factory

    		 The product configuration engines—lending engine and deposit engine—that Mambu customers use to create a new product using pre-defined parameters. The product factory is one of the three components of the Mambu core alongside the technical platform and foundation platform.

    production

    		 A tenant provided by Mambu which is used for processing end-client data. It's the live application. Also known as production tenant.

    purchase financing

    		 Consumer finance loans offered by a business or retail e-commerce to its clients, such as point-of-sale financing, “buy now pay later” programs, or credit cards.

    queue node

    		 A type of node in a Mambu Process Orchestrator process that implements queue logic.

    Received (RCVD)

    		 The status of a payment order when it has been received and the input has been validated.

    reduce amount per installment (RAI)

    		 A method to recalculate the schedule by reducing the installment amount when a client makes a prepayment.

    reduce number of installments (RNI)

    		 A method to recalculate the schedule by reducing the number of installments when a client makes a prepayment.

    Rejected (RJCT)

    		 The status of a payment order when it has been rejected.

    repayment

    		 The amount that borrowers need to pay on a loan as determined by a repayment schedule. Repayments can include principal, interest, fees, and penalties.

    Repayment Schedule Versioning (RSV)

    		 A system for tracking the history of repayments on a loan in Mambu.

    reply to process node

    		 A type of node in a Mambu Process Orchestrator process that replies to a call from another process.

    retail mortgage

    		 A collateral-based mortgage for individuals. Despite the name, retail mortgages are for non-commercial real estate.

    RFI

    		 Short for Request for Information. A request to suppliers for information on the products and services that they can provide, typically used to gather information about potential future suppliers. RFIs are typically followed by an RFP or RFQ.

    RFP

    		 Short for Request for Proposal. A request that describes a project and solicits bids to complete it. An RFP is appropriate when the requester doesn't know specifically how they want to solve a problem.

    RFQ

    		 Short for Request for Quotation. A request for pricing proposal for a particular product or service, appropriate when the requester has a specific solution in mind but not how much it will cost.

    RFX

    		 Short for Request for X. A blanket term for RFP, RFI, and/or RFQ.

    role

    		 A way to group permissions and to control other forms of access within Mambu UI and API. Each user in Mambu may be assigned a role. The user will then have all the permissions that are a part of that role. Also known as user role.

    sandbox

    		 A tenant within a given Mambu instance that customers can use for development and testing. Also known as sandbox tenant.

    savings accounts

    		 Individual tenants associated with a Mambu deposit product. Savings account holders typically earn interest and can make deposits and withdrawals when they wish. For the relevant Mambu products, see personal deposits and business deposits.

    savings plan

    		 A savings product that allows a client to make deposits during the maturity period, but not withdrawals. Once the maturity period ends, a client can make withdrawals but not deposits.

    schedule

    		 The repayment plan for a loan, typically including repayment amounts, dates, accrued interest, and required fees.

    secured loan

    		 A loan whose value is secured by collateral.

    SEPA

    		 Short for Single Euro Payments Area. An EU initiative to integrate euro-based transfers between banks in EU and other participating countries.

    set parameter node

    		 A type of node in a Mambu Process Orchestrator process that sets or modifies a parameter value in the task.

    set state node

    		 A type of node in a Mambu Process Orchestrator process that implements storage logic and task state distribution.

    shared instance

    		 A Mambu instance shared among multiple Mambu customers, each with its own isolated data and configuration. The workload of all tenants in the instance is spread across the same infrastructure and software processes. Compare with dedicated instance.

    single sign-on (SSO)

    		 an authentication scheme, available when federated authentication is enabled, that allows users to log into multiple systems with a single identity.

    SME lending

    		 Interest-bearing secured or unsecured loans granted to small and medium-sized enterprises (SMEs) to help them to start or expand their business or support their operational needs. Examples include working capital loans, term loans, and SME lines of credit.

    sponsor bank

    		 A bank that is a member of an approved bank card system such as Visa or Mastercard. Sponsor banks offer credit cards and other lending options related to the bank card system.

    state (loan and deposit account)

    		 The stage of an account in an organization. Loan accounts can be in a pending approval, approved, active, active (in arrears), closed (with obligations met), closed (rescheduled) or closed (written off) state. Deposit accounts can be in a pending approval, active, closed, or dormant state.

    stored value accounts

    		 Transactional accounts that support digital wallets or prepaid card accounts. Stored value accounts don't offer typical bank account features like interest.

    Streaming API

    		 An API available through Mambu’s API Reference that allows customers to subscribe to real time data streaming from Mambu.

    sum node

    		A type of node in a Mambu Process Orchestrator process that adds up a series of values and returns the sum.

    task

    		 A logical set of parameters that represents data passing through the nodes of a process in the Mambu Process Orchestrator (MPO). The MPO routes and transforms the task according to the logic and functions of the nodes.

    technical champion

    		 An employee at the organization that receives services from Mambu (a customer) who is designated as the primary contact for the integration consultant and other technical contacts at Mambu.

    technical overdraft

    		 See overdraft.

    technical platform

    		 The conceptual component of the Mambu core (alongside the foundation platform and product factory) that includes supporting services such as account sub-ledgers, customer information, and access management.

    teller

    		 A user type in the Mambu UI and API that represents the “front office” customer service in financial institutions that are usually responsible for processing client transactions, such as making deposits or withdrawals or processing loan repayments and disbursements.

    tenant

    		 A logically isolated access point in a Mambu instance with its own URL, database, accounting, and configuration. Each instance includes at least two tenants (production and sandbox) but supports more if needed (for example, a bank operating in multiple regions).

    total due

    		 The loan amount due to be paid by the borrower, factoring in the loan principal, interest, fees, payments, and penalties.

    traditional bank

    		 A typical financial institution that handles both individual and business clients. Most traditional banks maintain a physical presence and often employ older technology. See also neobank and nontraditional.

    transaction

    		 Any operation implying changes in the balance of an account such as deposits, withdrawals, or disbursements. Mambu tracks all transactions and associates them to the clients' accounts where they occurred.

    unauthorized overdraft

    		 See overdraft.

    unsecured loan

    		 A loan that is not secured with collateral.

    user

    		 Anyone who accesses and uses Mambu via the UI or the API. Each user has a user account with unique credentials and may have a role, user type, and/or permissions assigned to them.

    user type

    		 A user setting in the Mambu UI and API that assigns certain access settings to a user or an API consumer. There are three available user types, administrator, credit officer, and teller.

    username

    		 A short identifier, usually an abbreviation of the user's name which is determined when the their profile is being created in the Mambu UI or API.

    waiting for callback node

    		 A type of node in a Mambu Process Orchestrator process that requests and waits for a response from an external system.

    withdrawal (deposit account)

    		 The action of taking money out of a deposit account.

    withdrawal (state)

    		 The removal of a loan application from Mambu.

    write-off

    		 The action of closing a loan account after determining that the amount won't be recoverable. Written off loans will be automatically considered as an expense for accounting purposes.
    --- # Using Google as your Identity Provider (IdP) URL: https://docs.mambu.com/docs/google-as-idp/ ## Setting up Federated Authentication with Google 1. Log in to [Google Admin](https://admin.google.com/) with an admin account and go to **Apps** > **SAML apps** 2. Create a new application and select **SETUP MY OWN CUSTOM APP**. ![setupcustomapp](@site/static/img/support/setupcustomapp.png) 3. The next screen (Step 2 of 5) will contain information about the Google IdP. Copy the SSO URL, Entity ID and download the certificate from Option 1, because you will need them later. Select **Next**. ![Step 2 of 5 - Google IdP information](@site/static/img/support/Screen%20Shot%202018-09-26%20at%202.41.22%20PM.png) 4. Fill in the Application Name and select **Next** 5. You'll now need to fill in the provider details: ![google apps saml add new provider](@site/static/img/support/google_apps_saml_step_4.png) - **ACS URL** and **Entity ID**: add a URL that points to the login endpoint of Mambu (for example `https://TENANT_NAME.mambu.com/saml/login`) - **Start URL**: leave blank - **Name ID**: select Basic Information and Primary Email - **Name ID Format**: select EMAIL - Select **NEXT** 6. Google will ask you to set up attribute mapping but you can skip this for now, we will cover this later when [adding users and assigning roles](#add-and-assign-roles) ![google apps saml setup set up attribute mapping](@site/static/img/support/google_apps_saml_step_5.png) 7. You can simply select **FINISH** and continue the setup in Mambu. 1. In Mambu, on the main menu go to **Administration** > **Access** > **Federated Authentication** select the **Enable Sign Sign-On** check box with the **Manual Settings** option selected as well. 2. Enter the **Name** you would like to use for your IdP 3. Enter the **Single Sign-On Endpoint**, this will be the **SSO URL** from the Google IdP 4. Enter the **Certificate Fingerprint** with the value of the following command: ```shell openssl x509 -noout -fingerprint -sha256 -inform pem -in ``` > Do not forget to replace the placeholders above with the correct certificate name / path. 5. Enter the **Issuer ID**, this will be the **Entity ID** from the Google IdP 6. If an ACS URL is provided, it must match the ACS URL and Entity ID from Google IDP (this is optional and might be an URL pointing to a reverse proxy in case a specific tenant uses a private Mambu environment). ![Screen Shot 2019-02-01 at 10.56.43](@site/static/img/support/Screen%20Shot%202019-02-01%20at%2010.56.43.png) 7. Select **Test SSO Connection** and enter the username and password of your Google account 8. In case of a successful setup, you can select **Save Changes**. ## Restrict access to only certain users In case you want to limit Mambu access to specific users, you can use Google organizational units, as described in [How the organizational structure works](https://support.google.com/a/answer/4352075?hl=en) and [Tailor service settings for different users](https://support.google.com/a/answer/2655363?hl=en). 1. In Google, go to **Manage organizational units** and create a new item (such as "support") under your current one. ![Organizational units screen with "support" subunit](@site/static/img/support/orgunits.png) 2. Go to [Users](https://admin.google.com/ac/users) and change the organizational unit for the desired users. ![users screen with change organization unit option visible in menu](@site/static/img/support/new-users.png) 3. Select your app from SAML apps and select **Edit Service**. 4. On the panel from the left hand side, select **Settings for specific organizational units**. For example, for "mambuqa.com", you can select OFF as Service status, whereas for "support" you can select ON. 5. Under the Status, you should see something like "ON for some" ![apps](@site/static/img/support/apps.png) 6. Go to Mambu and try to log in with a user that belongs to the "support" organizational unit. The login should be successful. 7. If you try to log in with a user that is not included in the "support" organizational unit, you should get a 403 error message. ## Add and assign roles 1. From Directory /Users list select **Manage custom attributes**. ![Users list with "Manage custom attributes" button visibile](@site/static/img/support/Screen%20Shot%202018-09-13%20at%2015.04.43.png) 2. Add custom attribute. ![adding custom attribute with the category "federation roles" and the custom field name "RoleID"](@site/static/img/support/Screen%20Shot%202018-09-13%20at%2015.09.50.png) 3. From the Users list, select a user and select the **User information** panel. ![example user information panel](@site/static/img/support/new-Screen%20Shot%202019-02-06%20at%206.56.35%20PM.png) 4. For the RoleID custom attribute, select **Edit** and add a value. Even though we can configure multi values, currently in Mambu only the first one will be used. ![adding the mambu-regular-user value to the RoleID field](@site/static/img/support/Screen%20Shot%202018-09-13%20at%2015.18.44.png) 5. Add new attribute mapping (in SAML Apps) ![attribute mapping when using google as an identity provider](@site/static/img/support/google_as_idpo_attribute_mapping.png) ## Branch Assignment For each of your users, you must also define the branch they are assigned to in Google. For more information, see [Managing Users under Federated Authentication - Branch assignment](/docs/managing-sso-provisioned-users#branch-assignment). The following are the main steps to perform branch assignment using Google as your IdP: 1. Create a custom attribute called `BranchID`. ![Google_IdP_create_custom_attribute.png](@site/static/img/support/Google_IdP_create_custom_attribute.png) 2. Associate the `BranchID` custom attribute to the `BranchID` app attribute. ![Mapping Branch ID attribute in Google identity provider](@site/static/img/support/map_branch_id_attribute_in_google_idp.png) 3. Edit each user in your IdP to add the `BranchID` custom attribute to their profile and fill out the ID of the branch they are assigned to. ![Google_IdP_add_branchid_to_user.png](@site/static/img/support/Google_IdP_add_branchid_to_user.png) --- # Group Role Names URL: https://docs.mambu.com/docs/group-role-names/ This page describes group role names. For general information on groups and how they are used, see [Clients and Groups Overview](/docs/clients-and-groups-overview). Members of a group can be assigned a *group role name*, which is also sometimes called a *group role*. For example, if you have a group type called **Institution**, you may want to create group role names for different types of members of the insitution, such as CEO, secretary, managing director, and treasurer. Another example is if you have a **Joint Account** group type, then you may have group role names for a main signatory and a secondary signatory. Group role names may be assigned to members when you are creating or editing a group. You may assign the same group role name to multiple members. For more information, see [Creating a Group](/docs/creating-a-group). The main benefit of using group role names is that they allow you to set notifications for specific members of a group. For example, you may create a notification for the CFO of a company to notify them whenever a repayment is becoming due in a certain number of days. Whereas, you may create a notification for the CEO of a company that notifies them whenever a loan is approved. For more information, see [Creating notifications for group members](#creating-notifications-for-group-members) below. ![A list of group role names](@site/static/img/support/clients-and-groups--group-roles.png) :::warning In Mambu we sometimes refer to *group role names* as *group roles*. For example in the group creation form. We also sometimes refer to *group types* as *group roles*. It is important to be aware when the term *group role* refers to group type or when it refers to group role name, as these are two separate concepts. For more information about group types, see [Group Types](/docs/group-types). ::: ## Creating group role names To create a group role name: 1. On the main menu, go to **Administration** > **General Setup** > **Group Roles**. 2. Select **Add New Group Role Name**. 3. In the **Adding Group Role Name** dialog, enter the name and ID. The name must be a maximum of 254 characters. The ID must be unique and a maximum of 32 characters. If you do not enter an ID, then the system will automatically generate one for you. 4. Select **Add Group Role Name**. 5. Select **Save Changes**. ![Adding Group Role Name dialog](@site/static/img/support/clients-and-groups--add-group-role-name.png) ## Editing group role names To edit a group role name: 1. On the main menu, go to **Administration** > **General Setup** > **Group Roles**. 2. Select the group role name field and edit the text directly in the field. 3. Select **Save Changes**. ## Deleting group role names To delete a group role name: 1. On the main menu, go to **Administration** > **General Setup** > **Group Roles**. 2. Find the group role name you want to delete in the list and select the delete icon . 3. Select **Save Changes**. ## Creating notifications for group members When creating email and SMS notifications you can specify which group role name will be the recipient of the notification. This allows you to be more granular and specific about which members of a group receive which notifications. For more information on setting up email and SMS notifications, see [Automating Notifications](/docs/automated-email-notifications). To specify the group role name that will be the recipient for a notification: 1. On the main menu go to, **Administration** and then either **SMS** or **Email**. 2. Select **Add Notification**. 3. Enter all the necessary information. In the **Conditions** section, use the **Target** dropdown to select the **Groups** option. 4. The **Recipient** dropwdown will appear. Use it to select the group role name that will be the recipient for this notification. 5. Select **Save Changes**. ![Creating a new SMS notification dialog assigning group role name as notification recipient. ](@site/static/img/support/clients-and-groups--creating-a-new-sms-notification.png) --- # Group Types URL: https://docs.mambu.com/docs/group-types/ This page describes how to create, edit, and delete group types. For general information on groups and how they are used, see [Clients and Groups Overview](/docs/clients-and-groups-overview). Every group must be assigned a group type during the creation process. The group type **Group** is available by default. You may create custom group types or change the default type to organize your clients as you wish. All exiting group types are listed in the **Create** menu in the top bar. If your user has the `CHANGE_GROUP_TYPE` permission, you may change the group type of a group. For example, you may have a group with the type **Prospective Clients** and once this group becomes an active client their type can change to **Existing Clients**. ![Create menu with default group type available](@site/static/img/support/clients-and-groups--client-types-administration.png) :::warning In Mambu we sometimes refer to *group types* as *group roles*. For example in our Configuration as Code (CasC) implementation for client roles and group roles. We also sometimes refer to *group role names* as *group roles*. It is important to be aware when the term *group role* refers to group type or when it refers to group role name, as these are two separate concepts. ::: ## Creating group types In the example below we create a group type called **Joint Account**. To create a group type: 1. On the main menu, go to **Administration** > **General Setup** > **Client Types**. 2. In the **Type** dropdown select **Group**. 3. In the **Add Group Type** dialog, enter all the necessary information. 4. Select **Add Group Type**. ![Add Group Type dialog creating Joint Account group type](@site/static/img/support/clients-and-groups--add-group-type-3.png) Once you have created a new group type it will be available in the **Create** menu in the top bar. In our example, we created a group type called **Joint Account** and it is available in the **Create** menu. ![Create menu with Joint Account option available](@site/static/img/support/clients-and-groups--client-types-management.png) ## Fields for group types | Name | Description | Required | | --- | --- | --- | | Name | The name for the group type. It must be a maximum of 255 characters and it must be unique. | YES | | ID | The unique identifier for the group type. It must be a maximum of 32 characters and it must be unique. | YES | | Client ID Template | The template to generate alphanumeric IDs. For more information, see [Client ID Template](#client-id-template).| NO | | Description | The description for the group type. | NO | ### Client ID Template :::warning In Mambu you create ID templates to manage the identification document information you collect for your clients. These are a completely separate concept to **Client ID Template** field that is part of setting up client types. For more information about ID Templates for identification documents, see [ID Templates](/docs/id-templates). ::: Provide a **Client ID Template** to define the ID number length and format. ### Allow opening accounts If you select the **Allow opening accounts** checkbox, then groups made from this group type will be able to open accounts. In some cases you may want to create a group type that does not allow groups to open accounts, such as, for example, a group for prospective clients that are still going through your Know Your Customer (KYC) review. You could assign a group type called **Prospects** to this group. This group type would not be allowed to open accounts. The individuals that are still going through KYC checks would be added to the prospective clients group. Once the clients pass those checks they can be added to a new group with the group type **Existing Clients** which would have the option to open accounts. ![Add Group Type dialog creating Prospects group type](@site/static/img/support/clients-and-groups--add-group-type.png) ### Allow as guarantor If you select the **Allow as guarantor** checkbox, then groups made from this group type will be able to be assigned as guarantors. When a loan is issued, the client has to provide guarantees. Guarantees can be given in the form of securities such as collateral or someone can be assigned to be a guarantor. This option determines whether a group with this group type can be assigned as the guarantor for a loan. ### Show default address fields If you select the **Show default address fields** checkbox, then your group creation form will include the default address fields. Otherwise, you can use custom field definitions to model the address fields section. ## Editing and deleting group types You can not delete group types that are in use. To edit or delete a group type: 1. On the main menu, go to **Administration** > **General Setup** > **Client Types**. 2. In the **Type** drop-down, select **Group**. 3. In the list of group types, find the one you want to edit or delete and select **Actions** and then **Edit** or **Delete**. --- # Holidays and Non-Working Days URL: https://docs.mambu.com/docs/holidays-and-non-working-days/ *Holidays* and *non-working days* define the days on which there will be no loan account installments. Holidays fall on specific dates in the year. Non-working days are days of the week which are regularly not considered work days. For example, in many European countries, Saturday and Sunday are typical non-working days. Whereas non-working days apply to your entire organisation, holidays can be defined as either organisation-wide, for specific branches, or currencies. For more information on managing branch-specific holidays, see [Setting holidays for a branch](/docs/branches-and-centres#setting-holidays-for-a-branch). :::warning Please Be Aware If you change your configuration settings for non-working days or holidays, all accounts that are not currently closed will be affected. ::: ## Holidays A holiday is configured for a specific date in Mambu. Your organization may recognize holidays that do not occur every year, or that move from year to year. Holidays may be configured as either recurring or non-recurring. :::warning Please Be Aware We recommend scheduling time at the beginning of each year to review all currently-configured holidays to verify they are still valid, so you can delete or move them if necessary. ::: To define a new holiday: 1. On the main menu, go to **Administration** > **General Setup** > **Holidays**. 2. Under **General Holidays**, select **Add Holiday**. 3. Enter all necessary information in the **Add A Holiday** dialog. See below for more information on the fields. 4. Select **Apply Changes** to save. ![Add a holiday screen. Specific holidays added for each organization.](@site/static/img/support/add-holiday%281%29.png) :::warning Please be aware When the changes required for adding or updating a holiday are saved, the update of the affected accounts is only enqueued to be started, not completed with the save. This is due to the update of the accounts being a possibly long-running process depending on the number of affected entities. ::: To be notified when the background update finishes, subscribe to the `HOLIDAY_SYNC_COMPLETED` webhook event on the Administrative target. See [Event triggers](/docs/event-triggers) and [Create webhook templates](/docs/webhooks-defining-a-new-webhook). ### Holidays fields | Name | Description | | --- | --- | | Description | The name of the holiday. | | Date | The date of the holiday. | | Recurring | Whether the holiday recurs on the same date every year. | | Id | A unique ID. If this field is left blank, Mambu will generate a unique ID automatically. | ## Non-working days Non-working days are days of the week which are regularly not considered work days. For example, in many European countries, Saturday and Sunday are typical non-working days. To select the non-working days for your organization: 1. On the main menu, go to **Administration** > **General Setup** > **Holidays**. 2. In the **Non Working Days** field select the checkboxes next to the appropriate non-working days. 3. Select **Save Changes**. ![Holidays section with Saturday and Sunday selected as non-working days](@site/static/img/support/managing-your-organization--holidays-configuration.png) ## Holidays per currency *Holidays per currency* refers to the national or regional public holidays that affect financial markets, banks, and trading activities in different countries or regions where specific currencies are used. A holiday per currency is configured for a specific date in Mambu. Holidays per currency may be configured as either recurring or non-recurring. They can be set in advance. To define a new holiday per currency: 1. On the main menu, go to **Administration** > **General Setup** > **Holidays**. 2. Under **Holiday per currency**, select **Add Holiday**. 3. Enter all necessary information in the **Add A Holiday** dialog. See below for more information on the fields. 4. Select **Apply Changes** to save. ### Holidays per currency fields | Name | Description | | --- | --- | | Description | The name of the holiday per currency. | | Date | The date of the holiday per currency. | | Recurring | Whether the holiday occurs on the same date every year. | | ID | A unique ID defined per currency field. The unique ID is validated at a currency level. If this field is left blank, Mambu will automatically generate a unique ID. | --- # ID Templates URL: https://docs.mambu.com/docs/id-templates/ ID templates are representations of different forms of identification documents that you can collect from your clients. For each type of ID document that you can use when you create clients, you should create a corresponding ID template. For example, passports and driving licenses. When you create clients you will be able to select which ID template to use in order to enter ID document information for the client. :::warning When setting up client types and group types there is a field titled **Client ID Template**. This is a template to generate alphanumeric IDs for clients or groups created from the respective type. This is not the ID Template we are discussing in this article and is a completely separate concept. For more information about this Client ID Template field, see [Configuring Client Types](/docs/client-types) and [Group Types](/docs/group-types). ::: ## Creating ID templates To create an ID template: 1. On the main menu, go to **Administration** > **General Setup** > **ID Templates**. 2. Select **Add Template**. 3. Enter all the necessary information. See below for more information on the fields. 4. Select **Save Changes**. ![Creating ID Template dialog with required and optional fields.](@site/static/img/support/managing-your-organization--create-id-template.png) ### Fields for ID templates Fields with a green outline are required fields. Fields with a grey outline are optional. #### ID Type (required) The kind of document template being created, such as a passport or driving licence. #### Template Id The ID used to access the ID document template via the API. It may not contain any spaces and it may consist of only letters and numbers. If this field is left blank, the system will generate a random ID for the template ID. #### Issuing Authority (required) The document's issuing authority, such as the passport office or municipality. #### ID Document Template (required) Provide an input mask to define the ID number length and format. For example, a passport number may consist of nine numbers in which case the ID document template would be `#########`. #### Mandatory for Clients This field makes the ID document based on the ID template mandatory for creating new clients. The fields for the ID template will be present on the client creation form by default and they will have a solid green rectangle surrounding them indicating they are required fields. ![ID template mandatory for client](@site/static/img/support/managing-your-organization--identification-documents.png) :::warning This feature only works when you are creating a client based on a client type for which you have selected the **Require identification documents** checkbox. For more information, see [Configuring Client Types](/docs/client-types). ::: #### Allow Attachments Allows you to attach a file (for example, a scan or picture of the ID) when adding this particular type of ID document to a client's profile. ## Using ID templates when creating clients The **Identification Documents** section in the **Creating a Client** dialog is where you can add identification document information, using the ID templates you have created. ![Add Identification Document dialog with ID Template dropdown](@site/static/img/support/managing-your-organization--add-identification-document.png) For more information on using ID templates to add identification document information to clients, see [Creating an Individual Client - Adding identification documents](/docs/create-an-individual-client#identification-documents). ### Enabling other custom templates Under the list of ID templates, which you can view at **Administration** > **General Setup** > **ID Templates**, there is an **Enable Other Custom Templates** toggle. ![The Enable Other Custom Templates Toggle](@site/static/img/support/managing-your-organization--id-templates-configuration.png) This toggle adds an **Other** option to the list of available templates in the **Add Identification Document** dialog when adding ID documents for a client. ![Other option in Add Identification Document template](@site/static/img/support/managing-your-organization--add-identification-document-3.png) This option allows you to add an ID document to your client and enter all the information for the necessary fields without a predefined template. ## Editing ID templates To edit an ID template: 1. On the main menu, go to **Administration** > **General Setup** > **ID templates**. 2. Find the ID template in the list that you want to edit and select **Edit** . 3. Edit the information. 4. Select **Save Changes**. :::warning This may result in existing ID documents using the edited template no longer fitting the defined template. When editing those clients, the ID document will need to be edited to fit the latest template, or removed if it is not mandatory. ::: ## Deleting ID templates To delete an ID template: 1. On the main menu, go to **Administration** > **General Setup** > **ID templates**. 2. Find the ID template in the list that you want to delete and select **Delete** . 3. Select **Delete**. :::warning This can only be done for templates that are not in use. ::: --- # Ideas and Feature Planning URL: https://docs.mambu.com/docs/ideas-and-feature-planning/ ## Raising an idea If you'd like to raise your own idea, we recommend discussing it with your Customer Success Manager. They will review the requirements with you, analyse any potential gaps, and research alternative solutions. They can also help make sure we have all the information our product team needs to effectively integrate your idea into the development roadmap. --- # Import Database clone URL: https://docs.mambu.com/docs/import-database-clone/ ## Overview After you have [obtained a database dump](/docs/database-clone), you can proceed and import it into the local instance of MySql Server. *** ## Import Please follow the steps below to perform the operation: ![developer--data-import-restore-dialog.png](@site/static/img/support/developer--data-import-restore-dialog.png) 1. Ensure the dump file is not in an archived format, but as plain SQL - extract it if needed. 1. Open MySQL Workbench and in the _Management_ tab, select **Data Import/Restore** 1. Choose _Import from Self-Contained File_ and select the dump file 1. Create a new Database Schema as a target or mention an existing empty one 1. Click **Start Import** (the process might take a few moments). *** ## Test After a confirmation message is displayed, can perform a double check on the just imported database: 1. Go to the Schemas tab and hit Refresh button 1. Search in the available schemas and the new database should be present 1. Look for tables - all Mambu tables should be listed. *** --- # Importing Your Data via API URL: https://docs.mambu.com/docs/importing-your-data-via-api/ This article describes how to import data using the Mambu API. Before you begin, there are some preliminary steps in setting up your organization that must be completed. For more information, see [Data Management Overview - Import prerequisites](/docs/data-migration-overview#import-prerequisites). ## What we'll need from you When planning to migrate via API, please contact your onboarding consultant to request support. Our specialists will help coordinate, provide support with the initial mapping, answer questions, and help troubleshoot any issues related to the data migration. When you are planning your migration, please provide us with the following information: * The amount of data you plan to import, including the number of clients and the total number of accounts and transactions. * The steps which are going to be performed for every client/account migration, such as: * Client creation * Loan account creation * Loan account approval * Loan account linked to deposit settlement account * Loan account schedule edited * Loan account disbursed * Manual fees applied * Repayment posted * Sample API calls you will use to perform each of the actions above, including the endpoints and parameters to be used. * Sample database queries and/or reports generated during the migration process, if any. * When you want to migrate your data into Mambu. Based on the results of the data migration requirements analysis and the results of your sample data migration, we might need to assess performance implications of using APIs for the data migration process and: * Suggest the best flow step-by-step to limit the number of API calls needed to a minimum. * Suggest the number of APIs calls that can be processed within a given period of time to guarantee the performance. * Consider temporary adjustments of the environment performance. For more information on using our APIs, see our [API Reference](/api/pages/api-v2/welcome). ## Data security and confidentiality Because the migration of your data involves the handling of personal identifiable information of your clients and the processing of private access credentials, Customer Systems Data Protection and General Data Protection Regulation (GDPR) rules apply. --- # Importing Your Data via Excel URL: https://docs.mambu.com/docs/importing-your-data-via-excel/ ## Getting started You may import data into Mambu by filling out an Excel template that we provide and submitting it with the Mambu UI. This can be convenient if your legacy system exports data in CSV format. Importing transactions via Excel will not create accounting Journal Entries. :::note The **data import** feature is not available by default. Please reach out to your Customer Success Manager or contact [Mambu Support](/docs/mambu-support) to have it enabled. ::: :::warning Your imported spreadsheet must be five megabytes or smaller. If you need to import more data than you can fit in a file of that size, you must split the data into multiple submissions. For more information, see [Excel Migration Template](/docs/excel-migration-template). ::: In most cases, we recommend importing your data into Mambu using the Mambu API or a combination of the Mambu API and spreadsheet-based import. For more information, see [Data Management Overview - Importing Data](/docs/data-migration-overview#importing-data). Before you begin, there are some preliminary steps in setting up your organization that must be completed. For more information, see [Data Management Overview - Import Prerequisites](/docs/data-migration-overview#import-prerequisites). ## Download the Excel template You will find our Excel import template in the Mambu UI under the **Data** tab of the **Administration** section. ![Download Template step with Download Template button](@site/static/img/support/data-and-reporting--import-data-wizard-download-template.png) The spreadsheet contains two types of sheets: 1. Empty sheets to fill in with data: including Clients, Groups, Loan Accounts, Savings Accounts and Chart of Accounts. These sheets have green cell titles. 2. Sheets with data: such as IDs to be used as a reference when filling the others, including Branches, Credit Officers, Centres, Loan Products and Savings Products. These sheets have gray cell titles. All sheets are editable. :::note The provided template uses an `XLSX` extension - do not change this extension, or you will not be able to import it into Mambu. An `XLS` file will not pass validation. ::: For a complete reference guide to the Excel template, see [Excel Migration Template](/docs/excel-migration-template). ## Fill in the Data The template can be either manually filled from your old system or you can use mapping tools. Each sheet contains field validations. For example, mandatory fields cannot be empty and specific date formats are required. Please review the validation rules in [Excel Migration Template](/docs/excel-migration-template/#id-consistency-and-validation) to ensure your data is entered correctly. ## Import the file into Mambu for validation Once you have entered all your data in the Excel template, the file is ready to be imported. During the import process, your data is automatically validated by Mambu. To begin importing your data, go to **Administration** > **Data**. Click on **Choose File** and select the file you want to import. Then, click on the **Import Data** button. Note that the **Import Data** button is not active until a file has been selected. ![Validate And Import set with Import Data button](@site/static/img/support/data-and-reporting--import-data-workflow-validate-and-import.png) During the import process, a progress bar shows the percentage of data that has been imported. ![Processing Import Data pop with progress bar](@site/static/img/support/data-and-reporting--processing-import-data.png) The imported data is displayed in the Mambu UI and the process continues automatically to the approval stage. During this period, an orange bar at the bottom of the screen notifies users that the data migration is in progress. :::warning No action can be taken in the Mambu UI during the approval stage of the import process. ::: The status of the uploaded file is **Draft** during this phase. ![Info related to Import process](@site/static/img/support/data-and-reporting--import-data-workflow.png) During this process, we recommend navigating through the Mambu UI to do an initial check that everything is working correctly and your data appears correct. ## Validation unsuccessful: handling errors If your submitted data contains errors, you will see a notification message and an Excel file that includes all errors, displayed in cells highlighted in red. The error report will include comments about how to fix any problems in the **Errors** sheet, which is the last sheet in the file. Once you have corrected any reported errors, you may resubmit your corrected data by repeating the import process described above. ![data-and-reporting--import-validation-errors.png](@site/static/img/support/data-and-reporting--import-validation-errors.png) ## Validation successful: completing import When validation is successful, you will see a confirmation notification is displayed on the page. When the file is fully uploaded, summary information is displayed in the **Import Events** section, such as how many loan accounts and clients were imported. You will see two options: **Approve** and **Reject**. ### Approving a successful import Once you have successfully imported your data, you may either approve or reject the import. :::warning Be sure you are ready before you approve your import. Once you do so, the migration process is complete, and it can no longer be rejected or rolled back. Any furtherchanges to data will have to be performed manually. ::: To approve the import, select **Approve Import** and select **Confirm**. ![Apply Import Changes pop-up with Cancel and Confirm button](@site/static/img/support/data-and-reporting--confirm-import-storage-dialog.png) When you approve the import, its status changes from **Draft** to **Approved**. At this point: * All clients and groups are assigned to branches, centres, and credit officers. * Any custom field values are filled for every entity. * All accounts are assigned to their products. ### Rejecting a successful import If for any reason you wish to reject the import before it is approved, such as if you find that bad data has been imported, then you can reject the import by clicking on **Reject Import** and selecting **Confirm**. ![data-and-reporting--revert-import-changes-confirmation.png](@site/static/img/support/data-and-reporting--revert-import-changes-confirmation.png) When you reject an import, its status changes from **Draft** to **Reverted** and all migrated data is deleted from the system. --- # Incoming and Outgoing Payment Messages URL: https://docs.mambu.com/docs/incoming-and-outgoing-payment-messages/ The Mambu Payment Gateway groups information about payment messages under two menu items, **Incoming** and **Outgoing**. The **Incoming** menu item contains information about incoming payment messages. This includes all the pending payment messages as well as the those that have already been processed by the scheduler. ## Payment messages ## Pending payments For both incoming and outgoing payment messages, the payment message will first enter the pending state and once the scheduler runs if will move to the list of processed payment messages. For more information about schedulers, see [Schedulers](/docs/schedulers-and-holidays#schedulers). ## Payment message detail screen In any list of payment messages, you may select a payment message to view the payment message detail screen. Here you can see more detailed information about the SEPA message (XML). In the table we provide a list of the fields in the XML. ## Alerts ## PREVIOUS CONTENT ## Incoming / Outgoing The incoming / outgoing menus are used to monitor received/sent payment messages. When clicking this menu, the user is prompted with two sub-menus: * SEPA * Alerts The sub-menu SEPA gives users a view on the incoming / outgoing SEPA messages: ![Screenshot 2019-07-24 at 04.59.34](@site/static/img/support/payments--incoming-sepa-transactions.png) ### Transactions List Each row represents one of the following SEPA messages: * Pacs.008 * Pacs.004 * Pacs.002 * Camt.056 * Camt.029 The list provides the following information on a message: * System ID * Message type * Message ID * Number of transactions inside a given message * Settlement date Clicking a single row will provide users more information on the payment message: * Transaction number * Message ID * Status * Amount * Creditor IBAN ![Screenshot 2019-07-24 at 05.00.24](@site/static/img/support/payments--sepa-transaction-details.png) By clicking on the arrow of each row the SEPA message (xml) will be seen in full on the detail screen. :::note For more information about these messages, please refer to the 2019 SEPA Credit Transfer rulebook version 1.2 which you can find at the website of the [European Payments Council](https://www.europeanpaymentscouncil.eu/ ::: The fields displayed are relevant for the end users and provide useful information in case of investigation or customer requests. #### List row detail Clicking a single row will redirect users to the full details of the payment message: ![Screenshot 2019-07-24 at 05.02.27](@site/static/img/support/payments--list-row-detail.png) The image above represents a SEPA message (xml) and can be seen in full in this detail screen. For more information, please refer to the [European Payments Council's](https://www.europeanpaymentscouncil.eu/) 2019 SEPA Credit Transfer rulebook version 1.2. The fields displayed are relevant for the end users and provide useful information in case of investigation or customer requests :::note For ISO 20022 fields, the XML Tag is indicated in parentheses. ::: | Field | Description | | --- | --- | | Message ID | Unique reference generated by the payment engine and used to identify a single message in the system | | Message Identification (MsgId) | Message reference created by the sender and forwarded in the SEPA message| |Message type |The type of message sent/received e.g pacs.008 | | Transaction status | Status of the message assigned by the payment engine after processing: rejected, pending, Sent | | Reception date | Date at which the message is received in the payment engine. In search screens, users can enter From and To reception dates | | Sending party (InstgAgt) | BIC of the sending Bank| | Receiving party (InstdAgt) |BIC of the receiving Bank | |Order status | Status of the order assigned by the payment engine after processing: rejected, processed, pending, on hold. Order status depends on the status of the message. An order is automatically rejected if the corresponding message is rejected. | | Order Category Purpose (PmtTpInf, CtgyPurp) | It provides information about the purpose of the order and may trigger special processing. So interesting for the end user | Execution date | Date at which the order is really executed. Requested and real execution dates are the same most of the time. | |Order amount | Amount of the order | | Interbank Settlement Date (IntrBkSttlmDt) | The date at which the order / transaction is settled | |Interbank Settlement Amount (IntrBkSttlmAmt) | Total amount of the transactions contained in the order or message (e.g if pacs.008 has 2 payments of 10 then IntrBkSttlmAmt=20 | | Debtor name (DbtrNm |Name of the debtor | | Debtor Account DbtrAcct (Debtor IBAN) | IBAN of the debtor | | Debtor Agent (DbtrAgt) |Debtor bank BIC | | Beneficiary name (CdtrNm)|Beneficiary name | | Creditor Agent (CdtrAgt) | Beneficiary Bank BIC | |Creditor Account (CdtrAcct) | IBAN of the beneficiary| |Transaction ID (TxId) | Unique reference generated by the payment engine and used to identify a single transaction in the system | |Interbank Settlement Amount (IntrBkSttlmAmt)|This is the transaction amount | |End To End Identification (EndToEndId) | It is generated by initiating party to unambiguously identify the transaction. Good to have as search criteria since users can easily find a transaction with it| | Transaction Status | Status of the transaction assigned by the payment engine after processing: rejected, processed, pending, on hold. Transaction status depends on the status of the order. A transaction is automatically rejected if the corresponding order is rejected | | Original transaction ID | This is available in R-transactions only. It provides for example the transaction ID of the original transaction linked to a return. | :::note For more information about these messages, including a complete set of fields, please refer to the 2019 SEPA Credit Transfer rulebook version 1.2 which you can find at the website of the [European Payments Council](https://www.europeanpaymentscouncil.eu/). ::: ## Alerts The sub-menu _Alerts_, gives users a list of alerts for the SEPA messages. The section provides information on the error so that the user can trigger actions to resolve the issue. The alerts section can be found both on the outgoing and incoming menus. ![Screenshot 2019-07-24 at 05.28.47](@site/static/img/support/payments--pending-alerts.png) ## Pending In this section you will see messages that are pending to be sent: either they require manual input before they can proceed the payment flow, such as outgoing returns requests or replying to these return requests positivily or negativily or messages that cannot be sent given the day the messages were generated is a holiday. **Outgoing returns waiting to be accepted or rejected**: ![image.png](@site/static/img/support/image%2871%29.png) **Pending pacs.008 given a payment was sent on an holiday** ![image.png](@site/static/img/support/image%2874%29.png) --- # Index Rates Configuration URL: https://docs.mambu.com/docs/index-rates-configuration/ The index rates that can be configured are interest rate, value added tax rate, and withholding tax. For more information, see [Customizing Index Interest Rates & Tax Rates](/docs/customizing-index-rates). With *Configuration as Code* (CasC), you may batch configure your index rates configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for index rates supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/indexrates.yaml` | Get the current index rates configuration. | | `PUT` | `/configuration/indexrates.yaml` | Write a new index rates configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ### GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/indexrates.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/indexrates.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @indexrates.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. “@indexrates.yaml” represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml --- indexRateSources: - id: "1515528602" name: "3 Month LIBOR" type: "INTEREST_RATE" notes: "" indexRates: - id: "54082948" startDate: "2021-03-08T01:00:00+01:00" rate: 0.85 notes: "" - id: "384947284" startDate: "2019-03-06T01:00:00+01:00" rate: 2.33 notes: "" - id: "951490027" startDate: "2018-03-05T01:00:00+01:00" rate: 2.3 notes: "" - id: "865715514" name: "1 Month LIBOR" type: "INTEREST_RATE" notes: "" indexRates: - id: "967424433" startDate: "2020-10-05T02:00:00+02:00" rate: 0.69 notes: "" - id: "1306016671" startDate: "2019-10-07T02:00:00+02:00" rate: 2.22 notes: "" - id: "703118600" startDate: "2018-10-01T02:00:00+02:00" rate: 2.02 notes: "" - id: "1529349105" name: "VAT Switzerland" type: "TAX_RATE" notes: "" indexRates: - id: "1662077234" startDate: "2018-10-10T02:00:00+02:00" rate: 7.7 notes: "" - id: "1055113792" startDate: "2017-10-03T02:00:00+02:00" rate: 8 notes: "" - id: "954835635" name: "Wittholding Tax" type: "WITHHOLDING_TAX_RATE" notes: "" indexRates: - id: "1618217994" startDate: "2019-10-07T02:00:00+02:00" rate: 35 notes: "" ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | The id of the index rate source. If created via the UI it is not required, using the API it is required. If it is not provided when created a rate via the UI, then a random nine digit number is created. | ✔ | | `name` | String | The name of the index rate source. | ✔ | | `type` | String | The type of the index rate source. The available types are `INTEREST_RATE`, `TAX_RATE`, and `WITHHOLDING_TAX_RATE`.| ✔ | | `notes` | String | Any custom text to be associated with the index rate source. | ✘ | | `indexRates` | IndexRateConfiguration| List of index rates associated with the index rate source. | ✘ | | `indexRates.id` | String |The id of the index rate. If created via the UI it is not required, using the API it is required. If it is not provided when created a rate via the UI, then a random ten digit number is created.| ✔ | | `indexRates.startDate` | String (date-time) | The date when this index rate starts being the active rate for its source.| ✔ | | `indexRates.rate` | Number | The percentage value of the index rate. | ✔ | | `indexRates.notes` | String | Any custom text to be associated with this index rate. | ✘ | ## Replies ## Requirements The endpoints do not accept empty configurations or null/empty entries in a configuration. | Name | Requirement | | --- | --- | | `id` | Must be non blank, alphanumeric, unique in the list of index rate sources, and with a maximum length of 32 characters. | | `name` | Must be non blank, unique in the list of index rate sources, and with a maximum length of 32 characters. | | `type` | Must not be blank. in case the type is changed during an update operation, the index rate source must not be in use. | | `notes` | Can be blank, but if it is specified, the length must not be larger than 255 characters.| | `indexRates` | Can be blank. | | `indexRates.id` | Must be non blank, alphanumeric, unique in the list of index rates, and with a maximum length of 32 characters. | | `indexRates.startDate` | Must not be blank, must be unique in the index rate, and there must not be a transaction after the specified start date. Must follow the ISO 8601 format for date and time `YYYY-MM-DD'T'hh:mm:ss±hh:mm`. | | `indexRates.rate` | Must not be blank, must be between 0 and 100 for `TAX_RATE` index rate types, and must be between 0 and 1000 for other index rate types. | | `indexRates.notes` | Can be blank, but if it is specified, the length must not be larger than 255 characters. | ## Warnings An index rate source cannot be deleted when it is already in use, or if a transaction exists after its date. If you attempt to delete an index rate or index rate source that cannot be deleted, it will be deactivated and a warning message will be returned. --- # Welcome to Mambu URL: https://docs.mambu.com/docs/ Mambu is the core engine of a cloud-based composable banking architecture that enables the use of best-for-purpose technologies to offer modern lending and banking services. Our full suite of deposit and lending products along with our comprehensive APIs, ledger service, and third-party integration products allow for fast, flexible implementation that can help you speed up your go-to-market strategy and rapidly scale to keep pace in today’s changing market. ## Using Mambu As a Mambu user, there are three main ways to interact with our service: using the Mambu UI, with our APIs, and by using the Mambu Ecosystem. ### Mambu UI The Mambu UI is our core banking user interface, accessible through your browser. It is used to set up, administer, configure, and access your organization, branches, clients, Mambu users, financial products and services, and more. You can log into the Mambu UI at the following URLs: * Production: `https://TENANT_NAME.mambu.com` * Sandbox: `https://TENANT_NAME.sandbox.mambu.com` For more information on setting up and configuring your sandbox, see [Sandbox](/docs/sandbox). This User Guide covers how to work with the Mambu UI. For more information, see [Mambu User Guide](#mambu-user-guide) below. ### Mambu APIs Mambu offers a full suite of RESTful APIs to provide programmatic access to our banking software. Mambu APIs allow users to perform many tasks, including: * create clients, loan accounts, or savings accounts * make transactions * manage system configuration * set up branches * configure interest rates * manage API keys, user roles, and access permissions * and much, much more Our primary API documentation for the Mambu v1 and v2, Payments, and Streaming APIs may be found on our [API Reference](/api/). There, you will find complete reference material including authentication and request format information, endpoints, field descriptions, example requests and responses, and general help on requirements and conventions. Some operations allow or require action from both the Mambu UI and our APIs. For example, complete setup and configuration of API keys for authentication involves steps in both the Mambu UI and via the API v2. In these cases, you will find information on these features in both the Mambu User Guide and the API Reference. ## Mambu User Guide This guide provides a detailed overview of how to administer, manage, and run your organization and financial services with Mambu. Special attention is given in this guide to the Mambu UI, but we sometimes cover conceptual topics related to working with Mambu programmatically, using our APIs. Many of the conceptual topics relevant to developing against Mambu are included in our [Developer](/docs/developer-overview) section. The User Guide also covers additional services such as the Mambu Payment Gateway (MPG). ## Release notes Want to know more about what we're working on? Have a look at the latest features we've included on our latest releases by joining the [Mambu Community](https://community.mambu.com/c/release-notes/). ## Technical Success Packages For certain contracts concluded before 2021, capabilities and features may be limited by Technical Success Packages: * Standard Technical Success Package: All standard features. * Premium Technical Success Package: All standard features, Audit Trail, and Configuration as Code (CasC). * Enterprise Technical Success Package: All standard features, all Premium features, Streaming API, and the Mambu Process Orchestrator (MPO). ## Couldn't find what you need? Try the [Mambu Community](https://community.mambu.com) where you can post questions and participate in discussions with us and with other users. We're also constantly adding articles and improving our User Guide. Please contact us through [Mambu Support](/docs/mambu-support) if you have any questions about this content and to help us identify any missing topics. --- # Indicators URL: https://docs.mambu.com/docs/indicators/ *Indicators* show you a wide range of useful information about your clients, products, or accounts, directly on the main dashboard of the Mambu UI. The **Indicators** widget allows you to select which indicators you want to display on your dashboard. To add or remove an indicator: 1. On the main Dashboard, next to the widget's title, select **Settings** . 2. To add an indicator, use the **Indicator** dropdown, select the indicator, and then select **Add Indicator**. 3. To remove an indicator, find the indicator in the **Selected Indicators** list, and select **Delete** . 4. Select **Save Changes**. ![The Indicators widget in the Mambu UI](@site/static/img/support/mambu-ui-indicators-widget-1302x562.png) ## Outreach information | Indicator | Description | | --- | --- | | **Active Clients** | The number of clients in an Active state. | | **Active Deposit Account Holders (groups and clients)** | The number of clients and groups which have at least one deposit account in the following states: Active, Dormant, Locked, and Active in Arrears. | | **Active Loan Account Holders (groups and clients)** | The number of clients and groups which have at least one loan account in the following states: Active, Dormant, Locked, and Active in Arrears. | | **Active Solidarity Groups** | The number of Active or Active in Arrears individual loan accounts that are part of a Solidarity Group. | | **Average Group Size** | The number of unique clients that are part of a group, divided by total number of groups. | | **Borrowers (In Groups)** | The number of unique individuals within the group that have an Active or Active in Arrears account. | | **Borrowers (Individuals)** | The number of clients that have an account in an Active or Active in Arrears state that are not part of a group. | | **Borrowers (Solidarity Groups)** | The number of unique clients that have an Active or Active in Arrears loan account that is part of a solidarity group. | | **Closed Clients** | The number of clients in an Exited or Blacklisted state. | | **Exited Clients** | The number of clients in an Exited state. | | **Groups Borrowing** | The number of unique groups that have an Active or Active in Arrears loan account. | | **Inactive Clients** | The number of clients in an Inactive state. | | **Number of Clients** | The number of clients in the database, regardless of their state. | | **Number of Groups** | The number of pure groups from the database. | | **Number of Group Depositors** | The number of unique groups that have an Active, Matured, Locked or In Arrears deposit account. | | **Number of Group deposit Accounts** | The number of unique clients that are part of a group that has an Active, Matured, Locked, or In Arrears deposit account. The deposit account should belong to the group and not the individual. | | **Number of Individual Depositors** | The number of unique clients that have an Active, Matured, Locked or In Arrears deposit account. | | **Open Clients** | The number of non-closed clients in a Pending Approval, Active, or Inactive state. | | **Pending Approval Clients** | The number of clients in a Pending Approval state. | | **Percentage of Female Borrowers** | The percentage of female clients that have at least one active loan account or are in a group with an active loan account. | ## Deposit accounts portfolio | Indicator | Description | | --- | --- | | **Active Accounts** | The number of active accounts with transactions in the past three months, regardless of their product category. | | **Active Business Accounts** | The number of active business deposit accounts with transactions in the past three months. | | **Active Personal Deposits** | The number of active personal deposit accounts with transactions in the past three months. | | **Active Stored Value** | The number of active stored value accounts with transactions in the past three months. | | **Active Daily Banking Accounts** | The number of active daily banking accounts with transactions in the past three months. | | **Active Business Banking Accounts** | The number of active business banking accounts with transactions in the past three months. | | **Deposit Accounts** | The number of deposit accounts in an Active, Mature, Locked, or In Arrears state. | | **Dormant Accounts** | The number of dormant deposit accounts, regardless of their category| | **Dormant Accounts Business Deposits** | The number of dormant accounts in the Business Deposit category; not counting distinct account holders. | | **Dormant Accounts Personal Deposit** | The number of dormant accounts in the Personal Deposit category. | | **Dormant Store Value Accounts** | The number of dormant accounts in the Stored Value category. | | **Dormant Daily Banking Accounts** | The number of dormant accounts in the Daily Banking category. | | **Dormant Business Banking** | The number of dormant accounts in the Business Banking category. | | **Interest Payable** | The total interest accrued - and not yet applied - in deposit accounts in an Active, Mature, Locked or In Arrears state. | | **Total Deposits** | The total balance of deposit accounts in an Active, Mature, Locked, or In Arrears state with a positive balance. | | **Total Overdrafts** | The total balance of all the overdraft accounts. | ## Loan portfolio | Indicator | Description | | --- | --- | | **Average Loan Balance** | The amount of money that results from dividing the Gross Loan Portfolio by the number of loan accounts in an Active or Active in Arrears state. | | **Loans Outstanding** | The number of loan accounts in Active or In Arrears state. | | **Loans Pending Disbursal** | The number of loan accounts in an Approved state. | | **Loans Awaiting Approval** | The number of loan accounts in a Pending Approval state. | | **Loans in Arrears** | The number of all loan accounts in the Active in Arrears state. | | **Portfolio Pending Disbursal** | The sum of the principal due for all loan accounts in the Approved state. | | **Gross Loan Portfolio (GLP)** | The total principal balance of loans that are in an Active or In Arrears state. Partially disbursed loans are ignored (refinanced loans not yet disbursed). | | **Total Disbursed (Active Loans)** | The total amount for loans that are in an Active and In Arrears state. | | **Loans Disbursed (All time)** | The total amount of un-reversed disbursement transactions. | | **Projected Loan Interest Earnings** | The total Interest Due for all the installments for loans in an Active and In Arrears state. | ## Risk and aging analysis | Indicator | Description | Value Type | | --- | --- | --- | | **Interest In Suspense** | The total interest due for all installments of loans in the Active in Arrears state. | Amount of money | | **Portfolio at Risk (PAR)** | The total principal balance for loans that are in an In Arrears state, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR > 7 days** | The total principal balance of accounts that are in an In Arrears state for more than 7 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR > 15 days** | The total principal balance of accounts that are in an In Arrears state for more than 15 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR 7 to 30** | The total principal balance of accounts that are in an In Arrears state for between 7 to 30 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR > 30 days** | The total principal balance of accounts that are in an In Arrears state for more than 30 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR > 90 days** | The total principal balance of accounts that are in an In Arrears state for more than 90 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR 90 to 180** | The total principal balance of accounts that are in an In Arrears state between 90 to 180 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **PAR 180 to 360** | The total principal balance of accounts that are in an In Arrears state between 180 to 360 days, divided by the Gross Loan Portfolio (GLP). | Percentage | | **Value at Risk (VAR)** | The total principal balance of loans that are in an In Arrears state. | Amount of money | | **VAR > 7 days** | The total principal balance of accounts that are in an In Arrears state for more than 7 days. | Amount of money | | **VAR > 15 days** | The total principal balance of accounts that are in an In Arrears state for more than 15 days. | Amount of money | | **VAR > 30 days** | The total principal balance of accounts that are in an In Arrears state for more than 30 days. | Amount of money | | **VAR > 90 days** | The total principal balance of accounts that are in an In Arrears state for more than 90 days. | Amount of money | ## Organization indicators | Indicator | Description | | --- | --- | | **Branches** | The number of branches in your organization. | | **Credit Officers** | The number of credit officers in your organization. | | **Loans per Branch** | The number of loan accounts in an Active or Active in Arrears state, divided by the number of branches in your organization. | | **Loans per Credit Officer** | The number of loan accounts in an Active or Active in Arrears state, divided by the number of credit officers in your organization. | | **Number of Loans (all times)** | The number of loan accounts in your organization. | | **Number of Users** | The total number of users in the organization. | --- # Initial Payment Adjustment URL: https://docs.mambu.com/docs/initial-payment-adjustment/ Sometimes, the time between the mortgage payments isn't a perfect, standard interval. This often happens in two key situations: * Initial payment adjustment: This can happen at the start of the loan. If the period from when the loan is disbursed to the very first repayment date is either longer or shorter than the usual payment cycle (e.g., a month), an adjustment is made to that first payment. * Changing installment due dates: If you alter the due dates of your payments later on during the loan term, the periods between those future payments will also vary from your standard interval. For example: A loan was disbursed on 1st and the monthly payment date is 16th every month. This means that the first payment will be lower as it represents a smaller interval than a month. The first payment will then have unique value and from the 2nd payment loan will follow an equal payment structure. ![initial payment adjustment](/img/support/initial-payment-adjustment-1.png) For dynamic mortgages, specific options are available to enable these precise interest calculations. These options are: * **Adjust the total due of the first repayment**: Activates the logic for Initial Payment Adjustments. It ensures the first mortgage payment is accurately calculated based on the actual time between loan disbursement and the first due date. * Use this option if the first repayment period differs from the rest of the payment periods. * **Adjust the total due of repayments with different intervals**: This option applies to situations where instalment due dates are changed by editing the schedule during the loan term. When selected, it enables the system to recalculate future payments precisely, adjusting the total due amount to reflect the exact interest accrued over the new, varying payment periods. * Use this option if you wish to edit the schedule and have the total due changed based on the longer or shorter duration until the newly set instalment date. This option works only with monthly installments (1-month interval or 1 Fixed Day of Month). These settings are crucial for maintaining payment accuracy, ensuring that the correct amount of interest is always paid based on the actual duration between payments. If these options are not enabled, the total amount due for your installments will remain unchanged, regardless of how long or short the period between payments is. In such cases, only the interest will be calculated for the actual number of days in that specific interval, which will then adjust the amount of principal paid for that particular installment. ![dynamic mortgage options](/img/support/dynamic-mortgage-options.png) For interest-only loans, these adjustment options are applied by default, and no specific checkbox configuration is required. The system automatically accounts for non-standard periods to ensure accurate interest calculation. Let's explore how each of these options applies to different product configurations: ## Adjust 1st installment total due when the duration is different than the interval ### Dynamic mortgage * **Standard interval payments due are equal**: The appropriate PMT (CMS/EMI) formula is used, either based on simple interest or compound interest. ![standard interval](/img/support/standard-interval-dynamic-mortgages.png) * **Shorter interval**: In case of a smaller number of days (less than 1 month) between disbursement and first repayment date, the 1st installment due amount is going to be smaller than the rest of the instalments. ![shorter interval](/img/support/shorter-interval.png) * 1st instalment due = 1PMT + (Interest for full installment - interest for 1 regular interval) When (Interest for full installment - interest for 1 regular interval) generates a negative value the amount will be subtracted from the PMT resulting in a lower *total due*I compared to the PMT of the other installments. * **Longer interval**: In case of a higher period (more than 1 month) between disbursement and first repayment date, the 1st installment due amount is going to be higher than the rest of the instalments. ![longer interval](/img/support/longer-interval.png) * 1st instalment due = 1PMT + (interest for full installment - interest for 1 regular interval) When (Interest for full installment - interest for 1 regular interval) generates a positive value, the amount will be added to the PMT resulting in a higher *total due* compared to the PMT of the other installments. ### Interest only equal installments There is no toggle or checkbox to be enabled for interest only loans. **Broken installment total due calculation** * **Standard interval** ![equal installment standard interval](/img/support/equal-installment-standard-interval%282%29.png) * **Shorter interval** ![equal installment shorter interval](/img/support/equal-installment-shorter-interval%283%29.png) * Total Due = Interest accrued for that number of days (Principal Balance* daily rate * #days). * **Longer interval** ![equal installment longer interval](/img/support/equal-installment-longer-interval.png) * Total Due = 1 Standard PMT + interest accrued for the additional number of days. ### Adjust total due when editing installment due dates **Dynamic mortgages** For [dynamic mortgages](/docs/dynamic-mortgages) (capital repayment loans), any changes to your installment dates part-way through the loan term are handled only if the **Adjust total due of repayments with different intervals** checkbox is selected. This ensures that the system actively recalculates your payments based on the new schedule. When an installment date changes, the total dues of the affected installments are recalculated as follows: * **If the instalment period is longer than the standard interval:** The total amount due for that payment will be calculated as: * Total due=1 Standard PMT+(Actual interest for the instalment−Interest for 1 regular interval) * In this scenario, if the *Actual interest for the instalment* is greater than the *Interest for 1 regular interval*, the difference (a positive value) will be added to your standard payment amount (PMT). This ensures you're paying the additional interest accrued due to the longer period. * **If the installment period is shorter than the standard interval**: The total amount due for that payment will be calculated as: * Total due=Standard PMT+(Actual interest for the instalment−Interest for 1 regular interval) * Here, if the *Actual interest for the instalment* is less than the *Interest for 1 regular interval*, the difference (a negative value) will be subtracted from your standard payment amount (PMT). This reduces your payment because less interest has accrued over the shorter period. This precise calculation ensures that your payments are always accurate, reflecting the exact amount of capital and interest due for the specific period, even when your instalment dates are adjusted. The following image shows the mechanics of broken interest when installment due dates are edited for dynamic mortgages: ![broken interest installment due dates edited](/img/support/broken-interest-installment-due-dates-edited.png) **Interest only equal installments** If you need to change an installment date for a mortgage during its term, you'll need to edit the existing payment schedule. This means you'll have to individually update the due date for each specific installment that you want to change. For interest-only loans, the system is designed to automatically account for any installment date changes that occur part-way through the loan term. When this happens, a special *broken interest* calculation will be applied to ensure the correct interest is charged for the modified period. Broken interest typically works in the following way, depending on whether your installment period is longer or shorter than the usual interval: * **If the installment period is longer than the standard interval (e.g., more than a month between payments)**: The *total due* for that specific installment will be calculated as: * Total due = 1 month Instalment PMT + Interest accrued up to the new due date. * This means the borrower will pay their usual monthly installment amount, plus any additional interest that has built up because the payment is being made later than usual. * **If the installment period is shorter than the standard interval (e.g., less than a month between payments)**: The *total due* for that specific installment will be calculated as: * Total Due = Interest accrued for the number of days in the interval. * In this scenario, the borrower will only pay the interest that has accumulated for the actual number of days in that shorter period, as they are making a payment earlier than the full interval. * This broken interest calculation ensures that you are always charged the correct amount of interest even when payment dates are adjusted. The following image shows the mechanics of broken interest when installment due dates are edited for equal interest on loans: ![broken interest edited installment dates](/img/support/broken-interest-edited-installment-dates.png) --- # Initial setup URL: https://docs.mambu.com/docs/initial-setup/ As a new Mambu customer, our onboarding team will guide you through our onboarding process and answer any questions you may have. In a series of onboarding sessions, we will walk you through the core functionality in the Mambu UI and we will help you configure your initial setup so your organization can get up and running as fast as possible. Once the onboarding process is complete, we will inform you about all available Mambu Support resources for any further help you may need. For more information, see [Mambu Support](/docs/mambu-support). ## Customer Service Portal The Customer Service Portal provides access to your tenant information. During the onboarding process your team will have access to users with the *onboarding* user type. Once onboarding is complete, the onboarding users will be replaced by users with more wide-ranging access to the Customer Service Portal. For more information about Customer Service Portal and its user types, see [Customer Service Portal](/docs/customer-service-portal). ### Tenant provisioning We will provision you with your production tenant and your sandbox tenants, which can be accessed via the Mambu UI or via API. * **Production**: `https://TENANT_NAME.mambu.com` * **Sandbox**: `https://TENANT_NAME.sandbox.mambu.com` Your tenant name will be available in the Customer Service Portal. For more information about your production and sandbox tenants and their differences, see [User Guide - Sandbox](/docs/sandbox) and [API v2 Reference - Sandbox](/api/pages/api-v2/sandbox). ## Setting up Mambu Below is a non-exhaustive list of some steps in the setup process: * Setting up administration settings including your [organization details](/docs/organization-contact-currency-and-timezone), [branches](/docs/branches-and-centres), [holidays](/docs/holidays-and-non-working-days), and [user roles](/docs/roles). * Customizing Mambu by [setting up custom field definitions](/docs/custom-fields) for various intake forms. * Creating your initial [client types](/docs/client-types) and creating [clients](/docs/create-an-individual-client) and [groups](/docs/creating-a-group) based on those types. * Setting up your financial settings including, [transaction channels](/docs/transaction-channels), [currencies](/docs/currencies), and [index interest rates and tax rates](/docs/customizing-index-rates). * Setting up your [loan products](/docs/setting-up-new-loan-products). This includes covering all the different loan product types and settings related to penalties, fees, and interest. * Setting up your [deposit products](/docs/setting-up-new-deposit-products). This includes covering all the deposit product types and topics such as the different [interest calculation methods](/docs/interest-calculation-methods-in-deposit-accounts) available. * Configuring your [accounting settings](/docs/accounting-setup). * Creating your [Chart of Accounts](/docs/creating-your-chart-of-accounts/). ## Data migration You can migrate data from legacy systems into Mambu using either the Mambu APIs or by submitting your data in an Excel spreadsheet, using our provided template. For more information, see [Data Management Overview](/docs/data-migration-overview). --- # Connecting Third Party Tools URL: https://docs.mambu.com/docs/insights-connecting-third-party-tools/ Mambu Insights is designed for seamless integration with your existing data ecosystem. Data is made available through standard object storage, allowing you to connect a wide variety of data platforms and business intelligence (BI) tools. :::info Mambu Insights does not provide direct access to data via a Relational Database Management System (RDBMS). All access is through the object storage layer. ::: ## S3 direct access The most direct way to connect to your Mambu Data Lake is via an S3 [PrivateLink](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-example-privatelink.html). This method allows your data engineers and data scientists to directly access the Parquet files that make up the Gold Standard data products. You can use this access to load data into any S3-compatible system or process it using custom scripts and applications. ## Snowflake integration You can easily integrate your Mambu Data Lake with [Snowflake](https://www.snowflake.com/en/). By configuring an external stage in Snowflake that points to the provided S3 bucket, you can query the data directly using Snowflake's SQL interface or load it into Snowflake tables for enhanced performance. This allows you to combine your Mambu data with other data sources within your Snowflake environment. ## Databricks integration Mambu Insights supports direct integration with [Databricks](https://www.databricks.com/). You can mount the S3 bucket in your Databricks workspace to work with the data using notebooks, run complex analytics, and build machine learning models with Spark. The Delta Lake format used in Mambu Insights is native to Databricks, ensuring optimal performance and reliability. --- # Insights Data Catalog URL: https://docs.mambu.com/docs/insights-data-catalog/ The Insights data catalog provides an overview of the available Gold Standard data products. These datasets are modeled, versioned, and aligned with Mambu's APIs to provide a stable and reliable view of your core banking entities. There can be minor differences in the availability of the fields in Mambu Insights and fields in the API V2, and this page specifies cases where a field is not available in Mambu Insights. ## Activity The `Activity` entity is designed to track and record various actions and events that occur within the system to provide operational insights. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **encodedKey** | Available | `ACTIVITY.ENCODEDKEY` | Primary key (UUID) | | **transactionID** | Available | `ACTIVITY.TRANSACTIONID` | Unique transaction identifier (bigint) | | **timestamp** | Available | `ACTIVITY.TIMESTAMP` | When activity occurred (UTC datetime) | | **type** | Available | `ACTIVITY.TYPE` | ActivityType enum (e.g., TASK\_DELETED, CLIENT\_CREATED) | | **notes** | Available | `ACTIVITY.NOTES` | Activity description/notes (varchar(256)) | | **userKey** | Available | `ACTIVITY.USERKEY` | User who performed the activity (FK to User) | | **assignedUserKey** | Available | `ACTIVITY.ASSIGNEDUSERKEY` | User assigned to be notified (FK to User) | | **branchKey** | Available | `ACTIVITY.BRANCHKEY` | Branch reference (FK to Branch, nullable) | | **clientKey** | Available | `ACTIVITY.CLIENTKEY` | Client reference (FK to Client, nullable) | | **groupKey** | Available | `ACTIVITY.GROUPKEY` | Group reference (FK to Group, nullable) | | **centreKey** | Available | `ACTIVITY.CENTREKEY` | Centre reference (FK to Centre, nullable) | | **loanAccountKey** | Available | `ACTIVITY.LOANACCOUNTKEY` | Loan account reference (FK to LoanAccount, nullable) | | **loanProductKey** | Available | `ACTIVITY.LOANPRODUCTKEY` | Loan product reference (FK to LoanProduct, nullable) | | **savingsAccountKey** | Available | `ACTIVITY.SAVINGSACCOUNTKEY` | Savings account reference (FK to SavingsAccount, nullable) | | **savingsProductKey** | Available | `ACTIVITY.SAVINGSPRODUCTKEY` | Savings product reference (FK to SavingsProduct, nullable) | | **lineOfCreditKey** | Available | `ACTIVITY.LINEOFCREDITKEY` | Line of credit reference (FK to LineOfCredit, nullable) | | **taskKey** | Available | `ACTIVITY.TASKKEY` | Task reference (FK to Task, nullable) | | **glAccountKey** | Available | `ACTIVITY.GLACCOUNTKEY` | GL account reference (FK to GLAccount, nullable) | | **glAccountsClosureKey** | Available | `ACTIVITY.GLACCOUNTSCLOSUREKEY` | GL accounts closure reference (FK to GLAccountsClosure, nullable) | | **assignedCentreKey** | Available | `ACTIVITY.ASSIGNEDCENTREKEY` | Assigned centre reference (FK to Centre, nullable) | | **entityKey** | Available | `ACTIVITY.ENTITYKEY` | Generic entity key (varchar(32), nullable) | | **entityType** | Available | `ACTIVITY.ENTITYTYPE` | Type of entity (e.g., LOAN\_TRANSACTION, SAVINGS\_TRANSACTION, GL\_JOURNAL\_ENTRY, nullable) | | **parentKey** | Available | `ACTIVITY.PARENT_KEY` | Parent activity reference for sub-activities (self-referencing FK, nullable) | | **fieldChangeName** | Available | `ACTIVITY.FIELDCHANGENAME` | Field change name for sub-activities (nullable) | | **fieldChanges\[\]** | Available | `FIELDCHANGEITEM` table | Array of field change objects (1:N) | | └─ id | Available | `FIELDCHANGEITEM.ID` | Field change identifier (bigint) | | └─ fieldChangeName | Available | `FIELDCHANGEITEM.FIELDCHANGENAME` | Name of the changed field (varchar(256)) | | └─ fieldDetailName | Available | `FIELDCHANGEITEM.FIELDDETAILNAME` | Optional detailed name (e.g., custom field name, nullable) | | └─ fieldDetailKey | Available | `FIELDCHANGEITEM.FIELDDETAILKEY` | Optional detailed key (e.g., custom field key, nullable) | | └─ originalValue | Available | `FIELDCHANGEITEM.ORIGINALVALUE` | Original value before change (mediumtext, nullable) | | └─ newValue | Available | `FIELDCHANGEITEM.NEWVALUE` | New value after change (mediumtext, nullable) | ## Branch The `Branch` Gold data product provides organizational branch information with associated addresses and holiday calendars. This is a master data entity used throughout Mambu for organizational structure and geographical hierarchy. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **encodedKey** | Available | `BRANCH.ENCODEDKEY` | Primary key (UUID) | | **id** | Available | `BRANCH.ID` | Business identifier, unique, user-defined | | **name** | Available | `BRANCH.NAME` | Branch display name | | **creationDate** | Available | `BRANCH.CREATIONDATE` | Stored as UTC timestamp | | **lastModifiedDate** | Available | `BRANCH.LASTMODIFIEDDATE` | Stored as UTC timestamp | | **emailAddress** | Available | `BRANCH.EMAILADDRESS` | Contact email | | **phoneNumber** | Available | `BRANCH.PHONENUMBER` | Contact phone | | **notes** | Available | `BRANCH.NOTES` | Long text description | | **state** | Available | `BRANCH.STATE` | ACTIVE, INACTIVE, or DELETED | | **addresses\[\]** | Available | `ADDRESS` table | Array of address objects (1:N) | | └─ encodedKey | Available | `ADDRESS.ENCODEDKEY` | Address identifier | | └─ parentKey | Available | `ADDRESS.PARENTKEY` | FK back to BRANCH | | └─ line1 | Available | `ADDRESS.LINE1` | Street address line 1 | | └─ line2 | Available | `ADDRESS.LINE2` | Street address line 2 | | └─ city | Available | `ADDRESS.CITY` | City name | | └─ region | Available | `ADDRESS.REGION` | State/province/region | | └─ postcode | Available | `ADDRESS.POSTCODE` | Postal/ZIP code | | └─ country | Available | `ADDRESS.COUNTRY` | Country name | | └─ indexInList | Available | `ADDRESS.INDEXINLIST` | Ordering in address list | | └─ latitude | Available | `ADDRESS.LATITUDE` | GPS latitude (DDD.dddd, \-90 to \+90) | | └─ longitude | Available | `ADDRESS.LONGITUDE` | GPS longitude (DDD.dddd, \-180 to \+180) | | **branchHolidays\[\]** | Available | `HOLIDAY` table | Array of holiday objects (1:N) | | └─ encodedKey | Available | `HOLIDAY.ENCODEDKEY` | Holiday identifier | | └─ id | Available | `HOLIDAY.KEYID` | Numeric ID | | └─ name | Available | `HOLIDAY.NAME` | Holiday name | | └─ date | Available | Constructed from YEAR/MONTH/DAY | ISO date format (YYYY-MM-DD) | | └─ isAnnuallyRecurring | Available | `HOLIDAY.ISANNUALYRECURRING` | TRUE if holiday repeats yearly | | └─ creationDate | Available | `HOLIDAY.CREATIONDATE` | When holiday was created | ## Client The `Client` Gold data product provides comprehensive client/customer information including personal details, contact information, addresses, identification documents, group memberships, and custom fields. This is a core master data entity representing individual customers who use the banking services. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **encodedKey** | Available | `CLIENT.ENCODEDKEY` | Primary key (UUID, auto-generated) | | **id** | Available | `CLIENT.ID` | Business identifier, unique, user-defined | | **firstName** | Available | `CLIENT.FIRSTNAME` | Required field | | **lastName** | Available | `CLIENT.LASTNAME` | Required field | | **middleName** | Available | `CLIENT.MIDDLENAME` | Optional middle name | | **creationDate** | Available | `CLIENT.CREATIONDATE` | Stored as UTC timestamp | | **lastModifiedDate** | Available | `CLIENT.LASTMODIFIEDDATE` | Stored as UTC timestamp | | **activationDate** | Available | `CLIENT.ACTIVATIONDATE` | When client was first set to ACTIVE | | **approvedDate** | Available | `CLIENT.APPROVEDDATE` | When client was approved | | **closedDate** | Available | `CLIENT.CLOSEDDATE` | When client was closed/exited/blacklisted | | **birthDate** | Available | `CLIENT.BIRTHDATE` | Stored as Organization Time (no timezone) | | **gender** | Available | `CLIENT.GENDER` | MALE, FEMALE, or NULL | | **state** | Available | `CLIENT.STATE` | PENDING\_APPROVAL, ACTIVE, INACTIVE, EXITED, REJECTED, WITHDRAWN, BLACKLISTED | | **emailAddress** | Available | `CLIENT.EMAILADDRESS` | Primary email | | **homePhone** | Available | `CLIENT.HOMEPHONE` | Home telephone number | | **mobilePhone** | Available | `CLIENT.MOBILEPHONE1` | Primary mobile number | | **mobilePhone2** | Available | `CLIENT.MOBILEPHONE2` | Secondary mobile number | | **notes** | Available | `CLIENT.NOTES` | Long text field (LONGVARCHAR, lazy-loaded) | | **assignedBranchKey** | Available | `CLIENT.ASSIGNEDBRANCHKEY` | FK to BRANCH table | | **assignedCentreKey** | Available | `CLIENT.ASSIGNEDCENTREKEY` | FK to CENTRE table (optional) | | **assignedUserKey** | Available | `CLIENT.ASSIGNEDUSERKEY` | FK to USER table (loan officer) | | **clientRoleKey** | Available | `CLIENT.CLIENTROLEKEY` | FK to CLIENTROLE table | | **profilePictureKey** | Available | `CLIENT.PROFILEPICTUREKEY` | FK to IMAGE table | | **profileSignatureKey** | Available | `CLIENT.PROFILESIGNATUREKEY` | FK to IMAGE table | | **preferredLanguage** | Available | `CLIENT.PREFERREDLANGUAGE` | ISO 639-1 language code | | **loanCycle** | Available | `CLIENT.LOANCYCLE` | Number of loans completed | | **groupLoanCycle** | Available | `CLIENT.GROUPLOANCYCLE` | Number of group loans completed | | **migrationEventKey** | Available | `CLIENT.MIGRATIONEVENTKEY` | FK to data migration event | | **addresses\[\]** | Available | `ADDRESS` table | Array of addresses (1:N), filtered by PARENTKEY | | **idDocuments\[\]** | Available | `IDENTIFICATIONDOCUMENT` table | Array of identification documents (1:N) | | **groupKeys\[\]** | Available | `GROUPMEMBER` table | Array of group encoded keys (client memberships) | | **customFields** | Available | `CUSTOMFIELDVALUE` table | Map of custom field sets to field values | | **portalSettings** | Not available | `PORTALPREFERENCES` table | Portal preferences (@NotPersistent, separate table) | | **idDocuments\[\].attachments\[\]** | Not available | `ATTACHMENT` table | Document attachments (requires ATTACHMENT join) | | **numCenters** | Not available | `@NotPersistent` | Runtime-calculated count | ## Credit Arrangements The `CreditArrangement` Gold data product provides a comprehensive line of credit information including credit limits, available credit calculations, consumed credit amounts, holder information, and custom fields. This is a core credit management entity representing credit facilities that can be shared across multiple loan and savings accounts. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **encodedKey** | Available | `LINEOFCREDIT.ENCODEDKEY` | Primary key (UUID) | | **id** | Available | `LINEOFCREDIT.ID` | Business identifier, unique, user-defined | | **amount** | Available | `LINEOFCREDIT.AMOUNT` | Total credit limit amount (Decimal(38,18)) | | **state** | Available | `LINEOFCREDIT.STATE` | Credit arrangement state (e.g., PENDING\_APPROVAL, APPROVED, ACTIVE, CLOSED) | | **subState** | Available | `LINEOFCREDIT.SUBSTATE` | Sub-state for additional state classification (nullable) | | **exposureLimitType** | Available | `LINEOFCREDIT.EXPOSURELIMITTYPE` | Type of exposure limit (APPROVED\_AMOUNT or other) | | **notes** | Available | `LINEOFCREDIT.NOTES` | Credit arrangement notes (varchar, nullable) | | **creationDate** | Available | `LINEOFCREDIT.CREATIONDATE` | When credit arrangement was created (UTC timestamp) | | **lastModifiedDate** | Available | `LINEOFCREDIT.LASTMODIFIEDDATE` | Last modification timestamp (UTC, nullable) | | **approvedDate** | Available | `LINEOFCREDIT.APPROVEDDATE` | When credit arrangement was approved (UTC timestamp, nullable) | | **closedDate** | Available | `LINEOFCREDIT.CLOSEDDATE` | When credit arrangement was closed (UTC timestamp, nullable) | | **startDate** | Available | `LINEOFCREDIT.STARTDATE` | Credit arrangement start date (UTC timestamp) | | **expireDate** | Available | `LINEOFCREDIT.EXPIREDATE` | Credit arrangement expiry date (UTC timestamp, nullable) | | **currency** | Available | `LINEOFCREDIT` table | Struct containing currency information | | └─ currencyCode | Available | `LINEOFCREDIT.CURRENCYCODE` | ISO currency code (nullable) | | **availableCreditAmount** | Available | Calculated | Available credit \= amount \- consumed (calculated from savings/loan accounts) | | **consumedCreditAmount** | Available | Calculated | Consumed credit \= amount \- availableCreditAmount | | **holderKey** | Available | `LOANACCOUNT.ACCOUNTHOLDERKEY` | Account holder key (from first loan account, nullable) | | **holderType** | Available | `LOANACCOUNT.ACCOUNTHOLDERTYPE` | Account holder type CLIENT or GROUP (from first loan account, nullable) | | **customFields\[\]** | Available | `CUSTOMFIELD` \+ `CUSTOMFIELDVALUE` tables | Array of custom field objects (1:N) | | └─ fieldKey | Available | `CUSTOMFIELD.ENCODEDKEY` | Custom field identifier | | └─ fieldName | Available | `CUSTOMFIELD.NAME` | Custom field name | | └─ fieldValue | Available | `CUSTOMFIELDVALUE.VALUE` | Custom field value | ## Deposit Account The `DepositAccount` Gold data product provides comprehensive deposit/savings account information including account details, balances, interest settings, overdraft settings, and custom fields. This is a core transactional entity representing customer deposit accounts in the Mambu banking system. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **encodedKey** | Available | `SAVINGSACCOUNT.ENCODEDKEY` | Primary key (UUID) | | **id** | Available | `SAVINGSACCOUNT.ID` | Business identifier, unique, user-defined | | **name** | Available | `SAVINGSACCOUNT.NAME` | Account display name | | **accountHolderKey** | Available | `SAVINGSACCOUNT.ACCOUNTHOLDERKEY` | FK to account holder (Client/Group) | | **accountHolderType** | Available | `SAVINGSACCOUNT.ACCOUNTHOLDERTYPE` | CLIENT or GROUP | | **accountState** | Available | `SAVINGSACCOUNT.ACCOUNTSTATE` | PENDING\_APPROVAL, APPROVED, ACTIVE, ACTIVE\_IN\_ARREARS, CLOSED, etc. | | **balance** | Available | `SAVINGSACCOUNT.BALANCE` | Current account balance (Decimal(38,18)) | | **currencyCode** | Available | `SAVINGSACCOUNT.CURRENCYCODE` | ISO currency code | | **productTypeKey** | Available | `SAVINGSACCOUNT.PRODUCTTYPEKEY` | FK to SavingsProduct | | **creditArrangementKey** | Available | `SAVINGSACCOUNT.LINEOFCREDITKEY` | FK to LineOfCredit (optional) | | **assignedBranchKey** | Available | `SAVINGSACCOUNT.ASSIGNEDBRANCHKEY` | FK to Branch (optional) | | **assignedCentreKey** | Available | `SAVINGSACCOUNT.ASSIGNEDCENTREKEY` | FK to Centre (optional) | | **assignedUserKey** | Available | `SAVINGSACCOUNT.ASSIGNEDUSERKEY` | FK to User (optional) | | **withholdingTaxSourceKey** | Available | `SAVINGSACCOUNT.WITHHOLDINGTAXSOURCEKEY` | FK to IndexRateSource (optional) | | **migrationEventKey** | Available | `SAVINGSACCOUNT.MIGRATIONEVENTKEY` | FK to data migration event (optional) | | **notes** | Available | `SAVINGSACCOUNT.NOTES` | Account notes (varchar) | | **creationDate** | Available | `SAVINGSACCOUNT.CREATIONDATE` | When account was created (UTC timestamp) | | **lastModifiedDate** | Available | `SAVINGSACCOUNT.LASTMODIFIEDDATE` | Last modification timestamp (UTC) | | **activationDate** | Available | `SAVINGSACCOUNT.ACTIVATIONDATE` | When account was activated (UTC timestamp, nullable) | | **approvedDate** | Available | `SAVINGSACCOUNT.APPROVEDDATE` | When account was approved (UTC timestamp, nullable) | | **closedDate** | Available | `SAVINGSACCOUNT.CLOSEDDATE` | When account was closed (UTC timestamp, nullable) | | **lockedDate** | Available | `SAVINGSACCOUNT.LOCKEDDATE` | When account was locked (UTC timestamp, nullable) | | **maturityDate** | Available | `SAVINGSACCOUNT.MATURITYDATE` | Account maturity date (UTC timestamp, nullable) | | **lastAccountAppraisalDate** | Available | `SAVINGSACCOUNT.LASTACCOUNTAPPRAISALDATE` | Last appraisal date (UTC timestamp, nullable) | | **lastInterestCalculationDate** | Available | `SAVINGSACCOUNT.LASTINTERESTCALCULATIONDATE` | Last interest calculation (UTC timestamp, nullable) | | **lastInterestStoredDate** | Available | `SAVINGSACCOUNT.LASTINTERESTSTOREDDATE` | Last interest storage date (UTC timestamp, nullable) | | **lastInterestReviewDate** | Available | `SAVINGSACCOUNT.LASTINTERESTREVIEWDATE` | Last interest review date (UTC timestamp, nullable) | | **lastOverdraftInterestReviewDate** | Available | `SAVINGSACCOUNT.LASTOVERDRAFTINTERESTREVIEWDATE` | Last overdraft interest review (UTC timestamp, nullable) | | **lastSetToArrearsDate** | Available | `SAVINGSACCOUNT.LASTSETTOARREARSDATE` | Last time account was set to arrears (UTC timestamp, nullable) | | **accruedAmounts** | Available | `SAVINGSACCOUNT` table | Struct containing accrued interest amounts | | └─ interestAccrued | Available | `SAVINGSACCOUNT.ACCRUEDINTEREST` | Accrued interest amount | | └─ negativeInterestAccrued | Available | `SAVINGSACCOUNT.NEGATIVEINTERESTACCRUED` | Negative interest accrued | | └─ overdraftInterestAccrued | Available | `SAVINGSACCOUNT.OVERDRAFTINTERESTACCRUED` | Overdraft interest accrued | | └─ technicalOverdraftInterestAccrued | Available | `SAVINGSACCOUNT.TECHNICALOVERDRAFTINTERESTACCRUED` | Technical overdraft interest accrued | | **balances** | Available | `SAVINGSACCOUNT` table | Struct containing all balance components | | └─ availableBalance | Available | `SAVINGSACCOUNT.BALANCE` | Available balance (same as balance) | | └─ blockedBalance | Available | `SAVINGSACCOUNT.BLOCKEDBALANCE` | Blocked balance amount | | └─ feesDue | Available | `SAVINGSACCOUNT.FEESDUE` | Fees due amount | | └─ forwardAvailableBalance | Available | `SAVINGSACCOUNT.FORWARDAVAILABLEBALANCE` | Forward available balance | | └─ holdBalance | Available | `SAVINGSACCOUNT.HOLDBALANCE` | Hold balance amount | | └─ lockedBalance | Available | `SAVINGSACCOUNT.LOCKEDBALANCE` | Locked balance amount | | └─ overdraftAmount | Available | `SAVINGSACCOUNT.OVERDRAFTAMOUNT` | Overdraft amount | | └─ overdraftInterestDue | Available | `SAVINGSACCOUNT.TECHNICALINTERESTDUE` | Overdraft interest due | | └─ technicalOverdraftAmount | Available | `SAVINGSACCOUNT.TECHNICALOVERDRAFTAMOUNT` | Technical overdraft amount | | └─ technicalOverdraftInterestDue | Available | `SAVINGSACCOUNT.TECHNICALINTERESTDUE` | Technical overdraft interest due | | └─ totalBalance | Available | `SAVINGSACCOUNT.BALANCE` | Total balance (same as balance) | | **interestSettings** | Available | `SAVINGSACCOUNT` table | Struct containing interest payment settings | | └─ interestPaymentSettings | Available | `SAVINGSACCOUNT` table | Nested struct for payment settings | | └─ └─ interestPaymentDates | Available | `SAVINGSACCOUNT.INTERESTPAYMENTDATES` | Binary field for payment dates | | └─ interestPaymentPoint | Available | `SAVINGSACCOUNT.INTERESTPAYMENTPOINT` | Interest payment point | | **interestRateSettings** | Available | `INTERESTACCOUNTSETTINGS` \+ `INTERESTBASESETTINGS` | Struct from joined tables | | └─ encodedKey | Available | `INTERESTACCOUNTSETTINGS.ENCODEDKEY` | Interest settings identifier | | └─ interestChargeFrequency | Available | `INTERESTBASESETTINGS.INTERESTCHARGEFREQUENCY` | Charge frequency (e.g., MONTHLY) | | └─ interestChargeFrequencyCount | Available | `INTERESTBASESETTINGS.INTERESTCHARGEFREQUENCYCOUNT` | Frequency count | | └─ interestRate | Available | `INTERESTACCOUNTSETTINGS.INTERESTRATE` | Interest rate (Decimal(38,18)) | | └─ interestRateReviewCount | Available | `INTERESTBASESETTINGS.INTERESTRATEREVIEWCOUNT` | Review count | | └─ interestRateSource | Available | `INTERESTBASESETTINGS.INTERESTRATESOURCE` | Rate source | | └─ interestRateTerms | Available | `INTERESTBASESETTINGS.INTERESTRATETERMS` | Rate terms | | └─ interestSpread | Available | `INTERESTACCOUNTSETTINGS.INTERESTSPREAD` | Interest spread (Decimal(38,18)) | | **overdraftInterestSettings** | Available | `INTERESTACCOUNTSETTINGS` \+ `INTERESTBASESETTINGS` | Struct from joined tables (overdraft) | | └─ encodedKey | Available | `INTERESTACCOUNTSETTINGS.ENCODEDKEY` | Overdraft interest settings identifier | | └─ interestChargeFrequency | Available | `INTERESTBASESETTINGS.INTERESTCHARGEFREQUENCY` | Charge frequency | | └─ interestChargeFrequencyCount | Available | `INTERESTBASESETTINGS.INTERESTCHARGEFREQUENCYCOUNT` | Frequency count | | └─ interestRate | Available | `INTERESTACCOUNTSETTINGS.INTERESTRATE` | Overdraft interest rate | | └─ interestRateReviewCount | Available | `INTERESTBASESETTINGS.INTERESTRATEREVIEWCOUNT` | Review count | | └─ interestRateSource | Available | `INTERESTBASESETTINGS.INTERESTRATESOURCE` | Rate source | | └─ interestRateTerms | Available | `INTERESTBASESETTINGS.INTERESTRATETERMS` | Rate terms | | └─ interestSpread | Available | `INTERESTACCOUNTSETTINGS.INTERESTSPREAD` | Interest spread | | **overdraftSettings** | Available | `SAVINGSACCOUNT` table | Struct containing overdraft configuration | | └─ allowOverdraft | Available | `SAVINGSACCOUNT.ALLOWOVERDRAFT` | Boolean flag for overdraft allowance | | └─ overdraftExpiryDate | Available | `SAVINGSACCOUNT.OVERDRAFTEXPIRYDATE` | Overdraft expiry date (UTC timestamp, nullable) | | └─ overdraftLimit | Available | `SAVINGSACCOUNT.OVERDRAFTLIMIT` | Overdraft limit amount (Decimal(38,18)) | | **internalControls** | Available | `SAVINGSACCOUNT` table | Struct containing internal control limits | | └─ maxdepositbalance | Available | `SAVINGSACCOUNT.MAXDEPOSITBALANCE` | Maximum deposit balance (Decimal(38,18), nullable) | | └─ maxwithdrawalamount | Available | `SAVINGSACCOUNT.MAXWIDTHDRAWLAMOUNT` | Maximum withdrawal amount (Decimal(38,18), nullable) | | └─ recommendedDepositAmount | Available | `SAVINGSACCOUNT.RECOMMENDEDDEPOSITAMOUNT` | Recommended deposit amount (Decimal(38,18), nullable) | | └─ targetAmount | Available | `SAVINGSACCOUNT.TARGETAMOUNT` | Target amount (Decimal(38,18), nullable) | | **customFields\[\]** | Available | `CUSTOMFIELD` \+ `CUSTOMFIELDVALUE` tables | Array of custom field objects (1:N) | | └─ fieldKey | Available | `CUSTOMFIELD.ENCODEDKEY` | Custom field identifier | | └─ fieldName | Available | `CUSTOMFIELD.NAME` | Custom field name | | └─ fieldValue | Available | `CUSTOMFIELDVALUE.VALUE` | Custom field value | ## Deposit Products The `DepositProduct` Gold data product provides comprehensive deposit product information with nested structures for accounting settings, availability settings, currency settings, fees settings, interest settings, overdraft settings, and more. | API Field | Status | Source Table | Source Column | Notes | | :---- | :---- | :---- | :---- | :---- | | **Top-Level Fields** | | | | | | `customFields` | Available| `CUSTOMFIELD` \+ `CUSTOMFIELDVALUE` | Aggregated from `SAVINGS_PRODUCT_INFO` type custom fields | Array of structs with `fieldKey`, `fieldName`, `fieldValue` | | `encodedKey` | Available| `SAVINGSPRODUCT` | `ENCODEDKEY` | Primary key | | `id` | Available| `SAVINGSPRODUCT` | `ID` | Product identifier | | `name` | Available| `SAVINGSPRODUCT` | `NAME` | Product name | | `creationDate` | Available| `SAVINGSPRODUCT` | `CREATIONDATE` | Product creation timestamp | | `lastModifiedDate` | Available| `SAVINGSPRODUCT` | `LASTMODIFIEDDATE` | Last modification timestamp | | `notes` | Available| `SAVINGSPRODUCT` | `DESCRIPTION` | Product description/notes | | `type` | Available| `SAVINGSPRODUCT` | `PRODUCTTYPE` | Product type enum | | `category` | Available| `SAVINGSPRODUCT` | `CATEGORY` | Product category | | `state` | Available| `SAVINGSPRODUCT` | `ACTIVATED` | Transformed: `1` → `ACTIVE`, `0` → `INACTIVE` | | **Accounting Settings** | | | | | | `accountingSettings.accountingMethod` | Available| `SAVINGSPRODUCT` | `ACCOUNTINGMETHOD` | Accounting method enum | | `accountingSettings.interestAccrualCalculation` | Available| `SAVINGSPRODUCT` | `INTERESTACCRUALCALCULATION` | Interest accrual calculation method | | `accountingSettings.interestAccruedAccountingMethod` | Available| `SAVINGSPRODUCT` | `INTERESTACCRUEDACCOUNTINGMETHOD` | Interest accrued accounting method | | `accountingSettings.accountingRules` | Available| `GLACCOUNTINGRULE` | Aggregated by `PRODUCTKEY` | Array of structs with all GL accounting rule fields | | **Availability Settings** | | | | | | `availabilitySettings.availableFor` | Available| `SAVINGSPRODUCT` | `FORINDIVIDUALS`, `FORGROUPS` | Array: `1` → `INDIVIDUALS`/`GROUPS` | | `availabilitySettings.branchSettings.forAllBranches` | Available| `SAVINGSPRODUCT` | `FORALLBRANCHES` | Boolean flag | | `availabilitySettings.branchSettings.availableProductBranches` | Available| `SAVINGSPRODUCTBRANCH` | Aggregated `BRANCHKEY` by `PRODUCTKEY` | Array of branch keys | | **Currency Settings** | | | | | | `currencySettings.currencies` | Available| `CURRENCYMAPPING` \+ `CURRENCY` | Aggregated by `PARENTKEY` | Array of currency structs (joined `CURRENCYMAPPING` to `CURRENCY` on `CURRENCYCODE == CODE`) | | **Fees Settings** | | | | | | `feesSettings.allowArbitraryFees` | Available| `SAVINGSPRODUCT` | `ALLOWARBITRARYFEES` | Boolean flag | | `feesSettings.fees` | Available| `SAVINGSPREDEFINEDFEE` \+ `SAVINGSPREDEFINEDFEEAMOUNT` \+ `PREDEFINEDFEE` | Aggregated by `SAVINGSPRODUCT_ENCODEDKEY` | Array of fee structs with all fee-related fields | | **Interest Settings** | | | | | | `interestSettings.collectInterestWhenLocked` | Available| `SAVINGSPRODUCT` | `COLLECTINTERESTWHENLOCKED` | Boolean flag | | `interestSettings.daysInYear` | Available| `SAVINGSPRODUCT` | `INTERESTDAYSINYEAR` | Days in year method enum | | `interestSettings.interestCalculationBalance` | Available| `SAVINGSPRODUCT` | `INTERESTCALCULATIONBALANCE` | Interest calculation balance enum | | `interestSettings.interestGainsProvidedStartDate` | Available| `SAVINGSPRODUCT` | `INTERESTSETEXTERNALLYSTARTDATE` | Date field | | `interestSettings.interestGainsProvidedEndDate` | Available| `SAVINGSPRODUCT` | `INTERESTSETEXTERNALLYENDDATE` | Date field | | `interestSettings.interestPaidIntoAccount` | Available| `SAVINGSPRODUCT` | `INTERESTPAIDINTOACCOUNT` | Boolean flag | | `interestSettings.interestPaymentSettings.interestPaymentDates` | Available| `SAVINGSPRODUCT` | `INTERESTPAYMENTDATES` | Array of dates | | `interestSettings.interestPaymentSettings.interestPaymentPoint` | Available| `SAVINGSPRODUCT` | `INTERESTPAYMENTPOINT` | Payment point enum | | `interestSettings.interestRateSettings` | Available| `INTERESTPRODUCTSETTINGS` \+ `INTERESTBASESETTINGS` \+ `INDEXRATESOURCE` \+ `INDEXRATE` \+ `INTERESTRATETIER` | Complex aggregation | Array of structs with interest rate settings, index rates, and tiers | | `interestSettings.maximumBalance` | Available| `SAVINGSPRODUCT` | `MAXIMUMBALANCE` | Decimal field | | **Internal Controls** | | | | | | `internalControls.dormancyPeriodDays` | Available| `SAVINGSPRODUCT` | `DORMANCYPERIODDAYS` | Integer field | | `internalControls.maxWithdrawalAmount` | Available| `SAVINGSPRODUCT` | `MAXWIDTHDRAWLAMOUNT` | Decimal field | | `internalControls.openingBalance.defaultValue` | Available| `SAVINGSPRODUCT` | `DEFAULTOPENINGBALANCE` | Decimal field | | `internalControls.openingBalance.maxValue` | Available| `SAVINGSPRODUCT` | `MAXOPENINGBALANCE` | Decimal field | | `internalControls.openingBalance.minValue` | Available| `SAVINGSPRODUCT` | `MINOPENINGBALANCE` | Decimal field | | `internalControls.recommendedDepositAmount` | Available| `SAVINGSPRODUCT` | `RECOMMENDEDDEPOSITAMOUNT` | Decimal field | | **Maturity Settings** | | | | | | `maturitySettings.maturityPeriod.defaultValue` | Available| `SAVINGSPRODUCT` | `DEFAULTMATURITYPERIOD` | Integer field | | `maturitySettings.maturityPeriod.maxValue` | Available| `SAVINGSPRODUCT` | `MAXMATURITYPERIOD` | Integer field | | `maturitySettings.maturityPeriod.minValue` | Available| `SAVINGSPRODUCT` | `MINMATURITYPERIOD` | Integer field | | `maturitySettings.maturityPeriodUnit` | Available| `SAVINGSPRODUCT` | `MATURITYPERIODUNIT` | Maturity period unit enum | | **New Account Settings** | | | | | | `newAccountSettings.idGeneratorType` | Available| `SAVINGSPRODUCT` | `IDGENERATORTYPE` | ID generator type enum | | `newAccountSettings.idPattern` | Available| `SAVINGSPRODUCT` | `IDPATTERN` | ID pattern string | | **Offset Settings** | | | | | | `offsetSettings.allowOffset` | Available| `SAVINGSPRODUCT` | `ALLOWOFFSET` | Boolean flag | | **Overdraft Interest Settings** | | | | | | `overdraftInterestSettings.daysInYear` | Available| `SAVINGSPRODUCT` | `OVERDRAFTDAYSINYEAR` | Days in year method enum | | `overdraftInterestSettings.interestCalculationBalance` | Available| `SAVINGSPRODUCT` | `OVERDRAFTINTERESTCALCULATIONBALANCE` | Interest calculation balance enum | | `overdraftInterestSettings.interestRateSettings` | Available| `INTERESTPRODUCTSETTINGS` \+ `INTERESTBASESETTINGS` \+ `INDEXRATESOURCE` \+ `INDEXRATE` \+ `INTERESTRATETIER` | Complex aggregation via `OVERDRAFTINTERESTRATESETTINGSKEY` | Struct with `indexSourceKey`, `interestRate`, `interestRateSource`, `interestRateTerms`, `interestChargeFrequency`, `interestRateReviewUnit`, `interestRateTiers` | | **Overdraft Settings** | | | | | | `overdraftSettings.allowOverdraft` | Available| `SAVINGSPRODUCT` | `ALLOWOVERDRAFT` | Boolean flag | | `overdraftSettings.allowTechnicalOverdraft` | Available| `SAVINGSPRODUCT` | `ALLOWTECHNICALOVERDRAFT` | Boolean flag | | `overdraftSettings.maxOverdraftLimit` | Available| `SAVINGSPRODUCT` | `MAXOVERDRAFTLIMIT` | Decimal field | | **Tax Settings** | | | | | | `taxSettings.withholdingTaxEnabled` | Available| `SAVINGSPRODUCT` | `WITHHOLDINGTAXENABLED` | Boolean flag | | **Unmapped Fields** | | | | | | `creditArrangementSettings` | Available | `SAVINGSPRODUCT` | `LINEOFCREDITREQUIREMENT` | Field exists in source but not yet mapped in `_transform_to_json` | | `templates` | Not available | `PRODUCTTEMPLATE` or similar | Unknown | Document templates \- not currently mapped | | `technicalOverdraftInterestSettings` | Not available | N/A | N/A | Explicitly ignored in API mapper (`@Mapping(target = "technicalOverdraftInterestSettings", ignore = true)`) | ## Deposit Transaction The `DepositsTransaction` Gold data product provides comprehensive deposit transaction information with nested structures for account balances, affected amounts, fees, taxes, terms, card transactions, payment details, and transaction details. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **accountBalances** | Available | `SAVINGSTRANSACTION` | Nested struct with balance fields | | └─ totalBalance | Available | `SAVINGSTRANSACTION.BALANCE` | Total balance | | **adjustmentTransactionKey** | Available | `SAVINGSTRANSACTION.REVERSALTRANSACTIONKEY` | Key of reversal transaction | | **affectedAmounts** | Available | `SAVINGSTRANSACTION` | Nested struct with 9 amount fields | | └─ feesAmount | Available | `SAVINGSTRANSACTION.FEESAMOUNT` | Fees amount | | └─ fractionAmount | Available | `SAVINGSTRANSACTION.FRACTIONAMOUNT` | Fraction amount | | └─ fundsAmount | Available | `SAVINGSTRANSACTION.FUNDSAMOUNT` | Funds amount | | └─ interestAmount | Available | `SAVINGSTRANSACTION.INTERESTAMOUNT` | Interest amount | | └─ overdraftAmount | Available | `SAVINGSTRANSACTION.OVERDRAFTAMOUNT` | Overdraft amount | | └─ overdraftFeesAmount | Available | `SAVINGSTRANSACTION.OVERDRAFTFEESAMOUNT` | Overdraft fees amount | | └─ overdraftInterestAmount | Available | `SAVINGSTRANSACTION.OVERDRAFTINTERESTAMOUNT` | Overdraft interest amount | | └─ technicalOverdraftAmount | Available | `SAVINGSTRANSACTION.TECHNICALOVERDRAFTAMOUNT` | Technical overdraft amount | | └─ technicalOverdraftInterestAmount | Available | `SAVINGSTRANSACTION.TECHNICALOVERDRAFTINTERESTAMOUNT` | Technical overdraft interest amount | | **amount** | Available | `SAVINGSTRANSACTION.AMOUNT` | Transaction amount | | **blockId** | Not available | `BLOCKFUNDTRANSACTIONSOURCE.BLOCKFUNDKEY` → `BLOCKFUND.ENCODEDKEY` | Block fund ID (table not in Silver yet \- will be added as new field) | | **bookingDate** | Not available | `GLJOURNALENTRY.ENTRYDATE` | Date when journal entry is booked (table not in Silver yet \- will be added as new field) | | **branchKey** | Available | `SAVINGSTRANSACTION.BRANCHKEY` | Branch where transaction was performed | | **cardTransaction** | Available | `CARDTRANSACTIONSOURCE` \+ `CARDACCEPTOR` | Nested struct with card transaction details | | └─ advice | Available | `CARDTRANSACTIONSOURCE.ISADVICE` | Whether transaction is advice | | └─ amount | Available | `CARDTRANSACTIONSOURCE.AMOUNT` | Card transaction amount | | └─ cardAcceptor | Available | `CARDACCEPTOR` | Nested card acceptor details | | └─ city | Available | `CARDACCEPTOR.CITY` | City | | └─ country | Available | `CARDACCEPTOR.COUNTRY` | Country | | └─ mcc | Available | `CARDACCEPTOR.MCC` | Merchant category code | | └─ name | Available | `CARDACCEPTOR.NAME` | Merchant name | | └─ state | Available | `CARDACCEPTOR.STATE` | State | | └─ street | Available | `CARDACCEPTOR.STREET` | Street address | | └─ zip | Available | `CARDACCEPTOR.ZIP` | ZIP code | | └─ cardToken | Available | `CARDTRANSACTIONSOURCE.CARDREFERENCETOKEN` | Card reference token | | └─ currencyCode | Available | `CARDTRANSACTIONSOURCE.CURRENCYCODE` | Currency code | | └─ encodedKey | Available | `CARDTRANSACTIONSOURCE.ENCODEDKEY` | Card transaction source key | | └─ externalAuthorizationReferenceId | Available | `CARDTRANSACTIONSOURCE.EXTERNALAUTHORIZATIONREFERENCEID` | External authorization reference | | └─ externalReferenceId | Available | `CARDTRANSACTIONSOURCE.EXTERNALREFERENCEID` | External reference ID | | └─ userTransactionTime | Available | `CARDTRANSACTIONSOURCE.USERTRANSACTIONTIME` | User transaction time | | **centreKey** | Available | `SAVINGSTRANSACTION.CENTREKEY` | Centre where transaction was performed | | **creationDate** | Available | `SAVINGSTRANSACTION.CREATIONDATE` | Transaction creation date (UTC) | | **currencyCode** | Available | `SAVINGSTRANSACTION.CURRENCYCODE` | Currency code | | **encodedKey** | Available | `SAVINGSTRANSACTION.ENCODEDKEY` | Primary key (UUID) | | **externalId** | Available | `SAVINGSTRANSACTION.EXTERNALID` | External ID | | **fees** | Available | `SAVINGSPREDEFINEDFEE` \+ `SAVINGSPREDEFINEDFEEAMOUNT` \+ `PREDEFINEDFEE` | Array of fee structures | | └─ (all fee fields) | Available | Aggregated from multiple tables | Complete fee structure with amounts and predefined fee details | | **holdExternalReferenceId** | Available | `BLOCKFUND.EXTERNALREFERENCEID` | External reference ID of account authorization hold | | **id** | Available | `SAVINGSTRANSACTION.TRANSACTIONID` | Transaction ID | | **interestAccruedAmounts** | Available | `SAVINGSINTERESTTRANSACTIONAMOUNTS` | Nested struct with interest accrued amounts | | └─ interestAccrued | Available | `SAVINGSINTERESTTRANSACTIONAMOUNTS.INTERESTACCRUED` | Interest accrued | | └─ negativeInterestAccrued | Available | `SAVINGSINTERESTTRANSACTIONAMOUNTS.NEGATIVEINTERESTACCRUED` | Negative interest accrued | | └─ overdraftInterestAccrued | Available | `SAVINGSINTERESTTRANSACTIONAMOUNTS.OVERDRAFTINTERESTACCRUED` | Overdraft interest accrued | | └─ technicalOverdraftInterestAccrued | Available | `SAVINGSINTERESTTRANSACTIONAMOUNTS.TECHNICALOVERDRAFTINTERESTACCRUED` | Technical overdraft interest accrued | | **migrationEventKey** | Available | `SAVINGSTRANSACTION.MIGRATIONEVENTKEY` | Migration event key | | **notes** | Available | `SAVINGSTRANSACTION.COMMENT` | Transaction notes/comment | | **originalTransactionKey** | Not available | Service logic (OriginalTransactionApiEnhancer) | Original transaction key for reversal transactions (complex service logic \- will be added when logic can be replicated) | | **parentAccountKey** | Available | `SAVINGSTRANSACTION.PARENTACCOUNTKEY` | Parent deposit account key | | **paymentDetails** | Available | `PAYMENTDETAILS` | Nested struct with payment details (creditor, debtor, payment identification, etc.) | | └─ creditor | Available | `PAYMENTDETAILS.CREDITORNAME` | Creditor name | | └─ creditorAccount | Available | `PAYMENTDETAILS` | Creditor account details (currency, IBAN, other identification) | | └─ creditorAgent | Available | `PAYMENTDETAILS.CREDITORAGENTBIC` | Creditor agent BIC | | └─ debtor | Available | `PAYMENTDETAILS.DEBTORNAME` | Debtor name | | └─ debtorAccount | Available | `PAYMENTDETAILS` | Debtor account details (currency, IBAN, other identification) | | └─ debtorAgent | Available | `PAYMENTDETAILS.DEBTORAGENTBIC` | Debtor agent BIC | | └─ paymentIdentfication | Available | `PAYMENTDETAILS` | Payment identification (end-to-end, instruction, transaction) | | └─ paymentTypeInformation | Available | `PAYMENTDETAILS.SERVICELEVELCODE` | Payment type information (service level code) | | └─ remittanceInformation | Available | `PAYMENTDETAILS` | Remittance information (structured and unstructured) | | **paymentOrderId** | Available | `SAVINGSTRANSACTION.PAYMENTORDERID` | Payment order ID | | **taxes** | Available | `INDEXRATE` | Nested struct with tax rate | | └─ taxRate | Available | `INDEXRATE.RATE` | Tax rate (from `TAXRATE_ENCODEDKEY_OID`) | | **terms** | Available | `SAVINGSTRANSACTION` \+ `INTERESTACCOUNTSETTINGS` \+ `INDEXRATE` \+ `SAVINGSACCOUNT` | Nested struct with interest settings, overdraft settings | | └─ interestSettings | Available | Nested struct | Interest rate settings | | └─ indexInterestRate | Available | `INDEXRATE.RATE` (conditional) | Index interest rate (if transaction type is INTEREST\_RATE\_CHANGED) | | └─ interestRate | Available | `INTERESTACCOUNTSETTINGS.INTERESTRATE` | Transaction interest rate | | └─ overdraftInterestSettings | Available | Nested struct | Overdraft interest rate settings | | └─ indexInterestRate | Available | `INDEXRATE.RATE` (conditional) | Index interest rate (if transaction type is NOT INTEREST\_RATE\_CHANGED) | | └─ interestRate | Available | `INDEXRATE.RATE` (from `OVERDRAFT_INDEXRATE_KEY`) | Overdraft interest rate | | └─ overdraftSettings | Available | Nested struct | Overdraft settings | | └─ overdraftLimit | Available | `SAVINGSACCOUNT.OVERDRAFTLIMIT` | Overdraft limit | | **tillKey** | Available | `SAVINGSTRANSACTION.TILLKEY` | Till key | | **transactionDetails** | Available | `TRANSACTIONDETAILS` \+ `TRANSACTIONCHANNEL` | Nested struct with transaction channel info | | └─ transactionChannelId | Available | `TRANSACTIONCHANNEL.ID` | Transaction channel ID | | └─ transactionChannelKey | Available | `INDEXRATE.ENCODEDKEY` (from tax rate) | Transaction channel key (mapped from tax rate encoded key) | | **transferDetails** | Available | `SAVINGSTRANSACTION` | Nested struct with linked transaction keys | | └─ linkedDepositTransactionKey | Available | `SAVINGSTRANSACTION.LINKEDSAVINGSTRANSACTIONKEY` | Linked deposit transaction key | | └─ linkedLoandTransactionKey | Available | `SAVINGSTRANSACTION.LINKEDLOANTRANSACTIONKEY` | Linked loan transaction key | | **type** | Available | `SAVINGSTRANSACTION.TYPE` | Transaction type | | **userKey** | Available | `SAVINGSTRANSACTION.USERKEY` | User who performed the transaction | | **valueDate** | Available | `SAVINGSTRANSACTION.ENTRYDATE` | Date of the entry (as Organization Time) | ## General Ledger Account The `GlAccount` Gold data product provides General Ledger account information with currency details and account configuration settings. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **activated** | Available | `GLACCOUNT.ACTIVATED` | Boolean flag for account activation status | | **allowManualJournalEntries** | Available | `GLACCOUNT.ALLOWMANUALJOURNALENTRIES` | Whether manual journal entries are allowed | | **balance** | Not available | `@NotPersistent` | Runtime calculation from GLJournalEntry records | | **creationDate** | Available | `GLACCOUNT.CREATIONDATE` | Stored as UTC timestamp | | **currency** | Available | `GLACCOUNT.CURRENCYCODE → CURRENCY` | Nested currency object | | └─ code | Available | `CURRENCY.CODE` | ISO-4217 currency code or NON\_FIAT | | └─ currencyCode | Available | `CURRENCY.CODE` | Same as code (API requirement) | | **description** | Available | `GLACCOUNT.DESCRIPTION` | Long text description of the account | | **encodedKey** | Available | `GLACCOUNT.ENCODEDKEY` | Primary key (UUID) | | **glCode** | Available | `GLACCOUNT.GLCODE` | GL code for categorization (e.g., "3201") | | **lastModifiedDate** | Available | `GLACCOUNT.LASTMODIFIEDDATE` | Stored as UTC timestamp | | **migrationEventKey** | Available | `GLACCOUNT.MIGRATIONEVENTKEY` | Data migration event reference | | **name** | Available | `GLACCOUNT.NAME` | Account display name | | **stripTrailingZeros** | Available | `GLACCOUNT.STRIPTRAILINGZEROS` | Boolean for report formatting | | **type** | Available | `GLACCOUNT.TYPE` | ASSET, LIABILITY, INCOME, EXPENSE, EQUITY | | **usage** | Available | `GLACCOUNT.USAGE` | DETAIL or HEADER | ## General Ledger Journal Entry The `GLJournalEntry` Gold data product provides General Ledger journal entry transactions with complete GL Account information, foreign currency details, and accounting rate conversions. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **accountKey** | Available | `GLJOURNALENTRY.ACCOUNTKEY` | FK to account entity (loan/savings), NULL for manual entries | | **amount** | Available | `GLJOURNALENTRY.AMOUNT` | Amount in organization currency, DECIMAL(60, 20\) | | **assignedBranchKey** | Available | `GLJOURNALENTRY.ASSIGNEDBRANCHKEY` | FK to BRANCH table | | **bookingDate** | Available | `GLJOURNALENTRY.ENTRYDATE` | Stored as Organization Time | | **creationDate** | Available | `GLJOURNALENTRY.CREATIONDATE` | Stored as UTC timestamp | | **encodedKey** | Available | `GLJOURNALENTRY.ENCODEDKEY` | Primary key (UUID) | | **entryID** | Available | `GLJOURNALENTRY.ENTRYID` | Auto-increment ID, unique per entry | | **foreignAmount** | Available | `GLJOURNALENTRYFOREIGNAMOUNT` | Optional nested object for foreign currency | | └─ accountingRate | Available | `ACCOUNTINGRATE` | Exchange rate used for conversion | | └─ encodedKey | Available | `ACCOUNTINGRATE.ENCODEDKEY` | Rate identifier | | └─ endDate | Available | `ACCOUNTINGRATE.ENDDATE` | Rate validity end (Organization Time) | | └─ fromCurrencyCode | Available | `ACCOUNTINGRATE.FROMCURRENCYCODE` | Organization currency | | └─ rate | Available | `ACCOUNTINGRATE.RATE` | Conversion rate value | | └─ startDate | Available | `ACCOUNTINGRATE.STARTDATE` | Rate validity start (Organization Time) | | └─ toCurrencyCode | Available | `ACCOUNTINGRATE.TOCURRENCYCODE` | Foreign currency | | └─ amount | Available | `GLJOURNALENTRYFOREIGNAMOUNT.AMOUNT` | Amount in foreign currency | | └─ currency | Available | `CURRENCY` via `GLJOURNALENTRYFOREIGNAMOUNT.CURRENCYCODE` | Foreign currency details | | └─ code | Available | `CURRENCY.CODE` | Currency code | | └─ currencyCode | Available | `CURRENCY.CODE` | Same as code (API requirement) | | **glAccount** | Available | `GLACCOUNT` | Full nested GL Account object | | └─ activated | Available | `GLACCOUNT.ACTIVATED` | Account activation status | | └─ allowManualJournalEntries | Available | `GLACCOUNT.ALLOWMANUALJOURNALENTRIES` | Configuration flag | | └─ balance | Not available | `@NotPersistent` | See GlAccount mapping analysis | | └─ creationDate | Available | `GLACCOUNT.CREATIONDATE` | Account creation timestamp | | └─ currency | Available | `CURRENCY` via `GLACCOUNT.CURRENCYCODE` | GL Account currency | | └─ code | Available | `CURRENCY.CODE` | Currency code | | └─ currencyCode | Available | `CURRENCY.CODE` | Same as code | | └─ description | Available | `GLACCOUNT.DESCRIPTION` | Account description | | └─ encodedKey | Available | `GLACCOUNT.ENCODEDKEY` | GL Account identifier | | └─ glCode | Available | `GLACCOUNT.GLCODE` | GL code for categorization | | └─ lastModifiedDate | Available | `GLACCOUNT.LASTMODIFIEDDATE` | Last modification timestamp | | └─ migrationEventKey | Available | `GLACCOUNT.MIGRATIONEVENTKEY` | Migration reference | | └─ name | Available | `GLACCOUNT.NAME` | Account display name | | └─ stripTrailingZeros | Available | `GLACCOUNT.STRIPTRAILINGZEROS` | Formatting flag | | └─ type | Available | `GLACCOUNT.TYPE` | ASSET, LIABILITY, INCOME, EXPENSE, EQUITY | | └─ usage | Available | `GLACCOUNT.USAGE` | DETAIL or HEADER | | **notes** | Available | `GLJOURNALENTRY.NOTES` | Optional user notes | | **productKey** | Available | `GLJOURNALENTRY.PRODUCTKEY` | FK to product entity, NULL for manual entries | | **productType** | Available | `GLJOURNALENTRY.PRODUCTTYPE` | LOAN, SAVINGS, etc., NULL for manual entries | | **reversalEntryKey** | Available | `GLJOURNALENTRY.REVERSALENTRYKEY` | FK to reversing journal entry, NULL if not reversed | | **transactionId** | Available | `GLJOURNALENTRY.TRANSACTIONID` | Groups related journal entries | | **type** | Available | `GLJOURNALENTRY.TYPE` | DEBIT or CREDIT | | **userKey** | Available | `GLJOURNALENTRY.USERKEY` | User who performed the transaction | ## Group The `Group` Gold data product provides information about client groups (solidarity groups, village banking groups, etc.) including group details, addresses, and member information with roles. Groups are used for group lending methodologies where multiple clients form a collective borrowing unit. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **encodedKey** | Available | `GROUP.ENCODEDKEY` | Primary key (UUID, auto-generated) | | **id** | Available | `GROUP.ID` | Business identifier, unique, user-defined | | **groupName** | Available | `GROUP.GROUPNAME` | Required field | | **creationDate** | Available | `GROUP.CREATIONDATE` | Stored as UTC timestamp | | **lastModifiedDate** | Available | `GROUP.LASTMODIFIEDDATE` | Stored as UTC timestamp | | **emailAddress** | Available | `GROUP.EMAILADDRESS` | Group email | | **homePhone** | Available | `GROUP.HOMEPHONE` | Group phone | | **mobilePhone** | Available | `GROUP.MOBILEPHONE1` | Group mobile | | **notes** | Available | `GROUP.NOTES` | Long text field (LONGVARCHAR, lazy-loaded) | | **assignedBranchKey** | Available | `GROUP.ASSIGNEDBRANCHKEY` | FK to BRANCH table | | **assignedCentreKey** | Available | `GROUP.ASSIGNEDCENTREKEY` | FK to CENTRE table (optional) | | **assignedUserKey** | Available | `GROUP.ASSIGNEDUSERKEY` | FK to USER table (loan officer) | | **groupRoleKey** | Available | `GROUP.CLIENTROLEKEY` | FK to CLIENTROLE table | | **loanCycle** | Available | `GROUP.LOANCYCLE` | Number of group loans completed | | **migrationEventKey** | Available | `GROUP.MIGRATIONEVENTKEY` | FK to data migration event | | **preferredLanguage** | Available | `GROUP.PREFERREDLANGUAGE` | ISO 639-1 language code | | **addresses\[\]** | Available | `ADDRESS` table | Array of addresses (1:N), filtered by PARENTKEY | | └─ All address fields | Available | Same as Branch/Client | Same ADDRESS table structure | | **groupMembers\[\]** | Available | `GROUPMEMBER` \+ `GROUPROLE` | Member list with complete role mapping | | └─ clientKey | Available | `GROUPMEMBER.CLIENTKEY` | FK to CLIENT table | | └─ roles\[\] | Available | `GROUPROLE` table | Aggregated via CTE with collect\_list | | └─ encodedKey | Available | `GROUPROLE.ENCODEDKEY` | Role assignment identifier | | └─ groupRoleNameKey | Available | `GROUPROLE.GROUPROLENAMEKEY` | FK to GROUPROLENAME | | └─ roleName | Available | `GROUPROLENAME.NAME` | Role display name (e.g., "President") | | └─ roleNameId | Available | `GROUPROLENAME.ID` | Role ID (e.g., "PRESIDENT") | | **customFields** | Not available | `CUSTOMFIELDVALUE` table | Not implemented (GROUP\_INFO entity type) | ## Loan Account The `LoanAccount` Gold data product provides comprehensive loan account information with nested structures for arrears settings, balances, disbursement details, interest settings, penalty settings, assets, guarantors, and funding sources. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **accountArrearsSettings** | Available | `ACCOUNTARREARSSETTINGS` \+ `BASEARREARSSETTINGS` | Joined via `joinArrearsSettings()` | | └─ dateCalculationMethod | Available | `BASEARREARSSETTINGS.DATECALCULATIONMETHOD` | Direct mapping | | └─ encodedKey | Available | `BASEARREARSSETTINGS.ENCODEDKEY` | Direct mapping | | └─ monthlyToleranceDay | Available | `ACCOUNTARREARSSETTINGS.MONTHLYTOLERANCEDAY` | Direct mapping | | └─ nonWorkingDaysMethod | Available | `BASEARREARSSETTINGS.NONWORKINGDAYSMETHOD` | Direct mapping | | └─ toleranceCalculationMethod | Available | `BASEARREARSSETTINGS.TOLERANCECALCULATIONMETHOD` | Direct mapping | | └─ toleranceFloorAmount | Available | `BASEARREARSSETTINGS.TOLERANCEFLOORAMOUNT` | Direct mapping | | └─ tolerancePercentageOfOutstandingPrincipal | Available | `ACCOUNTARREARSSETTINGS.TOLERANCEPERCENTAGEOFOUTSTANDINGPRINCIPAL` | Direct mapping | | └─ tolerancePeriod | Available | `ACCOUNTARREARSSETTINGS.TOLERANCEPERIOD` | Direct mapping | | **accountHolderKey** | Available | `LOANACCOUNT.ACCOUNTHOLDERKEY` | Direct mapping | | **accountState** | Available | `LOANACCOUNT.ACCOUNTSTATE` | Direct mapping | | **accountSubState** | Available | `LOANACCOUNT.ACCOUNTSUBSTATE` | Direct mapping | | **accruedInterest** | Available | `LOANACCOUNT.ACCRUEDINTEREST` | Direct mapping | | **accruedPenalty** | Available | `LOANACCOUNT.ACCRUEDPENALTY` | Direct mapping | | **activationTransactionKey** | Available | `LOANACCOUNT.ACTIVATIONTRANSACTIONKEY` | Direct mapping | | **allowOffset** | Available | `LOANACCOUNT.ALLOWOFFSET` | Direct mapping (deprecated field) | | **approvedDate** | Available | `LOANACCOUNT.APPROVEDDATE` | Direct mapping | | **arrearsTolerancePeriod** | Available | `LOANACCOUNT.ARREARSTOLERANCEPERIOD` | Direct mapping | | **assets\[\]** | Available | `GUARANTY` (filtered by TYPE='ASSET') | Aggregated via `aggregateAssets()` | | └─ amount | Available | `GUARANTY.AMOUNT` | Direct mapping | | └─ assetName | Available | `GUARANTY.ASSETNAME` | Direct mapping | | └─ depositAccountKey | Available | `GUARANTY.SAVINGSACCOUNTKEY` | Direct mapping | | └─ encodedKey | Available | `GUARANTY.ENCODEDKEY` | Direct mapping | | └─ guarantorKey | Available | `GUARANTY.GUARANTORKEY` | Direct mapping | | └─ guarantorType | Available | `GUARANTY.GUARANTORTYPE` | Direct mapping | | └─ originalAmount | Available | `GUARANTY.ORIGINALAMOUNT` | Direct mapping | | └─ originalCurrency | Available | `GUARANTY.ORIGINALCURRENCYCODE` | Nested struct | | **assignedBranchKey** | Available | `LOANACCOUNT.ASSIGNEDBRANCHKEY` | Direct mapping | | **assignedCentreKey** | Available | `LOANACCOUNT.ASSIGNEDCENTREKEY` | Direct mapping | | **assignedUserKey** | Available | `LOANACCOUNT.ASSIGNEDUSERKEY` | Direct mapping | | **balances** | Available | `LOANACCOUNT` balance fields | Nested structure | | └─ feesBalance | Available | `LOANACCOUNT.FEESBALANCE` | Direct mapping | | └─ feesDue | Available | `LOANACCOUNT.FEESDUE` | Direct mapping | | └─ feesPaid | Available | `LOANACCOUNT.FEESPAID` | Direct mapping | | └─ holdBalance | Available | `LOANACCOUNT.HOLDBALANCE` | Direct mapping | | └─ interestBalance | Available | `LOANACCOUNT.INTERESTBALANCE` | Direct mapping | | └─ penaltyBalance | Available | `LOANACCOUNT.PENALTYBALANCE` | Direct mapping | | └─ penaltyDue | Available | `LOANACCOUNT.PENALTYDUE` | Direct mapping | | └─ penaltyPaid | Available | `LOANACCOUNT.PENALTYPAID` | Direct mapping | | └─ principalBalance | Available | `LOANACCOUNT.PRINCIPALBALANCE` | Direct mapping | | └─ principalDue | Available | `LOANACCOUNT.PRINCIPALDUE` | Direct mapping | | └─ principalPaid | Available | `LOANACCOUNT.PRINCIPALPAID` | Direct mapping | | └─ redrawBalance | Available | `LOANACCOUNT.REDRAWBALANCE` | Direct mapping | | **closedDate** | Available | `LOANACCOUNT.CLOSEDDATE` | Direct mapping | | **creationDate** | Available | `LOANACCOUNT.CREATIONDATE` | Direct mapping | | **creditArrangementKey** | Available | `LOANACCOUNT.LINEOFCREDITKEY` | Direct mapping | | **currency** | Available | `LOANPRODUCT.CURRENCYCODE` | Via LoanAccount → LoanProduct join | | └─ code | Available | `LOANPRODUCT.CURRENCYCODE` | Direct mapping | | **customFields\[\]** | Available | `CUSTOMFIELD` \+ `CUSTOMFIELDVALUE` | Aggregated via `_combineCustomFields()` | | └─ fieldKey | Available | `CUSTOMFIELD.ENCODEDKEY` | Direct mapping | | └─ fieldName | Available | `CUSTOMFIELD.NAME` | Direct mapping | | └─ fieldValue | Available | `CUSTOMFIELDVALUE.VALUE` | Direct mapping | | **daysInArrears** | Available | Calculated | `LoanAccountLogic.calculate_days_in_arrears()` | | **daysLate** | Available | Calculated | `LoanAccountLogic.calculate_days_late()` | | **disbursementDetails** | Available | `DISBURSEMENTDETAILS` \+ joins | Nested structure | | └─ disbursementDate | Available | `DISBURSEMENTDETAILS.DISBURSEMENTDATE` | Direct mapping | | └─ encodedKey | Available | `DISBURSEMENTDETAILS.ENCODEDKEY` | Direct mapping | | └─ expectedDisbursementDate | Available | `DISBURSEMENTDETAILS.EXPECTEDDISBURSEMENTDATE` | Direct mapping | | └─ fees | Available | `PREDEFINEDFEE` \+ `CUSTOMPREDEFINEDFEE` | Aggregated via `aggregateFees()` | | └─ firstRepaymentDate | Available | `DISBURSEMENTDETAILS.FIRSTREPAYMENTDATE` | Direct mapping | | └─ transactionDetails\[\] | Available | `TRANSACTIONDETAILS` \+ `TRANSACTIONCHANNEL` | Aggregated via `joinTransactionDetails()` | | **encodedKey** | Available | `LOANACCOUNT.ENCODEDKEY` | Primary key | | **fundingSources\[\]** | Available | `GUARANTY` (filtered by DISC\_RIM\_IN\_AT\_OR='INVESTOR\_FUND') | Aggregated via `aggregateFundingSources()` | | └─ amount | Available | `GUARANTY.AMOUNT` | Direct mapping | | └─ assetName | Available | `GUARANTY.ASSETNAME` | Direct mapping | | └─ depositAccountKey | Available | `GUARANTY.SAVINGSACCOUNTKEY` | Direct mapping | | └─ encodedKey | Available | `GUARANTY.ENCODEDKEY` | Direct mapping | | └─ guarantorKey | Available | `GUARANTY.GUARANTORKEY` | Direct mapping | | └─ guarantorType | Available | `GUARANTY.TYPE` | Direct mapping | | └─ id | Available | `GUARANTY.ID` | Direct mapping | | └─ interestCommission | Available | `GUARANTY.INTERESTCOMMISSION` | Direct mapping | | └─ sharePercentage | Available | `GUARANTY.INVESTMENTPERCENTAGE` | Direct mapping | | **futurePaymentsAcceptance** | Available | `LOANACCOUNT.FUTUREPAYMENTSACCEPTANCE` | Direct mapping | | **guarantors\[\]** | Available | `GUARANTY` (filtered by GUARANTORTYPE='GUARANTOR') | Aggregated via `aggregateGuarantors()` | | └─ amount | Available | `GUARANTY.AMOUNT` | Direct mapping | | └─ assetName | Available | `GUARANTY.ASSETNAME` | Direct mapping | | └─ depositAccountKey | Available | `GUARANTY.SAVINGSACCOUNTKEY` | Direct mapping | | └─ encodedKey | Available | `GUARANTY.ENCODEDKEY` | Direct mapping | | └─ guarantorKey | Available | `GUARANTY.GUARANTORKEY` | Direct mapping | | └─ guarantorType | Available | `GUARANTY.GUARANTORTYPE` | Direct mapping | | **id** | Available | `LOANACCOUNT.ID` | Direct mapping | | **interestAccruedInBillingCycle** | Not available | `RevolvingLoanAccountState` service | **Service-based field for revolving credit only** | | **interestCommission** | Available | `LOANACCOUNT.INTERESTCOMMISSION` | Direct mapping | | **interestFromArrearsAccrued** | Available | `LOANACCOUNT.INTERESTFROMARREARSACCRUED` | Direct mapping | | **interestSettings** | Available | `ACCOUNTINTERESTRATESETTINGS` \+ `LOANACCOUNT` | Nested structure | | └─ accountInterestRateSettings | Available | `ACCOUNTINTERESTRATESETTINGS` \+ `INDEXRATESOURCE` | Nested struct | | └─ encodedKey | Available | `ACCOUNTINTERESTRATESETTINGS.ENCODEDKEY` | Direct mapping | | └─ indexSourceKey | Available | `ACCOUNTINTERESTRATESETTINGS.INDEXSOURCEKEY` | Direct mapping | | └─ interestRate | Available | `ACCOUNTINTERESTRATESETTINGS.INTERESTRATE` | Direct mapping | | └─ interestRateCeilingValue | Available | `ACCOUNTINTERESTRATESETTINGS.INTERESTRATECEILINGVALUE` | Direct mapping | | └─ interestRateFloorValue | Available | `ACCOUNTINTERESTRATESETTINGS.INTERESTRATEFLOORVALUE` | Direct mapping | | └─ interestRateReviewCount | Available | `ACCOUNTINTERESTRATESETTINGS.INTERESTRATEREVIEWUNIT` | Direct mapping (note: using review\_unit) | | └─ interestRateReviewUnit | Available | `ACCOUNTINTERESTRATESETTINGS.INTERESTRATEREVIEWUNIT` | Direct mapping | | └─ interestRateSource | Available | `INDEXRATESOURCE.NAME` | Via join | | └─ interestSpread | Available | `ACCOUNTINTERESTRATESETTINGS.INTERESTSPREAD` | Direct mapping | | └─ validFrom | Available | `ACCOUNTINTERESTRATESETTINGS.VALIDFROM` | Direct mapping | | └─ accrueInterestAfterMaturity | Available | `LOANACCOUNT.ACCRUEINTERESTAFTERMATURITY` | Direct mapping | | └─ accrueLateInterest | Available | `LOANACCOUNT.ACCRUELATEINTEREST` | Direct mapping | | └─ interestApplicationDays | Available | `LOANACCOUNT` | Nested struct | | └─ daysInMonth | Not available | Computed/derived | **Runtime calculation based on days in year method** | | └─ shortMonthHandlingMethod | Available | `LOANACCOUNT.SHORTMONTHHANDLINGMETHOD` | Direct mapping | | └─ interestApplicationMethod | Available | `LOANACCOUNT.INTERESTAPPLICATIONMETHOD` | Direct mapping | | └─ interestBalanceCalculationMethod | Available | `LOANACCOUNT.INTERESTBALANCECALCULATIONMETHOD` | Direct mapping | | └─ interestCalculationMethod | Available | `LOANACCOUNT.INTERESTCALCULATIONMETHOD` | Direct mapping | | └─ interestChargeFrequency | Available | `LOANACCOUNT.INTERESTCHARGEFREQUENCY` | Direct mapping | | └─ interestRate | Available | `LOANACCOUNT.INTERESTRATE` | Direct mapping | | └─ interestRateReviewCount | Available | `LOANACCOUNT.INTERESTRATEREVIEWCOUNT` | Direct mapping | | └─ interestRateSource | Available | `LOANACCOUNT.INTERESTRATESOURCE` | Direct mapping | | └─ interestSpread | Available | `LOANACCOUNT.INTERESTSPREAD` | Direct mapping | | └─ interestType | Available | `LOANACCOUNT.INTERESTTYPE` | Direct mapping | | └─ pmtAdjustmentThreshold | Not available | `LendingAccountContract` | **Contract-based field** | | **lastAccountAppraisalDate** | Available | `LOANACCOUNT.LASTACCOUNTAPPRAISALDATE` | Direct mapping | | **lastInterestAppliedDate** | Available | `LOANACCOUNT.LASTINTERESTAPPLIEDDATE` | Direct mapping | | **lastInterestReviewDate** | Available | `LOANACCOUNT.LASTINTERESTREVIEWDATE` | Direct mapping | | **lastLockedDate** | Available | `LOANACCOUNT.LASTLOCKEDDATE` | Direct mapping | | **lastModifiedDate** | Available | `LOANACCOUNT.LASTMODIFIEDDATE` | Direct mapping | | **lastSetToArrearsDate** | Available | `LOANACCOUNT.LASTSETTOARREARSDATE` | Direct mapping | | **lastTaxRateReviewDate** | Available | `LOANACCOUNT.LASTTAXRATEREVIEWDATE` | Direct mapping | | **latePaymentsRecalculationMethod** | Available | `LOANACCOUNT.LATEPAYMENTSRECALCULATIONMETHOD` | Direct mapping | | **loanAmount** | Available | `LOANACCOUNT.LOANAMOUNT` | Direct mapping | | **loanName** | Available | `LOANACCOUNT.LOANNAME` | Direct mapping | | **lockedAccountTotalDueType** | Not available | `ACCOUNTLOCK` table | **Table not in Silver stage** | | **lockedOperations** | Available | `LOANACCOUNT.LOCKEDOPERATIONS` | Direct mapping (binary type) | | **migrationEventKey** | Available | `LOANACCOUNT.MIGRATIONEVENTKEY` | Direct mapping | | **modifyInterestForFirstInstallment** | Not available | `LendingAccountContract` | **Contract-based field** | | **notes** | Available | `LOANACCOUNT.NOTES` | Direct mapping | | **originalAccountKey** | Available | `LOANACCOUNT.RESCHEDULEDACCOUNTKEY` | Direct mapping | | **paymentHolidaysAccruedInterest** | Not available | `ACCOUNTPAYMENTHOLIDAYSDETAILS` table | **Table not in Silver stage** | | **paymentMethod** | Available | `LOANACCOUNT.PAYMENTMETHOD` | Direct mapping | | **penaltySettings** | Available | `LOANACCOUNT` | Nested structure | | └─ loanPenaltyCalculationMethod | Available | `LOANACCOUNT.LOANPENALTYCALCULATIONMETHOD` | Direct mapping | | └─ penaltyRate | Available | `LOANACCOUNT.PENALTYRATE` | Direct mapping | ## Loan Account Schedule The `LoanAccountSchedule` Gold data product provides comprehensive loan repayment schedule information including installments with detailed breakdowns of principal, interest, fees, and penalties. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **currency** | | | | | └─ code | Available | `LOANPRODUCT.CURRENCYCODE → CURRENCY.CODE` | Via LoanAccount → LoanProduct join | | └─ currencyCode | Available | `LOANPRODUCT.CURRENCYCODE → CURRENCY.CODE` | Via LoanAccount → LoanProduct join | | **installments\[\]** | | | Array of installment records | | └─ carryForwardInterestSplit | Not available | `REPAYMENT.ADDITIONS` (JSON) | **Column not available in current data** | | └─ amount | Not available | `$.carryForwardInterest` | Requires ADDITIONS column | | └─ tax | Not available | `$.carryForwardInterestTax` | Requires ADDITIONS column | | └─ customSettingDetails\[\] | Available | `CUSTOMREPAYMENTSETTINGS` | Aggregated via CTE with collect\_list | | └─ loanTransactionKey | Available | `CUSTOMREPAYMENTSETTINGS.LOANTRANSACTIONKEY` | Direct field | | └─ source | Available | `CUSTOMREPAYMENTSETTINGS.SOURCE` | Direct field | | └─ type | Available | `CUSTOMREPAYMENTSETTINGS.TYPE` | Direct field | | └─ dueDate | Available | `REPAYMENT.DUEDATE` | Direct mapping | | └─ encodedKey | Available | `REPAYMENT.ENCODEDKEY` | Primary key | | └─ expectedClosingBalance | Not available | `@NotPersistent` | Runtime calculation for interest-only products | | └─ fee | Available | `REPAYMENT` fee fields | Nested structure | | └─ amount.due | Available | `FEESDUE - FEESPAID` | Calculated balance | | └─ amount.expected | Available | `REPAYMENT.FEESDUE` | Direct field | | └─ amount.expectedUnapplied | Not available | Repository query | Requires `RepaymentUnappliedFeeDetailsRepo` | | └─ amount.paid | Available | `REPAYMENT.FEESPAID` | Direct field | | └─ tax.due | Available | `TAXFEESDUE - TAXFEESPAID` | Calculated balance | | └─ tax.expected | Available | `REPAYMENT.TAXFEESDUE` | Direct field | | └─ tax.paid | Available | `REPAYMENT.TAXFEESPAID` | Direct field | | └─ feeDetails\[\] | Available | `REPAYMENTFEEDETAILS` \+ joins | Aggregated via CTE | | └─ amount.due | Available | `REPAYMENTFEEDETAILS.FEEDUE` | Per-fee breakdown | | └─ amount.expected | Available | `REPAYMENTFEEDETAILS.FEEDUE` | Per-fee breakdown | | └─ amount.paid | Available | `REPAYMENTFEEDETAILS.FEEPAID` | Per-fee breakdown | | └─ amount.reduced | Available | `REPAYMENTFEEDETAILS.FEEREDUCED` | Per-fee breakdown | | └─ encodedKey | Available | `REPAYMENTFEEDETAILS.ENCODEDKEY` | Direct field | | └─ id | Available | `PREDEFINEDFEE.ID` | Via transaction → fee linkage | | └─ name | Available | `PREDEFINEDFEE.NAME` | Via transaction → fee linkage | | └─ tax.due | Available | `REPAYMENTFEEDETAILS.TAXONFEEDUE` | Per-fee tax breakdown | | └─ tax.expected | Available | `REPAYMENTFEEDETAILS.TAXONFEEDUE` | Per-fee tax breakdown | | └─ tax.paid | Available | `REPAYMENTFEEDETAILS.TAXONFEEPAID` | Per-fee tax breakdown | | └─ tax.reduced | Available | `REPAYMENTFEEDETAILS.TAXONFEEREDUCED` | Per-fee tax breakdown | | └─ fundersInterestDue | Available | `REPAYMENT.FUNDERSINTERESTDUE` | P2P-specific field | | └─ interest | Available | `REPAYMENT` interest fields | Nested structure | | └─ amount.due | Available | `INTERESTDUE - INTERESTPAID` | Calculated balance | | └─ amount.expected | Available | `REPAYMENT.INTERESTDUE` | Direct field | | └─ amount.paid | Available | `REPAYMENT.INTERESTPAID` | Direct field | | └─ tax.due | Available | `TAXINTERESTDUE - TAXINTERESTPAID` | Calculated balance | | └─ tax.expected | Available | `REPAYMENT.TAXINTERESTDUE` | Direct field | | └─ tax.paid | Available | `REPAYMENT.TAXINTERESTPAID` | Direct field | | └─ interestAccrued | Not available | `@NotPersistent` | Runtime calculation for interest-only products | | └─ isPaymentHoliday | Available | `CUSTOMREPAYMENTSETTINGS` | WHERE TYPE='PAYMENT\_HOLIDAY' | | └─ lastPaidDate | Available | `REPAYMENT.LASTPAIDDATE` | Direct mapping | | └─ lastPenaltyAppliedDate | Available | `REPAYMENT.LASTPENALTYAPPLIEDDATE` | Direct mapping | | └─ nonScheduledPrincipalBalanceOverpayment | Not available | `@NotPersistent` | Runtime calculation for DYNAMIC\_MORTGAGE only | | └─ notes | Available | `REPAYMENT.NOTES` | Direct mapping | | └─ number | Available | Calculated | `ROW_NUMBER() OVER (PARTITION BY parentAccountKey ORDER BY dueDate)` | | └─ organizationCommissionDue | Available | `REPAYMENT.ORGANIZATIONCOMMISSIONDUE` | P2P-specific field | | └─ parentAccountKey | Available | `REPAYMENT.PARENTACCOUNTKEY` | Foreign key to LOANACCOUNT | | └─ penalty | Available | `REPAYMENT` penalty fields | Nested structure | | └─ amount.due | Available | `PENALTYDUE - PENALTYPAID` | Calculated balance | | └─ amount.expected | Available | `REPAYMENT.PENALTYDUE` | Direct field | | └─ amount.paid | Available | `REPAYMENT.PENALTYPAID` | Direct field | | └─ tax.due | Available | `TAXPENALTYDUE - TAXPENALTYPAID` | Calculated balance | | └─ tax.expected | Available | `REPAYMENT.TAXPENALTYDUE` | Direct field | | └─ tax.paid | Available | `REPAYMENT.TAXPENALTYPAID` | Direct field | | └─ principal | Available | `REPAYMENT` principal fields | Nested structure | | └─ amount.due | Available | `PRINCIPALDUE - PRINCIPALPAID` | Calculated balance | | └─ amount.expected | Available | `REPAYMENT.PRINCIPALDUE` | Direct field | | └─ amount.paid | Available | `REPAYMENT.PRINCIPALPAID` | Direct field | | └─ repaidDate | Available | `REPAYMENT.REPAIDDATE` | Direct mapping | | └─ state | Available | `REPAYMENT.STATE` | PENDING/LATE/PAID/PARTIALLY\_PAID/GRACE | ## Loan Product The `LoanProduct` Gold data product provides comprehensive loan product configuration information with nested structures for account links, accounting, arrears, availability, fees, funding, interest, payment, penalty, redraw, schedule, security, and tax settings. | Field Path | Status | Source | Implementation Notes | |------------|--------|--------|---------------------| | **accountLinkSettings** | Available | `LOANPRODUCT` | Nested struct | | └─ enabled | Available | `LOANPRODUCT.ACCOUNTLINKINGENABLED` | Direct mapping | | └─ linkableDepositProductKey | Available | `LOANPRODUCT.LINKABLESAVINGSPRODUCTKEY` | Direct mapping | | └─ linkedAccountOptions[] | Available | `LOANPRODUCT.AUTOLINKACCOUNTS`, `AUTOCREATELINKEDACCOUNTS` | Computed array via `LoanProductLogic.get_linked_account_options()` | | └─ settlementMethod | Available | `LOANPRODUCT.SETTLEMENTOPTIONS` | Direct mapping | | **accountingSettings** | Available | `LOANPRODUCT` + `GLACCOUNTINGRULE` | Nested struct with aggregated rules | | └─ accountingMethod | Available | `LOANPRODUCT.ACCOUNTINGMETHOD` | Direct mapping | | └─ accountingRules[] | Available | `GLACCOUNTINGRULE` | Aggregated via CTE with `collect_list()` | |    └─ encodedKey | Available | `GLACCOUNTINGRULE.ENCODEDKEY` | Direct field | |    └─ financialResource | Available | `GLACCOUNTINGRULE.FINANCIALRESOURCE` | Direct field | |    └─ glAccountKey | Available | `GLACCOUNTINGRULE.GLACCOUNTKEY` | Direct field | |    └─ transactionChannelKey | Available | `GLACCOUNTINGRULE.TRANSACTIONCHANNELKEY` | Direct field | | └─ interestAccrualCalculation | Available | `LOANPRODUCT.INTERESTACCRUALCALCULATION` | Direct mapping | | └─ interestAccruedAccountingMethod | Available | `LOANPRODUCT.INTERESTACCRUEDACCOUNTINGMETHOD` | Direct mapping | | **adjustInterestForFirstInstallment** | Not available | `@Contract-based` | Contract-based field from `LendingProductContract`, not in database | | **allowCustomRepaymentAllocation** | Available | `LOANPRODUCT.ALLOWCUSTOMREPAYMENTALLOCATION` | Direct mapping | | **arrearsSettings** | Available | `PRODUCTARREARSSETTINGS` + `BASEARREARSSETTINGS` | Nested struct via join | | └─ dateCalculationMethod | Available | `BASEARREARSSETTINGS.DATECALCULATIONMETHOD` | Via join | | └─ encodedKey | Available | `BASEARREARSSETTINGS.ENCODEDKEY` | Via join | | └─ monthlyToleranceDay | Available | `PRODUCTARREARSSETTINGS.MONTHLYTOLERANCEDAY` | Via join | | └─ nonWorkingDaysMethod | Available | `BASEARREARSSETTINGS.NONWORKINGDAYSMETHOD` | Via join | | └─ toleranceCalculationMethod | Available | `BASEARREARSSETTINGS.TOLERANCECALCULATIONMETHOD` | Via join | | └─ toleranceFloorAmount | Available | `BASEARREARSSETTINGS.TOLERANCEFLOORAMOUNT` | Via join | | └─ tolerancePercentageOfOutstandingPrincipal | Available | `PRODUCTARREARSSETTINGS` | Nested struct | |    └─ defaultValue | Available | `PRODUCTARREARSSETTINGS.DEFAULTTOLERANCEPERCENTAGEOFOUTSTANDINGPRINCIPAL` | Direct field | |    └─ maxValue | Available | `PRODUCTARREARSSETTINGS.MAXTOLERANCEPERCENTAGEOFOUTSTANDINGPRINCIPAL` | Direct field | |    └─ minValue | Available | `PRODUCTARREARSSETTINGS.M_INTOLERANCEPERIOD` | Direct field | | └─ tolerancePeriod | Available | `PRODUCTARREARSSETTINGS` | Nested struct | |    └─ defaultValue | Available | `PRODUCTARREARSSETTINGS.DEFAULTTOLERANCEPERIOD` | Direct field | |    └─ encodedKey | Available | `PRODUCTARREARSSETTINGS.ENCODEDKEY` | Direct field | |    └─ maxValue | Available | `PRODUCTARREARSSETTINGS.MAXTOLERANCEPERIOD` | Direct field | |    └─ minValue | Available | `PRODUCTARREARSSETTINGS.M_INTOLERANCEPERIOD` | Direct field | | **availabilitySettings** | Available | `LOANPRODUCT` + `LOANPRODUCTBRANCH` | Nested struct with aggregated branches | | └─ availableFor[] | Available | `LOANPRODUCT.FORINDIVIDUALS`, `FORPUREGROUPS`, `FORHYBRIDGROUPS` | Computed array | | └─ branchSettings | Available | `LOANPRODUCTBRANCH` + `LOANPRODUCT` | Nested struct | |    └─ availableProductBranches[] | Available | `LOANPRODUCTBRANCH.BRANCHKEY` | Aggregated via CTE with `collect_list()` | |    └─ forAllBranches | Available | `LOANPRODUCT.FORALLBRANCHES` | Direct mapping | | **category** | Available | `LOANPRODUCT.CATEGORY` | Direct mapping | | **creationDate** | Available | `LOANPRODUCT.CREATIONDATE` | Direct mapping | | **creditArrangementRequirement** | Available | `LOANPRODUCT.LINEOFCREDITREQUIREMENT` | Direct mapping | | **currency** | Available | `LOANPRODUCT.CURRENCYCODE` | Direct mapping | | **encodedKey** | Available | `LOANPRODUCT.ENCODEDKEY` | Primary key | | **feesSettings** | Available | `PREDEFINEDFEE` + `GLACCOUNTINGRULE` + `PERIODINTERVALSETTINGS` | Nested struct with aggregated fees | | └─ allowArbitraryFees | Available | `LOANPRODUCT.ALLOWARBITRARYFEES` | Direct mapping | | └─ fees[] | Available | `PREDEFINEDFEE` | Aggregated via CTE with `collect_list()` | |    └─ amount | Available | `PREDEFINEDFEE.AMOUNT` | Direct field | |    └─ amountCalculationFunctionName | Not available | `PREDEFINEDFEEFUNCTION` | Table not in Silver stage | |    └─ amountCalculationMethod | Available | `PREDEFINEDFEE.AMOUNTCALCULATIONMETHOD` | Direct field | |    └─ applyDateMethod | Available | `PREDEFINEDFEE.APPLYDATEMETHOD` | Direct field | |    └─ creationDate | Available | `PREDEFINEDFEE.CREATIONDATE` | Direct field | |    └─ encodedKey | Available | `PREDEFINEDFEE.ENCODEDKEY` | Direct field | |    └─ feeApplication | Available | `PREDEFINEDFEE.FEEAPPLICATION` | Direct field | |    └─ id | Available | `PREDEFINEDFEE.ID` | Direct field | |    └─ lastModifiedDate | Available | `PREDEFINEDFEE.LASTMODIFIEDDATE` | Direct field | |    └─ name | Available | `PREDEFINEDFEE.NAME` | Direct field | |    └─ percentageAmount | Available | `PREDEFINEDFEE.PERCENTAGEAMOUNT` | Direct field | |    └─ state | Available | `PREDEFINEDFEE.ACTIVE` | Computed: `ACTIVE` if `ACTIVE == 1`, else `INACTIVE` | |    └─ taxSettings | Available | `PREDEFINEDFEE` | Nested struct | |       └─ taxableCalculationMethod | Available | `PREDEFINEDFEE.TAXABLECALCULATIONMETHOD` | Direct field | |    └─ amortizationSettings | Available | `PREDEFINEDFEE` + `PERIODINTERVALSETTINGS` | Nested struct via join | |       └─ amortizationProfile | Available | `PREDEFINEDFEE.AMORTIZATIONPROFILE` | Direct field | |       └─ encodedKey | Available | `PERIODINTERVALSETTINGS.ENCODEDKEY` | Via join | |       └─ feeAmortizationUponRescheduleRefinanceOption | Available | `PREDEFINEDFEE.FEEAMORTIZATIONUPONRESCHEDULEOPTION` | Direct field | |       └─ frequency | Available | `PERIODINTERVALSETTINGS.FREQUENCY` | Via join | |       └─ intervalCount | Available | `PERIODINTERVALSETTINGS.INTERVALCOUNT` | Via join | |       └─ intervalType | Available | `PERIODINTERVALSETTINGS.INTERVALTYPE` | Via join | |       └─ periodCount | Available | `PERIODINTERVALSETTINGS.PERIODCOUNT` | Via join | |       └─ periodUnit | Available | `PERIODINTERVALSETTINGS.PERIODUNIT` | Via join | |    └─ accountingRules[] | Available | `GLACCOUNTINGRULE` | Aggregated via CTE | |       └─ encodedKey | Available | `GLACCOUNTINGRULE.ENCODEDKEY` | Direct field | |       └─ financialResource | Available | `GLACCOUNTINGRULE.FINANCIALRESOURCE` | Direct field | |       └─ glAccountKey | Available | `GLACCOUNTINGRULE.GLACCOUNTKEY` | Direct field | |       └─ transactionChannelKey | Available | `GLACCOUNTINGRULE.TRANSACTIONCHANNELKEY` | Direct field | |    └─ trigger | Available | `PREDEFINEDFEE.TRIGGER` | Direct field | | **fundingSettings** | Available | `PRODUCTSECURITYSETTINGS` + `DECIMALINTERVALCONSTRAINTS` | Nested struct via joins | | └─ enabled | Available | `PRODUCTSECURITYSETTINGS.ISINVESTORFUNDSENABLED` | Direct field | | └─ funderInterestCommission | Available | `DECIMALINTERVALCONSTRAINTS` | Nested struct via join | |    └─ defaultValue | Available | `DECIMALINTERVALCONSTRAINTS.DEFAULTVALUE` | Via join | |    └─ encodedKey | Available | `DECIMALINTERVALCONSTRAINTS.ENCODEDKEY` | Via join | |    └─ maxValue | Available | `DECIMALINTERVALCONSTRAINTS.MAXVALUE` | Via join | |    └─ minValue | Available | `DECIMALINTERVALCONSTRAINTS.MINVALUE` | Via join | | └─ funderInterestCommissionAllocationType | Available | `PRODUCTSECURITYSETTINGS.F_UNDERINTERESTCOMMISSIONKEY` | Direct field | | └─ lockFundsAtApproval | Available | `PRODUCTSECURITYSETTINGS.LOCKFUNDSATAPPROVAL` | Direct field | | └─ organizationInterestCommission | Available | `DECIMALINTERVALCONSTRAINTS` | Nested struct via join | |    └─ defaultValue | Available | `DECIMALINTERVALCONSTRAINTS.DEFAULTVALUE` | Via join | |    └─ encodedKey | Available | `DECIMALINTERVALCONSTRAINTS.ENCODEDKEY` | Via join | |    └─ maxValue | Available | `DECIMALINTERVALCONSTRAINTS.MAXVALUE` | Via join | |    └─ minValue | Available | `DECIMALINTERVALCONSTRAINTS.MINVALUE` | Via join | | └─ requiredFunds | Available | `PRODUCTSECURITYSETTINGS.REQUIREDINVESTORFUNDS` | Direct field | | **gracePeriodSettings** | Available | `LOANPRODUCT` | Nested struct | | └─ gracePeriod | Available | `LOANPRODUCT` | Nested struct | |    └─ defaultValue | Available | `LOANPRODUCT.DEFAULTGRACEPERIOD` | Direct mapping | |    └─ encodedKey | Available | `LOANPRODUCT.ENCODEDKEY` | Direct mapping | |    └─ maxValue | Available | `LOANPRODUCT.MAXGRACEPERIOD` | Direct mapping | |    └─ minValue | Available | `LOANPRODUCT.MINGRACEPERIOD` | Direct mapping | | └─ gracePeriodType | Available | `LOANPRODUCT.GRACEPERIODTYPE` | Direct mapping | | **id** | Available | `LOANPRODUCT.ID` | Direct mapping | | **interestSettings** | Available | `INTERESTPRODUCTSETTINGS` + `INTERESTBASESETTINGS` + `PRODUCTINTERESTRATESETTINGS` + `INDEXRATESOURCE` + `INTERESTRATETIER` | Complex nested struct | | └─ accrueLateInterest | Available | `INTERESTBASESETTINGS.ACCRUEINTERESTAFTERMATURITY` | Via join | | └─ compoundingFrequency | Available | `INTERESTPRODUCTSETTINGS.COMPOUNDINGFREQUENCY` | Via join | | └─ daysInYear | Available | `LOANPRODUCT.DAYSINYEAR` | Direct mapping | | └─ decoupleInterestFromArrears | Not available | `@Contract-based` | Contract-based field from `LendingProductContract` | | └─ indexRateSettings | Available | `INTERESTBASESETTINGS` + `INTERESTPRODUCTSETTINGS` + `INDEXRATESOURCE` + `INTERESTRATETIER` + `PRODUCTINTERESTRATESETTINGS` | Nested struct | |    └─ accrueInterestAfterMaturity | Available | `INTERESTBASESETTINGS.ACCRUEINTERESTAFTERMATURITY` | Via join | |    └─ allowNegativeInterestRate | Available | `INTERESTPRODUCTSETTINGS.ALLOWNEGATIVEINTERESTRATE` | Via join | |    └─ indexSourceKey | Available | `INDEXRATESOURCE.ENCODEDKEY` | Via join (from first non-null productInterestRate) | |    └─ interestChargeFrequency | Available | `INTERESTBASESETTINGS.INTERESTCHARGEFREQUENCY` | Via join | |    └─ interestChargeFrequencyCount | Available | `INTERESTBASESETTINGS.INTERESTCHARGEFREQUENCYCOUNT` | Via join | |    └─ interestRate | Available | `INTERESTPRODUCTSETTINGS` | Nested struct | |       └─ defaultValue | Available | `INTERESTPRODUCTSETTINGS.DEFAULTINTERESTRATE` | Via join | |       └─ maxValue | Available | `INTERESTPRODUCTSETTINGS.MAXINTERESTRATE` | Via join | |       └─ minValue | Available | `INTERESTPRODUCTSETTINGS.MININTERESTRATE` | Via join | |    └─ interestRateCeilingValue | Available | `INTERESTPRODUCTSETTINGS.INTERESTRATECEILINGVALUE` | Via join | |    └─ interestRateFloorValue | Available | `INTERESTPRODUCTSETTINGS.INTERESTRATEFLOORVALUE` | Via join | |    └─ interestRateReviewCount | Available | `INTERESTBASESETTINGS.INTERESTRATEREVIEWCOUNT` | Via join | |    └─ interestRateReviewUnit | Available | `INTERESTBASESETTINGS.INTERESTRATEREVIEWUNIT` | Via join | |    └─ interestRateSource | Available | `INDEXRATESOURCE.NAME` | Via join | |    └─ interestRateTerms | Available | `INTERESTBASESETTINGS.INTERESTRATETERMS` | Via join | |    └─ interestRateTiers[] | Available | `INTERESTRATETIER` | Aggregated via CTE with `collect_list()` | |       └─ encodedKey | Available | `INTERESTRATETIER.ENCODEDKEY` | Direct field | |       └─ endingBalance | Available | `INTERESTRATETIER.ENDINGBALANCE` | Direct field | |       └─ interestRate | Available | `INTERESTRATETIER.INTERESTRATE` | Direct field | |    └─ productInterestRates[] | Available | `PRODUCTINTERESTRATESETTINGS` | Aggregated via CTE with `collect_list()` | |       └─ encodedKey | Available | `PRODUCTINTERESTRATESETTINGS.ENCODEDKEY` | Direct field | |       └─ indexSourceKey | Available | `PRODUCTINTERESTRATESETTINGS.INDEXSOURCEKEY` | Direct field | |       └─ interestRate | Available | `PRODUCTINTERESTRATESETTINGS` | Nested struct | |          └─ defaultValue | Available | `PRODUCTINTERESTRATESETTINGS.DEFAULTINTERESTRATE` | Direct field | |          └─ maxValue | Available | `PRODUCTINTERESTRATESETTINGS.MAXINTERESTRATE` | Direct field | |          └─ minValue | Available | `PRODUCTINTERESTRATESETTINGS.MININTERESTRATE` | Direct field | |       └─ interestRateCeilingValue | Available | `PRODUCTINTERESTRATESETTINGS.INTERESTRATECEILINGVALUE` | Direct field | |       └─ interestRateFloorValue | Available | `PRODUCTINTERESTRATESETTINGS.INTERESTRATEFLOORVALUE` | Direct field | |       └─ interestRateReviewCount | Available | `PRODUCTINTERESTRATESETTINGS.INTERESTREVIEWCOUNT` | Direct field | |       └─ interestRateReviewUnit | Available | `PRODUCTINTERESTRATESETTINGS.INTERESTRATEREVIEWUNIT` | Direct field | | └─ interestApplicationDays | Available | `LOANPRODUCT` | Nested struct | |    └─ daysInMonth | Not available | `@Contract-based` | Complex array field from contract | |    └─ shortMonthHandlingMethod | Available | `LOANPRODUCT.SHORTMONTHHANDLINGMETHOD` | Direct mapping | | └─ interestApplicationMethod | Available | `LOANPRODUCT.INTERESTAPPLICATIONMETHOD` | Direct mapping | | └─ interestBalanceCalculationMethod | Available | `LOANPRODUCT.INTERESTBALANCECALCULATIONMETHOD` | Direct mapping | | └─ interestCalculationMethod | Available | `LOANPRODUCT.INTERESTCALCULATIONMETHOD` | Direct mapping | | └─ interestRateSettings | Not available | `@Duplicate/alias` | Duplicate/alias of `indexRateSettings` | | └─ interestType | Available | `LOANPRODUCT.INTERESTTYPE` | Direct mapping | | └─ pmtAdjustmentThreshold | Available | `LOANPRODUCT` | Nested struct | |    └─ method | Available | `LOANPRODUCT.PAYMENTMETHOD` | Direct mapping | |    └─ numberOfDays | Not available | `@Contract-based` | Contract-based field from `PMTAdjustmentThreshold` | | └─ scheduleInterestDaysCountMethod | Available | `LOANPRODUCT.SCHEDULEINTERESTDAYSCOUNTMETHOD` | Direct mapping | | **internalControls** | Available | `LOANPRODUCT` | Nested struct | | └─ dormancyPeriodDays | Available | `LOANPRODUCT.DORMANCYPERIODDAYS` | Direct mapping | | └─ fourEyesPrinciple | Available | `LOANPRODUCT` | Nested struct | |    └─ activeForLoanApproval | Available | `LOANPRODUCT.FOUREYESPRINCIPLELOANAPPROVAL` | Direct mapping | | └─ lockSettings | Available | `LOANPRODUCT` | Nested struct | |    └─ cappingConstraintType | Available | `LOANPRODUCT.CAPPINGCONSTRAINTTYPE` | Direct mapping | |    └─ cappingMethod | Available | `LOANPRODUCT.CAPPINGMETHOD` | Direct mapping | |    └─ cappingPercentage | Available | `LOANPRODUCT.CAPPINGPERCENTAGE` | Direct mapping | |    └─ lockPeriodDays | Available | `LOANPRODUCT.LOCKPERIODDAYS` | Direct mapping | | **lastModifiedDate** | Available | `LOANPRODUCT.LASTMODIFIEDDATE` | Direct mapping | | **loanAmountSettings** | Available | `LOANPRODUCT` | Nested struct | | └─ defaultValue | Available | `LOANPRODUCT.DEFAULTLOANAMOUNT` | Direct mapping | | └─ encodedKey | Available | `LOANPRODUCT.ENCODEDKEY` | Direct mapping | | └─ maxValue | Available | `LOANPRODUCT.MAXLOANAMOUNT` | Direct mapping | | └─ minValue | Available | `LOANPRODUCT.MINLOANAMOUNT` | Direct mapping | | └─ loanAmount | Available | `LOANPRODUCT` | Nested struct | |    └─ activeForLoanApproval | Available | `LOANPRODUCT.FOUREYESPRINCIPLELOANAPPROVAL` | Direct mapping | | └─ trancheSettings | Available | `LOANPRODUCT` | Nested struct | |    └─ maxNumberOfTranches | Available | `LOANPRODUCT.MAXNUMBEROFDISBURSEMENTTRANCHES` | Direct mapping | | **name** | Available | `LOANPRODUCT.PRODUCTNAME` | Direct mapping | | **newAccountSettings** | Available | `LOANPRODUCT` | Nested struct | | └─ accountInitialState | Available | `LOANPRODUCT.ACCOUNTINITIALSTATE` | Direct mapping | | └─ idGeneratorType | Available | `LOANPRODUCT.IDGENERATORTYPE` | Direct mapping | | └─ idPattern | Available | `LOANPRODUCT.IDPATTERN` | Direct mapping | | **notes** | Available | `LOANPRODUCT.PRODUCTDESCRIPTION` | Direct mapping | | **offsetSettings** | Not available | `PRODUCTOFFSETSETTINGS` | Table not in Silver stage | | └─ allowOffset | Not available | `PRODUCTOFFSETSETTINGS.ISOFFSETENABLED` | Requires table | | **paymentSettings** | Available | `LOANPRODUCT` + `PRINCIPALPAYMENTPRODUCTSETTINGS` + `PRINCIPALPAYMENTBASESETTINGS` | Complex nested struct | | └─ amortizationMethod | Available | `LOANPRODUCT.AMORTIZATIONMETHOD` | Direct mapping | | └─ latePaymentRecalculationMethod | Available | `LOANPRODUCT.LATEPAYMENTSRECALCULATIONMETHOD` | Direct mapping | | └─ paymentMethod | Available | `LOANPRODUCT.PAYMENTMETHOD` | Direct mapping | | └─ prepaymentSettings | Available | `LOANPRODUCT` | Nested struct | |    └─ applyInterestOnPrepaymentMethod | Available | `LOANPRODUCT.APPLYINTERESTONPREPAYMENTMETHOD` | Direct mapping | |    └─ elementsRecalculationMethod | Available | `LOANPRODUCT.ELEMENTSRECALCULATIONMETHOD` | Direct mapping | |    └─ ercFreeAllowance | Not available | `@Contract-based` | Contract-based or computed field | |    └─ futurePaymentAcceptance | Available | `LOANPRODUCT.FUTUREPAYMENTSACCEPTANCE` | Direct mapping | |    └─ prepaymentAcceptance | Available | `LOANPRODUCT.PREPAYMENTACCEPTANCE` | Direct mapping | |    └─ prepaymentRecalculationMethod | Available | `LOANPRODUCT.PREPAYMENTRECALCULATIONMETHOD` | Direct mapping | |    └─ principalPaidInstallmentStatus | Available | `LOANPRODUCT.PRINCIPALPAIDINSTALLMENTSTATUS` | Direct mapping | | └─ principalPaymentSettings | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS` | Nested struct via join | |    └─ amount | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS` | Nested struct | |       └─ defaultValue | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.DEFAULTAMOUNT` | Via join | |       └─ encodedKey | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.ENCODEDKEY` | Via join | |       └─ maxValue | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.MAXAMOUNT` | Via join | |       └─ minValue | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.MINAMOUNT` | Via join | | └─ defaultPrincipalRepaymentInterval | Available | `LOANPRODUCT.DEFAULTPRINCIPALREPAYMENTINTERVAL` | Direct mapping | | └─ encodedKey | Available | `LOANPRODUCT.ENCODEDKEY` | Direct mapping | | └─ includeFeesInFloorAmount | Available | `PRINCIPALPAYMENTBASESETTINGS.INCLUDEFEESINFLOORAMOUNT` | Via join | | └─ includeInterestInFloorAmount | Available | `PRINCIPALPAYMENTBASESETTINGS.INCLUDEINTERESTINFLOORAMOUNT` | Via join | | └─ percentage | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS` | Nested struct | |    └─ defaultValue | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.DEFAULTPERCENTAGE` | Via join | |    └─ encodedKey | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.ENCODEDKEY` | Via join | |    └─ maxValue | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.MAXPERCENTAGE` | Via join | |    └─ minValue | Available | `PRINCIPALPAYMENTPRODUCTSETTINGS.MINPERCENTAGE` | Via join | | └─ principalCeilingValue | Available | `PRINCIPALPAYMENTBASESETTINGS.PRINCIPALCEILINGVALUE` | Via join | | └─ principalFloorValue | Available | `PRINCIPALPAYMENTBASESETTINGS.PRINCIPALFLOORVALUE` | Via join | | └─ principalPaymentMethod | Available | `PRINCIPALPAYMENTBASESETTINGS.PRINCIPALPAYMENTMETHOD` | Via join | | └─ totalDueAmountFloor | Not available | `@Contract-based` | Contract-based or computed field | | └─ totalDuePayment | Not available | `@Contract-based` | Contract-based or computed field | | └─ repaymentAllocationOrder | Available | `LOANPRODUCT.REPAYMENTALLOCATIONORDER` | Direct mapping | | **penaltySettings** | Available | `LOANPRODUCT` | Nested struct | | └─ loanPenaltyCalculationMethod | Available | `LOANPRODUCT.LOANPENALTYCALCULATIONMETHOD` | Direct mapping | | └─ penaltyRate | Available | `LOANPRODUCT.DEFAULTPENALTYRATE` | Direct mapping | | **redrawSettings** | Available | `PRODUCTREDRAWSETTINGS` | Nested struct via join | | └─ allowRedraw | Available | `PRODUCTREDRAWSETTINGS.ALLOWREDRAW` | Via join | | **scheduleSettings** | Available | `LOANPRODUCT` | Complex nested struct | | └─ amortizationPeriod | Not available | `@Contract-based` | Contract-based or computed field | | └─ billingCycles | Not available | `@Contract-based` | Contract-based or computed field | | └─ defaultRepaymentPeriodCount | Available | `LOANPRODUCT.DEFAULTREPAYMENTPERIODCOUNT` | Direct mapping | | └─ firstRepaymentDueDateOffset | Available | `LOANPRODUCT` | Nested struct | |    └─ defaultValue | Available | `LOANPRODUCT.DEFAULTFIRSTREPAYMENTDUEDATEOFFSET` | Direct mapping | |    └─ encodedKey | Not available | `@Contract-based` | Contract-based identifier | |    └─ maxValue | Available | `LOANPRODUCT.MAXFIRSTREPAYMENTDUEDATEOFFSET` | Direct mapping | |    └─ minValue | Available | `LOANPRODUCT.MINFIRSTREPAYMENTDUEDATEOFFSET` | Direct mapping | | └─ fixedDaysOfMonth | Available | `LOANPRODUCT.FIXEDDAYSOFMONTH` | Direct mapping | | └─ interestAccrualSince | Not available | `@Contract-based` | Contract-based or computed field | | └─ numInstallments | Available | `LOANPRODUCT` | Nested struct | |    └─ defaultValue | Available | `LOANPRODUCT.DEFAULTNUMINSTALLMENTS` | Direct mapping | |    └─ encodedKey | Not available | `@Contract-based` | Contract-based identifier | |    └─ maxValue | Available | `LOANPRODUCT.MAXNUMINSTALLMENTS` | Direct mapping | |    └─ minValue | Available | `LOANPRODUCT.MINNUMINSTALLMENTS` | Direct mapping | | └─ previewSchedule | Not available | `@Contract-based` | Contract-based or computed field | | └─ repaymentMethod | Not available | `@Contract-based` | Contract-based or computed field | | └─ repaymentPeriodUnit | Available | `LOANPRODUCT.REPAYMENTPERIODUNIT` | Direct mapping | | └─ repaymentReschedulingMethod | Available | `LOANPRODUCT.REPAYMENTRESCHEDULINGMETHOD` | Direct mapping | | └─ repaymentScheduleEditOptions | Available | `LOANPRODUCT.REPAYMENTSCHEDULEEDITOPTIONS` | Direct mapping | | └─ repaymentScheduleMethod | Available | `LOANPRODUCT.REPAYMENTSCHEDULEMETHOD` | Direct mapping | | └─ roundingSettings | Available | `LOANPRODUCT` | Nested struct | |    └─ repaymentCurrencyRounding | Available | `LOANPRODUCT.REPAYMENTCURRENCYROUNDING` | Direct mapping | |    └─ repaymentElementsRoundingMethod | Available | `LOANPRODUCT.REPAYMENTELEMENTSROUNDINGMETHOD` | Direct mapping | |    └─ roundingRepaymentScheduleMethod | Available | `LOANPRODUCT.ROUNDINGREPAYMENTSCHEDULEMETHOD` | Direct mapping | | └─ scheduleDueDatesMethod | Available | `LOANPRODUCT.SCHEDULEDUEDATESMETHOD` | Direct mapping | | └─ scheduleEditOptionDetails | Not available | `@Contract-based` | Contract-based nested field | |    └─ paymentHolidaysSettings | Not available | `@Contract-based` | Contract-based nested field | |       └─ paymentHolidaysLoanTermOption | Not available | `@Contract-based` | Contract-based field | | └─ shortMonthHandlingMethod | Available | `LOANPRODUCT.SHORTMONTHHANDLINGMETHOD` | Direct mapping | | **securitySettings** | Available | `PRODUCTSECURITYSETTINGS` | Nested struct via join | | └─ isCollateralEnabled | Available | `PRODUCTSECURITYSETTINGS.ISCOLLATERALENABLED` | Via join | | └─ isGuarantorsEnabled | Available | `PRODUCTSECURITYSETTINGS.ISGUARANTORSENABLED` | Via join | | └─ requiredGuaranties | Available | `PRODUCTSECURITYSETTINGS.REQUIREDGUARANTIES` | Via join | | **status** | Available | `LOANPRODUCT.ACTIVATED` | Computed: `ACTIVE` if `ACTIVATED == 1`, else `INACTIVE` | | **taxSettings** | Available | `LOANPRODUCT` | Nested struct | | └─ taxCalculationMethod | Available | `LOANPRODUCT.TAXCALCULATIONMETHOD` | Direct mapping | | └─ taxSourceKey | Available | `LOANPRODUCT.TAXSOURCEKEY` | Direct mapping | | └─ taxesOnFeesEnabled | Available | `LOANPRODUCT.TAXESONFEESENABLED` | Direct mapping | | └─ taxesOnInterestEnabled | Available | `LOANPRODUCT.TAXESONINTERESTENABLED` | Direct mapping | | └─ taxesOnPenaltyEnabled | Available | `LOANPRODUCT.TAXESONPENALTYENABLED` | Direct mapping | | **templates** | Not available | `DOCUMENTTEMPLATEMAPPING` + `DOCUMENTTEMPLATE` | Tables not in Silver stage | | └─ [] | Not available | Multiple fields from `DOCUMENTTEMPLATE` | Requires tables | | **type** | Available | `LOANPRODUCT.LOANPRODUCTTYPE` | Direct mapping | ## Loan Transaction The `LoanTransaction` Gold data product provides comprehensive loan transaction information with nested structures for account balances, affected amounts, fees, taxes, terms, card transactions, and transaction details. | Field Path | Status | Source | Implementation Notes | | :---- | :---- | :---- | :---- | | **accountBalances** | Available | `LOANTRANSACTION` | Nested struct with 6 balance fields | | └─ advancePosition | Available | `LOANTRANSACTION.ADVANCEPOSITION` | Advance position amount | | └─ arrearsPosition | Available | `LOANTRANSACTION.ARREARSPOSITION` | Arrears position amount | | └─ expectedPrincipalRedraw | Available | `LOANTRANSACTION.EXPECTEDPRINCIPALREDRAW` | Expected principal redraw | | └─ principalBalance | Available | `LOANTRANSACTION.PRINCIPALBALANCE` | Principal balance | | └─ redrawBalance | Available | `LOANTRANSACTION.REDRAWBALANCE` | Redraw balance | | └─ totalBalance | Available | `LOANTRANSACTION.BALANCE` | Total balance | | **adjustmentTransactionKey** | Available | `LOANTRANSACTION.REVERSALTRANSACTIONKEY` | Key of reversal transaction | | **affectedAmounts** | Available | `LOANTRANSACTION` | Nested struct with 9 amount fields | | └─ deferredInterestAmount | Available | `LOANTRANSACTION.DEFERREDINTERESTAMOUNT` | Deferred interest | | └─ feesAmount | Available | `LOANTRANSACTION.FEESAMOUNT` | Fees amount | | └─ fundersInterestAmount | Available | `LOANTRANSACTION.FUNDERSINTERESTAMOUNT` | Funders interest | | └─ interestAmount | Available | `LOANTRANSACTION.INTERESTAMOUNT` | Interest amount | | └─ interestFromArrearsAmount | Available | `LOANTRANSACTION.INTERESTFROMARREARSAMOUNT` | Interest from arrears | | └─ organizationCommissionAmount | Available | `LOANTRANSACTION.ORGANIZATIONCOMMISSIONAMOUNT` | Organization commission | | └─ paymentHolidaysInterestAmount | Not available | `TRANSACTIONPAYMENTHOLIDAYSDETAILS.INTERESTAMOUNT` | Payment holidays interest (table not in Silver yet \- will be added as new field) | | └─ penaltyAmount | Available | `LOANTRANSACTION.PENALTYAMOUNT` | Penalty amount | | └─ principalAmount | Available | `LOANTRANSACTION.PRINCIPALAMOUNT` | Principal amount | | **amount** | Available | `LOANTRANSACTION.AMOUNT` | Transaction amount | | **bookingDate** | Available | `GLJOURNALENTRY.ENTRYDATE` | Date when journal entry is booked (from GLJOURNALENTRY) | | **branchKey** | Available | `LOANTRANSACTION.BRANCHKEY` | Branch where transaction was performed | | **cardTransaction** | Available | `CARDTRANSACTIONSOURCE` \+ `CARDACCEPTOR` | Nested struct with card transaction details | | └─ advice | Available | `CARDTRANSACTIONSOURCE.ISADVICE` | Whether transaction is advice | | └─ amount | Available | `CARDTRANSACTIONSOURCE.AMOUNT` | Card transaction amount | | └─ cardAcceptor | Available | `CARDACCEPTOR` | Nested card acceptor details | | └─ city | Available | `CARDACCEPTOR.CITY` | City | | └─ country | Available | `CARDACCEPTOR.COUNTRY` | Country | | └─ mcc | Available | `CARDACCEPTOR.MCC` | Merchant category code | | └─ name | Available | `CARDACCEPTOR.NAME` | Merchant name | | └─ state | Available | `CARDACCEPTOR.STATE` | State | | └─ street | Available | `CARDACCEPTOR.STREET` | Street address | | └─ zip | Available | `CARDACCEPTOR.ZIP` | ZIP code | | └─ cardToken | Available | `CARDTRANSACTIONSOURCE.CARDREFERENCETOKEN` | Card reference token | | └─ currencyCode | Available | `CARDTRANSACTIONSOURCE.CURRENCYCODE` | Currency code | | └─ encodedKey | Available | `CARDTRANSACTIONSOURCE.ENCODEDKEY` | Card transaction source key | | └─ externalAuthorizationReferenceId | Available | `CARDTRANSACTIONSOURCE.EXTERNALAUTHORIZATIONREFERENCEID` | External authorization reference | | └─ userTransactionTime | Available | `CARDTRANSACTIONSOURCE.USERTRANSACTIONTIME` | User transaction time | | **centreKey** | Available | `LOANTRANSACTION.CENTREKEY` | Centre where transaction was performed | | **creationDate** | Available | `LOANTRANSACTION.CREATIONDATE` | Transaction creation date (UTC) | | **currency** | Available | `LOANPRODUCT.CURRENCYCODE` → `CURRENCY` | Currency from loan product (nested struct) | | └─ code | Available | `CURRENCY.CODE` | Currency code (ISO-4217) | | └─ currencyCode | Available | `CURRENCY.CODE` | Currency code (same as code) | | **customPaymentAmounts** | Available | `CUSTOMPAYMENTAMOUNT` | Array of custom payment amounts | | └─ customPaymentAmountType | Available | `CUSTOMPAYMENTAMOUNT.CUSTOMPAYMENTAMOUNTTYPE` | Payment amount type | | └─ amount | Available | `CUSTOMPAYMENTAMOUNT.AMOUNT` | Custom payment amount | | └─ taxOnAmount | Available | `CUSTOMPAYMENTAMOUNT.TAXONAMOUNT` | Tax on amount | | └─ predefinedFeeKey | Available | `CUSTOMPAYMENTAMOUNT.PREDEFINEDFEEKEY` | Predefined fee key | | **encodedKey** | Available | `LOANTRANSACTION.ENCODEDKEY` | Primary key (UUID) | | **externalId** | Available | `LOANTRANSACTION.EXTERNALID` | External ID | | **fees** | Available | `PREDEFINEDFEEAMOUNT` \+ `PREDEFINEDFEE` | Array of fee structures | | └─ amount | Available | `PREDEFINEDFEEAMOUNT.AMOUNT` | Fee amount | | └─ name | Available | `PREDEFINEDFEE.NAME` | Fee name | | └─ predefinedFeeKey | Available | `PREDEFINEDFEEAMOUNT.ENCODEDKEY` | Predefined fee key | | └─ taxAmount | Available | `PREDEFINEDFEEAMOUNT.TAXAMOUNT` | Tax amount on fee | | └─ trigger | Available | `PREDEFINEDFEE.TRIGGER` | Fee trigger | | **id** | Available | `LOANTRANSACTION.TRANSACTIONID` | Transaction ID | | **installmentEncodedKey** | Not available | `CUSTOMREPAYMENTTRANSACTIONSETTINGS.INSTALLMENTKEY` | Installment key (table not in Silver yet \- will be added as new field) | | **migrationEventKey** | Available | `LOANTRANSACTION.MIGRATIONEVENTKEY` | Migration event key | | **notes** | Available | `LOANTRANSACTION.COMMENT` | Transaction notes/comment | | **originalAmount** | Available | `LOANTRANSACTION.ORIGINALAMOUNT` | Original amount in foreign currency | | **originalCurrencyCode** | Available | `LOANTRANSACTION.ORIGINALCURRENCYCODE` | Original currency code | | **originalTransactionEncodedKey** | Available | `LOANTRANSACTION` (self-join) | Original transaction key (for reversal transactions) | | **parentAccountKey** | Available | `LOANTRANSACTION.PARENTACCOUNTKEY` | Parent loan account key | | **parentLoanTransactionKey** | Available | `LOANTRANSACTION.PARENTLOANTRANSACTIONKEY` | Parent loan transaction key | | **prepaymentRecalculationMethod** | Available | `LOANPRODUCT.PREPAYMENTRECALCULATIONMETHOD` | Prepayment recalculation method | | **taxes** | Available | `LOANTRANSACTION` \+ `INDEXRATE` | Nested struct with tax amounts and rate | | └─ deferredTaxOnInterestAmount | Available | `LOANTRANSACTION.DEFERREDTAXONINTERESTAMOUNT` | Deferred tax on interest | | └─ taxOnFeesAmount | Available | `LOANTRANSACTION.TAXONFEESAMOUNT` | Tax on fees | | └─ taxOnInterestAmount | Available | `LOANTRANSACTION.TAXONINTERESTAMOUNT` | Tax on interest | | └─ taxOnInterestFromArrearsAmount | Available | `LOANTRANSACTION.TAXONINTERESTFROMARREARSAMOUNT` | Tax on interest from arrears | | └─ taxOnPaymentHolidaysInterest | Not available | `TRANSACTIONPAYMENTHOLIDAYSDETAILS.TAXONINTERESTAMOUNT` | Tax on payment holidays interest (table not in Silver yet \- will be added as new field) | | └─ taxOnPenaltyAmount | Available | `LOANTRANSACTION.TAXONPENALTYAMOUNT` | Tax on penalty | | └─ taxRate | Available | `INDEXRATE.RATE` | Tax rate | | **terms** | Available | `LOANTRANSACTIONTERMS` \+ `INDEXRATE` \+ `LOANTRANSACTION` | Nested struct with interest settings and payment terms | | └─ interestSettings | Available | Nested struct | Interest rate settings | | └─ indexInterestRate | Available | `INDEXRATE.RATE` | Index interest rate | | └─ interestRate | Available | `LOANTRANSACTION.INTERESTRATE` | Transaction interest rate | | └─ periodicPayment | Available | `LOANTRANSACTIONTERMS.PERIODICPAYMENT` | Periodic payment amount | | └─ principalPaymentAmount | Available | `LOANTRANSACTIONTERMS.PRINCIPALPAYMENTAMOUNT` | Principal payment amount | | └─ principalPaymentPercentage | Available | `LOANTRANSACTIONTERMS.PRINCIPALPAYMENTPERCENTAGE` | Principal payment percentage | | **tillKey** | Available | `LOANTRANSACTION.TILLKEY` | Till key | | **transactionDetails** | Available | `TRANSACTIONDETAILS` \+ `TRANSACTIONCHANNEL` | Nested struct with transaction channel info | | └─ transactionChannelKey | Available | `TRANSACTIONDETAILS.TRANSACTIONCHANNELKEY` | Transaction channel key | | └─ transactionChannelId | Available | `TRANSACTIONCHANNEL.ID` | Transaction channel ID | | **transferDetails** | Available | `LOANTRANSACTION` \+ `SAVINGSTRANSACTION` | Transfer details (complex logic \- multiple enhancers, TRANSFER transaction handling \- will be added as new field) | | **type** | Available | `LOANTRANSACTION.TYPE` | Transaction type | | **userKey** | Available | `LOANTRANSACTION.USERKEY` | User who performed the transaction | | **valueDate** | Available | `LOANTRANSACTION.ENTRYDATE` | Value date (entry date in organization time) | --- # Getting Started with Mambu Insights URL: https://docs.mambu.com/docs/insights-getting-started/ This guide introduces the core components of Mambu Insights: the [Mambu Data Lake](#mambu-data-lake-introduction) and the [Agentic AI framework (Mambu Copilot)](#agentic-ai-mambu-copilot-introduction). Understanding these concepts is the first step toward unlocking the full potential of your banking data. ## Mambu Data Lake introduction The Mambu Data Lake is a centralized, cloud-native repository designed to hold all your Mambu data. It addresses the common challenges of data extraction by providing a scalable and unified source for analytics, reporting, and integration, with minimal impact on your core banking engine's performance. Key features include: * **Near real-time data updates**: Access complete, accurate, and timely data that is updated hourly. * **Domain-aligned data products**: Instead of exposing raw database tables, Mambu Insights provides ready-to-use "Gold Standard" data products that are aligned with Mambu's domain models and APIs. This eliminates your exposure to internal Mambu data models and protects you from breaking changes. * **Modern data formats**: The Data Lake uses open formats like [Parquet](https://parquet.apache.org/) and [Delta Lake](https://delta.io/), making it easy to integrate with modern data platforms. ## Agentic AI (Mambu Copilot) introduction Mambu Copilot is the intelligence layer of Mambu Insights. It uses an agentic AI framework to analyze your data, uncover hidden trends, and deliver actionable insights directly to you. How it works: * **Proactive discovery**: AI agents run automatically on your data to identify opportunities and risks across different domains, such as lending, deposits, customer segmentation, and compliance. * **Actionable recommendations**: Mambu Copilot doesn't just present data; it provides clear, concise insights and recommends actions you can take. For example, it might identify a liquidity risk from foreign currency accounts and suggest implementing FX hedging strategies. * **Conversational interface**: You can interact with the Mambu Copilot Assistant via a chat interface to ask follow-up questions, request deeper analysis, or get guidance on implementing solutions using Mambu APIs. This AI-driven approach transforms your data from a passive asset into a proactive, competitive advantage. --- # Mambu Data Lake URL: https://docs.mambu.com/docs/insights-mambu-data-lake/ The Mambu Data Lake is the foundation of Mambu Insights. It provides a robust and scalable architecture for ingesting, processing, and storing your banking data, making it ready for analysis and integration. ## Architecture overview The data journey in Mambu Insights follows a structured ETL (Extract, Transform, Load) process that ensures data quality and usability. 1. **Mambu Core Banking Engine database**: This is the single source of truth for all financial product data. 2. **Mambu Delta Extract**: All changes from the core banking database are captured in near-real time through a Change Data Capture (CDC) stream. This process has minimal impact on the performance of your operational database. This raw, replicated data is landed in the Bronze layer of the data lake. 3. **Mambu Gold Standard ETL pipelines**: The raw data is then cleaned, transformed, and modeled into structured, domain-aligned data products. These curated datasets reside in the Gold layer of the data lake and are ready for consumption. 4. **Data access**: You can access the Gold Standard data products via direct object storage access (S3) or through integrations with platforms like [Snowflake](https://www.snowflake.com/en/) and [Databricks Delta Share](https://www.databricks.com/product/delta-sharing). ## Base data products Initially, Mambu Insights provides a set of **Gold Standard base products**. These products are modeled after Mambu's core entities and provide a comprehensive view of your deposit and lending portfolios. * Activity * Branch * Client * Credit Arrangement * Deposit Product * Deposit Account * Deposit Transaction * GL Account * GL Journal Entry * Group * Loan Product * Loan Account * Loan Transaction For more information on the Gold Standard product offerings and field availability, refer to the [Insights Data Catalog](/docs/insights-data-catalog). These products ensure you have access to clean, reliable, and versioned data without needing to understand the complexities of Mambu's internal database schema. --- # Operations and Monitoring URL: https://docs.mambu.com/docs/insights-operations-and-monitoring/ Mambu Insights provides a dedicated user interface (UI) to help you monitor the health of your data pipelines, track consumption, and manage your data products effectively. ## Data Products Dashboard The main dashboard in the Mambu Insights UI gives you a centralized view of all the data products you are subscribed to. From here, you can quickly assess the status of your data. Key monitoring features include: * **Last updated timestamp**: See exactly when each data product was last successfully refreshed. * **Last run duration**: Monitor the time it took for the last ETL job to complete, helping you understand performance. * **Credits spent**: Track the number of Mambu Insights Credits (MICs) consumed by each update job, allowing for transparent cost management. For more information on pricing, refer to [Pricing and Consumption](/docs/insights-pricing-and-consumption) * **Update frequency**: View the configured refresh rate for your data products, which is typically hourly. ## Job scheduler and configuration Mambu Insights includes a Job Scheduler that manages the execution of the ETL pipelines to keep your data products up to date. Through the UI, you will be able to configure the refresh frequency and compute size (MCU) for your data pipelines to balance freshness requirements with cost efficiency. ## Mambu Copilot Discovery The UI also features the Mambu Copilot Discovery section, where you can view the latest insights generated by the AI agents. You can browse a list of all agentic insights categorized by domain (e.g., Loan Insights, Deposit Insights) and explore the details of each finding. --- # Pricing and Consumption URL: https://docs.mambu.com/docs/insights-pricing-and-consumption/ Mambu Insights uses a hybrid pricing model that combines the predictability of a fixed subscription with the flexibility of usage-based consumption, ensuring you only pay for what you use. You will be able to subscribe and use any product as listed on this page to be used and billed accordingly, with credits always debited from your annual subscription. ## SaaS Yearly Subscription Fee (Fixed) This is a fixed annual fee tiered based on your transactional volume, measured in Transactions Per Second (TPS). This fee covers the core platform components: * Product licensing and UI access * Platform observability, operations, and security * Core Banking Engine data streaming for one production tenant. ## Mambu Insights Credits (Variable) Credits are the currency of the Mambu Insights platform and are used to pay for variable consumption of resources. You purchase credits in bundles, which are then consumed for the following activities: ### Storage You are charged for the amount of compressed data stored in the Mambu Data Lake (AWS S3). * **Rate**: 100 credits per Terabyte per month. * **Billing**: Usage is metered on the first day of each month, and the corresponding credits are debited from your balance. ## Compute Compute resources for running data pipelines are measured in Mambu Compute Units (MCUs). Each data product update consumes credits based on: * **MCU size**: Workers are available in T-shirt sizes (e.g., XS, S, M), with larger sizes consuming more credits per hour but processing data faster. * **Execution duration**: You are billed for the time an MCU is active, with a one-minute minimum charge. This model allows you to control costs by configuring the frequency and compute power for each of your data pipelines. --- # Security URL: https://docs.mambu.com/docs/insights-security/ Security is a foundational pillar of Mambu Insights. The platform is designed with robust controls to ensure your data is protected and access is managed securely. ## Data isolation and tenancy Your Mambu Insights environment runs on a dedicated instance, meaning your data and all related services are logically and physically isolated from those of other Mambu customers. Each customer has their own logically isolated tenant within the platform, addressable via a dedicated URL. ## Data access and connectivity * **No public exposure**: Data is never exposed to the public internet. Access to the Mambu Data Lake is provided exclusively via secure private connectivity options like [AWS PrivateLink](https://aws.amazon.com/privatelink/). * **Object storage access**: Data access is limited to the object storage layer (S3). There is no direct access to the underlying databases, reducing the attack surface. * **Role-based access control**: Future phases will introduce granular role-based access control within the UI, allowing you to define which users can view, manage, or configure specific data products and platform settings. ## AI and data privacy Mambu ensures the privacy of your data when using Mambu Copilot's agentic AI capabilities. * **Third-party LLM usage**: Mambu uses secure services like [AWS Bedrock](https://aws.amazon.com/bedrock/) to pre-train and power its AI agents. * **No training on customer data**: Your customer data will never be used to train or improve the underlying third-party large language models (LLMs). All session data remains private and is not persisted by the LLM provider. --- # Defining and Installing Mambu Apps URL: https://docs.mambu.com/docs/installing-apps/ A Mambu App is defined in an XML file, which contains information about the application that the Mambu App will communicate with, and which specifies where the App is to be located in the Mambu UI. ## 1. Create an XML Mambu App definition The definition can be split into two categories: - General definitions: The ID, name, and description. - Extension points: The location information of the Mambu App within the UI. These fields are explained in the table below. ### Example: Mambu App XML Definition The example below connects to a .Net application hosted in Heroku that provides interest rates for different countries. The Mambu App is a window that shows the interest rate in the current tenant's base currency. The XML would look something like this: ```xml gj8dl19d0 Interest Rates Now Interest Rater A tool to see the current interest rate REPORTING_VIEW https://interestrater.herokuapp.com/ ```
    | Field | Type | Description | Required | | -- | -- | -- | -- | | `id` | Alphanumeric | The unique id of the application. This is used as the App ID for authenticating API calls. Can be up to 256 characters long. | Yes | | `name` | String | The display name of the Mambu App. Can be up to 256 characters long. | Yes | | `provider` | String | The name of the application provider. No character limit. | | No | | `description` | String | A short description of the App. Only 256 characters are shown in some UI screens, but the character length is unlimited. | No | | `uninstallURL` | URL | The URL to call when a Mambu App is uninstalled. It must use HTTPS for security. | No | | `installURL` | URL | The URL to call when a Mambu App is installed. It must use HTTPS for security. | No | | `extensionpoint` | XML object | Extension points define the location in the Mambu UI where the App should appear. An extension point may be just the extensions or reporting menu, or it could be contextual such as showing the view for a branch, a client or a user. | Yes | | `extensionpoint.location` | String | The location in the Mambu UI where the App should appear. Possible values:
    • BRANCH_VIEW: Shown as a tab under a branch
    • CENTRE_VIEW: Shown as a tab under a centre
    • CLIENT_VIEW: Shown as a tab under clients' profiles
    • DEPOSIT_ACCOUNT_VIEW: Shown as a sub-tab for clients' deposit accounts
    • DEPOSIT_PRODUCT_VIEW: Shown as a tab under a deposit product
    • EXTENSION_MENU: Shown as a drop-down menu item under the App view
    • GROUP_VIEW: Shown as a tab under a group's profile
    • LINE_OF_CREDIT_VIEW: Shown as a sub-tab for clients' credit arrangements
    • LOAN_ACCOUNT_VIEW: Shown as a sub-tab for clients' loan accounts
    • LOAN_PRODUCT_VIEW: Shown as a tab under a loan product
    • REPORTING_VIEW: Shown as a tab under the reporting view
    • USER_VIEW: Shown as a tab under users' profiles
    | Yes | | `extensionpoint.label` | String | The interface tab or menu label to show for this extension point. Can be up to 256 characters long. | Yes | | `extensionpoint.url` | URL | This URL is used to load Apps and to authenticate them. It must use HTTPS for security. | Yes | ## 2. Load the App into the Mambu UI After your app has been defined in an XML file, the file will need to be uploaded into the Mambu UI. This is done using a source URL, so you will need to first upload the XML file onto a server and use the URL link to the file. You may use a cloud drive to host the XML file. The URL must begin with `http` or `https` and it cannot be a local address or file location. :::warning We strongly recommend using HTTPS whenever possible to add an additional layer of security in your communication. ::: 1. Log in to the Mambu UI and navigate to **Administration** > **Apps**. Click on **Add App**. 2. Specify the URL of the XML file in the **Source URL** field and click **Load** for the App's definition to be loaded. ![Enter the URL where the XML file can be loaded from](@site/static/img/support/mambu-apps-load-url-2874x714.png) 3. Enter the **App Key**, which is used to secure communication between the Mambu App and your application. The App Key can be up to 32 characters long and you may use symbols, numbers, and letters. You will use the same App Key in your application to [authenticate requests](/docs/authenticating-requests). ![Enter an App Key to complete loading the App](@site/static/img/support/mambu-load-apps-2428x1210.png) 4. Click **Save Changes** to save the App. Once the App is saved, the XML data is validated and the App's properties are loaded. Apps can disabled or uninstalled from the Actions menu in the **Administration** > **Apps** view. Click the **Actions** button to the right of the App you want to edit to reveal options to do this. ![The Mambu Apps list, where you can edit Apps](@site/static/img/support/mambu-apps-list-2874x714.png) --- # Installments on Non-Working Days URL: https://docs.mambu.com/docs/instalments-on-non-working-days/ This setting can be found in the **Repayment Scheduling** section of the **Creating a New Loan Product** form and determines what happens to loan repayments that fall on non-working days. ![Non Working Days Rescheduling with four options.](@site/static/img/support/loans--non-working-days-rescheduling.png) ## Do not reschedule repayments Mambu will not modify schedules for non-working days. If an installment is due on a non-working day it will be left as it is. ## Move ahead to next working day Mambu will modify loan schedules, so any installment that would be due on a non-working day will be moved ahead to the **next** working day. ## Move backward to previous working day Mambu will modify loan schedules, so any installment that would be due on a non-working day will be moved back to the **previous** working day. ## Extend Schedule When an installment is due on a non-working day, Mambu will shift that installment and all further installments by one installment period. For example, for a weekly installment loan where an installment would be due on a non-working day, the week with the holiday will have no installment. The whole remaining schedule will be pushed one week ahead, meaning that the loan will keep its payment day and be one week longer due to the skipped week. --- # Inter-Branch Transfer GL Account URL: https://docs.mambu.com/docs/inter-branch-transfer-gl-account/ An inter-branch transfer general ledger (GL) account is needed to correctly book any transactions affecting GL balances in two different branches in order to keep the integrity of the balance sheet at the branch level. You can define the rules that determine which GL accounts will be used for particular inter-branch transfers under **Administration** > **Financial Setup** > **Accounting**. ![The administration screen with the Inter-Branch Transfer GL account rules](@site/static/img/support/administration-screen-branch-transfer-gl-account-rules-2880x940.png) ## Inter-Branch Transfer GL Account Rules section The inter-branch transfer GL account rules consist of one default rule and additional custom rules which you can define. Access to this section can now be given as a separate permission using the "Manage Inter-Branch Transfer GL Account Rules" that can be found under User Permissions > Administration. ### Default rule The default rule is pre-populated with **All Branches**, which does not include unassigned, and can use any GL account of the asset typ in your organization's base currency. :::warning We strongly recommend that you set an inter-branch transfer GL account for this rule, even if you do not currently use branches. If you do not set a general ledger account for the default rule, it will not be possible to move a client or customer account from one branch to another and your books may end up unbalanced if a customer makes a transfer at a different branch to their own - as there will be no automatic balancing in your chart of accounts. ::: ### Custom rules Additional custom rules can be added between branches. To add a custom rule: 1. On the main menu, go to **Administration** > **Financial Setup** > **Accounting**. 2. Select **Add** . 3. Enter an **ID** (optional). If an ID is not entered then it will be automatically generated when saving the custom rule. The ID is used to manage the accounting rules using the API and also helps identify the same rules when working across Mambu instances, for example, your production and sandbox tenants. 3. Enter the two branches for which you want to specify a GL account for inter-branch transfers. 4. Use the dropdown to select the desired GL account. 5. Select **Save Changes**. To delete a custom rule, select **Delete** . :::warning Please be aware You cannot delete a branch if rules are defined for it and if clients or groups are assigned to it. Also, it will not be possible to delete a GL account which has been used in a rule. ::: When a user, who is not assigned to a branch, posts a transaction, for a client who is assigned to a branch, the journal entries will be logged in the client's branch and will not be logged through the inter-branch transfer GL account. ## Accounting in Multicurrency The Accounting in Multicurrency feature allows you to set new rules between branches for each currency. For example, you can define one rule with a GL account in EUR for inter-branch transfers between Branch A and Branch B. You can also define another rule with a GL account in GBP for inter-branch transfers between Branch A and Branch B. :::warning Rates need to be set immediately after enabling the Accounting in Multicurrency feature to cover all time periods, including the one before the feature is enabled. For more information, see [Accounting Rates](/docs/accounting-setup#accounting-rates). ::: If you have Accounting in Multicurrency enabled, we strongly recommend setting a rule for each foreign currency used. ![Setting up multicurrency rules in the Administration screen](@site/static/img/support/administration-screen-multicurrency-1233x769.png) ## Usage and examples The inter-branch transfer GL account will be used by Mambu to log automatic journal entries in the following scenarios: ### When a transfer transaction is posted between clients assigned to different branches An example of journal entries when a transfer of 100 is made from a deposit from a client assigned to Branch A to a deposit for a client assigned to Branch B: Dr Savings Control of Member in Branch A 100 Cr Inter-branch account for Branch A 100 Dr Inter-branch account for Branch B 100 Cr Savings Control of Member in Branch B 100 ### When a client is assigned to a different branch An example of a client with 500 outstanding loan portfolio and 100 interest balance assigned from Branch A to Branch B: Dr Inter-branch account for Branch A 600 Cr Loan Portfolio in Branch A 500 Cr Interest Receivable in Branch A 100 Dr Loan Portfolio in Branch B 500 Dr Interest Receivable in Branch B 100 Cr Inter-branch account for Branch B 600 ### When a user assigned to one branch posts a transaction for a client assigned to a different branch An example of a Credit Officer assigned to Branch A posting a repayment of 500 for a Client in Branch B via Cash: Dr Cash in Branch A 500 Cr Inter-branch account for Branch A 500 Dr Inter-branch account for Branch B 500 Cr Loan Portfolio in Branch B 400 Cr Interest Receivable in Branch B 100 ### When a user unassigned to a branch posts a transaction for a client assigned to a branch An example of a Credit Officer unassigned to a branch posting a repayment of 500 for a Client in Branch B via Cash: Dr Cash in Branch B 500 Cr Loan Portfolio in Branch B 400 Cr Interest Receivable in Branch B 100 :::note The net balance on the inter-branch transfer account should always be zero across all branches. For example, debits in Branch A will always be equal to credits in Branch B. ::: ## Manual Journal Entries When posting manual journal entries for an inter-branch transaction with an inter-branch transfer GL account defined, the user will need to manually define the relevant journal entries for the inter-branch transfer GL account as well. An error message will be displayed otherwise. --- # Interest Application URL: https://docs.mambu.com/docs/interest-application/ Whenever accrued interest is applied on an account, it means that the interest has been recognized as income in the case of loan accounts or overdrafts and as an expense for interest paid to client deposit accounts. When interest is posted, an Interest Applied transaction is created to update the account balances. Automatic interest posting on accounts is controlled by the Loan or Deposit Product settings, please see the relevant settings for [Loan](/docs/setting-up-new-loan-products) and [Deposit](/docs/setting-up-new-deposit-products) products. Interest can also be applied manually, as described below. *** ## Manually Apply Interest To manually apply interest: 1. Open the account. 2. On the right hand side of the screen, go to **More** > **Apply Accrued Interest**. 3. Confirm the date. 4. Select **Apply**. ![Manually apply accrued interest to an account](@site/static/img/support/apply-accrued-interest.png) As a result, one or multiple _Interest applied_ transactions will be posted on the account. The amount of interest applied reflects the interest accrued in the given period. The interest accrued is calculated using the product settings. *** ## Undo Interest Applied Interest is applied under the form of transactions. As such, to undo the interest applied, you must adjust the corresponding transaction(s). To adjust an interest applied transaction: 1. Open the account. 2. Go to the **Transactions** tab. 3. Find the transaction for which you want to undo the _Apply Interest_ operation and, on the right-hand side of the row, select **Actions** > **Adjust**. 4. Add a reason. 5. Select **Adjust Interest Applied**. ![Undo interest applied by adjusting the corresponding transaction](@site/static/img/support/adjust-interest-applied.png) --- # Interest Calculation Methods in Deposit Accounts URL: https://docs.mambu.com/docs/interest-calculation-methods-in-deposit-accounts/ In this article we discuss how we calculate the deposit interest, overdraft interest, and how we manage days in a year. ## Deposit interest calculation In deposit products, interest is accrued daily on the account and applied at a later time. Both the balance used for accruing the interest and the date to apply it are defined by the settings explained in this article. ### What account balance is used for calculations? * **Average Daily Balance**: Mambu will calculate the average balance that the client had in their account during the day, and base the interest calculation on that amount. * **Minimum Daily Balance**: Mambu will base the interest calculation on the minimum balance the client had in their account during the day. * **End of Day Balance**: Mambu will base the interest calculation on the balance the client had in their account at the end of the day. For this method, you can also choose a **Maximum Balance** to be used for interest calculation and if the end of day balance is greater than the maximum balance, then Mambu will base the interest calculation on the maximum balance value instead and will only use the end of day balance when it falls below the maximum balance. :::warning The first transaction dictates the account's opening balance. ::: ### Example Day 1 * No transactions. The account is not activated yet. * The average daily balance for interest calculation is 0. * The minimum daily balance for interest calculation is 0. * The end of day balance for interest calculation is 0. Day 2 (starting account balance = 40) * A deposit of 40 is made, the account is activated and the balance is 40. * A withdrawal of 5 is made, the balance is 35. * A deposit of 25 is made, the balance is 60. * The average daily balance for interest calculation (40+35+60)/3 = 45 * The minimum daily balance for interest calculation is 35. * The end of day balance for interest calculation is 60. Day 3 (starting account balance = 60) * No transactions. * The average daily balance for interest calculation is 60. * The minimum daily balance for interest calculation is 60. * The end of day balance for interest calculation is 60. ![Interest Rate section with Interest paid into account option checked](@site/static/img/support/deposits--interest-rate-configuration.png) ### When is the interest paid into the account? For more information about all the available options for when interest can be paid into the account, see [Setting up new deposit products](/docs/setting-up-new-deposit-products#when-is-the-interest-paid-into-the-account). ## Overdraft interest calculation In deposit products with overdraft, interest is also accrued daily on the account and applied at a later time. Both the balance used for accruing the interest and the date to apply it are defined by the settings explained in this article. ### What account balance is used for calculations? When using the **Minimum daily balance** option, Mambu will calculate interest based on the maximum amount the client has overdrawn for a given day. This means that if an account was overdrawn by 100 EUR in the morning and the account holder makes a payment of 50 EUR in the afternoon, interest will still be charged on a value of 100 EUR. ### When is the interest paid into the account? Interest will be accrued daily when an account has gone overdraft and will be paid into the account at the same frequency as any interest from positive balance would be. This is configurable in the product settings in the **Interest rate** section. For more information on how to configure this option, see [Overdraft products](/docs/overdraft-products#overdraft-setup) . Just like for positive balance interest, interest accrued from overdrafts can also be applied manually. From the account detail page for an account with **Overdraft Accrued Interest** greater than 0, select **More** > **Apply Accrued Interest**. Both manually and automatically applied interest transactions can be adjusted by following the steps in [Interest application](/docs/interest-application#undo-interest-applied). ### Interest rate terms Two interest rate terms are available for Overdraft interest: Fixed & Tiered per Balance. ### Tiered interest rate terms When selecting a Tiered interest rate, you can select a starting and ending balance for each tier and an associated interest rate. When interest is accrued on the account, Mambu determines the Overdraft interest rate from the tier corresponding to the account's Minimum Balance at accrual moment (mathematical minimum; which, if the balance is negative, is the equivalent of the maximum overdrawn amount). The Overdraft interest rate displayed on the account is updated based on the current account balance and is changed every time the account balance matches another tier. When selecting the **Current Interest Tier** in the **Account Details** tab, a dialog is displayed showing all the tiers that are available for that account. When changing the positive interest rate tiers on the product, you can choose to update existing accounts with the current changes performed on the tiers. :::note The tiers can be printed in contracts and any other product documents using available placeholders. These placeholders can be indexed with the tier number, so all the tiers defined in the product can be printed in the document. For example: * Tier 1 Interest Rate: `\` * Tier 2 Interest Rate: `\` ::: ### Fixed interest rate terms When selecting **Fixed Interest** terms for a deposit product, it implies a set overdraft interest rate that is constant. At product level, you can set the minimum and maximum constraints for interest rates available for accounts under that product. These overdraft interest rate constraints can be changed in retrospect and applied to either all existing and new accounts or only new accounts. At account level, any overdraft interest rate rounded to two decimal places can be set within the product constraints. Deposit accounts under the same product can have different overdraft interest rates, as long as they remain within the set contstraints. ## Interest rate source Two sources of interest rates are supported for overdraft interest: fixed and indexed interest. This section is not available if there isn't any index rate defined in the Administration module. For more information, see [Customizing Index Interest Rates and Tax Rates](/docs/customizing-index-rates#interest-rate). :::warning Interest source can be defined at the moment only for the overdraft interest. ::: ### Fixed Interest Rate A fixed interest rate is agreed upon at account opening and remains fixed until renegotiated. #### Example Let's assume an Overdraft account with a 10% overdraft interest rate and interest calcuated based on the Minimum daily balance. Day 1: * Starting account balance: USD0 * At 10:00:00 a withdrawal of USD100 is made, account balance is -USD100 * At 20:00:00 a second withdrawal of USD200 was made, account balance is -USD300 * End of day balance: -USD300 = Minimum daily balance * Overdraft interest for Day 1: -USD300 (Minimum balance from Day 1) * 10% (Overdraft daily interest rate) = -USD30 * Total accrued interest on account: -USD30 Day 2 * Starting account balance: -USD300 * No transactions are posted that day * End of day balance -USD300 = Minimum daily balance * End of day accrued interest on account: -USD30 (from Day 1) * Overdraft interest for Day 2: - 300 (Minimum balance from Day 2) * 10% (Overdraft Interest rate) = -USD30 * Total accrued interest on account: -USD60 ### Index Interest Rate A floating interest rate is also known as a variable or adjustable rate. It is calculated as the sum of a reference (benchmark) index interest rate and a specified spread (margin). As a result, index interest rates will change as the reference (benchmark) index interest rate changes. By selecting the Index Interest Rate option, you can define: * **Interest Spread constraints**: The constraints of spread that will be added to the reference index rate. * **Interest Rate Review Frequency**: How often the overdraft interest rate should be updated or reviewed. Index Rates are managed under **Administration** > **Financial Setup** > **Rates**, where you can create and manage index rate sources as well as update the rates. Additionally, the frequency for which the interest is reviewed is determined when creating a product. If there is a new index rate at the end of the indicated frequency period, the index interest rate will be updated and Mambu will log an overdraft interest rate changed transaction on the account to mark that the rate was changed at that time. :::warning Mambu does not support negative interest rate from overdrafts. If index interest rate source has a negative sign, please make sure that: `Index rate + Interest spread > 0` If you need to use negative interest rate on overdraft, please contact us through [Mambu Support](/docs/mambu-support). ::: #### Example One of the most common reference rates to use as the basis for applying floating interest rates is the London Inter-bank Offered Rate (LIBOR) - the rates at which large banks lend to each other. We have based our example on the LIBOR index (reference) rate, reviewed daily and spread of 1% and interest calculated based on the Minumum daily balance. Day 1 * LIBOR Overnight on Day 1 = 0.2% * Overdraft daily Interest rate = 0.2% LIBOR Overnight on Day1 + 1% Spread = 1.2% * Starting account balance: `0 * At 10:00:00 a withdrawal of USD100 is made, account balance is -USD100 * At 20:00:00 a second withdrawal of USD200 was made, account balance is -USD300 * End of day balance -USD300 = Minimum daily balance. * Overdraft interest for Day 1: -USD300 (Minimum balance from Day 1) * 1.2% (Overdraft daily Interest rate) = -USD3.6 * Total accrued interest on account: -USD3.6 Day 2 * LIBOR Overnight on Day 1 = 0.5% * Overdraft daily Interest rate = 0.5% LIBOR Overnight on Day 2 + 1% Spread = 1.5% * Starting account balance: -USD300 * Accrued interest on account: -USD3.6 * No transactions are posted that day * End of day balance -USD300 = Minimum daily balance * Overdraft interest for Day 2: -USD300 (Minimum balance from Day 2) * 1.5% (Overdraft daily Interest rate) = -USD4.5 (Day 2 interest accrued) * Total accrued interest on account: -USD8.1 (the sum of accrued interest on Day 1 and Day 2) ## Days in Year The day count convention, also referred to as day count fraction or day count, determines how interest accrues over time. Because months and years have different numbers of days, calculating interest for different periods can be complicated and susceptible to error. To address this, day count conventions were developed to standardise this methodology, to avoid disputes and provide uniformity and transparency. Based on the market and financial product, you can choose from the following day count conventions that Mambu has to offer. ### Actual/365 Fixed (365 Days) The Actual/365 Fixed is a day count convention that counts the actual number of days in each month, but deems each year to be 365 days. It applies in leap years as well as in normal years. #### Example Let’s consider a loan with the following terms. Loan amount : USD 1000 Interest rate: 10% per year Number of installments: 5 Formula:`Annual Interest Rate * Outstanding Principal Balance/365 * Number Of Days In The Target Month`Interest expected for one month with 30 days: 10%* 1000/365 * 30 = USD 8.22 Interest expected for one month with 31 days: 10%* 1000/365 * 31 = USD 8.49 ### Actual/360 (360 Days) Actual/360 is a day count convention that counts the actual number of days in each month, but deems each year to be 360 days. #### Example For the same loan terms as in the example above, the interest expected is calculated as follows. Formula:`Annual Interest Rate * Outstanding Principal Balance/360 * Number Of Days In The Target Month`Interest expected for one month with 28 days: 10%* 1000/360 * 28 = USD 7.78 Interest expected for one month with 31 days: 10%* 1000/360 * 31 = USD 8.61 ### 30E/360 ISDA (30/360 German) The 30E/360 ISDA day count convention deems all months to be 30 days in length and each year to be 360 days. With this method, the interest accrues at a daily interest rate equal to 1/360th of the interest rate, but for each full month is deemed to accrue for 30 days, regardless whether the month has 28, 29, 30, or 31 days. Therefore, for a month with 31 days, the number of accrued interest days will be the same on the 31st of that month as on the 30th while the last day of February is considered to be the 30th day of the month. In all cases, with this day count convention, the total number of days in a year will always be 360. #### Example For the same loan terms as in the examples above, the interest expected is calculated as follows: Formula:`Interest = Annual Interest Rate * Outstanding Principal Balance/360 * 30$ Interest expected for one month with 28 days: 10%* 1000/360 * 30 = USD 8.33 Interest expected for one month with 31 days: 10%* 1000/360 * 30 = USD 8.33 ### Actual/Actual ISDA Calculates the interest daily by counting the number of days in the calendar and also considers leap years. --- # Interest Calculation Methods in Loans URL: https://docs.mambu.com/docs/interest-calculation-methods-in-loans/ Interest on loans is accrued on a daily basis, which allows you to charge your clients only for the days they used the loan amount. For example, if a client pays back the loan amount before the due date, Mambu will display the exact interest amount that the client owes at that moment. Also, when a repayment is late, interest will keep accumulating each day. The only calculation method in which interest is not accrued in Mambu is [Fixed Flat](#fixed-flat). When using this method, the interest always reflects the amount that would be due on the due date, regardless of the actual payment date. There are three different interest calculation methods you can choose from for your loan product: * [Fixed Flat](#fixed-flat) * [Declining Balance](#declining-balance) * [Declining Balance (Equal Installments)](#declining-balance-equal-installments) When [creating a new loan product](/docs/setting-up-new-loan-products#create-a-new-loan-product), you must choose one of these methods for that product and all the accounts created under it. Below you can find an example of how the repayment schedules would look for each of the interest calculation methods. The loan details for every example below are: * Loan Amount: USD1000 * Interest Rate: 10% * Number of installments: 4 * Monthly repayments * Interest Rate Frequency: Monthly * Disbursement Date: 2011/1/23 * Days in year: 365 days ## Fixed Flat The **Fixed Flat** calculation method is the only method for which interest is not accrued over time. All interest and principal become due immediately upon disbursement regardless of the first repayment date. The interest due depends only on the interest rate, principal amount and time between repayments. ![Schedule Preview for Fixed Flat Interest Calculation Method](@site/static/img/support/loans--loan-amortization-schedule-3.png) ## Declining Balance The **Declining Balance** method reflects the actual cost of the loan more accurately than the **Fixed Flat** method, as the interest is calculated on the outstanding balance. The client only pays interest on the actual amount they still owe and not on the total amount (as is the case with the **Fixed Flat** method). In this case, as the client starts making repayments, the interest due keeps decreasing over the duration of the loan. ![Schedule Preview for Declining Balance Interest Calculation Method.](@site/static/img/support/loans--loan-amortization-schedule.png) ## Declining Balance (Equal Installments) The **Declining Balance (Equal Installments) method is similar to the **Declining Balance** method in that the interest is calculated on the outstanding principal amount. However the difference between these two calculation methods is that for the **Declining Balance (Equal Installments) method, the client pays equal installments for the duration of the loan. This is achieved by increasing the amount of principal being repayed as the interest decreases, adding up to the same fixed amount for each installment. ![Schedule Preview for Declining Balance (Equal Instalments) Interest Calculation Method](@site/static/img/support/loans--declining-balance-amortization-schedule.png) ### Non-equal installments due to rounding and first repayment date In some situations, one of the installments may be slightly different from the others. This can occur when the time from disbursement until the first repayment date is longer than the time between each installment. In this case, there will be more interest accrued and less principal in the first installment, and the remaining principal is added to the last or to the first installment – as defined in the loan product settings. ![](@site/static/img/support/rounding-of-repayment-schedules-loan-product.png) ## Accrue Late Interest Normally, businesses have the right to charge interest on late payments. However, you may want to disable this option if, for example, you want to create a flexible product which rewards clients for paying on time rather than penalises them for paying late. **Accrue Late Interest** is enabled by default for all kinds of **Dynamic Term Loans**. However, you can disable it in order not to accrue and apply late interest but only if the **Declining Balance (Equal Installments) interest calculation method is chosen. For all the other interest calculation methods, interest will be accrued by default and you don't have the option to change that. The possibility to disable **Accrue Late Interest** is available for any Pre-Payment Allocation method as well as for all [payment methods](/docs/payment-methods-for-dbei-loans) (Standard and Balloon). The feature is available via API 2.0 and Mambu UI. To disable the **Accrue Late Interest** checkbox in the Mambu UI, follow these steps (click to expand): 1. Under [Product Type](/docs/setting-up-new-loan-products#loan-product-categories), select **Dynamic Term Loan**. ![Select the Payments Method](@site/static/img/support/loan-product-type-fixed-dynamic-interest-free-tranched-revolving.png) 2. In the **Interest Rate** section, set the Interest Calculation Method to **Declining Balance (Equal Installments)**. ![Select the Interest Calculation Method](@site/static/img/support/interest-calculation-method-dynamic-balance-equal-installments.png) 3. In the **Repayment Scheduling** section, ensure that the [Payments Method](/docs/payment-methods-for-dbei-loans) is set to **Standard Payments**. ![Select the Payments Method](@site/static/img/support/payments-method-standard-balloon-optimized.png) 4. In the **Repayment Collection** section, set the [Pre-Payment Allocation](/docs/prepayment-recalculation-methods#declining-balance-equal-installments) method to **On Upcoming Pending Installment Only**. This uncovers the options for **Pre-Payment Recalculation** methods in the same section. ![Pre-Payment Recalculation](@site/static/img/support/pre-payment-allocation.png) 5. Set the [Pre-Payment Recalculation](/docs/prepayment-recalculation-methods#declining-balance-equal-installments) method to **Reduce Number of Installments**. This uncovers the **Accrue Late Interest** checkbox in the **Interest Rate** section. ![Choose the Pre-Payment Recalculation method](@site/static/img/support/pre-payment-recalculation-dbei.png) ## Interest Rate Source You can set up two types of interest rate sources, via the **Interest Rate Source** setting of a loan product: * **Fixed**: a fixed interest rate source, which is used for the entire lifetime of the loan. * **Indexed**: the interest rate source is tied to a specific benchmark (determined by an external entity—such as the government) with rate changes based on the movement of the benchmark. In this case, loans will need to be updated to reflect the new interest rate whenever it changes. Click to see where to set the Index Rate Source option for loan products. ![Select the Index Rate Source option](@site/static/img/support/interest-rate-source-fixed-index.png) :::note Index rates are defined under **Administration** > **Financial Setup** > **Rates**. For more information, see [Customizing Index Rates](/docs/customizing-index-rates). They can only be applied to **non-Flat** interest calculation methods, since, for **Fixed term with Flat Interest calculation** products, the interest amounts are fixed from the beginning and cannot change. ::: The frequency at which the interest rate should be reviewed is determined when creating a product and can be set on a daily, weekly or monthly basis. If there is a new interest rate when the review is made, then all loans using that source as an Index Interest Rate will be updated. :::note Interest rate changes will take effect immediately on the account as per the scheduled review frequency date or period as follows: • **For a standard loan with both principal and interest**: the upcoming installment due amount will not be changed (this will be done by adjusting the principal component of that installment). • **For an interest only loan**: the upcoming installment due amount will be changed right away as there will not be any principal component available to adjust the installment amount. ::: ### Example Consider a loan with the following terms: * Loan Amount: USD1000 * Interest: 5% (index) + 2% (spread) * Monthly Installments * Disbursal date: December 13, 2022 * Interest Frequency Review: Monthly Now suppose that on January 1, 2023, the Central Bank keeps the Index rate at 5% and on February 1 increases it to 6%. The change will affect the loan's repayment schedule, according to the frequency review (in this case, the interest rate will change starting from March 13, 2023, one month from the review): * First installment on January 13, 2023: `Interest = 5% Index + 2% Spread = 7%` and the total interest due will not be changed. * Second installment on February 13, 2023: `Interest = 5% Index + 2% Spread = 7%` and total interest due will not be changed. * Third Installment on March 13, 2023: `Interest = 6% Index + 2% Spread = 8%` and total interest due will be changed (in case of equal installments, a new PMT will be generated, based on the new interest rate). * All the following installments will use `Interest = 6% Index + 2% Spread = 8%`. **Index Rate Constraints** You can apply a floor (min) or ceiling (max) to index interest rates as well. This means the combined index and spread cannot be less than or more than a predefined value. These limitations can be defined as part of the loan product configuration, and they will apply to all accounts based on this loan product. In addition, you can set a default for the interest rate. Click to see where to set the Interest Rate Default, Floor and Ceiling for loan products. ![Select the Interest Rate Default, Floor and Ceiling](@site/static/img/support/interest-rate-default-min-max-floor-ceiling-new.png) **Example** Assume the floor rate is 10% and the ceiling rate is 20%. | Index Interest Rate | Spread | Calculated Rate | Actual Rate | | --- | --- | --- | --- | | 10 | 5 | 15 | 15 | | 10 | 17 | 37 | 20 | | 5 | 3 | 8 | 10 | ## Calculating the days in a year The day count convention, also referred to as day count fraction or day count, determines how interest accrues over time in a variety of transactions, including bonds, swaps, bills, and loans. Because months and years have different numbers of days, calculating interest for different periods can be complicated and susceptible to error. To address this, day count conventions were developed to standardise this methodology, to avoid disputes and provide uniformity and transparency. Based on the market and financial product, you can choose from the following day count conventions that Mambu has to offer: * [Actual/365 Fixed](#actual365-fixed) * [Actual/360](#actual360) * [Actual/Actual](#actualactual) * [30E/360 ISDA](#30e360-isda) * [BUS/252](#bus252) ### Actual/365 Fixed The Actual/365 Fixed is a day count convention that counts the actual number of days in each month, but deems each year to be 365 days. It applies in leap years as well as in normal years. #### Example Let’s consider a loan with the following terms: Loan amount: USD 1000 Interest rate: 10% per year Number of installments: 5 Formula: `Annual Interest Rate * Outstanding principal balance/365 * Number of days in the target month` Interest expected for one month with 30 days: 10%* 1000/365 * 30 = USD 8.22 Interest expected for one month with 31 days: 10%* 1000/365 * 31 = USD 8.49 ### Actual/360 Actual/360 is a day count convention that counts the actual number of days in each month, but deems each year to be 360 days. #### Example For the same loan terms as in the example above, the interest expected is calculated as follows: Formula: `Annual Interest Rate * Outstanding principal balance/360 * Number of days in the target month` Interest expected for one month with 28 days: 10%* 1000/360 * 28 = USD 7.78 Interest expected for one month with 31 days: 10%* 1000/360 * 31 = USD 8.61 ### Actual/Actual The Actual/Actual method is the most precise way to calculate interest because it uses the actual number of days in a given period and the actual number of days in the year. This allows you to accurately account for leap years, for example. This is how it works: * **First "Actual"**: This refers to the actual number of days in the interest calculation period. For instance, if you're calculating interest for the month of January, you would use 31 days. For February, you'd use 28 days (or 29 in a leap year). * **Second "Actual"**: This refers to the actual number of days in the year. In a standard year, this is 365 days. In a leap year, it's 366 days. This method is considered to be the fairest because it accurately reflects the amount of time that a borrower has used the funds. #### Example * **Outstanding loan balance**: £200,000 * Interest calculation for January (31 days): * **Step 1**: Daily rate * In a leap year, the annual interest rate is divided by 366. * Daily interest rate = 3.5% / 366 = 0.00956284% (approximately) * As a decimal: 0.035 / 366 = 0.0000956284 * **Step 2**: Daily interest accrual * Daily interest amount = `Outstanding balance` × `Daily interest rate` * £200,000 × 0.0000956284 = £19.12568306 * **Step 3**: Monthly application * Total interest for January = `Daily interest amount` × `Actual number of days in January` * £19.12568306 × 31 = **£592.90** ### 30E/360 ISDA The 30E/360 ISDA day count convention deems all months to be 30 days in length and each year to be 360 days. With this method, the interest accrues at a daily interest rate equal to 1/360th of the interest rate, but for each full month is deemed to accrue for 30 days - except the 29th day of February/March for non-leap years - regardless whether the month has 28, 29, 30, or 31 days. Therefore, for a month with 31 days, the number of accrued interest days will be the same on the 31st of that month as on the 30th while the last day of February is considered to be the 30th day of the month. In all cases, with this day count convention, the total number of days in a year will always be 360. #### Example For the same loan terms as in the examples above, we calculate the interest expected as follows: ***Formula:*** `Annual Interest Rate * Outstanding principal balance/360*30` * Interest expected for one month with 28 days: 10%* 1000/360 * 30 = USD 8.33 * Interest expected for one month with 31 days: 10%* 1000/360 * 30 = USD 8.33 The calculation for days is as follows: * Start date: M1/D1/Y1 * End date: M2/D2/Y2 * Day count = (Y2-Y1)·360 + (M2-M1)·30 + (D2-D1) Convention: * If D1=31 then D1=30 * If D2=31 then D2=30 * If D1 and D2 are not the same and D1 is the last day of February then D1=30 * If D1 and D2 are not the same and D2 is the last day of February then D2=30 ### BUS/252 BUS/252 is a day count method that supports the characteristics of the Brazilian Day Count Accrual convention. This method is based on the Brazilian business calendar, where the average number of business days in a year is 252. The interest calculated using this day count convention takes into consideration only the working days of the year. The method excludes, by default, Saturdays and Sundays from the interest accrual computation. Adding them in Mambu administration is not required. However, general holidays need to be added in Mambu Administration as they are considered when accruing interest under the BUS/252 day count convention . :::warning This day count convention is available in Mambu only for the loan products with Compound Interest type. For more information, see [Interest Types](/docs/interest-types). ::: #### Example Consider a loan with the following terms. Loan amount: BRL 10000 Interest Rate: 10% per year Interest Type: Compound interest (Compounded Frequency: Daily ) Disbursement date: 01.05.2022 Compound interest formula: `Outstanding Principal Balance * ( (1+Annual Interest Rate %) ^ (NoOfDays/DaysInYear)-1 )` where DaysInYear = 252 (according to product setup with BUS/252 day count convention) Interest accrued for one working day: 10000*((1+0.10)^(1/252)-1) = BRL 3.78 Interest expected for May 2022, which has 31 calendar days but only 22 working days: 10000*((1+0.10)^(22/252)-1) = BRL 83.55 Days in arrears are calculated based only on **Non-Working Days in Arrears Tolerance Period and Penalty Calculation Method** option set at the product level (either **Exclude Non-Working Days** or **Include Non-Working Days**). The BUS 252 day count convention does not have any impact on the days in arrears computation. Late days are always calculated as days elapsed either from the date the account first went into arrears or from the oldest currently-late installment, set under the **Arrears days calculated from** option at the product level, regardless of the day count convention and **Non-Working Days in Arrears Tolerance Period and Penalty Calculation Method** setting. --- # Interest From Arrears URL: https://docs.mambu.com/docs/interest-from-arrears/ Interest from arrears decoupling provides a method to separate regular interest from interest on arrears. In this context, interest on arrears specifically refers to the interest that accrues only on missed installments. Interest from arrears offers lenders a way to specifically identify the interest portion that relates to a loan’s arrears and decouple it from the repayments schedule. This is important because it allows this particular interest to be paid off using a custom payment allocation, which can be tailored to the borrower's affordability. ## Terms and definitions * **Late interest**: This is the regular interest charged when there are late installment(s) on an account. It is calculated based on the overall outstanding balances and includes the interest on arrears. In this case the interest from arrears portion is tightly coupled with the repayments schedule. * **Interest from arrears**: Interest calculated on the overdue installment total due(s) (late installments). If an instalment is not paid, arrears would constitute the missed installment. Arrears interest would be the interest that accrues on this missed payment. For more information, see the following sections. ## Interest from arrears calculations Interest from arrears can be handled in two distinct ways: * **Coupled with the installment**: In this scenario, interest from arrears is integrated into the regular late interest calculation. It acts as a detailed breakdown of that late interest, primarily for reporting. This means interest from arrears is paid off whenever the regular late interest is settled. * **Decoupled from the repayment schedule**: Here, interest from arrears is entirely separate from the standard repayment schedule. It doesn't affect the loan's active status; the loan remains active even if there's unpaid interest from arrears, provided your regular loan installments are paid on time. When regular interest is calculated based on outstanding balances (meaning any unpaid amounts), the total interest figure will include interest from arrears. This combined amount is also known as *late interest*. Let's look at an example to see how this works: **Loan account setup** * Loan amount = $1000 * Interest rate = 10% per year * Number of installments = 5 * First installment: March 1st 2022 → not paid * Principal amount = $200 * Interest amount = $8.33 * Installment state: Late **Interest calculation on April 1st 2022** Since the installment is late, the interest is calculated as follows: * 10%*1000 (outstanding PB)*30/360 = 8.34 * This amount (8.34) consists of: * Regular interest expected (as if the installment had not been late): 10%*800 (expected PB)*30/360 = 6.67 As well as: * Interest from arrears amount: 10%*200 (overdue total due) *30/360= 1.67 in interest from arrears → 6.67 + 1.67 = 8.34 * We can observe that 6.67 (expected interest) + 1.67 (interest from arrears) = 8.34 interest calculated at outstanding PB). * We can conclude that interest applied by Mambu on the 1st of April (of 8.34) includes the interest from arrears amount. This is also known in Mambu as late interest. When interest is applied on April 1st 2022 interest from arrears accrued becomes 0, late interest of 8.34 is moved in the interest balance (including the interest from arrears). ## Interest from arrears decoupling The *interest from arrears decoupling* mortgage loan method allows lenders to separate regular interest from interest on arrears within their balances, transactions, and accounting records. With this approach, as seen in the following example, interest from arrears and regular interest will be treated as two distinct entities, each maintaining its own independent balances. * **Interest accrued** - for regular interest accrued (regular interest calculated at expected balances, as if installments are paid on time) * **Interest balance** - for regular interest applied * **Interest paid** - for regular interest paid * **Interest from arrears accrued** - for interest from arrears accrued (this balance is present in the normal functionality as well). These balances are unique to the interest from arrears functionality: * **Interest from arrears balance** - for interest from arrears applied * **Interest from arrears paid** - for interest from arrears paid. ### Interest from arrears formulas To clarify how these new balances are calculated and how they interact, let's look at the relevant formulas: ### Simple interest Interest from arrears = (Overdue Total Due + Interest from Arrears balance) * Annual Interest Rate/days in year * Number of days late ### Compound interest Interest from arrears = (Overdue Total Due + Interest from Arrears balance) *(((1 + Daily IR)^(Number of days late)-1)) :::note * For interest only loans, Overdue Total Due consists just of interest. * For capital repayment loans, Overdue Total Due consists of interest + principal. * Interest from arrears balance is used in the formula when IFA decoupling is enabled. ::: ## Interest from arrears functionality ### Key features of interest from arrears decoupling logic * **Separate from regular repayments**: The interest on arrears is kept entirely separate from your loan's standard repayment schedule. This means your regular instalments won't include the interest from arrears portion, and it won't impact the overall repayment plan of your loan. * **Paid via custom repayments**: Interest from arrears is paid off through custom repayments, giving lenders flexibility in how it's collected. * **Separate general ledger tracking**: Lenders gain the ability to track arrears interest independently within their general ledger (GL) accounts, allowing for clearer financial oversight. ### Interest application * Interest on arrears is applied automatically by the system on the instalment due date, or it can be applied manually if needed. * The system also recalculates interest on arrears if there are partial payments made towards the outstanding arrears amount. * While the system does apply interest from arrears, this interest never becomes "due" in a way that would put your loan into arrears. Only unpaid amounts at the schedule level (your regular instalment payments) have the ability to trigger an arrears status for your loan. ### Special situations * Even during a payment holiday (PH), interest on arrears will continue to accrue if there were any late instalments before the holiday period began. * Additionally, any actions such as a write-off, rescheduling, or refinancing of the loan will also take the accrued interest on arrears into account. * Interest from arrears must be applied at the time of loan closure so it can either be capitalised (added to the loan balance) or written off. If it isn't applied, it will remain in the accrued balance but will essentially be ignored by the system. ### Accrue late interest The option **Accrue late interest** works in the following way for mortgage products with interest from arrears: * **Accrue late interest** = **True**: When this option is enabled, your loan account will accrue late interest. This can happen either at the individual instalment level or as a decoupled amount, meaning it's tracked separately. * Setting **Accrue late interest** to **true** enables the **Decouple interest from arrears** option. * When only **Accrue Late Interest** is enabled, and **Decouple Interest From Arrears** is disabled, the interest computation after a late installment takes into consideration the outstanding closing balance. Interest, including interest on arrears amounts, will be allocated on installments. * When both the **Accrue Late Interest** and **Decouple Interest From Arrears** options are enabled, the *interest calculated on arrears* amounts will be decoupled from the repayment schedule. At the schedule level, interest will be calculated based on expected Principal Balance. * **Accrue late interest** = **False**: If this option is selected, your loan will not accrue late interest at all, and interest will always be calculated on the **expected closing balance** regardless if there are late installments on the schedule. --- # Interest on Arrears and Decoupling of Interest on Arrears URL: https://docs.mambu.com/docs/interest-on-arrears-and-interest-on-arrears-decoupling/ ## Overview The **Interest on Arrears** functionality allows lenders to identify and manage interest accrued on the arrears portion of a loan. This functionality enables repayment through a custom payment allocation and provides the flexibility to: * Charge customers interest on arrears. * Maintain the interest on arrears balance separately (decoupled) from the rest of the interest calculations. ![accrue late interest and decouple interest from arrears](@site/static/img/support/accrue-late-interest-and-decouple-interest-from-arrears.png) :::note This feature applies to [Equal Installment Interest-only Loans](/docs/equal-installment-interest-only-loans) and Dynamic Term + Principal and Interest Loans. ::: ## Functionality **Arrears interest calculation:** * If an installment is not paid, the arrears constitute the missed installment. * Arrears interest accrues on this missed payment. * If decoupled from the rest of the interest, the interest on arrears can be paid via a custom repayment. * There is no tolerance period; interest on arrears is calculated immediately upon an amount becoming overdue. **Interest decoupling:** * The interest on arrears can be decoupled from regular repayments by selecting the option **Decouple Interest From Arrears**, ensuring it does not affect the loan's overall repayment schedule. * Lenders can track arrears interest separately in General Ledger (GL) accounts. **Interest application:** * Interest on arrears is applied automatically by the system on the installment due date or manually if required. * Interest on arrears is recalculated based on partial payments of the arrears amount. **Special situations:** * During a payment holiday (PH), interest on arrears continues to accrue for late installments that occurred before the payment holiday. * Write-offs, rescheduling, and refinancing will incorporate interest on arrears. **Closing operations:** * Interest on arrears is applied before closing a loan. * Any unpaid interest remains tracked separately in the account balances, although it does not appear as due. ## Configuration Options **Accrue late interest** If **Accrue Late Interest** is selected, the loan will accrue late interest and interest on arrears, which will be tracked in the interest bucket. ![accrue late interest](@site/static/img/support/accrue-late-interest.png) **Not selecting accrue late interest** If you do not select **Accrue Late Interest**, the loan will not accrue interest on arrears. ![not selecting accrue late interest](@site/static/img/support/not-selecting-accrue-late-interest.png) **Decoupling interest from arrears** If you select both **Accrue Late Interest** and **Decouple Interest From Arrears**, the arrears interest is separated from the regular repayment schedule maintained separately in the loan repayment schedule. ![decouple interest from arrears ](@site/static/img/support/decouple-interest-from-arrears.png) --- # Interest Rate Management Enhancements URL: https://docs.mambu.com/docs/interest-rate-management-enhancements/ :::note Please note The interest rate enhancements are available on demand. Please reach out to your Customer Success Manager or to [support@mambu.com](mailto:support@mambu.com) with your questions for additional information or guidance. Mambu requires a minimum of 2 weeks' notice for these requests. Migrations will be scheduled on a first-come, first-served basis. ::: ## Interest rate changes based on the value dates Interest rates serve as tools for financial institutions to respond to economic shifts, stay competitive locally and globally, and attract new customers. IFRS 9, an accounting standard by the International Accounting Standards Board (IASB), guides the recognition, measurement, and presentation of financial instruments. Under IFRS 9, changes in interest rates on savings accounts generally don't retroactively affect interest income. Instead, interest income is calculated using the effective interest rate method, based on the instrument's initial carrying amount and the effective interest rate at inception. Changes in rates affect future interest income calculations, applied prospectively from the effective date of the rate change. When changes in interest rates occur, Mambu currently recalculates interest accruals to the last interest payment. This deviates from the principles of IFRS 9 and restricts the flexibility in interest applications. As a response, we have redesigned interest rate management for savings products in 2023. This page addresses the redesign principles and provides guidelines for users of the Mambu platform to seamlessly execute interest rate changes. ## Terminology **Interest availability:** Every interest configuration is now (after migration and enablement) associated with an interest availability record which indicates when this interest configuration becomes effective on the account. It is stored on the account level and represents the interest rate change history for each account. **interestAvailabilityKey:** The unique identifier for each interest availability record. **type:** In the Mambu Deposits engine there are 3 types of interest: Regular, Overdraft, and Technical Overdraft. In more general terms those can be thought of as credit interest, arranged overdraft interest, and un-arranged borrowing/overdraft interest. Within this new capability, we are enabling changes to the Regular type of interest. Overdraft and Technical Overdraft are to follow in 2024. **startDate:** This is the value date that you would need to set when creating or updating an interest availability record. It is the “effective from” indicator for interest availability. **Product propagation:** In the Mambu platform, every account created under a product inherits all configuration parameters from the product. Hence, the product is considered as a template that defines product specifics to be used by deposit accounts. When changing a product configuration parameter, depending on the parameter, the user is asked if the new value is applicable to all existing (already created) accounts and new accounts or only to new accounts. If the existing accounts option is chosen this means that for Mambu to pass down the new value of the parameter to all accounts under that product, the process of updating the parameter value is completed via cron jobs (as part of the EOD process), although the change is reflected in the Mambu UI immediately at the account level. This routine is called product propagation. **Bulk processing:** This describes the technical process of executing one request that has several tasks in it. It works with a queuing mechanism where every record is processed sequentially, and the processing status can be tracked when needed. For an example of this, see [Make Bulk Deposits.](/api/api-v2/deposits_transactions/make-bulk-deposits/) **Live migration:** This is an in-house solution that Mambu uses when we need an update on the data structure in order to accommodate a new implementation. This solution does not require any downtime and can be repeated if it fails for any reason. Live migration also guarantees data integrity. ## What functional changes have been made? At the start of the live migration, the following existing functionalities will be disabled: * `POST /deposits/:changeInterestRate` * `POST /depositproducts/:batchUpdate` * Interest rate changes for all existing accounts, on the Edit Product page of the Mambu UI. This will take effect for the duration of the migration. Mambu will be providing backwards compatibility on the existing functionalities for a period of time, starting from Q3 2024. With the release and/or enabling of backwards compatibility, all endpoints and UI functions mentioned above will be available again after the migration is completed. However there are a few key points for users to be aware of when using the old interest rate change functions: * [POST /deposits/``:changeInterestRate](/api/api-v2/deposits/change-interest-rate/), [POST /depositproducts/``:batchUpdate ](/api/api-v2/depositproducts/batch-update), and product propagation via the Mambu UI will start creating an interest availability record as well as an interest rate change transaction on the account, if used after the live migration. * We strictly advise against using the old endpoints and product propagation in conjunction with the new interest availability endpoints. This is because of the risk of data loss, data discrepancy, and incorrect interest accruals. * Product propagation - either done via the `batchUpdate` endpoint or from the Mambu UI for all existing and new accounts - will trigger a recalculation of the interest accrual from the last interest payment date for all accounts under that product to maintain the full backwards compatibility in the old interest rate management functionality. ## What are the components of the new functionality? ### Create interest availability for an account Endpoint: [POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) Every account will automatically be associated with an interest availability record from the activation date of the account in the new solution. This interest availability will define which interest rate is effective for an account on a certain date. When a Mambu user needs to change the interest rate on an account they will be using this endpoint. They will be required to supply the account id, start date, interest type and interest rate in the payload. Only the regular interest will be recognised, which should be specified as `“type”: INTEREST` in the request. #### Rules and validations * Permissions required: `EDIT_SAVINGS_ACCOUNT` * Account states that are allowed: `PENDING_APPROVAL`, `APPROVED`, `ACTIVE`, `ACTIVE_IN_ARREARS`, `DORMANT`, `LOCKED`. * For accounts in `DORMANT` or `LOCKED` states, the only available option is to create an interest availability with a future date. * For accounts in `PENDING_APPROVAL` and `APPROVED` states, the interest availability will become effective upon account activation. * For accounts in a `DORMANT` state, the interest availability will become effective when the account becomes `ACTIVE` again. Once the account returns into an `ACTIVE` state, interest will be accrued and applied if the interest application date is involved, with the interest availability that was effective for the dormancy period. * For accounts in a `LOCKED` state, the interest availability will become effective when the account is unlocked, and the account will be appraised to the point of the locking date with the effective interest rate. * Interest rate terms that are allowed: `FIXED`, `TIERED BY BALANCE`, `TIERED BY BANDS`, `TIERED BY PERIOD`: * For the `FIXED` interest rate term, there are two interest rate source options: * **fixed**: the interest rate can be changed as expected. * **indexed**: the Spread Default value can be changed. Spread Min and Spread Max values will adhere to the product configuration. The Index Source can be managed at the Admin level. * For `TIERED BY BALANCE`, the interest rate can be changed as expected. * For `TIERED BY BANDS`, the interest rate can be changed as expected. * For `TIERED BY PERIOD`, the start date can only be the current date. This interest rate term does not allow back- or future-dating the interest availability. * Negative rates will be only allowed if the product configuration allows negative interest. #### Use cases **Use case 1** An interest rate availability created with a past date triggers backdated transactions. Mambu will follow the existing backdating process. Example account setup: | Account Settings | Values | | -------------------------- | ------------------------ | | Account ID | A | | Account State | Active | | Interest Rate Term | Fixed | | Interest Rate | 2.67% per year | | Interest Calculated Using | End of Day Balance | | Interest paid into account | First day of every month | | Account Type | Savings Account | Assuming that this account has only one interest availability record: | Interest Availability Settings | Values | | ------------------------------ | -------------- | | encodedKey | xxx | | interestRate | 2.67% per year | | startDate | 01.01.2024 | If there is an interest rate change activity via [POST /deposits/``/interest-availabilities](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) on 15/01/2024 with the following request body: ``` { "type": "INTEREST", "startDate": "2024-01-05", "interestRateSettings": { "interestRate": 2.89 } ``` When this request is successfully processed, the interest accrual between 05/01/2024 and 15/01/2024 will be recalculated using the interest rate of 2.89%. From 15/01/2024 the account will keep accruing interest with a rate of 2.89%. This will be immediately reflected in the account. > **Example**: Interest Accrual calculation with the EOD that starts at 00:00 on 16/01/2024. > > Accrued Interest Amount = [((05.01.2024 - 01.01.2024)/365)x(2.67%)x(Account Balance)] + [((16.01.2024 - 05.01.2024)/365)x(2.89%)x(Account Balance)] --- **Use case 2** An interest rate availability created with a **future date** will be stored immediately, and it will be recognised by a new job that will run after every EOD upon arrival of the future date. This example uses the same account setup from the previous case: | Account Settings | Values | | -------------------------- | ------------------------ | | Account ID | A | | Account State | Active | | Interest Rate Term | Fixed | | Interest Rate | 2.89% per year | | Interest Calculated Using | End of Day Balance | | Interest paid into account | First day of every month | | Account Type | Savings Account | For this account there are now 2 interest availability records as: | Interest Availability Settings | Values | | ------------------------------ | -------------- | | encodedKey | xxx | | interestRate | 2.67% per year | | startDate | 01.01.2024 | | --- | --- | | encodedKey | xxx1 | | interestRate | 2.89% per year | | startDate | 05.01.2024 | If there is an interest rate change activity via [POST /deposits/``/interest-availabilities](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) on 16/01/2024 with the following request body: ``` { "type": "INTEREST", "startDate": "2024-01-18", "interestRateSettings": { "interestRate": 2.68 } ``` When this request is successfully processed, an interest rate change transaction will be logged on the account with the date of 18/01/2024 and the new rate will be picked up by a new cron step on 18/01/2024 at midnight and will be become the effective rate for the account appraisal step of the EOD that starts at 00:00 on 19/01/2024 at 00:00 (assuming the EOD starts at midnight). > **Example**: Interest Accrual calculation with the EOD that starts at 00:00 on 19/01/2024. > > Accrued Interest Amount = [((05.01.2024 - 01.01.2024)/365)x(2.67%)x(Account Balance)] + [((18.01.2024 - 05.01.2024)/365)x(2.89%)x(Account Balance)] + [((19.01.2024 - 18.01.2024)/365)x(2.68%)x(Account Balance)] --- **Use case 3** An interest rate availability created with the current date as a start date. It will be stored immediately, and will be recognised by the account appraisal process at EOD. This example uses the same account as the previous use cases: | Account Settings | Values | | -------------------------- | ------------------------ | | Account ID | A | | Account State | Active | | Interest Rate Term | Fixed | | Interest Rate | 2.68% per year | | Interest Calculated Using | End of Day Balance | | Interest paid into account | First day of every month | | Account Type | Savings Account | For this account there are now 3 interest availability records: | Interest Availability Settings | Values | | ------------------------------ | -------------- | | encodedKey | xxx | | interestRate | 2.67% per year | | startDate | 01.01.2024 | | --- | --- | | encodedKey | xxx1 | | interestRate | 2.89% per year | | startDate | 05.01.2024 | | --- | --- | | encodedKey | xxx1 | | interestRate | 2.68%per year | | startDate | 18.01.2024 | If there is an interest rate change activity via [POST /deposits/``/interest-availabilities](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) on 19/01/2024 with the following request body: ``` { "type": "INTEREST", "startDate": "2024-01-19", "interestRateSettings": { "interestRate": 3 } ``` When this request is successfully processed, an interest rate change transaction will be logged on the account on date 19/01/2024 at the time of request, and the new rate will be used by the next cron that starts at 00:00 on 20/01/2024 (assuming the EOD starts at midnight). > **Example**: Interest Accrual calculation with an EOD that starts at 00:00 on 20/01/2024 > > Accrued Interest Amount = [((05.01.2024 - 01.01.2024)/365)x(2.67%)x(Account Balance)] + [((18.01.2024 - 05.01.2024)/365)x(2.89%)x(Account Balance)] + [((19.01.2024 - 18.01.2024)/365)x(2.68%)x(Account Balance)] + [((20.01.2024 - 19.01.2024)/365)x(3%)x(Account Balance)] ### Update interest availability for an account Endpoint: [PUT /deposits/``/interest-availabilities/``](/api/api-v2/deposits/update-interest-availability) This endpoint allows users to make corrections or changes on an existing interest availability. #### Rules and validations * Permissions required: `EDIT_SAVINGS_ACCOUNT`. * This endpoint respects all validations listed for [POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability). * Start date cannot be updated. * Type parameter cannot be updated. * Based on the start date that is on the interest availability record, this endpoint may trigger recalculation of interest. #### Use case This example uses the same account as the prior use cases: | Account Settings | Values | | -------------------------- | ------------------------ | | Account ID | A | | Account State | Active | | Interest Rate Term | Fixed | | Interest Rate | 3% per year | | Interest Calculated Using | End of Day Balance | | Interest paid into account | First day of every month | | Account Type | Savings Account | Updating the IA xxx2: In case of an interest rate change activity via [PUT /deposits/``/interest-availabilities/``](/api/api-v2/deposits/update-interest-availability) on 20/01/2024 with the following request body: ``` { "interestRateSettings": { "interestRate": 3.01 } } ``` When this request is successfully processed, the interest accrual between 19/01/2024 and 20/01/2024 will be recalculated using the interest rate of 3.01% instead of 3%. From 20/01/2024 the account will keep accruing interest with the rate of 3.01% This will be immediately reflected in the account. > **Example 1**: Recalculation of interest accrual triggered on 20/01/2024 > > Accrued Interest Amount = [((05.01.2024 - 01.01.2024)/365)x(2.67%)x(Account Balance)] + [((18.01.2024 - 05.01.2024)/365)x(2.89%)x(Account Balance)] + [((19.01.2024 - 18.01.2024)/365)x(2.68%)x(Account Balance)] + [((20.01.2024 - 19.01.2024)/365)x(3.01%)x(Account Balance)] > **Example 2**: Interest accrual calculation with an EOD that starts at 00:00 on 21/01/2024 > > Accrued Interest Amount = [((05.01.2024 - 01.01.2024)/365)x2.67%)x(Account Balance)] + [((18.01.2024 - 05.01.2024)/365)x(2.89%)x(Account Balance)] + [((19.01.2024 - 18.01.2024)/365)x(2.68%)x(Account Balance)] + [((20.01.2024 - 19.01.2024)/365)x(3.01%)x(Account Balance)] + [((21.01.2024 - 20.01.2024)/365)x(3.01%)x(Account Balance)] ### Get interest availability with interest availability ID for an account Endpoint: [GET /deposits/``/interest-availabilities/``](/api/api-v2/deposits/get-interest-availability-by-id) This endpoint can be used for retrieving a specific interest availability record for an account. #### Rules and validations Permissions required: `VIEW_SAVINGS_ACCOUNT_DETAILS` ### Get interest availability for an account Endpoint: [GET /deposits/``/interest-availabilities](/api/api-v2/deposits/get-interest-availabilities-list) This endpoint can be used for retrieving interest availability records for an account and allows filtering by interest type and/or date range. #### Rules and validations Permissions required: `VIEW_SAVINGS_ACCOUNT_DETAILS` ### Delete an interest availability for an account Endpoint: [DELETE /deposits/``/interest-availabilities/``](/api/api-v2/deposits/delete-interest-availability) This endpoint can be used when there is a need to remove an interest availability record from an account. #### Rules and validations * Permissions required: `EDIT_SAVINGS_ACCOUNT` * Every interest availability record can be deleted except from the first (oldest) record on the account. * Deleting an interest availability can trigger recalculation of the interest. ### Bulk update interest availabilities for existing accounts Endpoint: [POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) This endpoint is the enhanced version of product propagation action. Now with this implementation it becomes possible to apply an interest rate change to a sub-set of accounts. It is also possible to apply the changes to all existing accounts under the same product. #### Rules and validations * Permissions required: `MAKE_BULK_CHANGE_INTEREST_AVAILABILITY` * This endpoint concludes two input parameters under the `accountFilter` wrapper as: * `productId or `encodedKey` of the product * `Id`s or the `encodedKeys` of the accounts. * Product Id and Ids cannot be used in the same request. * Providing a product Id will mean that changes posted in the request will be applied to all existing accounts under this product. * To use Ids, at least one account Id must be provided. * The `startDate` supplied should not be more than 31 days in the past. For future dates there is no limitation. * When using Ids, the maximum number of account Ids that can be provided is 100,000 due to RESTful API constraints. * The following interest configuration parameters can be changed with this endpoint: * `interestRate` * `interestSpread` * `interestRateTiers` * Interest Charge Frequency #### Bulk processing details * The endpoint works asynchronously, after an initial validation of the payload work is scheduled to be executed on the background workers. * In case of a success scheduling an identifier is being returned that can be used for tracking the progress & results of the asynchronous operation by using the endpoint `/api/bulks/`. * Pagination Sample result from calling `/api/bulks/`: ```json { "status": "ERROR", <<– this is an overall status, if at least one error occurred "errors": [ { "indexInRequest": 0, <<– always 0 in bulk Interest Availabilities case "externalId": "33", <<– the id/encoedkey of the account "errorSource": "An InterestAvailability already exists for account with the same date and type.", <<- error related information ->> "errorCode": 8104, "errorReason": "INVALID_INTEREST_RATE_SETTINGS" }, { "indexInRequest": 0, "externalId": "34", "errorSource": "An InterestAvailability already exists for account with the same date and type.", "errorCode": 8104, "errorReason": "INVALID_INTEREST_RATE_SETTINGS" } ], <<- all successful processings appear below ->> "processedItems": [{ "indexInRequest": 0, "externalId": "17" }, { "indexInRequest": 0, "externalId": "29" }, ] } ``` A bulk interest availability change process that is interrogated via `/api/bulks/` can be in one of the following states: | State | Description | | ----------- | ----------------------------------------------------- | | QUEUED | Payload has been validated and work will be scheduled | | IN_PROGRESS | Accounts are being processed | | ERROR | On at least one account there was a validation error | | COMPLETE | All accounts were processed successfully | The full response will only be available when the process reaches an `ERROR` or `COMPLETE` stage. #### Use case A new interest rate availability created for all existing accounts under the same product, with a current date as the start date. This action can be executed in two different ways: * By providing the Product Id in the request of [POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities). * By providing the list of Account Ids in the the request of [POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities). Mambu will: 1. Retrieve all accounts that are linked to the product Id or Ids provided in the request. 2. Post the new interest availability record to each one of those accounts. 3. Create an interest rate change transaction for every account retrieved. 4. The next EOD will update the interest rate used for account appraisal. Request body sample: ``` { "accountFilter": { "productId": "product1" }, "interestAvailability": { "type": "INTEREST", "startDate": "2024-01-26", "interestRateSettings": { "interestRate": 4.2 } } } ``` #### Comparison between the old and new solution | Capability Description | Old Behaviour | New Behaviour | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Interest rate change for Fixed interest via API at account level, effective from current date | Possible via`POST /deposits/:changeInterestRate` | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Interest rate change for Fixed interest via API at account level, effective from past date | Possible via`POST /deposits/:changeInterestRate` | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Interest rate change for Fixed interest via API at account level, effective from future date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Spread value change for Indexed interest via API at account level , effective from current date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Spread value change for Indexed interest via API at account level , effective from past date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Spread value change for Indexed interest via API at account level , effective from future date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by balance interest type via API at account level, with current date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by balance interest type via API at account level, with past date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by balance interest type via API at account level, with future date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by bands interest type via API at account level, with current date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by bands interest type via API at account level, with past date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by bands interest type via API at account level, with future date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by period interest type via API at account level, with current date | Not possible | Possible via[POST /deposits/``/interest-availabilities](/api/api-v2/deposits/create-interest-availability) | | Tier value/definition changes for tiered by period interest type via API at account level, with past date | Not possible | Not possible | | Tier value/definition changes for tiered by period interest type via API at account level, with future date | Not possible | Not possible | | Modifying an interest rate change record at account level, via API | Not possible | Possible via[PUT /deposits/``/interest-availabilities/``](/api/api-v2/deposits/update-interest-availability) | | Deleting an interest rate change record at account level, via API | Not possible | Possible via[DELETE /deposits/``/interest-availabilities/``](/api/api-v2/deposits/delete-interest-availability) | | Updating interest rate parameters (`interestRate`, `interestSpreadinterestSpread`, `interestRateTiers`, Interest Charge Frequency) at a product level for existing accounts via the Mambu UI with current date | Possible via Edit Product Page | Not possible via UI | | Updating interest rate parameters (`interestRate`, `interestSpreadinterestSpread`, `interestRateTiers`, Interest Charge Frequency) at a product level for new accounts via the Mambu UI with current date | Possible via Edit Product Page | Possible via Edit Product Page | | Updating interest rate parameters (`interestRate`, `interestSpreadinterestSpread`, `interestRateTiers`, Interest Charge Frequency) at a product level for all existing accounts via the API with the current date | Possible via`POST /depositproducts/:batchUpdate` | Possible via[POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) | | Updating interest rate parameters (`interestRate`, `interestSpreadinterestSpread`, `interestRateTiers`, Interest Charge Frequency) at the product level for all existing accounts via the API with the past date | Not possible | Possible via[POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) | | Updating interest rate parameters (`interestRate`, `interestSpreadinterestSpread`, `interestRateTiers`, Interest Charge Frequency) at the product level for all existing accounts via the API with a future date | Not possible | Possible via[POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) | | Updating interest rate parameters (`interestRate`, `interestSpreadinterestSpread`, `interestRateTiers`, Interest Charge Frequency) for a selected number of accounts | Not possible | Possible via[POST /deposits/interest-availabilities:bulk](/api/api-v2/deposits/make-bulk-interest-account-settings-availabilities) | --- # Interest Types URL: https://docs.mambu.com/docs/interest-types/ ## Set up the interest type of a loan product When [setting up new loan products](/docs/setting-up-new-loan-products#create-a-new-loan-product), in the **Interest Rate** section of the form, choose between the following **Interest Types** to define the interest frequency and formula you want to apply to your loan products: * Simple interest * Capitalized interest * Compound interest ![The interest section of the create loan product form showing the three available interest rate types: simple, capitalized, and compound](@site/static/img/support/interest-rate-types.png) ## Simple interest *Simple Interest* is the default interest type for all loan product types using **Flat**, **Declining Balance** or **Declining Balance (Equal Installments)** interest calculation methods. ### Formulas Simple interest type is based on the linear formula and it is determined by multiplying the daily interest rate by the principal, and then by the number of days that elapse between payments and divide by the number of days in the year. `Interest Amount = Base Balance * Annual Interest Rate \% * NoOfDays / DaysInYear` where Base Balance can be calculated using two methods: * **Principal Only** * **Principal and Interest** By default, the base balance used in the interest formula calculation is **Principal Only**, which represents the Outstanding Principal Balance from the loan account, so we will have the following formula: `\begin Interest Amount & = & Outstanding Principal Balance * Annual Interest Rate \% \\ & * & NoOfDays / DaysInYear \end`
    **Principal and Interest** is available only for dynamic term loans with the **Declining Balance (Equal Installments)** method, and calculates the interest by multiplying the daily interest rate by the principal and unpaid interest and then by the number of days that elapse between payments and divide by the number of days in the year. `\begin Interest Amount & = & (Outstanding Principal Balance + Unpaid Interest) \\ & * & Annual Interest Rate \% * NoOfDays / DaysInYear \end`
    ![Simple interest type with the dynamic declining balance calculation method and the principal only or the principal and interest calculations](@site/static/img/support/simple-interest-rate-calculate-using-principal-only-or-principal-and-interest.png) ### Example The following is an example of **Principal and Interest** calculation. Consider a loan with the following terms: * Loan amount: USD1000 * Interest Rate (IR%): 10% per year * No of installments: 5 * Monthly Repayments * Disbursement date: January 1, 2020 * Total Due (PMT): USD205.03 * Days in Year method: 30/360 **First installment February 1, 2020** Interest Amount = (Outstanding Principal Balance + Interest Balance) * IR% * NoOfDays/360 = (USD1000+USD0) * 10% * 30 / 360 = USD8.33 If we apply the interest, Interest Balance will be USD8.33. **Second installment March 1, 2020** Interest Amount = (Outstanding Principal Balance + Interest Balance) * IR% * NoOfDays/360 = (USD1000+USD8.33) * 10% * 30 / 360 = USD8.40 If we apply the interest, the Interest Balance will be: Interest Balance = Interest applied on the first installment + Interest applied on the second installment = USD8.33 + USD8.40 = USD16.73 After it is applied, the interest is updated in the schedule with the new calculation based on Principal and Interest. :::note If the repayments are paid on time, the interest balance will always be 0, and this method will act exactly like the **Principal Only** interest calculation method. ::: ### Accounting When simple interest is applied, it will be considered as an income from the accounting point of view. The following journal entries for the accrual accounting methodology are logged at interest application: * **Debit**: Interest Receivable * **Credit**: Interest Income When the interest will be paid, the following journal entries will be entered: * **Debit**: Transaction Source * **Credit**: Interest Receivable ## Capitalized interest The *Capitalized Interest* type means that, when the interest is applied, it is capitalized (applied) into the principal balance. This method is available for **Dynamic Term** loans with both the **Declining Balance** and the **Declining Balance (Equal Installments)** calculation methods. For **Declining Balance** with Capitalized Interest, the first (total-1) installments are by default principal grace installments. So, after applying interest in each due date, all the principal amount (which contain the interest amount as well) will be allocated on the last installment. For the **Declining Balance (Equal Installments)** calculation method with the capitalized interest, the installments will have both principal and interest expected. ### Formula Capitalized interest is calculated as simple interest type with Principal Only base: `\begin Interest Amount & = & Outstanding Principal Balance * Annual Interest Rate \% \\ & * & NoOfDays / DaysInYear \end`
    ### Example Consider a dynamic declining balance loan with the following terms: * Loan amount: USD1000 * Interest Rate: 10% per year * No of installments: 5 * Monthly Repayments * Disbursement date: June 10, 2022 * Days in Year method: 360 The schedule generated with capitalized interest type based on the above loan terms is: ![db capitalized.png](@site/static/img/support/db%20capitalized.png) See below the calculations implied in this case: Interest Expected = Outstanding Principal Balance * Annual Interest Rate % * NoOfDays / DaysInYear = USD1000 * 10% * 30/360 = USD8.33 Payment Due = USD8.33 ### Accounting From the accounting perspective, capitalized interest and simple interest are different. When it is applied, the interest is capitalized on the principal balance and the following journal entries are logged in accounting: * **Debit**: Portfolio Control * **Credit**: Interest Income When the interest will be paid, only the principal amount will be paid in the end, having the following journal entries: * **Debit**: Transaction Source * **Credit**: Portfolio Control ## Compound interest *Compound interest* is the interest calculated on the original principal and all the accumulated previously paid interests. An easier way to think of compound interest is that is it “interest on interest,” where the amount of the interest payment is based on changes in each period, rather than being fixed at the original principal amount. ### Frequency The compounding frequency determines how many times the interest is paid and it influences the interest rate itself. In Mambu, the interest is compounded daily, meaning that each interest accrued will be calculated based on the principal balance and the accrued interest from the previous day. ### Formulas Unlike the simple interest, which is based on a **linear** formula (see [above](/docs/interest-types#simple-interest)), the compound interest is based on the following **exponential** formula: `\beginInterest Amount =& &&Outstanding Principal Balance \\&* &&((1+Annual Interest Rate \%) ^)}-1))\end\`
    Compound interest calculation formulas in Mambu: | Convert annual interest rate to a smaller period| Formula | | --- | --- | | From IR% per year to Annual Interest Rate | `IC=(1+IR\%)^)}-1)` | | From IR% per year to Monthly Interest Rate | `IC=(1+IR\%)^)}-1)` | | From IR% per per year to 4 weeks Interest Rate | `IC=(1+IR\%)^)}-1)` | | From IR% per year to Weekly Interest Rate | `IC=(1+IR\%)^)}-1)` | | From IR% per year to Daily Interest Rate | `IC=(1+IR\%)^)}-1)` | Compound Interest has a direct implication in the Periodic Payment (PMT) formula as well, being calculated as: `PMT(periodic rate, no of installments, -loan amount)`, where the periodic rate is calculated based on the formulas from the above table. For more information about the PMT function, go to [How to Calculate Loan Payments with Excel PMT Function](https://www.youtube.com/watch?v=WzofplrjidU). :::note *Compound interest* type is available for all loan product setups, except for: * Fixed Term loans with Repayments Interest Calculation as using repayment periodicity * Revolving Credit ::: ![Compound Interest Type.png](@site/static/img/support/Compound%20Interest%20Type.png) ### Example Example of loan account with compound interest rate: Loan Amount: USD1000 Interest Rate: 10% per year No of installments: 5 Days in Year method: 30E/360 Monthly Repayments The schedule generated with compound interest type based on the above loan terms is: ![Schedule Compound Interest.png](@site/static/img/support/Schedule%20Compound%20Interest.png) See below the calculations implied in this case: * Monthly Interest Rate = (1+ Annual Interest Rate%)^(1/12)-1 = 0.80% * Payment Due = PMT(Monthly Interest Rate, no of installments, -Loan amount) = USD204.81 * Interest Expected = Outstanding Principal Balance * ((1+Annual Interest Rate%)^(30/360)-1) = USD7.97 * Principal Expected = Payment Due - Interest Expected = USD196.84 For more detailed calculations, see this file: [Download the spreadsheet](@site/static/files/Compound-Interest.xlsx) ### Accounting From the accounting point of view, the compound interest is similar with the simple interest. When Compound interest is applied, it will be considered as an income from the accounting point of view. The following journal entries for accrual accounting methodology are logged at interest application: * **Debit**: Interest Receivable * **Credit**: Interest Income When the interest will be paid, the following journal entries will be entered: * **Debit**: Transaction Source * **Credit**: Interest Receivable --- # Internal Controls for Loans URL: https://docs.mambu.com/docs/internal-controls-for-loans/ In the **Internal Controls** section of the **Creating a new loan product** form, you can set up automatic internal controls for loans, such as the dormancy period or the number of days before locking accounts in arrears. ![Internal Controls with Close Dormant Accounts, Lock Arrears Accounts and Cap Charges](@site/static/img/support/internal-controls.png) ## Close dormant accounts Loan accounts that have been completely paid off can be either manually or automatically closed. If you want Mambu to automatically close those accounts, check this option and enter the number of days after which the account should be automatically closed. The advantage of this option is that it reduces the risk of creating incorrect reports and performance indicators with data from accounts that have been paid off, but not closed. ## Lock arrears accounts Loan accounts that are in arrears can be locked automatically after a chosen number of days. Locking the account stops the application of interest, fees, and penalties. Additionally, locked accounts do not accept transactions posted to them unless the user has permission to post transactions on a locked account. If you want Mambu to automatically lock an account, check this option and enter the number of days after which the account should be automatically locked. ## Cap charges This option allows you to automatically lock accounts in arrears when interest, fees and penalties are more than a percentage of the current principal balance or of the original principal amount. For more information on which activities are suspended when an account is locked see [Locking and Unlocking oans](/docs/locking-loans). ![Cap Charges option with percentage of Outstanding Principal Balance and Soft Cap options.](@site/static/img/support/loans--cap-charges-configuration.png) * With **Soft Cap** constraints, when the threshold is exceeded, charges - such as interest, fees, or penalties - will be applied and the account will be set to a `Locked (Capping)` state. * With **Hard Cap** constraints, when the threshold is exceeded, charges will not be applied anymore and the account will be set to a `Locked (Capping)` state. ### Example We set up a loan product with the following internal control: when the interest, fees, or penalties add up to more than 10% of the outstanding principal, the account is automatically locked and no charges are applied to it. ![Example of a loan account 1444 days in arrears with charges of over 30% of the initial balance leading to its state to be automatically changed to locked](@site/static/img/support/hard-cap-example.png) If we select soft cap, the interest, fees, or penalties will be applied before the account gets automatically locked. If we select hard cap, the interest, fees, or penalties will not be applied before the account gets automatically locked. ### Apply accrued charges before lock (capping) If you select this option, accrued charges which are not yet applied will be taken into account when calculating whether an account has gone over your defined threshold. Accounts are checked during end-of-day processing and will go into a `Locked` state when the sum of accrued and applied interest, penalties, and fees goes over the limit. For more information on end-of-day processing jobs, see [End of Day Processing and Cron Jobs](/docs/automatic-end-of-day-actions). Unlocking the account is possible when the account is no longer in arrears or the client has paid the outstanding interest, fees, and penalties. Bear in mind that locked accounts will still accrue charges but these will not be applied until the account is unlocked. :::note Accounts will be closed or locked when the nightly actions are performed at midnight. Closing an account will also trigger any automated text messages or notifications you might have set up that are triggered by closing the account. ::: :::note If you want to enable any of these options for existing loans, you will see them available when [editing the product](/docs/managing-loan-products). ::: --- # Internal Controls URL: https://docs.mambu.com/docs/internal-controls/ Internal controls are settings related to managing risk that you can configure for clients, groups, and loans. To manage internal controls: 1. On the main menu, go to **Administration** > **General Setup** > **Internal Controls**. 2. Set or edit the internal controls. 3. Select **Save Changes**. :::note This article covers more general internal controls. For specific controls relating to deposits or loans, see [Setting up new deposit products - Internal controls](/docs/setting-up-new-deposit-products#internal-controls) or [Internal controls for loans](/docs/internal-controls-for-loans). ::: ## Maximum exposure The **Maximum Maximum Exposure To A Client** dropdown allows you to define the maximum amount of risk your organization is willing to take when providing loans by setting a maximum limit for the outstanding loans a client can have. There are three options: * Unlimited * Sum Of All Loans * Sum Of All Loans Minus Deposits Balance. If you specify a value for the Sum of All Loans, the outstanding balance of all the client's active and inactive (in arrears) loan accounts cannot exceed that amount. If you select Sum of All Loans Minus Deposits Balance, this effectively means that you take active deposit accounts into consideration by judging clients with larger deposits balances to represent a lower level of risk. This can provide an incentive for clients to save, as the higher their deposits balance, the larger loan amounts they can apply for. ### Example Suppose that the Maximum Exposure was set to USD12000 for the sum of all loans. If you try to approve a loan account for a client whose sum of all loans exceeds this amount, you will get a warning message and Mambu will prevent its approval. ![Maximum Exposure set to a Client and pop-up warning if exceeded](@site/static/img/support/managing-your-organization--maximum-client-exposure-warning-dialog.png) ## Can a client have more than one active loan? With **Clients Can Receive Multiple Loans**, you can choose whether you want your clients to have one or more active loan accounts: * **Yes, Unlimited Number of Active Loans**: if you want to impose no limit to the number of active loans. * **No, Only One Active Loan Per Client**: if you want to have no more than one active loan per client. :::note A loan is considered active after disbursal. ::: ## Can a client be in more than one group? With **Clients May Be In More Than One Group**, you can choose whether you want to allow clients to be added as members to more than one group. Use the dropdown to select **Yes** or **No**. :::warning If you change this setting from **Yes** to **No**, the system will not warn you about any existing clients that are part of two groups at the moment of changing the setting and it also won't raise a warning when you edit client profiles. After changing the setting to **No**, the system will no longer allow you to edit groups that have clients that are in more than one group. ::: ![Client cannot belong to more than one groups warning dialog](@site/static/img/support/managing-your-organization--clients-cannot-belong-to-more-than-one-groups.png) ## Do clients and groups need to be assigned to branches, centres, or credit officers? Selecting any of the options under **Client and Group Required Assignments** will make it a required field with a green outline in the **Association** section of the **Creating a Client** dialog. For more information, see [Creating an Individual Client](/docs/create-an-individual-client). For example, if you select **Branches**, then every time you create a client you will have to assign the client to an existing branch. ![Association section in Creating a Client dialog with branch association as required field](@site/static/img/support/managing-your-organization--client-association-settings.png) ## How can you make sure you are not creating a client that already exists? Under **Duplicate Client Checks**, select the fields you want to use to check if duplicate clients are being created. The available fields are: ![Duplicate client checks internal control](@site/static/img/support/managing-your-organization--duplicate-client-checks.png) You can also select the level type of duplicate client check. The options are: * **None**: Will not check for duplicate clients. * **Warning**: Will let you know if a client is possibly a duplicate according to the defined field checks. This option does not work with the API. * **Error**: Doesn't allow creating or editing a client that is a duplicate according to the defined field checks. This option is also applicable to client PATCH API. :::warning If you select the **Warning** level type, then you are still able to create a duplicate client using the API. We recommend you to use the **Error** level type. ::: ## What's the minimum number of days a loan must be In Arrears before you can write it off? If your organization's policies determine that a loan can only be written off after a certain number of days, you can define this period under **Minimum Days In Arrears Before Write-Off**. This will make sure that only the loan accounts that are in arrears for more than that number of days can be written off. ## What's the maximum number of days after which you cannot reopen closed loans? It might be necessary to reverse the closing of a loan in case of a human or technical error, for example, or if a previous payment towards the loan has been subsequently reversed. You can limit the number of days that can pass from a loan’s closure until said closure can no longer be undone (until the loan can no longer be reopened) under **Maximum Days Before Undo Close Loans**. Any change to this number will apply to all loan accounts, not just those created after the change had been made. ## Group size limit types You can set limits to the size of groups you manage. There are three limit types: * **None**: Sets no restrictions to the number of members a group can have. * **Warning**: Will give you a warning message if the number of members exceeds the number you define, but will allow you to proceed upon confirming. * **Hard**: Will present you with an **Invalid Group Size** error and will not allow you to exceed the group size limit. ![Invalid Group Size error dialog](@site/static/img/support/managing-your-organization--invalid-group-size-error-dialog.png) :::warning If you change your settings from the **None** limit type to the **Warning** or **Error** limit type, you will not be notified of any existing groups that exceed the group size limits. You will only be notified of group size limit violations when creating new groups or editing existing groups. ::: :::warning If you select the **Warning** limit type, then you will not receive any warning errors for exceeding the group size limit when managing groups via API. We recommend you to use the **Hard** limit type. ::: ## New client initial state When you create a new client in Mambu, you can choose if the client's state should be automatically set to **Inactive** or **Pending Approval**. You may choose to select **Pending Approval**, if you create clients in Mambu while you are still carrying out credit checks on them. In this case, a user with the **Approve Clients** (APPROVE_CLIENT) permission has to approve any new clients before they can start having accounts associated to their profile. You may choose to select **Inactive** if you only perform client creation in Mambu once a new client has already passed the necessary credit checks. In this case, once a client is created in Mambu, they don't need to be approved to start having loans and deposit accounts. For more information, see [Client Life Cycle](/docs/client-life-cycle). ## New credit arrangement initial state You can set the initial state of a credit arrangement, the available options are **Pending Approvable** or **Approved**. For more information, see [Credit arrangement states](/docs/credit-arrangement-states). ## Two-man rules If enabled, a single user cannot both approve and disburse the same loan. ## Available dashboard sections You can customize which widgets you see on your dashboard. The available options are: ![Available dashboard sections internal control](@site/static/img/support/managing-your-organization--available-dashboard-sections.png) For more information, see [Dashboard](/docs/dashboard). ## Maximum number of unclosed accounts shown With this option, you can hide loan accounts from the UI if the client or group has a lot of loan accounts, to avoid timeouts. Accounts are ordered by the creation date so the first X loans created will be displayed as tabs while the rest will be hidden. --- # Mambu Apps Basics URL: https://docs.mambu.com/docs/introduction-to-mambu-apps/ Mambu Apps allow you to extend your capabilities by integrating your own applications directly into the Mambu UI within an embedded iframe. Once defined and installed, a Mambu App is a selectable frame in the Mambu UI that renders your externally-hosted application. In this context, an *application* is a platform or application outside of the Mambu UI that securely communicates with the Mambu App. The Mambu App is defined by a short XML file that provides basic information about the application, such as the URL, as well as specifying where it will be displayed in the Mambu UI. Mambu Apps can be displayed in a variety of ways - for example, they can be integrated into client profiles or within individual accounts, and they can be included as selectable tabs under the **Clients**, **Branches**, or **Deposit Account**. ![A screen capture of a Mambu App in practice](@site/static/img/support/mambu-app-demo-simulated-1892x688.png) ## Integration through iframes Mambu Apps give you a canvas to integrate your applications within an embedded iframe. You can create, run, and maintain your application separately from Mambu, using any platform or programming language. Mambu Apps are [defined using an XML file](/docs/installing-apps), which describes the layout and extension points of the App. To install a Mambu app, you simply load the XML file into the Mambu UI. :::note Apps securely communicate using a private secret key as well as API credentials. You always remain in control of the application and you can disable or uninstall it at any time. ::: ## Uses Cases for Mambu Apps Mambu Apps cover a wide range of possible use cases, including the following real-world applications: - Credit Scoring: Access your client's credit information from third-party providers when viewing their profile in the Mambu UI. - Mobile Money: Integrate the reporting and analytics of a mobile money provider within Mambu. - Regulatory Reporting: Create tools for generating and automatically submitting regulatory reports. - Peer-to-Peer (P2P) Lending: Integrate P2P services with other financial products and services that you offer. - Insurance Products: Offer clients insurance products alongside the rest of your financial products. A Mambu App can be used to connect to insurance providers, with a fully automated data flow. - Social and Health Services: NGOs who also provide social and health services can develop apps to give them a single view of their clients and the services they use. - Human Resources: Create apps to manage and grow staff numbers by including automated commissions and managing calendars within the UI. --- # Islamic Funding Contracts URL: https://docs.mambu.com/docs/islamic-funding-contracts/ Islamic funding is a capability inside Mambu’s Core Banking Engine (CBE) that uses the Profit Sharing feature, which enables the calculation, approval, and distribution of profit on deposit accounts so that customers can offer Islamic funding (deposit) products to their users. Islamic Profit Sharing is a contractual arrangement between an investor (Rab al Maal) and a managing trustee (Mudareb). The trustee invests funds provided by the investor in permitted business ventures and returns to the investor the principal and an agreed share of profit. For the most part, the process of configuring an Islamic funding product is the same as the process for configuring a conventional deposit product, with the addition of the Profit Sharing setup, and excluding the components that deal with interest. ## Islamic banking contracts The contracts that provide the structure for financial products can be used interchangeably depending on their terms. It is important to note that contracts can be found to be contravening Shari'ah principles, despite being used in practice for a certain time period. For example, the _Sukuk_ contract - an analog for bonds - has attracted criticism from regulators in recent years and has resulted in a decline in use and popularity. :::note It is incumbent on you as a financial product developer to ensure that the contract you base your products on is valid according to Sharia principles and current law. ::: The sections below describe each type of commonly used Islamic banking contract in banking products. Some of these are not available or in early development (NPP stage) in Mambu. ## Mudarabah A party deposits their funds with a counterparty, which is tasked with managing those funds for a specified time period. Profits from this arrangement are shared between the parties. The return that the depositor gets is determined by the deposit amount and time period that the funds are managed by counterparty. Importantly, losses can only be levied on the depositor - unless there is negligence or misconduct on the part of the counterparty. :::note Banks often use this contract in conjunction with another Mudarabah, where the fund management is outsourced to an investment manager. Further distinctions can also be made with a Mudarabah that is restricted to investing only in certain assets or businesses. ::: ***Example*** Ali from Qatar is looking to deposit QAR 100 for 24 months and is hoping to get back QAR 105 (or more) back at the end of that period. He shops around for a contract and finds that the Qatari Infinity Bank offers a Mudharabah that gives 70% of profits to the depositor and takes 30% for managing depositors money. Ali agrees to this contract and deposits his money with Infinity Bank. The bank takes the deposit and puts it into an investment pool with other depositors. After the two year period the pool returns an 8% profit on the original investment. Ali's portion of the investment pool is QAR 108, but the contract stipulated that 30% of the profit (QAR 8) goes to his partner for services provided. So, the bank gets QAR 2.40 and Ali gets QAR 5.60 - leaving him happy with a total of QAR105.6. ## Wakala Wakala is similar to Mudarabah, except for some key differences. A party deposits their fund with a counterparty, which operates as the representative of the depositor to carry out their investment according to instructions. This principal-agent relationship is a key distinction. The other key distinction is that the counterparty promises an expected fixed return, and they also agree a cap for the maximum profit that the depositor may receive. Any profit in excess of the cap belongs to the representative and is an incentive for them to get as high a profit as they can. ***Example*** Ali is an environmentally-conscious traveller who wants to save for a holiday and is looking for a savings account to make that trip possible. After reviewing a couple of Mudarabah-type contracts he finds the return he is likely to get to not be enough for his travel plans and finds that many of the banks invest in fossil fuel companies. He wants something more aggressive and is more likely to meet his needs, while not investing for the benefit of the environment (in addition to the principles of Shari'ah law). From his research he finds Super Dubai Bank's offer, which although it is capped offers him more than the others. Super Dubai Bank offers a 12% return of up to AED70. The proposal from Ali to Super Dubai is to not invest his money in fossil fuel companies and he appoints them as his agent by taking out a savings account with them. Some time later, Ali goes to the bank to withdraw his money from the savings account. He has saved a total of AED1000 and his savings have grown to AED1120. He expects the profit of AED100 to be split between him and his agent (the bank). But wait, the cap he agreed to is AED70 for his portion of the profit. This means that he will on get AED1070, as the remainder (AED50) goes to his bank as agreed earlier. ## Wadiah A Wadiah contract operates much like a safety deposit box. The depositor deposits their money or assets with the counterparty, who keeps the money and assets and guarantees to return them at a later date. Like a safety deposit box, you get back what you put in. In certain cases the counterparty may choose to share any profits derived from the arrangement. This gift is known as hiba and is entirely voluntary. The difference between Wadiah and Qard Hassan is that the counterparty acts as the custodian of the money or assets of the depositor, and the money and assets continue to be owned by the depositor. ***Example*** Fatima wants to save some money for a gift for her friend later in the year, but knowing herself she expects that the money will be spent too soon. So she decides to get a simple savings account for safekeeping the money for when her friend's birthday comes around. As she visits her bank's website, she notices that they offer this very service and she deposits 200 000 Rupees (Rs). Her friend's birthday approaches and she happily withdraws the money to buy her friend a red cotton Kurta. Her friend is overjoyed to receive such a well-made item, but reminds Fatima that Pakistan Safe Bank often gives a small Hiba and she should keep her money there next time so that they can both get a gift. ## Qard Hassan Qard Hassan contracts operate much like Wadiah, bar this significant difference: the originator offers their deposit as a loan to the counterparty. The counterparty commits to repaying this loan in full back to the depositor. No profit or loss is shared between the participants of the contract. This contract works both ways: the originator may be a normal depositor giving their money to a bank, and vice-versa, the originator may be the bank offering a loan to a client. In some cases, the counterparty may charge a fee for maintaining this arrangement. Like a Wadiah contract, Hiba may be offered to the depositor, where the depositor is the originator. ***Example*** Muhammed has arrived in Jordan for a one-year contract assignment as a journalist with an international magazine. He wants to open a new current account where he can regularly deposit money from his assignments. After researching, he discovers that the Amman Islamic Bank offers a Qard current account linked to a Visa debit card. The account offers a discretionary monthly Hiba, and has a minimum opening amount of JD 200. After the year is complete, he closes the account before leaving the country, and uses the accumulated Hiba to take his family on a small holiday. ## Tawarruq A Tawarruq contract is based on receiving or selling goods for deferred payment through a facilitator. In a Tawarruq deposit, an originator deposits an amount for a facilitator to purchase an asset on behalf of the originator. The facilitator, in their own capacity, then sells the asset on to an unrelated third party and returns the originator's deposit. The difference between the deposit the originator gives the facilitator to buy the asset and the selling price that the facilitator sells the asset for is what makes the profit that is shared between the originator and the participant. --- # Convert to Islamic Products & Accounts URL: https://docs.mambu.com/docs/islamic-profit-sharing-configurations/ The Islamic Products section within the IPS interface displays Islamic deposit products. You may **convert** an existing conventional deposit product **into an Islamic deposit product & accounts** by: 1. Selecting **Link Product**. 2. Selecting a conventional deposit product to convert by selecting its checkbox. 3. Adding the **Effective Date** for the conversion. 4. Selecting the **Link** button. Please note that the product must use cash accounting methodology. Once a conventional deposit product has been converted to an Islamic deposit product, all accounts associated with this product will be converted too. After this action, interest/profit rate (including tiers) will be set to 0%, interest/profit term and source will be disabled. ![image.png](@site/static/img/support/image%28119%29.png) ### Transaction channel To choose a **transaction channel** for an Islamic deposit product, follow these steps: 1. Click on the **Islamic Products** tab in the top menu. 2. Locate the deposit product you wish to convert in the list, and click on **Actions**. 3. Choose **Transaction Channel** from the available options. ![\[IPS\] Products TSC.png](@site/static/img/support/%5BIPS%5D%20Products%20TSC.png) > The information how to create transaction chanels in Mambu can be found [here](/docs/transaction-channels). --- # Introduction URL: https://docs.mambu.com/docs/iso-20022-introduction/ The [ISO 20022](https://www.iso20022.org/) standard is a modern payment messaging format which was introduced in an attempt to standardise the rules of payment processing and provide a common language and set of messages for interchange, regardless of geographic region. By 2021, more than 70 countries have adopted ISO 20022 as a format for their regional clearing systems. Similarly to how you would initiate a SEPA credit transfer, you will now be able to initiate generic ISO 20022 credit transfers through the existing Mambu Payments Gateway API and user interface, which can be easily transformed to comply with regional schemes or sent directly to a local ISO-based clearing system. The actual processing of ISO-based payment orders is done in a similar manner as described in the [Payment Order Flow](/docs/payment-order) support article. The executed steps, as well as payment statuses remain the same regardless of the messaging format used. Supported use-cases: - Initiating outgoing ISO 20022 Credit Transfers - Receiving incoming ISO 20022 Credit Transfers Returns and/or Rejections - Initiating outgoing ISO 20022 Requests for Cancellation (recalls) - Receiving incoming ISO 20022 Positive and Negative responses to Cancellation Requests - Receiving incoming ISO 20022 Credit Transfers - Initiating outgoing ISO 20022 Credit Transfers Returns - Receiving incoming ISO 20022 Requests for Cancellation (recalls) - Initiating outgoing ISO 20022 Positive and Negative responses to Cancellation Requests :::info ISO 20022 Credit Transfers same currency support Please note that the above use-cases are applicable only for same currency payment messages. Cross-currency ISO 20022 payments are not yet supported. ::: :::warning Mambu recommends that Incoming ISO 20022 Credit Transfers messages should contain **at most 30.000 payments inside a single file**. Submitting files with larger payment amounts may result in delay of processing. In case the volume of payments is larger and cannot accomodate this number, consider limiting the number of payments that are included in a single file and send multiple, smaller files instead. ::: Please note that as this feature is still in an early development phase (Non-Production Preview). This page does not yet provide extensive usage documentation, as the specific implementation may be subject to change. Please refer to our [Mambu Release Cycle](/docs/mambu-release-cycle) support article to learn more about how this feature will progress from non-production preview to general availability. You can begin to familiarise yourself with the new messaging format by visiting the [ISO 20022 message catalogue](https://www.iso20022.org/iso-20022-message-definitions) and searching for ‘payments initiation’. --- # Jasper Reporting Overview URL: https://docs.mambu.com/docs/jasper-reporting-overview/ Jasper reports allow you to create custom reports that contain data from different Mambu database tables. :::warning Mambu is decommissioning Jasper reports. Jasper reports will not be available for customers who have agreements that are entered into on or after 1 January 2024. ::: To create Jasper reports, you can use Jaspersoft Studio. For more information, see [Creating Jasper reports](#creating-jasper-reports). Once your reports have been created in Jaspersoft Studio and you have the appropriate JRXML template, you may import this file to Mambu to display the Jasper report using data from various entities in Mambu. You can only import Jasper reports using the Mambu UI, you cannot import it using the API. For more information, see [Importing Jasper report templates in Mambu](#importing-jasper-report-templates-in-mambu). If you have done the migration from MySQL 5.7 to MySQL 8.0, you must update your existing Jasper reports. For more information, see [Updating Jasper reports](/docs/mysql-8-update#updating-jasper-reports). ## Jasper report templates and permissions There are five permissions related to viewing, creating, editing, and deleting reports in Mambu: * **View Jasper Reports** (`VIEW_JASPER_REPORTS`) * **Create Jasper Reports** (`CREATE_JASPER_REPORTS`) * **Edit Jasper Reports** (`EDIT_JASPER_REPORTS`) * **Delete Jasper Reports** (`DELETE_JASPER_REPORTS`) Regarding reports, there is a **Reports** tab under the **Administration** menu item and there is a **Reporting** menu item on the main menu. To view the **Reports** tab under **Administration**, you need at least one of the mentioned permissions assigned to your user - either directly or via a role. To view the **Reporting** menu item on the main menu you need the **View Historical Data** and the **View Reports** permissions assigned to your user, either directly or via a role. :::note These permissions do not affect whether your user is able to view a particular Jasper report when they have been embedded in the relevant entities. This is managed by the **Visibility** section when you manage a specific Jasper report template. For more information, see [Controlling access to reports](#controlling-access-to-reports) below. ::: ## Creating Jasper reports To create your Jasper report templates, you will need to: 1. Install Jaspersoft Studio and MySQL server. For more information on this setup, see [Software Requirements](/docs/software-requirements). 2. Link the MySQL database to Jaspersoft Studio so that all the data is available in Jaspersoft Studio. For more information on how to create an adapter between Jaspersoft Studio and MySQL Server, see [Data Adapter](/docs/data-adapter). 3. Download your current Mambu database and then import it into mySQL. For more information, see [Database clone](/docs/database-clone) and [Import Database clone](/docs/import-database-clone). :::warning Jasper reports cannot handle more than 10,000 rows when imported in Mambu since this is the batch limit. Reports based on more than 10,000 rows will therefore appear differently when run in Jaspersoft Studio as opposed to in Mambu. ::: ## Importing Jasper report templates in Mambu To import a Jasper report template in Mambu, you must first export the JRXML file from Jaspersoft Studio. Once you have this file: 1. In the main menu, go to **Administration** > **Reports**. 2. Using the **Reports Type** dropdown, select the entity for which you would like to create a report. 3. Select **Add Report**. 4. In the **Importing New Report** dialog, enter all the necessary information. For more information on the fields, see [Fields for reports](#fields-for-reports). ![Importing New Report dialog to import a Jasper report](@site/static/img/support/developer--import-new-jasper-report.png) ## Fields for reports | Name | Description | Required | | --- |-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| --- | | Report Name | The name for the report. Maximum length of 255 characters. If no name is entered, the field will be automatically filled with the name of the JRXML file you upload. | YES | | Report Type | The entity where the report will be displayed. The entity is chosen when using the **Reports Type** dropdown. There is an additional Other option. For more information, see [Viewing reports with report type other](#viewing-reports-with-report-type-other). | YES | | File | The JRXML file to upload. After selecting the file, select **Send** in order to complete the file upload process. | YES | | Visibility | The user roles that will have access to view the reports. For more information, see [Controlling access to reports](#controlling-access-to-reports). | NO | | Description | Additional notes about the report. | NO | ## Controlling access to reports Access to a report is controlled by the **Visibility** settings you select when creating or editing the report. If you select the **All Users** checkbox, then all roles will be selected and any user that has the appropriate permissions assigned to them either directly, or through a role will have access to the report. If you do not select the **All User** checkbox then users will need to be assigned a role with appropriate permissions to allow them access to the Jasper report template. This role needs to also be selected in the list of roles. Users will not have access to the report if they have the permissions directly assigned to them. ## Editing, deleting, and rearranging reports To edit, delete, or rearrange report templates: 1. In the main menu, go to **Administration** > **Reports**. 2. Using the **Reports Type** dropdown, select the entity for which you have created the report you want to edit, delete, or rearrange. 3. To edit or delete a report, find the report in the list and select **Actions** and then either **Edit** or **Delete**. To rearrange the reports, select **Rearrange Reports**, and then drag and drop the reports into the order you prefer and select **Save Changes**. ![List of jasper report templates to edit, delete, or rearrange](@site/static/img/support/developer--jasper-reports-list.png) ## Downloading and previewing the report template Jasper report templates are compiled before they are stored in the database, but the Jasper SDK is able to decompile reports into JRXML files. A Jasper report template will be decompiled before it is downloaded so that you can open it in Jasperstudio directly. To download a report template: 1. In the main menu, go to **Administration** > **Reports**. 2. Using the **Reports Type** dropdown, select the entity for which you have created the report you want to download. 3. Select the name of the report, which is a link, in order to go to the report detail page. 4. Select either **Download Report Template** or **Preview Report**. ![Report detail page where you can download the report template](@site/static/img/support/developer--client-jasper-report-configuration.png) ## Viewing reports In order to view a report you have to go to the entity under which you created the report. For example, if you create a report for the **Clients** entity, then to view the report: 1. Go to the client detail page of any client. 2. In the top right-hand corner select **Reports**, then select the name of the report you would like to view. ![Where to find reports on client detail page](@site/static/img/support/developer--client-detail-page-with-jasper-report.png) ### Viewing reports with report type Other There is an additional **Other** report type option. To view reports with the **Other** report type: 1. In the main menu, select **Reporting** > **Other Reports** 2. In the list of reports, select the report you want to view. --- # Journal Entries URL: https://docs.mambu.com/docs/journal-entries/ *Journal entries* are the logs of all the transactions in your organization which have accounting implications. Client account transactions will be logged automatically by Mambu after you [link your products](/docs/linking-products-to-accounting) to General Ledger (GL) accounts. Other transactions will need to be entered manually such as payroll or asset depreciation, for example. Automatic journal entries are logged when client transactions are posted, allowing you to generate accounting reports on real time data. To make the audit process easier, the journal entries are also linked to the correspondent client account transaction. ## Manual journal entries To enter a manual journal entry: 1. On the main menu, go to **Accounting** > **Journal Entries**. 2. On the right-hand side of the screen, select **New Journal Entry**. ![New Journal Entry view - Manual JE screen with fields like Debit/Credit, GL Account, Branch, Booking Date and Notes. The buttons found are Attach File, Cancel and Log Journal Entry. ](@site/static/img/support/accounting--new-journal-entry-3.png) 3. Fill in the following information: **Debit**: enter the amount to be debited to the account and the account number or name in the next field. As you start typing, you'll see the list of matching accounts in your Chart of Accounts so that you can choose the right one. **Credit**: enter the amount to be credited to the account and choose the correspondent account in the next field. **Branch**: for both credit and debit, you can select a branch. If you leave this field blank, transactions will not be associated with a branch. If you are already [filtering to view a specific branch](/docs/branches-and-centres), the journal entry is automatically set to that branch. **Booking Date (Entry Date)**: will be the current date by default, although you can backdate the journal entry, if the transaction was actually made previously. **Notes**: enter any comments you want to have associated with the transaction. Notes are mandatory when posting or reversing manual journal entries. **Attach File**: you can also attach up to five files to the manual journal entries, such as documents related to the amount needed for later audit or investigations. You must have the permission to manage documents in order for this option to be available. For more information, see [Permissions - Documents](/docs/permissions#documents). 4. Select **Log Journal Entry** and the new journal entry will be added to your list of journal entries. If you want to log several consecutive manual journal entries, select the **Create Another** checkbox and after the completion of the first manual journal entry, the window will remain open so you can log the next one. If you need to log "many-to-many" accounts journal entries, select the green plus sign, which will add another account to be either debited or credited. Keep adding as many as you need. :::note Mambu will validate that the total debit amounts are equal to the total credit amounts. If they are not, the journal entry cannot be saved and you will get an error message. ::: ### Accounting in multicurrency You can post manual journal entries in a currency other than the base currency. The manual journal entry will use [the accounting rate](/docs/accounting-setup) available at 00:00:00. Manual journal entries have only date stamps. ![New journal entry window with three different currencies, dollar, euro, and pound.png](@site/static/img/support/Screen%20Shot%202021-02-08%20at%208.09.00%20AM.png) ## Automatic journal entries After you link your products to GL Accounts by defining the [Product Rules](/docs/linking-products-to-accounting), Mambu will automatically log corresponding journal entries for each transaction posted in a client account. The deposit account transactions that generate automatic journal entries are: * Deposits * Deposit Adjustments (Reversals) * Withdrawals * Withdrawal Adjustments (Reversals) * Transfer * Transfer Adjustments (Reversals) * Fee Applied * Fees Adjustments (Reversals) * Interest Applied * Interest Applied Adjustments (Reversals) * Write-Off * Write-Off Adjustments (Reversals) :::note Interest Applied transactions on current accounts with overdraft interest and positive interest generate Journal Entries separately for overdraft and positive interest. ::: The loan accounts transactions that generate automatic journal entries are: * Disbursements * Disbursement Adjustments (Reversals) * Repayments * Repayment Adjustments (Reversals) * Interest Applied * Interest Applied Adjustments (Reversals) * Penalty Applied * Penalty Applied Adjustments (Reversals) * Fees Applied * Fees Applied Adjustments (Reversals) * Rescheduling * Write-Off * Write-Off Adjustments (Reversals) :::note In the case of automatically generated journal entries based on transactions entered in accounts, the journal entry date will always be the same as the client transaction's Entry Date. For example, if you backdate a repayment to three days ago, the corresponding journal entry will also be backdated to three days ago. ::: ## Entry ID vs Transaction ID *Entry IDs* refer to journal entry IDs. For example, when you enter a repayment, the repayment transaction will generate two journal entries—debit and credit—with the same transaction ID but with two different entry IDs, which are globally unique for journal entries. *Transaction IDs* refer to a withdrawal, a repayment, a fee applied, and so on. They are used to cross-reference them with the transaction on the loan or deposit account. :::note If you make a manual journal entry, a single transaction ID will be created for that set of journal entries which is not related to any client account transaction. Each individual entry will have its own entry ID. ::: :::warning Transaction IDs are independently generated for loans and deposits. It is therefore possible to have the same transaction ID for a deposit transaction in a deposit account and an existing repayment transaction in a loan account. ::: ## Reversing journal entries You can only reverse manual journal entries. If a journal entry is logged by mistake and needs to be reversed: 1. Find the journal entry using the appropriate filters. 2. Select the reversal icon next to the journal entry. 3. Confirm. You can also add a comment on the reversal reason - the Notes field is mandatory and needs to be filled out in order for the journal entry to be reversed. :::note If you reversed a journal entry by mistake, you will need to reverse the new reversal entry, so that the account debits and credits will go back to the original state. If you need to reverse a journal entry that was posted automatically for a client account transaction, you need to reverse the original client transaction. ::: ## Listing and reporting journal entries Similar to clients or accounts [custom views](/docs/custom-views), you can configure the columns visible in the journal entries view and define several "presets" that include different columns depending on the reporting needs. For more information on setting and editing presets, see [Customizing Columns](/docs/customizing-columns). ### Columns Include information about the journal entries (such as the ID, creation date, debit, and credit), but can also contain information from the client, group or account associated with the journal entry. ### Filters Mambu allows you to filter journal entries based on a various number of constraints. You can filter by any journal entry specific details (entry ID, date, branch GL Account, amount and so on) or by any detail related to the transaction associated with it. --- # Known Issues URL: https://docs.mambu.com/docs/known-issues/ This page describes any known issues affecting Mambu, Mambu Process Orchestrator, our Connectors, our APIs, or any other Mambu services or tools. | Product or Feature | Issue | Comments and/or Remediation Steps | Date Added | | --- | --- | --- | --- | | All Mambu Products | Log4j vulnerability Log4Shell | Mambu has been actively managing and mitigating threats associated with the recently disclosed security issue Log4Shell (initially CVE-2021-44228 - Log4j2, and other related ones). We continue to actively monitor the situation and we will provide new updates and new posts as required. At this moment we can confirm that all identified affected Mambu services were updated, related WAF rules have been deployed, traffic from anonymizer services such as TOR are blocked, and a dedicated external penetration test with only that particular library in scope has been conducted without any further findings. | Jan 2022 | | Mambu Process Orchestrator (MPO) | After an update, the UI may sometimes have problems for any user who was logged in while the update occurred. | Clear your browser cache and log in again. | Jan 2022 | --- # Labels URL: https://docs.mambu.com/docs/labels/ In the Mambu UI, we use *labels* to define the specific terms that are used to refer to various basic entities and concepts. For example, by default, we refer to various entities in the Mambu UI as *clients*, *groups*, *branches*, and so forth. These terms are customizable, and you may change them to match whatever terminology you use for these concepts in your organization. You can view your labels via the Mambu UI at **Administration** > **General Setup** > **Labels**. ![Labels in the Mambu UI](@site/static/img/support/managing-the-mambu-ui--labels-configuration.png) :::warning Customized labels apply to the Mambu UI only. The corresponding terms in the Mambu API will not be affected. ::: The default labels that can be changed are: * Clients * Groups * Branches * Centres * Credit officers * Interest * Fees * Loan ## Editing labels To edit the default labels: 1. On the main menu, go to **Administration** > **General Setup** > **Labels**. 2. In the **Language** dropdown, select the language for which you want to change the label. 3. Find the label you want to edit in the list. 4. Select **Actions** > **Edit**. 5. Enter the new labels in both singular and plural forms. 6. Select **Save Changes**. You will see the new labels immediately after saving the changes. ![Editing labels dialog](@site/static/img/support/managing-the-mambu-ui--customize-element-name.png) ## Labels and Mambu Display Language Settings The Mambu UI may be configured to use non-English languages. If you set a user profile to use a non-English language, terms that are defined by labels are **not automatically translated**. In this case, we recommend using labels to configure the Mambu UI to use the desired terms in the appropriate language. For more information, see [Language Settings](/docs/language-settings). --- # Language Settings URL: https://docs.mambu.com/docs/language-settings/ This article discusses the various language settings available in the Mambu UI. We support Spanish, German, French, Portuguese, and other languages. If you would like us to consider adding support for a new language, please contact your Customer Success Manager to discuss your requirements. :::warning The official language of the Mambu Platform is English. We have used reasonable efforts to provide an accurate translation of terms used on the Platform, however we cannot guarantee the accuracy of translations. ::: ## Mambu display language The Mambu display language determines the language settings for the UI. If you have federated authentication enabled, you must set the display language in your identity provider (IdP). We recommend consulting the documentation of your IdP for exact steps on how to do this. If you use Mambu login, then you set your display language when you create a user account. For more information, see [Creating a user](/docs/creating-new-users#mambu-display-language). To change your Mambu display language if you use Mambu login: 1. Navigate to **your name** > **Edit your profile** on the top right corner of your screen. 2. In the **User Access** section, under **Mambu Display Language**, choose your desired language from the dropdown list. 3. Select **Save User**. 4. Log out and then log back in to update the display language for the UI in the new language. ![Screen capture of available display languages.](@site/static/img/support/mambu-display-language.png) ## Menu items and views language configuration Some of the menu items, and their respective views, in the navigation will still be displayed in English, even when the language has been changed. These are configurable and can be adjusted to your preferred language. ![The Manage my views screen with the edit button highlighted where you can change the language of your parent menu item but also of its views](@site/static/img/support/edit-views-in-different-languages.png) For more information, see [Editing menu items](/docs/menu-items#editing-menu-items) and [Editing a saved custom view](/docs/custom-views#editing-a-saved-custom-view). ## Labels language configuration If you set a user profile to use a non-English language, terms that are defined by labels are not automatically translated. You may edit them to match your Mambu display language. ![Labels screen with the language and edit buttons highlighted](@site/static/img/support/editing-labels.png) For more information, see [Editing labels](/docs/labels#editing-labels). ## Custom fields Custom field definitions are additional fields that you can create in Mambu to capture any extra information required for your business processes. Custom field definitions are not translated automatically when users change their display language, but they may be edited for your entire organization to match the most commonly used display language. For more information, see [Custom Fields](/docs/custom-fields). ## Client preferred language When you create clients, you can set their preferred language so that the reports, schedules, and account statements you generate for them will be in their language. Their default preferred language is the Mambu display language, but you may change it to any of the available languages. ![Create a client form with preferred language highlighted](@site/static/img/support/client-preferred-language.png) For more information, see [Creating an individual client](/docs/create-an-individual-client#general-and-details-sections). ### Placeholders in notifications The client preferred language will also determine the language of some placeholders that you include in your notification templates and product documents. For more information on placeholders and how to use them, see [Placeholders](/docs/placeholders). ### Send notifications in different languages When communicating with your clients, you can have different language versions of your messages. To create a notification template for clients that have a specific preferred language, you may define a condition in the notification template and use the **Preferred language** filter. In the following example, an email notification template is set up for clients that have German set at their preferred language. ![Create email notification in a different language](@site/static/img/support/create-email-notification-in-a-different-language.png) --- # Linking Products to Accounting URL: https://docs.mambu.com/docs/linking-products-to-accounting/ Each action taken against an account will have an effect on your company's balance sheet, whether it's a deposit, a withdrawal, or the application of interest or fees. If you have set up a [Chart of Accounts](/docs/creating-your-chart-of-accounts), you can link individual actions and transaction types to one of your General Ledger (GL) Accounts. After linking them to GL Accounts, Mambu will automatically post journal entries on the corresponding GL Account whenever a transaction occurs. You can only link to _Detail_ type accounts. _Header_ accounts will not be selectable, as these are designed to provide a sum total for all of the detail accounts under them rather than record individual transactions. For more information, see [Creating Your Chart of Accounts - Chart of Accounts Structure](/docs/creating-your-chart-of-accounts#chart-of-accounts-structure). This article provides an overview of Mambu's standard behavior for loans and deposit accounts and provides examples based on a simple chart of accounts. If you need additional support configuring your system, we invite you to reach out to our support team - for more information, see [Contacting Support](/docs/mambu-support). ## For Loan Accounts |Category|Type|Description|Example Account| |----------|------|-----------|-------------------| | **Portfolio Control** | Asset | The current asset account that is controlling the product portfolio. | _Loan portfolio control_ | | **Transaction Source** | Asset | The current asset account that is managing your money source. | _Cash on hand_ | | **Write-off Expense** | Expense | The expense account that you use when cancelling or writing off an account. | _Un-recoverable expenses_ | | **Interest Receivable** | Asset | The account used when interest is owed by a customer but not yet paid. **Accrual Methodology only** | _Loan account interest receivable_ | | **Taxes Receivable** | Asset | The account used when taxes are owed but are not yet paid. **Accrual Methodology only** | _Loan account tax receivable_ | | **Fee Receivable**\* | Asset | The account used when fees are owed by a customer but have not yet been paid. **Accrual Methodology only** | _Loan account fees receivable_ | | **Penalty Receivable** | Asset | The account used when penalties are owed by customer but not yet paid. **Accrual Methodology only** | _Loan account penalties receivable_ | | **Deferred Interest Income** | Liability | **Only available when the product has been configured to accept pre-payment of future interest**| _Loan account interest liablities_ | | **Deferred Taxes** | Liability | **Only available when an amortization profile is applied for a fee** | _Loan account tax liablities_ | | **Deferred Fee Income**\* | Liability | **Only available when an amortization profile is applied for a fee** | _Loan account fee liablities_ | | **Fee Income**\* | Any | The account used when you receive income from fees charged to a customer account | _Loan account fee income_ | | **Interest Income** | Income | The account used when you receive interest on an outstanding loan | _Loan account interest income_ | | **Taxes Payable** | Liability | The account used when government taxes are paid based on the value of a loan in your book | _Loan account tax liablities_ | | **Penalty Income** | Income | The account used when you receive income from penalties applied to customer accounts | _Loan account penalty income_ | :::note When adding fees to a product, you can opt to use the product default General Ledger Accounts for **Fee Receivable**, **Fee Income**, **Fee Losses**, and **Deferred Fee Income** or set these to custom GL accounts. This allows you to have much more granularity in your reporting by, for example, differentiating between manual and automatic fees. For more information, see [Fees accounting](/docs/fees-accounting). ::: ### Loan Product Rules under Cash basis Accounting The following table shows Mambu's behavior after the accounting rules per product have been set: | Transaction Type | Debit | Credit | | --- | --- | --- | | Loan Disbursement | Portfolio Control | Transaction Source | | Principal Write-Off* | Write-Off Expense | Portfolio Control | | Principal (Re)paid | Transaction Source | Portfolio Control | | Interest Paid | Transaction Source | Interest Income | | Fee Paid | Transaction Source | Fee Income | | Penalty Paid | Transaction Source | Penalty Income | | Taxes (VAT) Paid | Transaction Source | Taxes Payable | :::note Under cash based accounting rules, as nothing accrues, there are no separate general ledger entries for writing off interest or taxes that would have been payable on the loan account. ::: After enabling the Cash basis Accounting method, Mambu will display dropdown menus where you can choose the accounts depending on the type (asset, expense or income) in each one of them. ![Select corresponding General Ledger Accounts for loan products using cash based accounting ](@site/static/img/support/loans_accounting_cash_gl_accounts_selection.png) After saving the changes the transactions will start being logged automatically in Accounting following those rules. ### Loan Product Rules under Accruals Accounting In the following table you can see Mambu's internal behaviour when you define the accounting rules in a Loan Product under Accruals Accounting: | Transaction Type | Debit | Credit | | --- | --- | --- | | Loan Disbursal | Portfolio Control | Transaction Source | | Interest Applied | Interest Receivable | Interest Income | | Fee Applied | Fees Receivable | Fee Income | | Penalty Applied | Penalties Receivable | Penalty Income | | Principal (Re)paid | Transaction Source | Portfolio Control | | Interest Paid | Transaction Source | Interest Receivable | | Fee Paid | Transaction Source | Fee Receivable | | Penalty Paid | Transaction Source | Penalty Receivable | | Principal Write-Off | Write-Off Expense | Portfolio Control | | Interest Write-Off | Write-Off Expense | Interest Receivable | | Fee Write-Off | Write-Off Expense | Fee Receivable| | Penalty Write-Off | Write-Off Expense | Penalty Receivable | | Taxes Applied | Taxes Receivable | Taxes Payable | | Taxes (VAT) Paid | Transaction Source | Taxes Recievable | | Tax Write-Off | Write-off Expense | Taxes Receivable | Like in the previous method, after enabling the Accruals Accounting method, Mambu will display dropdown menus where you can choose the accounts depending on the type (asset, expense or income) in each one of them. ![Select corresponding General Ledger Accounts for loan products using accrual based accounting ](@site/static/img/support/loans_accounting_accrual_gl_accounts_selection.png) For loan product types with accrual accounting you can select for the Interest Accrued Method to be Daily. Every day, when the End of Day Process runs, Mambu will log journal entries in accounting for the total amount of interest that is accrued (and not yet applied) on your active accounts. On the next process execution, Mambu will reverse the previous day's entries and log new ones with the updated accrued amounts. ![Interest Accrual Method dropdown with Daily and Monthly options](@site/static/img/support/accounting--interest-accrued-method-dropdown.png) Click on save and from this point onwards Mambu will log all of your transactions according to these rules. ## For Savings / Deposit Accounts |Category|Type|Description|Example Account| |----------|------|-----------|-------------------| |**Transaction Source** | Asset | The current asset account that is managing your money source. | _Cash on hand_ | | **Savings Control** | **Liability** or Equity | The current liability or equity account that is controlling the product portfolio.|_Deposit Portfolio Control_ | | **Interest Expense** | **Expense** or Income | The expense or income account that you use when have to pay interest for the deposits.| _Deposit account interest paid_ | | **Interest Payable** | **Liability** or Asset | The account used for interest earned by a saver but not yet paid into their account. **Accrual Methodology only**| _Deposit account interest accrued_ | | **Negative interest income** | **Income** or Expense | The income (or expense) account that you use to recognise negative interest from positive balance for the deposits.| _Deposit account negative interest income_ | | **Negative Interest Receivable** | **Asset** or Liability | The account used to hold negative interest accrued from a positive balance that has not yet been debited from the account**Accrual Methodology only**| _Deposit account negative interest accrued_ | | **Taxes Payable** | Liability | The account used for taxes payable on interest earned from a deposit or savings account. **Only available when interest is paid into the account and withholding taxes are applied** | _Deposit account tax liablities_ | | **Fee Income**\* | Any | The income accounts you recognize when cash is received| _Deposit account fee income_ | | **Overdraft Write-Off Expense** | Expense | The expense account that you use when cancelling or writing off an account. **Only available when the product offers an overdraft facility** |_Non-recoverable overdraft expenses_| | **Overdraft Portfolio Control** | Asset | The current asset account that is controlling the product portfolio. **Only available when the product offers an overdraft facility**| _Deposit account portfolio control_ | | **Overdraft Interest Receivable** | **Asset** or Liability | The account used to hold interest accrued from a customer's overdraft that has not yet been debited from their account. **Accrual Methodology only**. **Only available when the product offers an overdraft facility**| _Overdraft interest payable_ | | **Overdraft Interest Income** | **Income** or Expense | The income (or expense) account you recognize when cash is received. **Only available when the product offers an overdraft facility** | _Overdraft interest income_ | :::note When adding and configuring fees for your product you can indicate that the product default General Ledger Account for **Fee Income** should be used for this fee or select any other account. This will allow for greater granularity in reporting. ::: Just like for Loans, after enabling the accounting in the product, **select the account depending on the type (asset, liability, expense or income) in the dropdown menus > save it** and from that moment on, the transactions will be automatically logged in Accounting. ### Deposit Product Rules under Cash Basis Accounting For deposits, Mambu will manage the accounting using the rules below. See the sub-sections for additional information regarding interest application/accrual. ![Deposit Product - Accounting Rules - Methodology Cash](@site/static/img/support/LinkingtoAccounting-DepositProductRules-CashMethod.png) | Transaction Type | Debit | Credit | | --- | --- | --- | | Deposit into account | Transaction Source | Savings Control | | Withdrawal from account | Savings Control | Transaction Source | | Fee Applied | Savings Control | Fee Income | | Overdraft Written Off | Overdraft Write-Off Expense | Overdraft Portfolio Control | | Overdraft Withdrawal | Overdraft Portfolio Control | Transaction Source | | Overdraft Principal (Re)paid | Transaction Source | Overdraft Portfolio Control | | Overdraft Interest Paid | Transaction Source | Interest Income | | Overdraft Fee Paid | Transaction Source | Fee Income | | Interest applied (positive interest rate) | Interest Expense | Savings Control | | Interest applied (negative interest rate) | Savings Control | Negative Interest Income | | Withholding Taxes Paid | Savings Control | Taxes Payable | ### Deposit Product Rules under Accruals Accounting For deposit product types with accrual accounting, the Interest Accrued Methods available are Daily or Monthly. The process is the same as for loan product types, meaning that every day, when the End of Day Process runs, Mambu will log journal entries in accounting for the total amount of interest that is accrued (and not yet applied) on your active accounts. On the next process execution, Mambu will reverse the previous day's entries and log new ones with the updated accrued amounts. If you allow overdrafts and want to use this option, define all Overdraft-related GL accounts, and journal entries will be posted. When overdraft interest or fees are applied on the account, accounting entries will be posted. Mambu will credit the Overdraft Interest or Fees Income rule and debit the Overdraft Portfolio Control. ![Deposit Product - Accounting Rules - Methodology Accrual](@site/static/img/support/LinkingtoAccounting-DepositProductRules-AccrualMethod.png) | Transaction Type | Debit | Credit | --- | --- | --- | | Deposit into account | Transaction Source | Savings Control | | Withdrawal from account | Savings Control | Transaction Source | | Fee Applied | Savings Control | Fee Income | | Overdraft Written Off | Overdraft Write-Off Expense | Overdraft Portfolio Control | | Overdraft Withdrawal | Overdraft Portfolio Control | Transaction Source | | Overdraft Principal (Re)paid | Transaction Source | Overdraft Portfolio Control | | Overdraft Interest Paid (positive interest rate) | Transaction Source | Interest Income | | Overdraft Interest Paid (negative interest rate) | NOT SUPPORTED | NOT SUPPORTED | | Overdraft Fee Paid | Transaction Source | Fee Income | | Interest accrued (positive interest rate) | Interest Expense | Interest Payable | | Interest applied (positive interest rate) | Interest Expense | Savings Control | | Interest accrued (negative interest rate) | Negative interest receivable | Negative Interest Income | | Interest applied (negative interest rate) | Savings Control | Negative interest receivable | | Withholding Taxes Paid | Savings Control | Taxes Payable | ## Accounting in Multicurrency When [creating a new deposit product](/docs/setting-up-new-deposit-products#accounting-rules), if the Accounting in Multicurrency feature is enabled, Mambu will display dropdown menus under **Accounting Rules** where you can choose between the accounts created in the currency of the product or in the base currency. ![Screen Shot 2021-02-01 at 10.26.11 AM.png](@site/static/img/support/Screen%20Shot%202021-02-01%20at%2010.26.11%20AM.png) :::warning Please be aware * **Only** Journal entries for GL accounts in a currency other than the base currency will contain information regarding the foreign currency debit and credit amount and the currency of the transaction. * Deposit and loan product transactions will be allowed as long as the accounting rules of the related products have the GL accounts in the same currency ::: --- # Linking Deposit and Loan Accounts URL: https://docs.mambu.com/docs/linking-savings-and-loan-accounts/ A *settlement deposit account* allows you to have a deposit account that is automatically used as a source for loan repayments. On the day a repayment becomes due, the amount is automatically transfered from the settlement deposit account to the loan account. Settlement deposit accounts are sometimes also simply referred to as settlement accounts (for example in the Mambu UI). There are two main advantages of using settlement deposit accounts: 1. It allows organizations to collect money from clients into a deposit account and if the client also has a loan, to automatically transfer the repayment amount from the deposit account when a repayment on the loan is due. 2. It reduces the probability of having pre or late repayments, since the money is in another account and is automatically transferred on the actual repayment due date. ## Enabling linked accounts The option to enable linked accounts is under every loan product's settings. Once you enable it, you can choose the settlement deposit product that you want the loan product to be linked to. Here you have an option to choose either **Any**, meaning that you’ll be able to link loan accounts created under this product to any deposit product available, or you can choose a specific deposit product. If you decide to link the loan product to a specific deposit product, you will find two different options available: * **Auto-Set Settlement Accounts on Creation**: Any loan account you create under that product will automatically link to the client's deposit account, if they have one. If the client has several deposit accounts, the loan won't be automatically linked to any of the deposit accounts and you will have to link the correspondent accounts manually. * **Auto-Create Settlement Account**: If the client doesn't have a deposit account yet and this option is selected, Mambu will automatically create one when you open a new loan for that client and link both accounts. :::warning The auto-set and auto-create options are not yet available for deposit accounts with [Overdraft](/docs/overdraft-products). These deposit accounts with overdraft enabled can only be *manuallly* linked to loan products as settlement deposit accounts. ::: ![Product Links with Enable Linking option checked.](@site/static/img/support/product-links-with-enable-linking-option-checked.png) Choose a settlement option from the following three available for linked products: * **Only transfer full dues**: the transfer of funds will only be performed if there are enough funds in the deposit account to cover the entire amount of the installment due, otherwise nothing will happen. * **Allow partial transfers**: even if the funds in the deposit account are not enough to cover the entire amount of the installment due, the transfer will still happen. * **No automated transfers**: the accounts will be linked, but automated transfers between the deposit and loan account will not be made. You can create settlement deposit accounts as offsets for loan accounts. For more information, see [Redraw and Offset Settings](/docs/redraw-facility-and-offset-loans#offset). :::note When linking two accounts, both the loan and deposit products used to create the accounts must have the same accounting setup. For more information, see [Accounting Setup](/docs/accounting-setup#enabling-accounting-for-loans-and-deposits). ::: ## Transfers between linked accounts When a transfer occurs, all the product rules continue to be respected, which means that if the deposit account is not allowed to go negative and the funds are not sufficient to make the repayment, then the transfer will not be made and the loan account goes into arrears. If a deposit account is the settlement deposit account of more than one loan account, the automated transfers will happen in the order the accounts were linked. A deposit account can be linked to several loan accounts, but a loan account can only be linked to a single settlement deposit account. You can't have a loan account and a linked settlement deposit account on different branches. When a loan account is linked to a settlement deposit account, if you change the branch of the loan account, it will automatically change the branch of the settlement deposit account as well, unless the settlement deposit account is linked to other loan accounts. When removing the link between the settlement deposit account and the loan account, the settlement deposit account will be moved to the client's branch. --- # Loan Account Attachments URL: https://docs.mambu.com/docs/loan-account-attachments/ Any loan account can have files (attachments) uploaded in Mambu, for example, scans of documentation required in the loan application process, signed forms, and loan agreements. ## Uploading a new document To upload a document: 1. Open the loan account. 2. Go to the **Attachments** tab. 3. On the left-hand side of the screen, select **Upload Document**. 4. Enter a relevant name and description. 5. Select **Choose File** > select the file you want to upload > select **Open**. 6. Select **Save Changes**. **Use the following file types:** * Images - JPEG, PNG, GIF, BMP, TIFF * Documents - PDF, XML, DOC, DOCX, DOCM, DOT, DOTX, DOTM, XLS, XLSX, XLSB, PPT, PPTX, ODT, OTT, FODT, PDF, XML, TXT, CSV, PROPERTIES, MSG, TIF, ZIP, RTF, XLSM, ODS, ODP, EML, EMLX, HTML, MHT, MHTML, XPS, NUMBERS, KEY, PAGES, YAML, JSON, JASPER, JRXML **Don't use:** * XHTML, JS, JSP, PHP, SWF :::note * Obfuscated PDF files will always be rejected, since our anti-virus cannot scan them for malware. * You cannot upload files without an extension, with multiple extensions, or containing a period in their name. * You cannot upload empty files. * Don't use the following characters in the file's name when you upload it to Mambu: **/ > < | : & ? * [ ] # \* `** ::: ## Managing documents You can make changes to the title and description of the documents, download them to your local machine, or simply delete them. ![The Upload Document button from Attachments view and the available options related to documents, preview, download, edit, and delete](@site/static/img/support/manage-loan-account-documents.png) ### Previewing documents To preview a document: 1. Open the loan account. 2. Go to the **Attachments** tab. 3. In the list of documents, find the one you want to preview and, on the right-hand side of the row, select **Actions** > **Preview**. ### Downloading documents To download a document: 1. Open the loan account. 2. Go to the **Attachments** tab. 3. In the list of documents, find the one you want to download and on the right-hand side of the row, select **Actions** > **Download**. Or, you can click directly on the document name. ### Editing documents To edit a document: 1. Open the loan account. 2. Go to the **Attachments** tab. 3. In the list of documents, find the one you want to edit and on the right-hand side of the row, select **Actions** > **Edit**. 4. Make the desired changes. 5. Select **Save Changes**. ### Deleting documents To delete a document: 1. Open the loan account. 2. Go to the **Attachments** tab. 3. In the list of documents, find the one you want to delete and on the right-hand side of the row, select **Actions** > **Delete**. 4. Confirm. --- # Loan account goes in arrears URL: https://docs.mambu.com/docs/loan-account-goes-in-arrears/ ## Business case A 3rd party system must be notified when a loan account with a loan amount higher than 1 million goes into arrears. This will apply for individual clients only. The receiving end is exposing an API which is able to receive POST calls with a JSON payload containing the client id, loan id, the current date when the loan goes into arrears, and the loan amount. *** ## Configuration ![webhook showcase example loan account in arrears](@site/static/img/support/webhook_showcase_example_account_in_arrears.png) *** --- # Loan Account Life Cycle and States URL: https://docs.mambu.com/docs/loan-account-life-cycle-and-states/ From the moment you create a new loan account, it will go through different states, each of them with specific implications which are shown in the following diagram and described in more detail below. :::warning For all the examples below, the underlying assumption is that users have the right permissions to perform each of the actions. ::: ## Set up the initial state of a loan account When [setting up a new loan product](/docs/setting-up-new-loan-products), in the **New Account Settings** section of the form, choose what you want the initial state of the account to be: `Partial Application` or `Pending Approval`. ### Partial Application When a loan is in `Partial Application`, it means that the loan application is missing information and is not yet complete. As soon as all the documents are collected and the application is complete, you can request approval which will set the loan account to `Pending Approval` state, so that it can be evaluated. If at this stage a decision is made not to proceed with the application at all, it can be `Rejected` by the organization or `Withdrawn` by the client. :::note In this state it is still possible to edit the loan account terms, such as loan amount, interest rate, or number of installments. ::: ### Pending Approval When a loan is `Pending Approval`, it means that the loan application is under evaluation and can be either: * Approved * Rejected (by the organization) * Withdrawn (by the client) * Set as Incomplete (if there is still information or documentation missing from the application, you can send the application back to `Partial Application`). :::note In this state it is still possible to edit the loan account terms, such as loan amount, interest rate, or number of installments. ::: ### Reject an application When an application is `Rejected`, the account will be automatically closed and classified as `Closed (Rejected)`. The loan account will remain associated to the client or group who requested it and all the information that was entered, like comments or notes will remain associated to the account allowing you to keep track of the reasons for the rejection. This information can be used later, in case the client makes a new request and you want to consider it for the new evaluation process. :::note You can **Undo Reject** and send the account back to its previous state by selecting the option available under **More**. ::: ### Withdraw an application If the client chooses to **Withdraw** the loan application, it will be automatically closed and classified as `Closed (Withdrawn)`. :::note You can **Undo Withdraw** and send the account back to its previous state by selecting the option available under **More**. ::: ## Approved Once all the account terms are evaluated and agreed upon, the loan application can be approved. To approve a loan account, select **Approve**, add any comments you might have and confirm. After being approved, the loan terms such as loan amount, interest rate, or number of installments cannot be changed anymore. At this stage, the loan can either be `Disbursed` or can be `Withdrawn` by the client. :::note You can **Undo Approve** and send the account back to its previous state by selecting the option available under **More**. ::: ### Disburse a Loan As soon as the application is approved, it's ready to be disbursed. After being disbursed the loan account becomes automatically `Active`. :::note You can **Undo Disbursement** and send the application back to the `Approved` state by selecting the option available under **More**. ::: ## Active This is the state of an account immediately after being disbursed. It will remain in the `Active` state as long as the account remains in good standing. ## Active (in Arrears) When a loan account has at least one late repayment, Mambu will automatically change its state to `Active in Arrears` until all repayments are made. The late repayments will then be displayed under each account's repayment schedule. ## Locked When there are unexpected events, or a client is having problems repaying a loan, you can lock the account and suspend interest, penalties and fees from being applied on the account. When the account will be unlocked, the interest, fees and penalties that were accrued during the account locked state will be applied on the account. ## Terminated When you terminate a loan, the total outstanding principal plus all accrued charges become due immediately (as of the termination date). This feature is currently available for: * Dynamic Loans * Interest calculation method: Declining Balance Equal Installments * Pre-payment allocation: On upcoming pending installment only * Pre-payment recalculation: Reduce Number of Installments (RNI) * Pre-payment recalculation: Reduce Amount per Installment (RAI) * Types of fee allowed: Manual Fees only To terminate a loan account, select **Close** > **Terminate**. Add any notes you wish to this transaction for auditing purposes. These notes will be stored with the history of transactions for this account. :::note You can **Undo Terminate** and send the loan account back to its previous state by selecting the option available under **More**. The interest will still be applied, though. ::: ## Closed Loan accounts can be closed in several situations presented below. ### All Repayments Made When the client finishes repaying all the installments, the account can be closed and will be stored under the client's profile as `Closed (all obligations met)`. :::note Mambu will automatically calculate the "Completed Loan Cycles" whenever a loan account is closed with "All Obligations Met", meaning the loan has been either fully repaid or paid-off early. ::: ### Paid Off When a client pays the whole amount of the loan earlier, the account can be closed for that client. To pay off a loan account, select **Close** > **Pay-off**. If part of the outstanding loan amount is not collected, you can choose to write off any remaining balances for interest, fees and penalties. Add any notes you wish to this transaction for auditing purposes. These notes will be stored with the history of the transactions for this account. The paid-off loan account will be stored under the client's profile as `Closed (all obligations met)`. ### Writen Off When repayments are no longer expected on a loan account that is in arrears, it should be closed and written off. To write off a loan account, select **Close** > **Write off**. Add any notes you wish to this transaction for auditing purposes. These notes will be stored with the history of the transactions for this account. The written-off loan account will be stored under the client's profile as `Closed (Written Off)`. ### Rescheduled If for instance, due to an unexpected event, a client is having problems repaying a loan, you can choose to reschedule the loan, therefore adjusting its terms in order to prevent it from going into arrears. To reschedule a loan, select **Close** > **Reschedule**, add notes about the reasons for rescheduling and confirm the new state. When you reschedule a loan, the current loan will be closed, its state will change to `Closed (Rescheduled)` and a new loan with the new terms will be automatically created with a link to the original account (this is often a requirement in an auditing process). If the rescheduled account had interest, fees or penalties due, you can choose to either capitalize them on the new account principal balance or to writte them off when the new loan account is created. ### Refinanced If you decide to top-up a loan account, you can choose to refinance the loan by adding an additional amount to the current balance of the loan. To refinance a loan, select **Close** > **Refinance**, add notes about the reasons for refinancing and confirm the new state. When you refinance a loan, the current loan will be closed, its state will change to `Closed (Refinanced)` and a new loan account with the new terms will be automatically created with a link to the original account (this is often a requirement in an auditing process). If the refinanced account had interest, fees or penalties due, you can choose to capitalize them on the new account principal balance or to write them off when the new loan account is created. --- # Loan Account Overview Details URL: https://docs.mambu.com/docs/loan-account-overview-details/ Balance information can be retrieved from a loan account via API v2 by using the [Loan Accounts - getById](/api/api-v2/loans/get-by-id) endpoint. The same information is also available in the UI account overview, under **Details**. ![A loan account with information about balance, interest, currency, and so on](@site/static/img/support/loan-overview-page.png) | Balance | Description | | --- | --- | | **Total Balance** | The total amount of the loan, which consists of the principal plus any interest, fees, and penalties that may have been charged. | | **Principal Balance** | The total amount of principal. | | **Interest Balance** | The total amount of interest. | | **Interest from Arrears Balance** | The total amount of interest from arrears. | | **Interest Accrued** | The amount of interest accrued by the current date. | | **Interest from Arrears Accrued** | The amount of interest accrued from arrears by the current date. | | **Fee Balance** | The total amount of fees. | | **Total Due** | The total amount that is currently due. | | **Principal Due** | The principal amount that is currently due. | | **Interest Due** | The interest amount that is currently due. | | **Interest from Arrears Due** | The interest from arrears amount that is currently due. | | **Fees Due** | The total amount of fees that is currently due. | | **Penalty Due** | The total amount of penalties that is currently due. | | **Total Paid** | The total amount that has been paid. | | **Principal Paid** | The total principal amount that has been paid. | | **Interest Paid** | The total interest amount that has been paid. | | **Interest from Arrears Paid** | The total interest from arrears that has been paid. | | **Fees Paid** | The total amount of fees that has been paid. | | **Penalty Paid** | The total amount of penalties that has been paid. | ## Days in arrears vs. days late There is a difference between how many days an account is in arrears and how many days an account is late. In the example provided in the screenshot, a grace period of 12 days was set up. * **Days in Arrears**: For products with no grace period, a loan account will be marked as `In Arrears` from the day following the due date. For products with grace period, the days in arrears will be counted from the day following the arrears tolerance period. * **Days Late**: If a loan has a grace period, the loan will intially be marked simply as late. The days late are calculated from the day following the due date. ## Regular interest vs. late interest In the **Details** section of the loan account, you can also see more information about interest from arrears including how much of the total interest comes from interest from arrears. Here is the difference between the regular interest and the late interest: * **Interest Balance**: shows the total interest. * **Interest from Arrears Balance**: shows how much of **Interest Due** is coming from arrears. * **Interest from Arrears Accrued**: shows how much of **Interest Accrued** is coming from Arrears. :::note * **Interest Balance** already contains **Interest from Arrears Balance**. * **Interest Accrued** already contains **Interest from Arrears Accrued**. ::: ## Foreign currency loans When your tenant is first created, you will be asked to choose a base currency. Later on, you may create additional fiat, crypto, and non-traditional currencies which you will use to create your products and accounts. For more information, see [Currencies](/docs/currencies). Foreign currency loans are loans in a currency other than you base currency. Foreign currency loans is an early access feature. :::note You can make transactions between loan accounts and deposit accounts only if their respective GL accounts are set in the same currency. ::: --- # Loan Auto Approve workflow URL: https://docs.mambu.com/docs/loan-auto-approve-workflow/ ## Business case Approve a loan account of an individual client if the client has at least 5 years of service at at the current working place, the loan amount is greater than 1000 and the credit score captured at account level is greater than 2. :::warning In the conditions outline below, there is an `Account State` check which is not part of the business criteria but instead is necessary from a technical point of view. This check serves to prevent API calls from being made for every account activity performed after the account is approved, since the other conditions would then already have been met. This is referred to as a "notification breaker" criteria. ::: *** ## Configuration ![loans--loan-auto-approve-automation-rule-configuration.png](@site/static/img/support/loans--loan-auto-approve-automation-rule-configuration.png) *** --- # Loan Fees Setup URL: https://docs.mambu.com/docs/loan-fees-setup/ Fees can be applied to loan accounts after being created or activated under each product. ## Setting up a new fee To set up a new loan fee: 1. When creating a new loan product or editing an existing loan product, go to the **Product Fees** section of the form. 2. Select **Add Fee**. 3. Enter the name of the fee (this is the name that will be shown in different screens, when applying the fee to the account, when reporting, in the account statements, and so on). 4. Select the type of the fee (see more details about each fee type below). 5. Enter an Id for the fee. If you leave this field empty, an id will be automatically generated. 6. Define how the amount of the fee will be calculated, either as a fixed amount or as a percentage (the available calculation options will differ depending on the fee type). 7. Select if the fee is **Optional** or **Required** (only available for certain fees). 8. If accounting is enabled, and if applicable, select the specific General Ledger (GL) accounts. ![Product fees section of the setting up a new loan product form](@site/static/img/support/product-fees-loans.png) After fees are applied to an account, they will be paid according to the [allocation order](/docs/repayment-allocation-order) defined for that product. ## Deactivating and reactivating fees If a fee is not applicable anymore, you can deactivate it by selecting the small green square next to it and then saving your changes. When the fee is deactivated, the small green square will turn from green to grey. ![Product fees section with Activate/Deactivate dot.](@site/static/img/support/loans--product-fees-configuration-3.png) To reactivate a fee, follow the same procedure: select the grey square, then save your changes. When the fee is reactivated, the small grey square will turn from grey to green. ## Deleting fees Fees can be deleted only if they have never been applied to any account. This option is only available for specific cases when a fee was created by mistake and we strongly recommend you to use it with care. To delete a fee, select the red **Delete** button next to the fee name, then save your changes. If the fee has already been used and you try to delete it, Mambu will show you a warning message preventing you from doing so. In that case, you must **Deactivate** the fee. After you deactivate the fee, it will no longer be applied to any accounts created under that product. ## Nontaxable fees Nontaxable fees are available for *Dynamic Loans*. When adding a new fee, if you enable taxes on fees, then you can either choose to use the default tax rate source or not to apply taxes at all. When [creating a new loan product](/docs/setting-up-new-loan-products#taxes), if in the **Taxes** section of the form you select **Value Added Tax**, and in the **Fees** section you select **Apply taxes to** > **Fees**, then all the fees are subject to taxation by default. Besides the default behaviour, you have the option to mark a fee as being tax exempt by going to the **Fees** section and selecting **Nontaxable** under **Tax Source**, meaning that for the selected fee, the tax is neither going to be calculated, nor applied. :::note * Once the product is created, the tax source can no longer be edited. * You cannot reduce the fee balance of products with Nontaxable Fees. ::: ## Manual fees Manual fees can be applied to a loan account at any point in time. This type of fee applies when the event that triggers a fee application cannot be planned or predicted. For example: bounced cheques, lost cards, additional administration fees due to specific documents that had to be prepared, and so on. For Manual fees, the available calculation options are: * **Flat amount**: Can be set to a fixed amount if the fee amount is the same for all loans in this product or left empty, in which case you can enter the applicable fee amount on a case-by-case basis. * **% of Disbursement Amount**: Calculated as a percentage of the approved loan amount. ## Planned fees Planned fees are manual fees that can be set up in advance and added to the due date of future installments of all product types except for Revolving Credit. They represent an alternative to payment due fees, available for fixed loans only, but with added flexibility. When planned fees are being set up, they appear in the loan schedule as part of regulatory or business requirements, and are only applied on the due date of the installment. This allows for timely notification of payments to customers and transparent loan schedules from the moment you create the loan. Planned fees allow you to apply any sort of payment due fee you wish. They can be calculated externally at any time, and can be created to any installment you choose. You can adjust amounts whenever necessary, as long as they haven't been applied yet. You can add planned fees at any point during a loan account's lifecycle, before or after disbursement. Planned fees are automatically applied on their due dates, or they can be manually applied under the following circumstances: * When performing a backdated disbursement, in the installments with exceeded due date. * When entering a late repayment. * When adding a new fee or editing an existing fee, in installments with exceeded due date. :::warning You may only apply planned fees in future installments if the installments are not in the **Grace** or **Payment Holiday** state. ::: Planned fees are also available via API v2. For more information, see our [Loan Accounts - Planned Fees](/api/api-v2/loans/get-all-planned-fees/) in our API Reference. If you need to pay off a loan, make early repayments or overpayments and you want to have all the fees applied on the schedule before you do that, you can apply one or more planned fees using the POST call of the `/api/loans//plannedfees:apply` endpoint. :::note Planned fees are not applied automatically when making early repayments or paying off a loan but they are applied on the due date of the installment, unless that installment is paid. ::: Once the fee is applied, it is handled like a manual fee, in the following sequence: * a transaction is logged * accounting is logged * the fee balance can be reduced, in which case a write-off transaction will be logged ## Editing planned fees All planned fees can be edited at any time as long as they haven't been applied yet. To edit a planned fee: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Edit Planned Fees**. 3. In the **Edit Planned Fees** dialog, make changes to any of the defined planned fees, delete all the planned fees, or add a new fee. 4. Select **Save Changes**. ## Applying planned fees Planned fees, as the name suggests, are usually applied in future installments. You can also apply a planned fee on the account earlier than the due date of the installment if, for example, the client makes a repayment or a complete pay-off of the loan. To apply one or more fees: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Edit Planned Fees**. 3. In the **Edit Planned Fees** dialog, you will see a list with all the planned fees per installment. 4. Select which fees you wish to apply on the next installment or select **Apply on Date** to apply the fee on another date during the installment period. 5. Select **Save Changes**. ![The apply on date field for planned fees in the Edit planned fees dialog](@site/static/img/support/apply-on-date.png) :::note * The Apply on Date functionality does not support time stamps. The fees will be applied at 00:00:00. * The Apply on Date functionality cannot be set in the past, it needs to be set after the current organization date. ::: ## Deducted Disbursement fees As the name suggests, this type of fee will be deducted from the approved principal amount at disbursement, meaning the client receives less money as actual disbursement, but still has to repay the full loan amount by the end of the loan term. In other words, the fee will be effectively "paid" upfront. For deducted disbursement fees the available calculation options are: * **Flat amount**: Can be set to a fixed amount if the fee amount is the same for all loans created under this product or left empty, in which case you can enter the applicable fee amount on a case-by-case basis. For example, if the fee amount is calculated based on a very specific formula or logic that Mambu doesn't automatically replicate. * **% of Disbursed Amount**: Calculated as a percentage of the approved loan amount. Additionally, disbursement fees can be either **Required** or **Optional** — the required fees will be applied to all loan accounts disbursed under this product, while the optional fees can be selected to be applied or not at disbursement. :::note Any additional **% of Disbursed Amount** fees added on the account after disbursement will be calculated based on the sum of the loan amount and the deducted disbursement fee amount. ::: ### Example Loan amount = USD1,000 Deducted Disbursement Fee = USD100 Disbursed amount = USD900 Manual fee as 10% of disbursed amount = `(USD900 + USD100) * 10%` = USD100 ## Capitalized Disbursement fees As the name suggests, this type of fee will be added to the approved principal amount at disbursement, meaning the client receives the approved amount as actual disbursement, but has to repay a higher amount, including the loan fees, by the end of the loan term. Thus, the fees are effectively "paid" upfront but financed by the lender. Capitalized Disbursement Fees are identical to the Deducted Disbursement fees in all other respects: same fee amount calculation options, as well as the "required / optional" feature, are available. :::note Any additional **% of Disbursed Amount** fees added on the account after disbursement will be calculated based on the sum of the loan amount and the capitalized disbursement fee amount. ::: ### Example Loan amount = USD1,000 Capitalized Fee = USD100 Manual fee as 10% of disbursed amount = `(USD1,000 + USD100) *10%` = USD110 ## Upfront Disbursement As the name suggests, the upfront disbursement will be applied on the account as a “Fee” transaction, immediately after the account is disbursed and will be paid with one of the future payments. It can be selected when defining the disbursement details for a loan or when performing the disbursement. Fixed Term Loans and Payment Plans will have the upfront fees automatically allocated on the first due installment and then you can change these fees when editing the schedule. Dynamic Term and Tranched Loans will have the fee marked as due immediately. Upfront disbursement fees can’t be adjusted by themselves, but they will be automatically adjusted when the disbursement is undone. :::note A Tranched Loan product with required disbursement fees converts these required fees to optional on the next disbursement because they are meant to be applied only once during the loan's life cycle. ::: ## Late Repayment fees Late repayment fees will be applied any time the client misses an installment. That installment is set to **Late** in the schedule. For late repayment fees, the available calculation options are: * **Flat amount**: It can be set to a fixed amount if the fee amount is the same for all loans under this product; since this fee is applied to all payments in the schedule in advance, it can't be left empty and specified on a case-by-case basis. * **% of Disbursement Amount**: Is calculated as a percentage of the approved loan amount. * **% of Repayment Principal Amount**: Is calculated as a percentage of the principal amount that was expected with the installment that was missed. :::note When triggered, the late payment fee will take into account the arrears tolerance period defined for that product. For example, if there is a tolerance period of two days, the late payment fee will only be applied to the account two days after the due date of the installment. ::: ## Payment due fees The specificity of these fees is that they are calculated in advance and added to the loan's repayment schedule, along with the interest and principal due with each installment. For payment due fees the available calculation options are: * **Flat (€)**: It can be set to a fixed amount if the fee amount is the same for all loans under this product. Because this fee is applied to all payments in the schedule in advance, it can't be left empty and specified on a case-by-case basis. * **Flat (€) / Num of Installments**: When the loan is disbursed, the fee will be charged on each installment based on the formula: `the flat amount of the payment due fee divided by the number of installments`. * **% of Disbursement Amount**: Is calculated as a percentage of the approved loan amount. * **% of Disbursement Amount / Num of Installments**: When the loan is disbursed, the fee will be charged for each installment, calculated as a percentage of the approved loan amount divided by number of installments. In the **Fee Application** dropdown, choose to mark the fee as **Required** or as **Optional** at product level. The Payment Due fees marked as **Optional** can be linked to the account when: 1. Creating the loan account, by clicking on the "+" icon and selecting the **Payment Due** fee from the dropdown menu from the **Disbursement Details** section. 2. Disbursing the loan account by selecting the Payment Due fee from the dropdown menu displayed on the **Disbursement** dialog. The Payment Due fees (Required or Optional) will be displayed in **Disbursement Details** section at loan account creation and in the **Disbursement Dialog** at loan account disbursement. :::note Payment Due fees are not available for Tranched Loan products. ::: ### Fee included in Total Due The **Fee included in Total Due** calculation method is designed for products where a fee - typically calculated as a percentage of the principal balance - must be integrated into the equal installment (PMT) formula: `PMT = ( (Interest Rate + Fee Rate) / 12 , Number of Installments, -Loan Amount )` This capability addresses regulatory or business requirements in various markets where financial institutions must include certain fees, such as insurance, as part of the total loan installment amount. These fees are characteristically calculated based on a percentage of the remaining principal. To use this feature, you must create new Loan products with the following configuration: * **Product Type**: Dynamic Term Loan * **Interest Calculation**: Declining Balance (Equal installments) * **Interest Type**: Simple Interest * **Payment Method**: Optimized Payments * **Prepayment Allocation**: On Upcoming Pending Installments Only (RNI) * **Overdue Payment**: Increase Overdue Installments **Fee Included in Total Due** The Fee Included in Total Due fee type is found under the *Product Fees* section of the **Creating a New Loan Product** form. This fee is marked as Required and can be defined as a percentage (%). Currently, no amortization profile is available for this fee type. The accounting rules for the associated General Ledger (GL) accounts follow the standard Mambu fee accounting structure. This particular type of fee operates by mirroring both the interest accrual and penalty application mechanisms. It is accrued and applied on a daily basis. In instances of late payments, the fee's value within the schedule is updated daily with its application, and it is specifically allocated to the corresponding late installment, adhering to the logic used for penalties. When prepayments occur, the fee amount is recalculated based on the outstanding principal balance. Any accrued fee amounts are applied at the time of the repayment. For this fee type, the following actions are permissible: * Account closures (pay-off, write-off, reschedule/refinance) * Fee rate changes * Locking or unlocking accounts :::important If this fee type is configured at the product level, it will not be possible to configure Payment Holidays. ::: :::info If you wish to use the new **Fee included in Total Due** computation method, please get in touch with your Mambu Customer Success Manager or contact us through [Mambu Support](/docs/mambu-support) to discuss your requirements. ::: ## Arbitrary fees Arbitrary fees can be applied manually to the accounts at any point during the accounts' lifecycle and with any given amount. By default, this option is not checked when creating a new product, so if you need to apply arbitrary fees to the accounts under that product, you must select the **Allow Arbitrary Fees** checkbox. ![Product Fees section with Allow Arbitrary Fees unchecked.](@site/static/img/support/loans--product-fees-configuration.png) The difference between a manual and an arbitrary fee is that a manual fee is pre-defined, meaning it has a pre-set name and amount that the user can't change when applying the fee. An arbitrary fee is completely flexible—no predefined name and/or amount, it is up to you to input when applying such a fee onto the account. Arbitrary fees should be used with caution. We recommend setting manual fees for more granular reporting and control. ## Fee amortization Fee amortization is available for recognising up-front fees over the whole lifecycle of the loan. This option only becomes available if **Accrual Accounting** methodology is selected in the **Accounting Rules** section of the **Creating a New Loan Product** form. :::warning Please be aware For the Tranched Loan and Revolving Credit product types, there is no option to set up fee amortization profiles. ::: After you add a fee as per the above steps, under **Product Fees**, you can choose an Amortization Profile. ![Amortization profile options](@site/static/img/support/amortization-profiles.png) There are three calculation methods (“Amortization Profiles”) available: * [Sum-of-Year Digits](https://en.wikipedia.org/wiki/Depreciation#Sum-of-years-digits_method): A declining balance amortization that uses the number of installments and the sum of number of installments to calculate the amortization rate. This method is available only for *Deducted Fees*. * [Straight Line](http://www.accountingcoach.com/bonds-payable/explanation/6): A flat amortization method that equally divides the fee over the loan term. This method has a custom amortization frequency that can be defined for custom intervals or full term of the loan for manual fees ([Straight Line Manual Fees Amortization Method.xlsx](https://s3.amazonaws.com/mambu-notifications/Resources/Straight_line_manual_fees_amortization_method.xlsx)) and account installments due dates amortization frequency which is available for Manual, Deducted Disbursement and Capitalised Disbursement. * [Effective Interest Rate (EIR)](http://www.accountingcoach.com/bonds-payable/explanation/10): A declining balance amortization profile that uses the scheduled periodic payment and interest rate to calculate the amortization rate. This method is available for all types of predefined fees. * When selecting the EIR method you have the option to choose amortization frequency. To custom define the term select "Custom Interval" under "Amortization Frequency". You can define the frequency (in days, weeks, months, years) and over how many intervals the EIR is amortised. Mambu will apply the EIR calculation based on the Frequency and Period selected. * For Capitalised Disbursement, Deducted Disbursement and Payment Due fee types, there is an additional option for amortization frequency: "Account Installments Due Dates (Daily Booking)" and the calculation for this frequency is still based on the repayment frequency, however the accounting booking is performed daily. For Manual, Deducted Disbursement, Capitalised Disbursement, Upfront Disbursement fees with **Straight Line** or **Effective Interest Rate** amortization method and amortization frequency **Account Installments on Due Dates** or **Account Installments Due Dates (Daily Booking)**, it will be possible to choose if the amortization will end on the original account or if the amortization will continue on the rescheduled or refinanced account. ![Fee amortization upon reschedule](@site/static/img/support/fee-amortization-upon-reschedule.png) The **Fee Amortization upon Reschedule/Refinance** dropdown menu will have as default value **End Amortization on the Original Account** and it will be possible to reschedule or refinance the account with any product, regardless of the product setup. The default option can be changed with **Continue the Amortization on the Rescheduled/Refinanced account**. This option implies that the reschedule or refinance has to be done with the same product. For detailed examples of these methods and calculation formulas please see [Amortization_Profiles.xlsx](https://s3.amazonaws.com/mambu-notifications/Resources/Amortization_Profiles.xlsx) **How it works:** When the account is disbursed, Mambu will book the fee as Deferred Fee Income (liability) DR Portfolio Control CR Deferred Fee Income CR Deferred Taxes (if applicable) Then on each installment due date, a part of the amount (determined by the amortization profile) will recognise the deferred amount as actual fee income, generating an additional Journal Entry as follows: DR Deferred Fee Income / DR Deferred Taxes (if applicable) CR Fee Income / CR Taxes Payable (if applicable) If the loan is paid off (settled/ closed early), the remaining fees that are not yet amortised will be booked in accounting as income (same entry as above). :::note The Amortization Profile cannot be changed for the fees that are in use. ::: :::warning Adjusting the disbursement and the disbursement fees will also adjust the deferred income and amortization journal entries, posted in accounting. ::: :::warning If **Fee Amortization** is enabled, a Deferred Fee Income GL account has to be specified. This can be either a specific GL account for each fee or one generic account for all fees, if specified in the **Accounting Links** section. ::: ## Accounting If accounting is enabled for the loan product, the Fee Setup screen allows you to link each fee to specific GL accounts for accounting purposes, as well as to define fee amortization profiles for some fees. For more information, see [Fees Accounting](/docs/fees-accounting). --- # Loan Fractionalisation - P2P Lending URL: https://docs.mambu.com/docs/loan-fractionalisation-p2p-lending/ :::warning API v1 is no longer being actively developed. We strongly recommend that all customers use our API v2 endpoints for all new integrations and transition to API v2 endpoints for existing features wherever possible. For more information, see [Using API v1 and API v2](/docs/mambu-apis#using-api-v1-and-api-v2). ::: ### Description Starting with Mambu 3.13, a P2P lending functionality was added to allow loan accounts to be funded by investor deposit accounts. ## URL `/api/loans` `/api/loans/` ## Get accounts The funders information for a loan account can be found in the loan account JSON. Using [GET API](/api/api-v2/loans/get-by-id) for Loan Accounts the funders for a loan account can be seen. ### Usage example `GET /api/loans/ZNTS744` ### Sample Response **Sample response isolated with funds from loan account**`json ```json "funds":[ { "encodedKey":"8a818779565191ba015654a723aa5843", "guarantorKey":"8a818779565191ba0156548ce7b15811", "guarantorType":"GROUP", "savingsAccountKey":"8a818779565191ba0156548d6aaf581e", "amount":"4000", "type":"INVESTOR" }, { "encodedKey":"8a8186f4564c7aa2015654beb82813b4", "guarantorKey":"8a8187ce5525555f0155256c9ab40081", "guarantorType":"CLIENT", "savingsAccountKey":"8a81872a555e47e8015572bf0a5573a0", "amount":"1000", "type":"INVESTOR" } ] ``` *** ## Creating accounts New accounts can be created using the [Loan Accounts API](/api/api-v2/loans/create). `POST /api/loans` ```json { "loanAccount":{ "id":"11255", "accountHolderType":"CLIENT", "accountHolderKey":"40288a7d4f45f0fd014f45f18b8400ec", ...//Other account info "funds":[ { "guarantorKey":"GUARANTOR_KEY", "savingsAccountKey":"SAVINGS_ACC_KEY", "amount":"500" } ] } } ```
    **Parameter** **Value**
    guarantorKey The encoded key of the client that will invest in the loan
    savingsAccountKey The client savings account encoded key. It needs to be an active loan of type Funding Account
    amount The amount to be funded by the savings account. The account should have enough balance to cover this amount
    *** ## Updating loan funds Funding loans can be done through a POST to `/api/loans//funds` API. Any existing investment funds that are not specified in this update call will be deleted and activities will be logged for this change. `POST /api/loans/11255/funds` ```json { "funds":[ {// edit an existing investment fund "encodedKey":"40288a5d4f3fbac9014f3fd02745001d", "guarantorKey":"40288a5d4f273153014f2731afe40102", "savingsAccountKey":"40288a5d4f3fbac9014f3fcf822c0014", "amount":"50" }, {// add a new investment fund "guarantorKey":"40288a5d4f273153014f2731afe40103", "savingsAccountKey":"40288a5d4f3fbac9014f3fcf822c0015", "amount":"100" } ] } ``` :::warning Permissions required:
    `Create funds` -- Adding new funding source.
    `Edit funds`-- Editing an existing funding source.
    `Delete funds` -- Deleting funding source. ::: *** ## Retrieving the schedule Get the list of repayments or the list of loans which are founded by a particular account. ### Usage examples **Retrieve a list of repayments with the principal due/paid, state, last payment, and other details** `GET /api/savings//funding//repayments` **Get the list of loans which are funded by a particular account** `GET /api/savings//funding` :::warning The `View Fund Details` permission is required for this action. ::: *** --- # Loan Penalties Setup URL: https://docs.mambu.com/docs/loan-penalties-setup/ A *penalty* is a fee that your organization may charge clients when a specific term of the loan contract is violated. Penalties are applied after the arrears and penalty tolerance period has passed, but are calculated from the due date. ## Penalty calculation methods In Mambu the penalties are applied automatically when an installment is in arrears. The penalties are being computed based on the calculation methods explained below: | Penalty Calculation | Description | | --- |----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | No penalty | Won't charge penalties when a repayment is late | | Overdue Principal * Number of Late Days * Penalty Rate |

    The most common method, where the penalty rate is applied on the principal due late amount and the number of late days.


    If the Penalty rate is changed the accrued penalty amount is not recalculated.

    | | (Overdue Principal + Overdue Interest) * Number of Late Days * Penalty Rate |

    This method is similar to the previous one, but includes the overdue interest in the calculation.


    If the Penalty rate is changed the accrued penalty amount is not recalculated.

    | |(Overdue Principal + Overdue Interest + Overdue Fees) * Penalty Rate * Number of Days |

    This method is similar to the previous one, but includes the overdue fees in the calculation.


    If the Penalty rate is changed the accrued penalty amount is not recalculated.

    | | Outstanding Principal * Number of Late Days * Penalty Rate |

    This method mirrors adding a penalty interest rate on top of the usual interest rate.


    If the Penalty rate is changed the accrued penalty amount is recalculated.

    | :::note Arrears settings control how a loan's days in arrears should be calculated. These settings affect anything ßderived from a loan's days in arrears, such as penalties. For more information, see [Arrears Settings](/docs/arrears-settings). ::: ## Penalty tolerance period The *penalty tolerance period* is the number of days before which no penalties will be applied to an account even if there is a late repayment. Penalties start accruing once a payment is late (for example, if Days late = 1, it results in penalties accrued for one day), but they are applied if the payment is still not paid only after the number of days specified in the **Penalty tolerance period** defined in the **Penalties Settings** section of the **Creating a new loan product** form. After the penalty tolerance period is over, the accrued penalties are applied on the basis of overdue principal balance and the number of days late. :::warning The penalty tolerance period is set per installment and is valid for the payment due amount of the respective installment. ::: ### Examples Penalty Calculation Method: `Overdue Principal * Number of Late Days * Penalty Rate` | | Arrears tolerance period | Penalty tolerance period | Days late | Penalty is applied | | --- | --- | --- | --- | --- | | Example 1 | 32 days | 40 days | 34 days | No | | Example 2 | 32 days | 40 days | 41 days | Yes | | Example 3 | 40 days | 32 days | 34 days | No | | Example 4 | 40 days | 32 days | 41 days | Yes | #### Example 1 Arrears Tolerance Period: 32 days Penalty Tolerance Period: 40 days Account 34 days late (2 days in arrears) The penalty is not applied yet because the penalty tolerance period is still ongoing. #### Example 2 Arrears Tolerance Period: 32 days Penalty Tolerance Period: 40 days Account 41 days late (9 days in arrears) The penalty is applied and is calculated based on the number of days late (41). #### Example 3 Arrears Tolerance Period: 40 days Penalty Tolerance Period: 32 days Account 34 days late The installment is within the Arrears Tolerance Period so there are no penalties applied. #### Example 4 Arrears Tolerance Period: 40 days Penalty Tolerance Period: 32 days Account 41 days late (1 day in arrears) The penalty is applied and is calculated based on the number of days late (41). ## Penalty rate When [setting up a loan product](/docs/setting-up-new-loan-products), in the **Penalties Settings** section of the form, enter the rate you want to apply as penalty. You can either define a default, a minimum, a maximum rate or all of them. For the two methodologies where the penalties are calculated on the Overdue Principal, the penalty rate you define is a **daily** penalty rate. :::warning If you're using a monthly penalty rate, for instance, you can simply divide your current rate by 30 to obtain the daily penalty rate. ::: When the penalties are calculated on the outstanding principal, the penalty rate frequency always follows the interest rate frequency. For example, if the interest rate of a product is 30% per year, the penalty rate frequency for all the accounts created under this product can only be a yearly one. ### Accrued overdue penalties With this feature enabled, penalties are accrued daily and applied nightly, at cron jobs. The accrued overdue penalties will be displayed at account level but if the balance of the accrued overdue penalty is zero, then they will not be displayed. ### Accrued outstanding penalties Penalties are accrued daily and applied when you chose to apply them in the product settings. :::note Here are a few things you should consider when setting up and working with loan penalties: * If penalties are enabled for a loan product, the penalty rate can be defined individually per loan account. When viewing the loan account details, select **More** > **Edit Penalty Rate**. * For loan products where the “Interest Rate Type” is “None” and penalties are calculated on outstanding balance, the default penalty charge frequency is % per year. * Changing the penalties settings for an existing loan product with active accounts will affect only newly created accounts. For the existing ones penalties will keep being calculated with the methodology that was enabled when the accounts were created. ::: ## Reversal or adjustment When you reverse penalty accrued amounts in Mambu, they will be recalculated with the next cron job update. You can also backdate transactions for reversed penalties and they will be recomputed. In that case, if the recomputed amount is zero, penalty transactions are not reapplied. ## Edit schedule In Mambu you have an option to change the due date of repayments, meaning the number of days late can be increased or decreased. Holidays and Non-working days are excluded when computing the penalty accrued amount, if requested by product settings. Under **Edit Schedule**, you can update the penalty accrued amount when the number of days late is changed. :::note It will not be possible to edit an installment, if a penalty applied transaction has been made on or after its due date. ::: ## Lock account If the account is locked, the penalty amount will still be accrued, but it will not be applied. The penalty amount will be applied when the account is unlocked again. ## Change rate At change rate, the penalty accrued amount will be recalculated and updated with the new penalty rate. For more information on the impact of changing penalty rates on recalculating penalty charges, see the [Penalty calculation methods](/docs/loan-penalties-setup#penalty-calculation-methods) section above. ## Closure At closure the penalty accrued amount will be applied automatically. --- # loan-products-configuration URL: https://docs.mambu.com/docs/loan-products-configuration/ --- id: loan-products-configuration title: "Loan Products Configuration" --- A loan product allows you to set up, in advance, the parameters for a type of loan that you wish to offer. Loan products are flexible and highly customizable templates for creating individual loans. For more information, see [Setting Up New Loan Products](/docs/setting-up-new-loan-products). With *Configuration as Code* (CasC), you may batch configure your loan products configuration via Mambu API v2 using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API operations CasC for loan products supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/loanproducts.yaml` | Get current loan products configuration. | | `PUT` | `/configuration/loanproducts.yaml` | Write a new loan products configuration to Mambu. | :::note If you write a `PUT` configuration to Mambu, any loan products not included in the new YAML configuration will be deleted - if possible. If the loan products cannot be deleted, you will receive warnings. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. `` is the base64 encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ### Additional headers You may send synchronous or asynchronous `PUT` requests. :::warning If you have more than 60 loan products, we recommend you make your request asynchronous. ::: To use the endpoint asynchronously, you must provide two additional headers: * `X-Mambu-Async` with a value of `true`. * `X-Mambu-Callback` with the callback URL. The expected status code in case of a successful asynchronous request is `202 Accepted`. When the update configuration operation is completed, a message will be posted to the provided URL with information about whether the updated request completed successfully or not. ## GET configuration ### Get loan products for all product types ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/loanproducts.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` ### Get loan products for specific product types To retrieve loan products for specific product types, you may use the `type` query parameter. You may specify more than one product type. The following example returns all loan products for the revolving credit and dynamic term loan product types. ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/loanproducts.yaml?type=REVOLVING_CREDIT&type=DYNAMIC_TERM_LOAN' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/loanproducts.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @loanproducts.yaml ``` `@loanproducts.yaml` represents the absolute path of the file on your device. Use the `--data-raw` flag if you want to specify the YAML body inline. ### Configuration body example ```yaml --- id: "6354" name: "house_mortgage" notes: "loan product secured by a property that the loan applicant already owns" type: "DYNAMIC_TERM_LOAN" category: "COMMERCIAL" state: "INACTIVE" loanAmountSettings: loanAmount: minValue: 1 maxValue: 100 defaultValue: 10 trancheSettings: maxNumberOfTranches: 1 scheduleSettings: repaymentScheduleMethod: "FIXED" scheduleDueDatesMethod: "FIXED_DAYS_OF_MONTH" defaultRepaymentPeriodCount: 4 repaymentPeriodUnit: "MONTHS" fixedDaysOfMonth: - 2 - 4 shortMonthHandlingMethod: "LAST_DAY_IN_MONTH" roundingSettings: roundingRepaymentScheduleMethod: "NO_ROUNDING" repaymentCurrencyRounding: "ROUND_TO_NEAREST_WHOLE_UNIT" repaymentElementsRoundingMethod: "ROUND_ALL" numInstallments: defaultValue: 77 maxValue: 7 firstRepaymentDueDateOffset: defaultValue: 77 maxValue: 7 repaymentScheduleEditOptions: - "ADJUST_NUMBER_OF_INSTALLMENTS" - "ADJUST_FEE_PAYMENT_SCHEDULE" repaymentReschedulingMethod: "NEXT_WORKING_DAY" billingCycles: enabled: true startDays: - 9 - 5 - 7 previewSchedule: previewScheduleEnabled: true numberOfPreviewedInstalments: 3 paymentSettings: paymentMethod: "VERTICAL" amortizationMethod: "OPTIMIZED_PAYMENTS" prepaymentSettings: prepaymentRecalculationMethod: "RECALCULATE_SCHEDULE_KEEP_SAME_NUMBER_OF_TERMS" elementsRecalculationMethod: "PRINCIPAL_EXPECTED_FIXED" prepaymentAcceptance: "ACCEPT_PREPAYMENTS" futurePaymentsAcceptance: "ACCEPT_FUTURE_PAYMENTS" applyInterestOnPrepaymentMethod: "AUTOMATIC" principalPaidInstallmentStatus: "PARTIALLY_PAID" latePaymentsRecalculationMethod: "LAST_INSTALLMENT_INCREASE" repaymentAllocationOrder: - "FEE" - "PRINCIPAL" principalPaymentSettings: amount: minValue: 1 maxValue: 100 defaultValue: 10 percentage: minValue: 1 maxValue: 100 defaultValue: 10 principalPaymentMethod: "OUTSTANDING_PRINCIPAL_PERCENTAGE" totalDuePayment: "OUTSTANDING_PRINCIPAL_PERCENTAGE" defaultPrincipalRepaymentInterval: 6 principalCeilingValue: 5 principalFloorValue: 3 totalDueAmountFloor: 2 includeFeesInFloorAmount: true gracePeriodSettings: gracePeriod: defaultValue: 77 maxValue: 7 gracePeriodType: "NONE" newAccountSettings: idGeneratorType: "RANDOM_PATTERN" idPattern: "@@@###" accountInitialState: "PENDING_APPROVAL" interestSettings: interestApplicationMethod: "REPAYMENT_DUE_DATE" interestBalanceCalculationMethod: "PRINCIPAL_AND_INTEREST" interestCalculationMethod: "DECLINING_BALANCE" daysInYear: "ACTUAL_ACTUAL_ISDA" scheduleInterestDaysCountMethod: "REPAYMENT_PERIODICITY" interestType: "SIMPLE_INTEREST" indexRateSettings: indexSourceId: "index source id" interestRate: minValue: 1 maxValue: 100 defaultValue: 10 interestRateSource: "FIXED_INTEREST_RATE" interestRateTerms: "TIERED" interestChargeFrequency: "EVERY_DAY" interestRateReviewUnit: "MONTHS" interestRateReviewCount: 6 interestChargeFrequencyCount: 9 accrueInterestAfterMaturity: true interestRateCeilingValue: 34 interestRateFloorValue: 12 allowNegativeInterestRate: true interestRateTiers: - endingBalance: 17 interestRate: 45 - endingBalance: 17 interestRate: 45 accrueLateInterest: true compoundingFrequency: "DAILY" interestRateSettings: - interestRateSource: "INDEX_INTEREST_RATE" indexSourceId: "index rate source id" interestRate: minValue: 1 maxValue: 100 defaultValue: 10 interestRateCeilingValue: 45 interestRateFloorValue: 87 interestRateReviewCount: 7 interestRateReviewUnit: "DAYS" - interestRateSource: "INDEX_INTEREST_RATE" indexSourceId: "index rate source id" interestRate: minValue: 1 maxValue: 100 defaultValue: 10 interestRateCeilingValue: 45 interestRateFloorValue: 87 interestRateReviewCount: 7 interestRateReviewUnit: "DAYS" penaltySettings: penaltyRate: minValue: 1 maxValue: 100 defaultValue: 10 loanPenaltyCalculationMethod: "OUTSTANDING_PRINCIPAL" loanPenaltyGracePeriod: 4 arrearsSettings: toleranceCalculationMethod: "ARREARS_TOLERANCE_PERIOD" dateCalculationMethod: "ACCOUNT_FIRST_WENT_TO_ARREARS" nonWorkingDaysMethod: "EXCLUDED" toleranceFloorAmount: 45 tolerancePeriod: defaultValue: 77 maxValue: 7 tolerancePercentageOfOutstandingPrincipal: minValue: 1 maxValue: 100 defaultValue: 10 monthlyToleranceDay: 4 feesSettings: allowArbitraryFees: true fees: - name: "fee_name" id: "fee_id" amount: 10 amountCalculationMethod: "LOAN_AMOUNT_PERCENTAGE" trigger: "ARBITRARY" feeApplication: "OPTIONAL" state: "INACTIVE" applyDateMethod: "FIRST_OF_EVERY_MONTH" accountingRules: - glAccountId: "gl_account_code" financialResource: "FUND_SOURCE" transactionChannelId: "transaction_channel_id" - glAccountId: "gl_account_code" financialResource: "FUND_SOURCE" transactionChannelId: "transaction_channel_id" percentageAmount: 4.5 amortizationSettings: frequency: "CUSTOM_INTERVAL" periodUnit: "DAYS" periodCount: 5 intervalType: "PREDEFINED_INTERVALS" intervalCount: 7 amortizationProfile: "EFFECTIVE_INTEREST_RATE" feeAmortizationUponRescheduleRefinanceOption: "END_AMORTIZATION_ON_THE_ORIGINAL_ACCOUNT" taxSettings: taxableCalculationMethod: "CUSTOM_TAX" - name: "fee_name" id: "fee_id" amount: 10 amountCalculationMethod: "LOAN_AMOUNT_PERCENTAGE" trigger: "ARBITRARY" feeApplication: "OPTIONAL" state: "INACTIVE" applyDateMethod: "FIRST_OF_EVERY_MONTH" accountingRules: - glAccountId: "gl_account_code" financialResource: "FUND_SOURCE" transactionChannelId: "transaction_channel_id" - glAccountId: "gl_account_code" financialResource: "FUND_SOURCE" transactionChannelId: "transaction_channel_id" percentageAmount: 4.5 amortizationSettings: frequency: "CUSTOM_INTERVAL" periodUnit: "DAYS" periodCount: 5 intervalType: "PREDEFINED_INTERVALS" intervalCount: 7 amortizationProfile: "EFFECTIVE_INTEREST_RATE" feeAmortizationUponRescheduleRefinanceOption: "END_AMORTIZATION_ON_THE_ORIGINAL_ACCOUNT" taxSettings: taxableCalculationMethod: "CUSTOM_TAX" accountingSettings: accountingMethod: "ACCRUAL" interestAccruedAccountingMethod: "DAILY" interestAccrualCalculation: "NONE" accountingRules: - glAccountId: "gl_account_code" financialResource: "FUND_SOURCE" transactionChannelId: "transaction_channel_id" - glAccountId: "gl_account_code" financialResource: "FUND_SOURCE" transactionChannelId: "transaction_channel_id" accountLinkSettings: enabled: true linkableDepositProductId: "deposit id" linkedAccountOptions: - "AUTO_CREATE_LINKED_ACCOUNTS" - "AUTO_LINK_ACCOUNTS" settlementMethod: "FULL_DUE_AMOUNTS" taxSettings: taxesOnInterestEnabled: true taxesOnFeesEnabled: true taxesOnPenaltyEnabled: true taxSourceId: "here_should_be_an_id" taxCalculationMethod: "EXCLUSIVE" internalControls: dormancyPeriodDays: 4 lockSettings: lockPeriodDays: 4 cappingMethod: "OUTSTANDING_PRINCIPAL_PERCENTAGE" cappingConstraintType: "HARD_CAP" cappingPercentage: 9 fourEyesPrinciple: activeForLoanApproval: true securitySettings: isGuarantorsEnabled: true isCollateralEnabled: true creditArrangementSettings: creditArrangementRequirement: "NOT_REQUIRED" fundingSettings: enabled: true requiredFunds: 10 funderInterestCommissionAllocationType: "PERCENTAGE_OF_LOAN_FUNDING" organizationInterestCommission: minValue: 1 maxValue: 100 defaultValue: 10 funderInterestCommission: minValue: 1 maxValue: 100 defaultValue: 10 lockFundsAtApproval: true availabilitySettings: branchSettings: forAllBranches: true availableProductBranches: - "branchid1" - "branchid2" availableFor: - "SOLIDARITY_GROUPS" - "INDIVIDUALS" offsetSettings: allowOffset: true redrawSettings: allowRedraw: true allowCustomRepaymentAllocation: true currency: code: "AED" ``` ## Input requirements The input requirements are in addition to any existing validations or input requirements for loan products. The same loan product requirements apply whether a loan product is made via the Mambu UI, Mambu API v2, or through CasC. ### Basic fields | Name | Validations | Required | | --- | --- | --- | | `id` | Must not be empty, must not exceed a length of 16 characters, and must not be duplicate. | YES | | `name` | Must not be blank, and must be between 1 and 255 characters. | YES | ### Credit Arrangement Settings | Name | Validations | Required | | --- | --- | --- | | `creditArrangementSettings` | - | NO| | `creditArrangementRequirement` | If `creditArrangementSettings` are defined, must not be null. | YES | ### Offset Settings | Name | Validations | Required | | --- | --- | --- | | `offsetSettings` | - | NO| | `allowOffset` | If `offsetSettings` are defined, must not be null. | YES | ### Redraw Settings | Name | Validations | Required | | --- | --- | --- | | `redrawSettings` | - | NO| | `allowRedraw` | If `redrawSettings` are defined, must not be null. | YES | ### Currency | Name | Validations | Required | | --- | --- | --- | | `currency` | - | NO| | `code` | If `currency` is defined, must not be null and must contain existing currencies. | YES | ### Loan Amount Settings | Name | Validations | Required | | --- | --- | --- | | `loanAmountSettings` | - | NO| | `trancheSettings.`
    `maxNumberOfTranches` | If `loanAmountSettings` are defined, must not be null. | YES | ### Grace Period Settings | Name | Validations | Required | | --- | --- | --- | | `gracePeriodSettings` | - | NO| | `gracePeriodType` | If `gracePeriodSettings` are defined, must not be null. | YES | ### New Account Settings | Name | Validations | Required | | --- | --- | --- | | `newAccountSettings` | - | NO| | `idGeneratorType` | If `newAccountSettings` are defined, must not be null. | YES | | `idPattern` | If `newAccountSettings` are defined, must not be null. | YES | | `accountInitialState` | If `newAccountSettings` are defined, must not be null. | YES | ### Interest Settings | Name | Validations | Required | | --- | --- | --- | | `interestSettings` | - | YES| | `interestApplicationMethod` | Must not be null. | YES | | `interestBalanceCalculationMethod` | Must not be null. | YES | | `interestCalculationMethod` | Must not be null. | YES | | `daysInYear` | Must not be null. | YES | | `scheduleInterestDaysCountMethod` | Must not be null. | YES | | `interestType` | Must not be null. | YES | | `indexRateSettings` | - | NO | | `indexRateSettings.`
    `indexSourceId` | If `indexRateSettings` is defined, must contain existing ID. | YES | | `indexRateSettings.` `interestRate` | If `indexRateSettings` is defined, then it must respect the condition min<=def<=max | YES | |`indexRateSettings.`
    `interestRateTerms` | If `indexRateSettings` is defined, must not be null. | YES | |`indexRateSettings.`
    `interestRateSource` | If `indexRateSettings` is defined, must not be null. | YES | | `interestRateSettings` | If `indexRateSettings` is not null then `interestRateSettings` must be empty. | YES | | `indexSourceId` | Must not be duplicate, must contain existing ID. | YES | ### Fees Settings | Name | Validations | Required | | --- | --- | --- | | `feesSettings` | - |NO| | `fees` | - |NO| | `fees.id` | If `fees` is defined, must not be blank. |YES| | `fees.trigger` | If `fees` is defined, must not be null. |YES| | `fees.feeApplication` | If `fees` is defined, must not be null. |YES| | `fees.state` | If `fees` is defined, must not be null. |YES| | `accountingRules.`
    `glAccountId` | If `feesSettings` is defined, must not be null, must contain existing ID. |YES| | `accountingRules.`
    `financialResource` | If `feesSettings` is defined, must not be null. |YES| | `accountingRules.`
    `transactionChannelId` | If `feesSettings` is defined, must contain existing ID. |YES| ### Payment Settings | Name | Validations | Required | | --- | --- | --- | | `paymentSettings` | - |NO| | `paymentMethod` | If `paymentSettings` is defined, must not be null. |YES| | `amortizationMethod` | If `paymentSettings` is defined, must not be null. |YES| | `prepaymentSettings` | - |NO| | `prepaymentSettings.`
    `prepaymentAcceptance` | If `prepaymentSettings` is defined, must not be null. |YES| | `prepaymentSettings.`
    `futurePaymentsAcceptance` | If `prepaymentSettings` is defined, must not be null. |YES| | `latePaymentsRecalculationMethod` | If `paymentSettings` is defined, must not be null. |YES| | `repaymentAllocationOrder` | If `paymentSettings` is defined, must not be null. |YES| | `principalPaymentSettings` | - |NO| | `principalPaymentSettings.`
    `amount` | If `principalPaymentSettings` is defined and it is not null, then it must respect the condition min<=def<=max |NO| | `principalPaymentSettings.`
    `percentage` | If `principalPaymentSettings` is defined and it is not null, then it must respect the condition min<=def<=max |NO| | `principalPaymentSettings.`
    `principalPaymentMethod` | If `principalPaymentSettings` is defined and if product type is revolving credit, you must define either `principalPaymentMethod` or `totalDuePayment` and the other must be null. |YES| | `principalPaymentSettings.`
    `totalDuePayment` | If `principalPaymentSettings` is defined and if product type is revolving credit, you must define either `principalPaymentMethod` or `totalDuePayment` and the other must be null. |YES| | `principalPaymentSettings.`
    `principalFloorValue` | If `principalPaymentSettings` is defined, must be null if `totalDueAmountFloor` is not null. |YES| | `principalPaymentSettings.`
    `totalDueAmountFloor` | If `principalPaymentSettings` is defined, must be null if `principalFloorValue` is not null. |YES| ### Internal Controls | Name | Validations | Required | | --- | --- | --- | | `internalControls` | - |NO| | `internalControls.dormancyPeriodDays` | Value must be between 0 and 2000000000. |NO| | `internalControls.lockSettings` | - |NO| | `lockSettings.lockPeriodDays` | Value must be between 1 and 2000000000. |NO| | `lockSettings.cappingPercentage` | Value must be between 0 and 1999999973982208 |NO| ### Tax Settings | Name | Validations | Required | | --- | --- | --- | | `taxSettings` | - |NO| | `taxSourceId` | If defined, must contain existing ID. |NO| ### Account Link Settings | Name | Validations | Required | | --- | --- | --- | | `accountLinkSettings` | - |NO| |`accountLinkSettings.`
    `linkableDepositProductId` | If defined, must contain existing ID. |NO| | `accountLinkSettings.`
    `settlementMethod` | If `accountLinkSettings` is defined, must not be null.|YES| ### Accounting Settings | Name | Validations | Required | | --- | --- | --- | | `accountingSettings` | - |NO| | `accountingSettings.accountingMethod` | If `accountingSettings` is defined, must not be null. |YES| | `accountingSettings.interestAccrualCalculation` | If `accountingSettings` is defined, must not be null. |YES| | `accountingRules.`
    `glAccountId` | If `accountingSettings` is defined, must not be null and must contain existing ID. |YES| | `accountingRules.`
    `financialResource` | If `accountingSettings` is defined, must not be null. |YES| | `accountingRules.`
    `transactionChannelId` | If `accountingSettings` is defined, must not be null. Can only specify one rule per `financialResource`. |YES| ### Penalty Settings | Name | Validations | Required | | --- | --- | --- | | `penaltySettings` | - |NO| | `penaltySettings.`
    `loanPenaltyCalculationMethod` | If `penaltySettings` are defined, must not be null. |YES| ### Availability Settings | Name | Validations | Required | | --- | --- | --- | | `availabilitySettings` | - |NO| |`availabilitySettings.`
    `branchSettings` | - |NO| | `branchSettings.`
    `availableProductBranches` | If defined, must contain existing ID. |NO| | `branchSettings.`
    `allBranches` | If `branchSettings` is defined, must not be null. |YES| | `branchSettings.`
    `branches` | If `branchSettings` is defined, must not be null. |YES| | `availabilitySettings.`
    `availableFor` | If defined, must not be null.|NO| ### Schedule Settings | Name | Validations | Required | | --- | --- | --- | | `scheduleSettings` | Not mandatory, except for the revolving credit loan product type. |NO| | `roundingSettings` | - |NO| |`roundingSettings.`
    `repaymentElementsRoundingMethod` | If `roundingSettings` is defined, must not be null. |YES| |`billingCycles` | - |NO| |`billingCycles.`
    `enabled` | If `billingCycles` is defined, must not be null. |YES| |`previewSchedule` | - |NO| |`previewSchedule.`
    `enabled` | If `previewSchedule` is defined, must not be null. |YES| ## Replies --- # Loan Risk Levels Configuration URL: https://docs.mambu.com/docs/loan-risk-levels-configuration/ *Risk Levels* are user-defined categories composed of an interval for number of days in arrears and a correspondent provision amount. Risk levels will be used to calculate the organization’s portfolio at risk (PAR), based on the number of loans in arrears that fall into each level. For more information, see [Defining Risk Levels](/docs/defining-risk-levels). With *Configuration as Code* (CasC), you may batch configure your loan risk levels configuration via the API using YAML. For general information on CasC, see [Configuration as Code Overview](/docs/configuration-as-code-1/). ## API Operations CasC for loan risk levels supports two operations. | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/configuration/loanrisklevels.yaml` | Get current loan risk levels configuration. | | `PUT` | `/configuration/loanrisklevels.yaml` | Write a new loan risk levels configuration to Mambu. | :::note If you `PUT` a configuration to Mambu, any current configuration settings not included in the new YAML configuration will be deleted. `PATCH` requests are not currently supported. ::: ## Requests For general information on CasC requests such as authentication and required headers, see [Configuration as Code Overview](/docs/configuration-as-code-1/). The following section shows sample requests using curl and basic authentication. For all examples, replace `TENANT_NAME` with your actual tenant name. ## GET configuration ```bash curl -X GET 'https://TENANT_NAME.mambu.com/api/configuration/loanrisklevels.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Authorization: Basic ' ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. ## PUT configuration ```bash curl -X PUT 'https://TENANT_NAME.mambu.com/api/configuration/loanrisklevels.yaml' \ -H 'Accept: application/vnd.mambu.v2+yaml' \ -H 'Content-Type: application/yaml' \ -H 'Authorization: Basic ' \ --data-binary @loanrisklevels.yaml ``` `` is the base-64-encoded value of `username:password`. For more information, see [Authentication](/api/pages/api-v2/authentication) in our API reference. `@loanrisklevels.yaml` represents the absolute path of the file on your device. Use “--data-raw” if you want to specify the YAML body inline. ### Configuration body example ```yaml --- loanRiskLevels: - id: "1" name: "Mild Risk" arrearsFrom: 10 arrearsTo: 30 provisioningPercent: 4.5 - id: "1153177013" name: "Healthy loans" arrearsFrom: 0 arrearsTo: 0 provisioningPercent: 3 - id: "2" name: "Moderate Risk" arrearsFrom: 30 arrearsTo: 40 provisioningPercent: 7 ``` ### Attributes | Name | Type | Description | Required | | --- | --- | --- | --- | | `id` | String | User-defined ID, globally unique. | ✔ | | `name` | String | Name of the loan risk level. | ✔ | | `arrearsFrom` | Integer(int32) | Lower level of the band of number of days the account is at risk. | ✔ | | `arrearsTo` | Integer(int32) | Upper level of the band of number of days the account is at risk. | ✔ | | `provisioningPercent` | Number | How much to provision at this level (as a percent). | ✔ | ## Replies ## Input Requirements | Name | Validations | | --- | --- | | `id` | Must not be blank, must not exceed 32 characters in length, must contain only letters and numbers, and must be unique in the configuration. | | `name` | Must not be blank and must not exceed 256 characters in length. | | `arrearsFrom` `arrearsTo` | Must be a whole number (positive or 0), cannot be null or empty, cannot be larger than 2,000,000,000. | | `provisioningPercent` | Can be any number, but cannot be null or empty. | --- # Loan Securities - Guarantors and Collateral Assets URL: https://docs.mambu.com/docs/loan-securities-guarantors-and-collateral-assets/ Loan securities are used by organizations to secure or guarantee a part of the loan amount. If those loans are not repaid, the organization will be able to collect part of the dues from the pledged securities. There are two types of securities: * **Guarantors**: Another person is guaranteeing the loan for a specific client with their own money, the person guaranteeing a loan is called a guarantor. If the loan is not repaid, the amount guaranteed can be used to cover the amount not paid by the client. If the guarantor also has an account in Mambu, the guaranteed amount will be locked, preventing the account balance to go below the guaranteed amount. A client can be their own guarantor if they are securing the loan with their own savings. * **Collateral Assets**: When the borrower uses physical assets, such as a car or a real estate to secure the loan. If the loan is not fully paid then those assets can be confiscated to cover the loan amount which hasn’t been paid. ## Adding guarantors to loans If the **Guarantors** option is [enabled for the loan product](/docs/securities-settings), the option to add guarantors will be available for new and existing loans. Guarantors can be added when creating a loan or at any time after creation. ![Editing Securities adding Guarantor with mandatory fields Source and Amount.](@site/static/img/support/loans--edit-securities-form.png) To add a guarantor to a loan: 1. When creating the loan, go to the **Guarantors** section of the form and select **Add Guarantor**. 2. Fill out the following fields about the guarantor: * **Source**: Enter the name of the guarantor; the guarantor can also be the clients themselves. The individual client or group should be first registered in the system. * **Account**: Only if applicable, can be left empty. * **Amount**: The amount that is guaranteed. * Enter any custom field values, if applicable. 3. Save the loan when you finish defining all the other terms. If you want to add guarantors to an existing loan, in the account overview, select **More** > **Edit Securities** > **Add Guarantor**. ![More drop-down menu with Edit Securities option](@site/static/img/support/loans--loan-account-details.png) The amount guaranteed from an existing deposit account becomes a _locked balance_ on that account, meaning that the account owner cannot withdraw from the deposit account below the amount used as a guarantee for the loan. If the account doesn't have the balance for the amount guaranteed, an error message will be displayed. ![Insufficient Guarantees](@site/static/img/support/loans--insufficient-guarantees-warning.png) :::note Guarantors can only be associated with individual and pure group loans, not with solidarity group loans. When a client is guaranteeing any loans, the guaranteed amounts and accounts can be seen under the **Guarantees** tab in the client's overview page. For more information, see [Loans for Groups](/docs/types-of-loan-groups). ::: ## Adding collateral assets to loans If the **Collateral** option is [enabled for the loan product](/docs/securities-settings), the option to add assets and their value to new and existing loans as physical collateral assets will be available. Collateral assets can be added when creating a loan or at any time after creation. ![Editing Securities - Collateral asset with Description and Amount as mandatory fields](@site/static/img/support/collateral-assets.png) To add collateral assets to a loan: 1. When creating the loan, go to the **Collateral Asset** section of the form and select **Add Asset**. 2. Fill out the following fields about the asset: * **Description**: Enter a general description or a relevant name for the asset. * **Amount**: Enter the amount that the asset guarantees. * **Original Currency**: Enter the original currency you wish to use for the assets. The list consists of the currencies you've set up for your tenant. For more information, see [Currencies](/docs/currencies). * **Original Amount**: Enter the original value that the asset guarantees. This field can accept up to 20 decimals. * Complete any custom fields, if applicable. 3. Save the loan when you finish defining all the other terms. :::note The **Original Currency** and the **Original Amount** fields are only available upon request. If you would like to request access to them, please contact your Mambu Customer Success Manager to discuss your requirements. For more information, see [Mambu Release Cycle - Feature Release Status](/docs/mambu-release-cycle). ::: To add a collateral to an existing loan, in the account overview, select **More** > **Edit Securities** > **Add Asset**. During the lifecycle of a loan, you can execute a background task to re-evaluate the value of the collateral assets that are in a currency other than the loan currency with the latest exchange rates. For more information, see the [Re-evaluate Collateral Assets](/api/api-v2/loans/reevaluate-collateral-assets) endpoint in our API Reference. ## Removing loan securities When guarantors or assets are no longer required for an active loan, they can be removed under **More** > **Edit Securities** by selecting the **Delete** button next to the guarantor or the asset. --- # Loans in Arrears URL: https://docs.mambu.com/docs/loans-in-arrears/ ## Business case Extract all the loans in arrears along with the late installments. Calculate the total late principal, late interest, late fee, late penalties, and total late amount. ## Technical concepts Usage of grouping and totals over multiple entries. ## Sources * [jrxml template report](https://s3.amazonaws.com/mambu-notifications/Resources/LoansInArrears.jrxml) * [resulted report](https://s3.amazonaws.com/mambu-notifications/Resources/LoansInArrears.pdf) ## Preview ![Loans in arrears report](https://s3.amazonaws.com/mambu-notifications/Resources/LoansInArrears.png) :::warning Due to recent changes to the Jasper reports library used in Mambu, you may receive the following error when running this report if there are no accounts in arrears at the time of running: `The following error occurred: Invalid pattern specification.Please fix the error before re-submitting or contact Mambu support ` This is a known error and does not need to be submitted to Mambu. ::: *** --- # Loans overview URL: https://docs.mambu.com/docs/loans-overview/ Mambu lending is configured at two levels: - **[Loan products](/docs/setting-up-new-loan-products)** define the template a loan account is created from — which payment methods are allowed, which features can be enabled, how interest is calculated. - **[Loan accounts](/docs/creating-a-new-loan)** are instances created against a product. Account-level capabilities are gated by the product they belong to: if a feature isn't enabled on the product, it isn't available on the account. Most "I can't find option X on this account" questions are about a product-level setting. The matrix below shows which product-level decisions unlock which downstream capabilities. ## Loan types at a glance The basic five loan product types you can choose between on the [product setup form](/docs/setting-up-new-loan-products#loan-product-types) are defined here: [Loan product types](/docs/setting-up-new-loan-products#loan-product-types). In addition, two specific capital-repayment configurations are documented as their own product variants: - **[Dynamic Mortgages](/docs/dynamic-mortgages)** — equal-installment capital repayment loans sharing characteristics with Dynamic Term loans, with their own interest options and feature set. - **[Interest-Only Equal Installment Loans](/docs/equal-installment-interest-only-loans)** — equal-installment loans where each installment is interest-only. ## Capabilities and prerequisites Each row names a capability and the configuration prerequisites that have to be in place before it works. Blank cells mean the linked page does not state a constraint on that dimension. Where you need detail beyond what's tabulated, the linked page is the canonical reference. | Capability | Required product type | Required interest / schedule | Other product-level prerequisites | | -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | [Redraw and Offset](/docs/redraw-facility-and-offset-loans) | [Dynamic Term](/docs/setting-up-new-loan-products#loan-product-types) | [Declining Balance (Equal Installments)](/docs/interest-calculation-methods-in-loans#declining-balance-equal-installments) + [Simple Interest](/docs/interest-types#simple-interest) calculated using Principal and Interest | — | | [Fee Capitalization](/docs/fee-capitalization) | [Dynamic Mortgages](/docs/dynamic-mortgages) or [Interest-Only Equal Installment](/docs/equal-installment-interest-only-loans) | — | [Fee configured at product level](/docs/loan-fees-setup) (capitalization decision made when applied) | | [Principal Overpayment](/docs/principal-overpayment) (non-scheduled) | [Dynamic Mortgages](/docs/dynamic-mortgages) ([Interest-Only](/docs/equal-installment-interest-only-loans) via [Custom Repayment](/docs/processing-loan-repayments#enter-a-custom-repayment)) | — | Account must have no late installments at time of overpayment | | [Payment Holidays](/docs/payment-holidays) | [Dynamic Mortgages](/docs/dynamic-mortgages) or [Interest-Only Equal Installment](/docs/equal-installment-interest-only-loans) | — | Configured in[Repayments Schedule Editing](/docs/repayments-schedule-editing) on the product | | [Initial Payment Adjustment](/docs/initial-payment-adjustment) | [Dynamic Mortgages](/docs/dynamic-mortgages) (checkbox-driven) or [Interest-Only Equal Installment](/docs/equal-installment-interest-only-loans) (default-on) | — | — | | [Carry-Forward at reschedule / refinance](/docs/carry-forward-balances-at-reschedule-or-refinance) | [Dynamic Mortgages](/docs/dynamic-mortgages) or [Interest-Only Equal Installment](/docs/equal-installment-interest-only-loans) | — | [Custom Repayment Allocation](/docs/repayment-allocation-order) enabled | | [Securities (Guarantors / Collateral)](/docs/securities-settings) | Any | — | [Enabled at loan product level](/docs/securities-settings) | | [Funding Sources (P2P)](/docs/funding-sources-p2p-lending) | [Fixed Term](/docs/setting-up-new-loan-products#loan-product-types) or [Dynamic Term](/docs/setting-up-new-loan-products#loan-product-types) (excludes Fixed Term with [Payment Plan](/docs/payment-methods-for-dbei-loans#payment-plan)) | — | Deposit product with Funding Sources enabled + Funding Sources enabled on the loan product | ### Other capabilities documented in this section These have their own prerequisites described on their own pages; see the linked page for detail. - [Adjustable Interest Rates](/docs/adjustable-interest-rates) — compatible with [Dynamic Mortgages](/docs/dynamic-mortgages) (negative spread is not supported on dynamic mortgages). - [Compound Interest with Daily Rest](/docs/compound-interest-with-daily-rest) - [Interest from Arrears and decoupling](/docs/interest-on-arrears-and-interest-on-arrears-decoupling) - [Secondary Marketplace for P2P Loans](/docs/secondary-marketplace-for-p2p-loans) - [Choose Prepayment Recalculation Method at Repayment Time](/docs/choose-prepayment-recalculation-method-at-repayment-time) - [Non-Scheduled Fee Allocation](/docs/non-scheduled-fee-allocation) - [Payment Modification Thresholds](/docs/payment-modification-thresholds) — shared mechanism behind Fee Capitalization, Principal Overpayment, and interest-rate changes. ## Navigating this section The Loans sidebar follows the order you'd configure a product in: 1. **Get started with loan products** — [creating](/docs/setting-up-new-loan-products), [managing](/docs/managing-loan-products), and [grouping](/docs/types-of-loan-groups) loan products. 2. **Choose a loan type** — the parallel [product-type decisions](/docs/setting-up-new-loan-products#loan-product-types): fixed/dynamic term, [revolving credit](/docs/revolving-credit-loans), [mortgage variants](/docs/dynamic-mortgages), [P2P](/docs/loans-with-funding-sources-p2p-lending). 3. **Configure interest and schedule** — how money moves: [interest type](/docs/interest-types), [calculation method](/docs/interest-calculation-methods-in-loans), [schedule editing](/docs/repayments-schedule-editing), [repayment collection](/docs/repayment-collection). 4. **Configure fees, penalties, and arrears** — [fee](/docs/loan-fees-setup), [penalty](/docs/loan-penalties-setup), and [arrears](/docs/arrears-settings) setup at product level. 5. **Configure securities and controls** — [guarantors and collateral](/docs/securities-settings), [internal controls](/docs/internal-controls-for-loans), [savings/loan linking](/docs/linking-savings-and-loan-accounts). 6. **Mortgage and interest-only capabilities** — features available only on [Dynamic Mortgage](/docs/dynamic-mortgages) or [Interest-Only Equal Installment](/docs/equal-installment-interest-only-loans) products. 7. **Redraw and offset** — [settings](/docs/redraw-facility-and-offset-loans) and [account behavior](/docs/redraw-for-loans) for redraw/offset capability. 8. **Working with loan accounts** — day-to-day operations on a created account: [creating](/docs/creating-a-new-loan), [approving](/docs/approving-a-loan), [disbursing](/docs/disbursing-a-loan), [processing repayments](/docs/processing-loan-repayments). 9. **Closing and exiting a loan account** — [paying off](/docs/paying-off-a-loan), [writing off](/docs/writing-off-a-loan), [terminating](/docs/terminating-a-loan), [withdrawing](/docs/withdrawing-a-loan), or [deleting](/docs/deleting-a-loan) an account. --- # Loans with Funding Sources - P2P Lending URL: https://docs.mambu.com/docs/loans-with-funding-sources-p2p-lending/ Peer to peer lending differs from traditional lending on how the loans are funded. While in traditional lending it's the financial institution that funds the loans, with peer to peer lending the funds come from investors. Investors and borrowers (either individuals or SMEs) are connected via online platforms that serve as intermediaries usually for a disbursement fee and a spread on the interest rate. Mambu manages the loan fractionalisation by doing transfers from deposit accounts (investors' accounts) to the loan accounts at disbursement and refunding the deposit accounts as the repayments are made. For more information, go to [Funding Sources - P2P Lending](/docs/funding-sources-p2p-lending). ## Setting up Organisation and Funder Commissions In order for a loan to allow funding on a loan product, when creating or editing the product, go to **Funding Source** section and simply enable Funding on the product. You will see several fields available which will allow you to set up your organisation commission as well as the funder commission. ### Organisation Interest Commission In this section you can set up your organisation commission default, minimum, and maximum values for the organisation interest. This is the interest that will be gained by the organisation with each repayment on the loan. The values set on the product will be validated when creating a new funded loan account. ### Funder Interest Commission When setting up the funder interest commission, you can choose between two different allocation methods. 1. **Percentage of loan funding**: the interest commission is allocated based on the percentage of the investment made (for example, if the funder invested only in 40% of the loan). 2. **Fixed Interest Commissions**: the interest commission paid back to customers is applied based on the values inputed here. If they are left empty, the interest commission can be defined upon account creation and further customised for each funder. ### Locking funds on funding accounts When enabling Funding Sources on a loan, you can also choose to **Lock Funds on Funding Account at Approval**, a very useful setting as it prevents funders to over-commit to multiple loans. When funds are locked, Mambu will not allow withdrawal on that amount, from the funding deposit account, and funds will be displayed as locked on the account. --- # Locking and Unlocking Deposit Accounts URL: https://docs.mambu.com/docs/locking-and-unlocking-deposit-accounts/ Mambu allows you to lock and unlock deposit accounts to better manage situations where you need to stop applying interest or fees to them. ## Lock Accounts Any deposit account in the `Active` or `Active in Arrears` state can be locked. Locked accounts will not allow any transactions and won't charge or collect interest for the time they remain locked. To lock an account: 1. Open the deposit account. 2. On the right-hand side of the screen, select **More** > **Lock Deposit Account**. 3. Select **Change State**. The deposit account state is then set to `Locked` and Mambu saves the date when the account was locked. :::warning If a deposit account is locked, card payment transactions made from that account will not go through. ::: For more information, see [Deposit Account Life Cycle and States](/docs/deposit-accounts-life-cycle-and-states). ## Unlock Accounts When you unlock a deposit account, all the suspended activities will be unlocked and automated transactions will resume. To unlock an account: 1. Open the deposit account. 2. On the right-hand side of the screen, select **Unlock Deposit Account**. 3. Select **Change State**. Once an account is unlocked, all the locked activities are unlocked and as a result: * The account goes back to the state it was before being locked, either `Active` or `Active in Arrears`. * If the insterest type of the account is **Tiered per period**, Mambu checks if the interest needs to change and, if so, logs a **Change Interest** transaction. * All the interest and withholding taxes will start being accrued again and applied according to the product configuration after you unlock the account. * From the accounting point of view, if while the deposit account was locked, there was an accounting closure on the account's branch, then when you reopen the deposit account: * if, for the period between the last account appraisal and the closure date, you need to enter a transaction, then you'll apply it with the current date as its entry date, because you can't have a transaction on accounting closure. * for the period after the accounting closure until you unlock the account, the transaction entry date will be the same as the entry date as the date when the transaction should have been applied had the deposit account not been locked at all. ### Example The following is an example of applying interest after unlocking a deposit account: * You open a deposit account on January 1st. * You enter a deposit on January 5th, then lock the account on January 20th and unlock it on April 10th. * You set the interest to apply on the 1st of each month. * Accounting closure on account's branch happens on February 15th. As less than one month has passed by the time the deposit account was locked, no interest transaction was applied. * When you unlock the account, first you must apply the interest that should have been applied on February 1st. Since accounting is closed, the booking date will be the current day, April 10th. * Then you apply the interest that should have been applied on March 1st. Since accounting is open, the booking date will be March 1st. * The same thing will happen when you apply the interest on April 1st. In the example of applying interest after unlocking a deposit account, you can observe that you have three interest applied transactions, like you would have had if the account hadn't been locked, only that the first transaction has the booking date on April 10th and not on February 1st. --- # Locking and Unlocking Loans URL: https://docs.mambu.com/docs/locking-loans/ Mambu allows you to lock and unlock loan accounts to better manage situations where you need to stop applying interest, fees, or penalties to them. Locked accounts do not accept transactions posted to them unless a user has permission to **Post Transactions on Locked Accounts** (`POST_TRANSACTIONS_ON_LOCKED_LOAN_ACCOUNTS`). ## Locking loan accounts To lock a loan account: 1. Open the loan account you want to lock. 2. On the right-hand side of the screen, select **More** > **Lock Account**. 3. In the **Lock Account** dialog, select whether to suspend interest, fees, and/or penalties. You may optionally enter any comments in **Notes**. For more detail on the activties you may susped, see below. 4. Select **Lock Account**. There are three activities you may choose to suspend on a locked account: * **Applying Interest**: Interest will still be accrued, but it will not be applied, meaning no **Interest Applied** transactions will be logged during the time the account is locked. * **Applying Fees**: Fees will not be applied at all, meaning no **Fee Applied** transactions will be logged during the time the account is locked. This applies only to late repayment fees. * **Applying Penalties**: Penalties calculated on the outstanding principal balance and penalties calculated on the overdue balance will be accrued, but not applied, meaning no **Penalty Applied** transactions will be logged during the time the account is locked. ![Lock loan option with the available activities to suspend](@site/static/img/support/lock-loan-with-activities-to-suspend.png) You may change the settings of which activities are suspended for a locked account at any time. For example, fees can additionally be locked on the account where interest has already been previously locked. These updates can be made with the **Lock Account** function. Details of the activity currently locked will be displayed in the account’s overview. :::note There is no accounting layer supporting the locking functionality. If a particular activity on a loan account is locked, it is simply not recognized in the ledger at all. ::: All activities and dates associated with locking and unlocking will be tracked in the account's transactions, allowing you to use custom view reports in order to audit these accounts and manage any further workflows required like follow-ups or specific collections activities. :::warning * Automated transfers will not be made if the account is locked. * Mambu will not automatically move loan accounts which have been `Locked` into `In arrears` once the arrears tolerance period has passed. ::: ## Unlocking loan accounts When you unlock a loan account, all the suspended activities will be unlocked and automated transactions will resume. To unlock a loan account: 1. Open the loan account you want to unlock. 2. On the right-hand side of the screen, select **More** > **Unlock Account**. 3. Select **Unlock Account**. Once an account is unlocked, all the locked activities are unlocked and as a result: * The account goes back to the state it was before being locked, either `Active` or in `In Arrears`. * The total amount of interest accrued during the time when the account was locked will be automatically applied and the corresponding **Interest Applied** transaction will be logged in the **Transactions** tab. * Fees will start to be applied again from the date the account is unlocked. * Penalties calculated using the overdue balance methodology based on `Overdue Principal` or `Overdue Principal + Overdue Interest` will start to be accrued and applied again from the date the account is unlocked. * Penalties calculated using the outstanding balance methodology that were accrued when the account was locked will remain accrued and be applied to the account on the installment due date. * The respective unlocked transactions will be logged on the account under the **Transactions** tab. :::note Each of the activities that were locked can be unlocked separately by using the **Lock Account** function. Once one of the activities is unselected, it will be considered unlocked and the appropriate transaction will be logged in the **Transactions** tab. We don't recommend that you use this option to change the state of the account as such: even if all the activities in the locking screen are unselected, the state of the account will remain `Locked` until you unlock the account. ::: --- # Mambu APIs URL: https://docs.mambu.com/docs/mambu-apis/ Mambu offers a full suite of RESTful APIs to provide programmatic access to nearly every aspect of our banking software, typically with JSON or YAML requests. Some relevant information may be found here in our User Guide, but our primary API reference content for the Mambu v1 and v2, Payments, and Streaming APIs may be found on our [API Reference](/api/). There, you will find complete reference material including authentication and request format information, endpoints, field descriptions, example requests and responses, and general help on requirements and conventions. For information on using the MPO API, see our [MPO documentation](https://ecosystem.mambu.com/mpo/overview/). Mambu APIs allow users to perform many tasks, including: * create clients, loan accounts, or savings accounts * make transactions * manage system configuration * set up branches * configure interest rates * manage API keys, user roles, and access permissions * and much, much more Providing so much functionality via API is a cornerstone of our "composable banking" ethos, allowing you to easily build up your business around Mambu's Core Banking feature set or just dip in to our complete feature set to take advantage of the features you need, such as our trusted general ledger solution. ## Mambu APIs - [API v2](/api/pages/api-v2/welcome): APIs for our core banking platform. These provide access to our most widely used features such as client & account management, transactions & general ledger journal entries, tasks and system configuration. This is likely the first point of reference when building integrations and custom tools. - [API v1](/api/pages/api-v1/welcome): Our legacy core banking API; while we recommend that all new integrations are built using our v2 APIs, these endpoints and their documentation are retained for existing customers who may still be using them in legacy integrations. For more information, see [Using API v1 and API v2](#using-api-v1-and-api-v2). - [Mambu Payments Gateway API](https://api.mambu.com/payments-api/#welcome): Our payments product helps customers support national and international, standards-based schemes, including SEPA. APIs are provided for making and receiving payments and inquiries as well as mapping Mambu accounts to international account numbering systems such as IBAN and communicating with partners to deliver anti-money laundering measures and other requirements. - [Streaming API](/api/pages/streaming/streaming-index): Our streaming API is an enterprise feature which allows customers to set up configurable event feeds that can be used to power your own banking ecosystem, be it communication tool CRMs or your own auditing and logging system. ## Using API v1 and API v2 API v1 is no longer being actively developed. We strongly recommend that all customers use our API v2 endpoints for all new integrations and transition to API v2 endpoints for existing features wherever possible. API v2 can, however, be used in parallel with API v1, as they do not conflict. Request versioning is supported via the `Accept` header. An `Accept` header is required for all API v2 requests. Example: ```http Accept: application/vnd.mambu.v2+json ``` or ```http Accept: application/vnd.mambu.v2+yaml ``` --- # Mambu Data Dictionary URL: https://docs.mambu.com/docs/mambu-data-dictionary/ This document describes the database structure and fields used in Mambu for the purposes of supporting the Mambu APIs, Business Intelligence Reporting, and enabling data migration procedures. You may also perform a database backup which will give a backup of all your tables. For more information, see Database Backups in our User Guide or Database Backup [Database backups](/api/api-v2/database_backup/database-backup) in our API v2 Reference ### Overview Mambu is built on a relational database system, but is often de-normalized and puts the dependency on the application to maintain certain level of integrity. For instance, a loan account has a foreign key to its holder which may be a client or a group. Here we indicate which fields are also logically required or currently unused (or reserved for future use). This document focuses on tables which are importable or accessible via APIs. ### Common Fields All tables have a primary key called encodedKey. This key is a Universally unique identifier (UUID) generated by the application at the time of creating or storing the object. Many tables will also have fields called creationDate and lastModifiedDate indicating when the object was created and last modified. ### Time Stamps Most time stamps in Mambu are stored in UTC. Some variation to this are pure dates which have meaning for the organization itself. For instance, if a repayment is due on June 16th, 2010 it will be stored as “June 16, 2010 00:00:00” in the database. The application logic then takes care of ensuring that this repayment is set to in arrears as appropriate for the organizations’ time zone. In each entity’s table presented in this document, for its date fields extra info will be found about what value is stored in the database (UTC or Organization Time). :::warning Undocumented Tables Some tables in this data dictionary may be undocumented. This can be for a number of reasons: in some cases tables will be created to support upcoming features and documentation added once the feature has been released, in other cases tables are not intended to be modified/used by customers as they contain only Mambu system or UI data such as dashboard view preferences or custom views and menus. ::: ## accountarrearssettings > entity holding the required information for the arrears settings of an account. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    monthlytoleranceday`int(11)`Represents the monthly arrears tolerance day value.
    tolerancepercentageofoutstandingprincipal`decimal(50,20)`Indicates the amount by which an account will be allowed to go into arrears as a percentage of the outstanding principal.
    toleranceperiod`int(11)`The allowed period for loan to be in arrears.
    ## accountarrearssettingsmapping > Describes a link between a loan account and arrears settings when the terms change with a transaction of type `TERMS_CHANGED` Primary key: `loanaccountkey` + `loantransactionkey`+ `arrearssettingskey`
    Column Name Data Type Description
    arrearssettingskey`varchar(35)`The encoded key of the entry in the `arrearssettings` table holding the arrears settings.
    loanaccountkey`varchar(32)`The encoded key of the loan account.
    loantransactionkey`varchar(32)`The encoded key of the transaction which records the change of terms.
    ## accountinginterestaccrualbreakdown > Stores information regarding interest accrual Primary key: `id`
    Column Name Data Type Description
    accountencodedkey`varchar(32)`Reference to the account (loan/savings) `encodedkey` for which this entry is logged.
    accountid`varchar(32)`Reference to the account (loan/savings) ID for which this entry is logged.
    accrualtype`varchar(32)`The type of interest being accrued. For regular interest accrued, that isn’t paid already `INTEREST_ACCRUED`. For interest accrued that is already paid after a prepayment `PREPAID_INTEREST_ACCRUED`.
    amount`decimal(50,10)`The amount accrued.
    bookingdate`datetime`Booking Date of the referenced GL Journal Entry
    branchencodedkey`varchar(32)`Reference to the branch encoded key for which this entry is logged.
    creationdate`datetime`Date and time, in UTC, at which this entry was created.
    entryid`bigint(20)`Reference to GL Journal Entry entry id for which this entry is logged.
    entrytype`varchar(32)`Accounting entry type, for example, `DEBIT` or `CREDIT`.
    glaccountencodedkey`varchar(32)`Reference to the GL Account for which this entry is logged
    glaccounttype`varchar(32)`Type of GL Account for which this entry is logged, for example `ASSET`or `INCOME`.
    id`bigint(64)`Accounting interest accrual breakdown id
    processed`tinyint(1)`Flag for marking if this entry has been successfully processed and can be removed from this table.
    productencodedkey`varchar(32)`Reference to the product encoded key for which this entry is logged
    producttype`varchar(32)`Reference to the product type for which this entry is logged
    sent`tinyint(1)`Flag for marking is this entry was sent to the internal message broker
    transactionid`varchar(32)`Reference to GL Journal Entry transaction id for which this entry is logged.
    ## accountingloaninterestaccrualsnapshot > stores interest accrual data to generate the aggregated and breakdown amounts on the same data, saved in a snapshot at a specific point in time. Primary key: `id`
    Column Name Data Type Description
    accountencodedkey`varchar(32)`The unique identifier of the account.
    accountid`varchar(32)`The ID of the account.
    assignedbranchkey`varchar(32)`The unique key of the branch to which this account is assinged.
    interestamount`decimal(50,10)`The amount of interest.
    productinterestaccrualcalculation`varchar(256)`The method used to calculate interest accrual. Can be one of `NONE`, `BREAKDOWN_PER_ACCOUNT`, or `AGGREGATED_AMOUNT`.
    producttypekey`varchar(32)`The unique key of the product used to create this account.
    ## accountinterestratesettings >Stores the interest settings to be used in an adjustable interest rates context at account level. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkeyvarchar(32)A unique key for this row.
    accountkeyvarchar(32)The encoded key of the loan product.
    validfromdatetimeStart date of the interest rate.
    interestratetypevarchar(256)The type of interest rate source (FIXED_INTEREST_RATE or INDEX_INTEREST_RATE).
    indexsourcekeyvarchar(32)The encoded key of the index rate source.
    interestrateceilingvaluedecimal(50,20)The maximum (ceiling) value of interest rate.
    interestratefloorvaluedecimal(50,20)The minimum (floor) value of interest rate.
    interestrateviewcountintInterest rate review frequency unit count.
    interestratereviewunitvarchar(255)Interest rate review frequency measurement unit DAYS, WEEKS, MONTHS.
    interestratedecimal(50,20)The rate based on which the interest is accrued and applied for accounts with fixed interest rate.
    interestspreaddecimal(50,20)The rate based on which the interest is accrued and applied for accounts with index interest rate.
    ## accountingnotificationmessage Primary key: `encodedkey`
    Column Name Data Type Description
    body`mediumtext`
    creationdate`datetime`
    destination`varchar(1024)`
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    event`varchar(256)`
    failurecause`varchar(256)`
    failurereason`varchar(255)`
    gljournalentrykey`varchar(32)`
    id`varchar(256)`
    numretries`int(11)`
    senddate`datetime`
    state`varchar(256)`
    templatekey`varchar(32)`
    type`varchar(256)`
    ## accountingnotificationmessagequeue Primary key: `encodedkey`
    Column Name Data Type Description
    accountingnotificationmessage_encodedkey_oid`varchar(32)`
    creationdate`datetime`
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    state`varchar(256)`
    ## accountingrate > table used to store internal currency conversion rates for accounts in different currencies within the same bank. this table is for an upcoming feature. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    enddate`datetime`The last date on which this rate will be valid.
    fromcurrencycode`varchar(3)`Foreign key pointing to a currency defined in the `currency` table which is to be converted from.
    rate`decimal(50,20)`The currency conversion rate.
    startdate`datetime`The first date on which this rate is valid.
    tocurrencycode`varchar(3)`Foreign key pointing to a currency defined in the `currency` table that is the output currency of the conversion rate.
    userkey`varchar(32)`Unique key of a user who entered this exchange rate. Foreign key to the `user` table.
    ## accountlink > represents a link created between a loan account and a deposit account. these links are used to be able to pay the loan account due amounts in the due date of a repayment, automatically, via transfers from the linked deposit account. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the link was created - Stored as UTC
    encodedkey`varchar(32)`A unique ID used as a key for this table.
    lastmodifieddate`datetime`The date when the link was changed - Stored as UTC
    loanaccountkey`varchar(32)`The key of loan account with which the deposit account is linked. **Required**
    savingsaccountkey`varchar(32)`The key of deposit account linked to the loan account.Required
    ## accountpaymentholidaysdetails > this table contains details about payment holidays which have been granted for a given loan account and includes the interest amount accrued during the payment holiday period. read our documentation on payment holidays for more information on this feature. Primary key: `encodedkey`
    Column Name Data Type Description
    accountkey`varchar(32)`The encoded key for the loan account which has been granted a payment holiday.
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    interestaccrued`decimal(50,10)`The interest accrued during the payment holiday.
    ## activity > each action that takes place in the application is followed by an activity that is logged and posted on the dashboard and on the activity feed. Primary key: `encodedkey`
    Column Name Data Type Description
    activitychanges_integer_idx`int(11)`For single changes this will always be `-1`. When a single activity contains multiple changes, this field will indicate the position in the list of changes, starting from 0. For example if multiple holidays can be added for an organization and will be applied when the save button is clicked, there will be one activity of the type `HOLIDAY_SETTINGS_CHANGED` and multiple activities of the type `ENTITY_ADDED`. The `parent_key` will point to the main activity in the set.
    assignedcentrekey`varchar(32)`The key of the centre involved in this activity
    assigneduserkey`varchar(32)`Set to a user who is assigned to be notified about this activity (such being the owner of the clients) also, is used as the assigned user key of the entity for whom the activity is placed (the credit officer of the client, for example)
    branchkey`varchar(32)`Set to branch encoded key if the activity is associated with a particular branch
    centrekey`varchar(32)`Set to centre encoded key if the activity is associated with a particular centre
    clientkey`varchar(32)`Set to client encoded key if the activity is associated with a client
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `fieldchangeitem` table.
    entitykey`varchar(32)`Used for generic activities and specifies the key of the linked entity (`CLIENT`, `GROUP`, etc)
    entitytype`varchar(30)`Field used for generic activities and specifies entity type (Eg. `CLIENT`, `GROUP`, `BRANCH`)
    fieldchangename`varchar(256)`The field which corresponds to this activity in the case when it is a sub-activity
    glaccountkey`varchar(32)`Set to gl account encoded key if the activity is associated with a particular gl account
    glaccountsclosurekey`varchar(32)`Set to GlAccountClosure encoded key if the activity is associated with a particular accounting closure
    groupkey`varchar(32)`Set to group encoded key if the activity is associated with a group
    lineofcreditkey`varchar(32)`The key of the line of credit involved in this activity
    loanaccountkey`varchar(32)`Set to loan account encoded key if the activity is associated with a particular loan account
    loanproductkey`varchar(32)`Set to loan product encoded key if the activity is associated with a particular product (eg. account activity)
    notes`varchar(256)`The notes logged within the activity.
    parent_key`varchar(32)`Specifies the parent activity if any. The parent is another entry in this table.
    savingsaccountkey`varchar(32)`Set to loan account encoded key if the activity is associated with a particular loan account
    savingsproductkey`varchar(32)`Set to loan product encoded key if the activity is associated with a particular product (eg. account activity)
    taskkey`varchar(32)`The key of the task involved in this activity
    timestamp`datetime`The time when the activity was logged.
    transactionid`bigint(20)`The id of the transaction contained in the activity.
    type`varchar(256)`The type of the activity. See our API v1 reference listing available Activity types.
    userkey`varchar(32)`The user key of the user (activity actor) who was logged in and performed the activity
    ## address > captures address information about clients, groups, etc. foreign key (parentkey) relies on primary keys being uuids. parents may have any number of addresses. for instance, the address field may have a parentkey = “abc” which refer to the client.encodedkey = “abc”. as such, addresses are to be retrieved via their parents. Primary key: `encodedkey`
    Column Name Data Type Description
    addresstype`varchar(256)`Type of address. Unused
    city`varchar(256)`City of the address
    country`varchar(256)`Country of the address
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    indexinlist`int(11)`Order of the address if the parent holder has multiple addresses for display/formatting purposes. That is, 0 is displayed before 1, etc.
    latitude`decimal(9,6)`The latitude of the address point.
    line1`varchar(256)`First line of the address
    line2`varchar(256)`Second line of the address
    longitude`decimal(9,6)`The longitude of the address point.
    parentkey`varchar(32)`Foreign key as to who this address belongs to. For instance may refer to a client or a group, etc. **Required**
    postcode`varchar(256)`Postal code of the address
    region`varchar(256)`Sub-region of the address. Unused.
    ## amortizationamount > an amount that was amortized from a bigger one. when organizations hold an asset, an income or an expense, they want to amortize it over the time. this class is used to amortize a part of the initial amount. Primary key: `encodedkey`
    Column Name Data Type Description
    amortizedamounts_encodedkey_own`varchar(32)`Encoded key of an entry in the `predefinedfeeamount` table.
    amortizedamounts_integer_idx`int(11)`In the case this there are more than one amortized amount relating to the same entry in the `predefinedfeeamount` table, this field shows the index in that list for the current amount.
    amount`decimal(50,10)`The amount amortized by this instance. **Required**
    branchkey`varchar(32)`Encoded key of the branch.
    centrekey`varchar(32)`Encoded key of the centre.
    creationdate`datetime`The system date when this entry was logged (as UTC). **Required**
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    entrydate`datetime`The date when this amount was recognized as amortized (as Organization Time). **Required**
    reversalamountkey`varchar(32)`In the case when this amount is reversed the `reversalAmountKey` represents the key of an entry in this table containing the amount which reversed this current one
    taxamount`decimal(50,10)`The amount of taxes amortized by this instance.
    type`varchar(32)`The type of the amortization(regular amortization, reversal, etc.)
    - `AMORTIZATION`,
    - `AMORTIZATION_ADJUSTMENT`
    ## applicationrootencryptionkey > A table holding keys used to encrypt files and data being stored in your Mmabu system. Primary key: `encodedkey`
    Column Name Data Type Description
    content`varchar(256)`A key used in encrypting data.
    creationdate`datetime(6)`The date and time at which this key was created, in UTC.
    encodedkey`varchar(32)`A unique key for this row.
    iv`varchar(256)`An initialisation vector used in encrypting data.
    lastmodifieddate`datetime(6)`The date and time, in UTC, on which the key was last modified or replaced.
    ## authorizationhold > The model used for keeping authorization requests. Primary key: `encodedkey`
    Column NameData TypeDescription
    accountkey`varchar(32)`The key of the account linked with the authorization hold.
    amount`decimal(50,10)`The amount to hold. **Required**
    cardacceptorkey`varchar(32)`Link to the entity used for keeping card acceptor provided details like, the state, country, etc from which the request was made
    cardreferencetoken`varchar(72)`The card reference token used to reference the user card.
    creationdate`datetime(6)`As UTC. **Required**
    creditdebitindicator`varchar(256)`Indicates whether the hold is positive or negative. `DBIT` is a normal positive hold for card payments, `CRDT` indicates this hold will add money to the card-holder’s account, for example, for refunds &c..
    currencycode`varchar(3)`The ISO currency code, in which the request was made
    encodedkey`varchar(32)`The encoded key for this database entry. This value is auto-generated and should not be changed.
    exchangerate`decimal(50,10)`The exchange rate used at the time of the transaction to convert between the original and account currency.
    externalreferenceid`varchar(256)`The external reference Id to be used to reference this request in the subsequent requests
    isadvice`bit(1)`Whenever the given request should be accepted without any validations. **Required**
    lastmodifieddate`datetime(6)`The date on which this row was last modified. As UTC.
    originalamount`decimal(50,10)`The amount of the transaction in the original currency in the case that this transaction was made in a currency different to that of the account.
    originalcurrency`varchar(32)`The currency of the transaction in the case that it was anything other than the currency of the account.
    referencedateforexpiration`datetime(6)`The date to consider as start date when calculating the number of days passed until expiration (stored as UTC).
    source`varchar(32)`Indicates the source of the authorization hold. Can be:
    - `CARD`: The authorization hold has been created using the Cards functionality.
    - `ACCOUNT`: The authorization hold has been created directly in the account.
    state`varchar(256)`The current Authorization Hold state. Can be:
    - `CANCELED`: The previously registered was canceled and the balances updated,
    - `PENDING` : The request was registered, the available amount was updated, but the transaction was not applied yet,
    - `SETTLED`: The request was registered and the specific transaction was applied in Mambu.
    **Required**
    usertransactiontime`varchar(256)`The moment of time at which the transaction occurred. The format is caller dependant and it not restricted in anyway. Could be dates, timestamps, epoch millis etc.
    ## backgroundprocess > the execution of a process started by a user, that is done in the background. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime(3)`When this process was created. Stored as Organization Time
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    enddate`datetime`When this process was ended. Stored as Organization Time.
    lastheartbeatdate`datetime(3)`The date and time at which it was last checked that this process is still running.
    retryattempts`int(11)`The number of times the process was retried in the case of failure.
    simpleexception`varchar(3000)`A simple exception information summary for failed processes
    startdate`datetime`When this process was started. Stored as Organization Time.
    state`varchar(256)`The current status of this process:
    - `IN_PROGRESS`
    - `COMPLETE`
    - `NOT_FOUND`
    - `CANCEL`
    - `ERROR`
    - `OVERRIDDEN`
    **Required**
    type`varchar(256)`The type of the action:
    - `ACCOUNTING_BALANCE_SHEET_REPORT`
    - `ACCOUNTING_PRODUCT_LEDGER`
    - `ACCOUNTING_TRIAL_BALANCE_REPORT`
    - `ACCOUNTING_PROFIT_AND_LOSS_REPORT`
    - `STORE_HOLIDAYS`
    - `STORE_HOLIDAYS_FOR_BRANCH`
    - `CRON_JOBS`
    - `GENERATE_GL_ACCOUNTS_CLOSURE`
    **Required**
    userkey`varchar(32)`The key of the user that started this process.
    ## backgroundprocessprogress > entity which correspond to the progress information of a background process. Primary key: `encodedkey`
    Column Name Data Type Description
    currentprogress`decimal(50,20)`The process current progress
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `backgroundtask` table.
    progresstype`varchar(256)`How this progress is measured
    totalprogress`decimal(50,20)`The process total progress that need to be executed (includes the progress that was executed and the one that needs to be executed)
    ## backgroundtask > represents a task which is submitted for background processing Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field is autogenerated and should not be changed.
    entitykey`varchar(32)`The entity key which for which this task was created.
    entitytype`varchar(256)`The type of the entity for which this task was created
    input`mediumtext`Input of the task, JSON serialized version
    processkey`varchar(32)`Foreign key to the `backgroundProcess` table. The associated background process to this task, it contains information about process state and progress.
    progresskey`varchar(32)`Foreign key to the `backgroundProcessProgress` table. The associated background process progress to this task.
    result`mediumtext`Result of the task, JSON serialized version
    taskid`bigint(20)`Incremented id used for ordering. (UNIQUE INDEX ‘TASKID_UNIQUE’)
    ## basearrearssettings > base class for all the entities grouping settings related to arrears settings. Primary key: `encodedkey`
    Column Name Data Type Description
    datecalculationmethod`varchar(256)`How arrears dates are calculated. Can be one of
    - `ACCOUNT_FIRST_WENT_TO_ARREARS`
    - `LAST_LATE_REPAYMENT`
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `accountarrearssettings` and `productarrearssettings` tables.
    nonworkingdaysmethod`varchar(256)`Whether the non working days are taken in consideration or not when applying penalties/late fees or when setting an account into arrears. Either `INCLUDED` or `EXCLUDED`.
    tolerancecalculationmethod`varchar(256)`The method used to compute arrears day. Must be one of:
    - `ARREARS_TOLERANCE_PERIOD`
    - `MONTHLY_ARREARS_TOLERANCE_DAY`
    **Required**"
    toleranceflooramount`decimal(50,20)`The minimum threshold for marking an account as being in arrears. For example, if the floor is set as 15 euros and a loan account has a tolerance of 10% with 100 euros outstanding principal, it will not be marked as being in arrears as the amount is only 10 euros and so less than the 15 euro floor.
    ## batchmigration > holds information about batch migration scripts. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    entitykey`varchar(32)`Maintains the key of the migrated entity. **Required**
    exception`mediumtext`Exception of the failed update process.
    successful`bit(1)`Maintains the state of the migrated entity.
    type`varchar(32)`Holds the type of migration that contains the row information.
    ## batchmigrationarchived > this table is an archive of the batch migration table and was created as part of the v9.47 release to avoid losing existing data.
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    entitykey`varchar(32)`Maintains the key of the migrated entity. **Required**
    exception`mediumtext`Exception of the failed update process
    successful`bit(1)`Maintains the state of the migrated entity.
    type`varchar(32)`Holds the type of migration that contains the row information.
    ## blockfund > a table describing blocks or seizures of funds in client accounts which are generally made due to a governmental or judicial request, for example garnishment of wages, debt collection or seizure of funds which were generated through the proceeds of criminal activity. blocked funds will not be available to clients. Primary key: `encodedkey`
    Column Name Data Type Description
    accountkey`varchar(32)`The encoded of the account for which a certain amount will be blocked.
    amount`decimal(50,10)`The amount of the account owner’s funds which are blocked.
    creationdate`datetime`The date on which this seizure was created.
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    externalreferenceid`varchar(512)`A reference ID to refer to the blocked funds which is used when unblocking or withdrawing all or part of these funds.
    lastmodifieddate`datetime`The date on which this seizure was last modified.
    notes`varchar(256)`Notes recorded by the user when initiating the seizure.
    seizedamount`decimal(50,10)`The amount which has been blocked for this seizure.
    state`varchar(256)`The state of this block; `PENDING`, `REMOVED` or `SEIZED`.
    ## blockfundtransactionsource > represents a link between a transaction and a portion of an account holder’s balance which has been blocked. Primary key: `blockfundkey` + `savingstransactionkey`
    Column Name Data Type Description
    blockfundkey`varchar(32)`The `encodedkey` of the blocked funds. This links to the `blockfund` table
    blockfundreferenceid`varchar(512)`The reference ID for the blocked funds. This referes to the `externalreferenceid` column of the `blockfund` table.
    savingstransactionkey`varchar(32)`The encoded key of the savings/deposit account transaction. Links to the `savingstransaction` table.
    ## branch > a branch is the main division criteria of the organization. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date on which the branch was fdirst created. Stores in the organization’s local time.
    emailaddress`varchar(256)`The email address defined for a branch
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used to refer to this entity when using our API.
    id`varchar(32)`A unique user defined ID. **Required**
    lastmodifieddate`datetime`The date on which the entry was last modified. Stored in the organization’s local time.
    name`varchar(256)`The name of the branch.
    notes`mediumtext`Notes for the branch, usually stored as HTML
    phonenumber`varchar(256)`The phone number defined for a branch
    state`varchar(255)`Indicates whether the branch is `ACTIVE` or `INACTIVE`.
    ## branchcustomvalue > Holds values for custom information for branches. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## bulkprocessingprocesseditems Primary key: `encodedkey`
    Column Name Data Type Description
    bulkitemtemporarilyuuid`varchar(32)`
    bulkkey`varchar(32)`
    creationdate`datetime`
    encodedkey`varchar(32)`
    persistedentitykey`varchar(32)`
    ## cardacceptor > used for keeping card acceptor details linked to hold and financial transaction requests. Primary key: `encodedkey`
    Column Name Data Type Description
    city`varchar(256)`The city of the acceptor.
    country`varchar(256)`The country of the acceptor.
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `authorizationhold` table.
    mcc`int(11)`The business code of the acceptor, the code can be used for authorization holds expiration. For example for some MCC values, the hold could expire faster.
    name`varchar(256)`The name of the acceptor.
    state`varchar(256)`The state of the acceptor.
    street`varchar(256)`The street and house number of the acceptor.
    zip`varchar(256)`This is the zsip.
    ## cardreference > entity used for keeping the card assignments for an account. an account can have more cards assigned, but a card can be assigned only to one account. Primary key: `encodedkey`
    Column Name Data Type Description
    accountkey`varchar(32)`Keeps the encoded key of the account for which the cart was referenced. **Required**
    cardreferencetoken`varchar(72)`Keeps the card id reference token. **Required**
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `authorizationhold` table.
    type`varchar(32)`The type of card, ie. debit or credit.
    ## cardtransactionreversal > used for the context that caused a card transaction reversal. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The amount to be debited. **Required**
    cardreferencetoken`varchar(72)`The card reference token used to reference the user card.
    cardtransactionexternalreferenceid`varchar(256)`The reference ID of the corresponding card transaction external reference id
    creationdate`datetime(6)`Keeps the encoded key of the savings account for which the cart was referenced. **Required**
    currencycode`varchar(3)`The ISO currency code, in which the request was made.
    encodedkey`varchar(32)`The encoded key for this database entry.
    externalreferenceid`varchar(256)`The external reference ID to be used to reference this request in the subsequent requests.
    originaltransactionkey`varchar(32)`A reference to the original transaction that is being reversed here.
    transactionchannelid`varchar(32)`Foreign key for the `transactionChannel` table which points to the transaction channel used for this card transaction.
    transactionkey`varchar(32)`The ID for this transaction.
    ## cardtransactionsource > used for the context that caused a card transaction. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The amount to be debited. **Required**
    cardacceptorkey`varchar(32)`The `encodedkey` of a row in the `cardacceptor` table containing details of the acceptor for this transaction.
    cardreferencetoken`varchar(72)`The card reference token used to reference the user card.
    creationdate`datetime(6)`Keeps the encoded key of the savings account for which the cart was referenced. **Required**
    currencycode`varchar(3)`The ISO currency code, in which the request was made.
    encodedkey`varchar(32)`The encoded key for this database entry.
    externalauthorizationreferenceid`varchar(256)`The external authorization hold reference ID, which relates this card transaction to a previous authorization hold.
    externalreferenceid`varchar(256)`The external reference ID to be used to reference the card transaction in subsequent requests..
    isadvice`bit(1)`Whenever the given request should be accepted without any validations(i.e. advice). **Required**
    lastmodifieddate`datetime(6)`The date on which this row was last modified. As UTC.
    linkedtransactionkey`varchar(32)`The encodedKey of the linked financial transaction.
    linkedtransactiontype`varchar(32)`The type of the linked transaction (`DEPOSIT` / `LOAN`).
    transactionchannelid`varchar(32)`The ID of the channel through which the payment is done.
    usertransactiontime`varchar(256)`The date&time string at which the transaction was created by the merchant.
    ## centre > a centre is a common meeting area where credit officers, the individuals and group clients go to. each centre is assigned to a branch (a branch can have multiple centres) and might have a specific meeting day and location. Primary key: `encodedkey`
    Column Name Data Type Description
    assignedbranchkey`varchar(32)`Foreign key to a Branch. It defines the branch to whom this centre belongs to. **Required**
    creationdate`datetime`The date on which the centre was created. Stored in the organization’s local time.
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used with our API to get details on a specific Centre.
    id`varchar(32)`An unique user defined ID. **Required**
    lastmodifieddate`datetime`The date on which the entry was last modified. Stored in the organization’s local time.
    meetingday`varchar(256)`The day of week when the meeting is scheduled. The clients/groups that are associated to a centre, that have a meeting day, can have the repayments due date in the specified meeting day.
    The meeting day can be:
    - `MONDAY`
    - `TUESDAY`
    - `WEDNESDAY`
    - `THURSDAY`
    - `FRIDAY`
    - `SATURDAY`
    - `SUNDAY`
    migrationeventkey`varchar(32)`Foreign key to a specific Migration Event. A centre might be imported using the Data Import feature and all the data imported from a file will be a part of a specific migration event (when this event will be reverted, all the data associated with it will be removed from the system)
    name`varchar(256)`The name of the centre. **Required**
    notes`mediumtext`Optional notes that can be entered when the centre is created/edited.
    state`varchar(255)`State of the Centre: `ACTIVE`/`INACTIVE`.
    ## centrecustomvalue > Holds values for custom information for centres. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## changeduedateevent > Tracks changes made to the due date for loans with fixed day of month payment schedule. This operation will be made via api, read more about how to carry out this operation as well as the product constraints in our repayments schedule editing support article. Primary key: `transactionkey`
    Column Name Data Type Description
    dayofmonth`tinyint(4)`The new day of the month on which installments are due.
    transactionkey`varchar(32)`Foreign key which links to an entry in the `loantransaction` table of the type `DUE_DATE_CHANGED`.
    ## client > captures information about individual clients of the mfi. clients may have their own accounts or belong to groups. clients are also assigned to users and branches. custom fields, identification documents & addresses are stored in separate tables Primary key: `encodedkey`
    Column Name Data Type Description
    activationdate`datetime`The date when the account was set into `ACTIVE` state (when an active account was created for him) (UTC)
    approveddate`datetime`The date when the client was set into `APPROVED` state (UTC)
    assignedbranchkey`varchar(32)`Foreign key to the Branch table indicating which branch the client belongs to
    assignedcentrekey`varchar(32)`Foreign key to the Centre table indicating to which centre the client belongs to.
    assigneduserkey`varchar(32)`Foreign key to the Users table indicating who the the user assigned to the client is (ie: which credit officer is responsible for them)
    birthdate`datetime`Date of when the client was born (Organization Time)
    clientrolekey`varchar(32)`The key of the the client role this client belongs to
    closeddate`datetime`The date when the client was Exited or Blacklisted (UTC)
    creationdate`datetime`The date on which this client was first entered into the system.
    emailaddress`varchar(256)`Email address of the client
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used with our API to get details on a specific Client and is also used as a foreign key to link with other tables, such as the `groupmember`, `grouprole`, `passwordresetrequest`, `identificationdocument` tables, among others.
    firstname`varchar(256)`The first name(s) of the client. **Required**.
    gender`varchar(256)`Gender of the client. Must be one of: MALE or FEMALE.
    grouploancycle`int(11)`The client’s current group loan cycle. That is, how many successful loans they’ve been part of as a group. Auto-incremented on successful account closure.
    homephone`varchar(256)`The home phone number of the client
    id`varchar(32)`A unique (for Clients) human-readable identifier for the the client id. Generated automatically when storing a client through the application but can be set to anything during import. **Required**
    lastmodifieddate`datetime`The date on which some aspect of this client entry was last modified.
    lastname`varchar(256)`The last name(s) of the client. **Required**
    loancycle`int(11)`The client’s current individual loan cycles. Auto-increment on successful account closure.
    middlename`varchar(256)`The middle name(s) of the client.
    migrationeventkey`varchar(32)`Foreign key to a specific Migration Event. A client might be imported using the Data Import feature and all the data imported from a file will be a part of a specific migration event (when this event will be reverted, all the data associated with it will be removed from the system)
    mobilephone1`varchar(256)`Mobile phone number of the client
    mobilephone2`varchar(256)`Mobile phone number of the client (secondary)
    notes`mediumtext`HTML rich-text detailed notes about the client
    portalpreferenceskey`varchar(32)`Foreign key to the client’s portal preferences object - if preferences have been defined for this client. These is created when the portal is first activated for the client
    preferredlanguage`varchar(32)`The language preference for this user. Must be one of `ENGLISH`, `PORTUGUESE`, `RUSSIAN`, `SPANISH`, `FRENCH`, `CHINESE`, `GEORGIAN`, `INDONESIAN`, `ROMANIAN`, `BURMESE`, `GERMAN`.
    profilepicturekey`varchar(32)`Foreign key to the Images table containing the image of the client’s profile picture
    profilesignaturekey`varchar(32)`Foreign key to the Images table containing the signature image for this client
    state`varchar(256)`Like the accounts, the clients might go to an approval process, by the MFIs.
    A client can be:
    - `PENDING_APPROVAL`: is waiting for approval
    - `INACTIVE`: has only inactive accounts
    - `ACTIVE`: has at least one active account
    - `EXITED`: was closed normally
    - `BLACKLISTED`: was closed and blacklisted
    ## clientcustomvalue > Holds values for custom information for clients. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## clientrole > a role which describes the intended use of a client or group in the system Primary key: `encodedkey`
    Column Name Data Type Description
    canguarantee`bit(1)`Whether this role can guarantee for other clients/groups
    canopenaccounts`bit(1)`Whether this role can open loan/savings accounts.
    clienttype`varchar(255)`The category addressed by this role:
    - `CLIENT`
    - `GROUP`
    createdbyuserkey`varchar(32)`The key of the user who created the role
    creationdate`datetime`The date when the role was created (as UTC).
    description`varchar(256)`Description text for client roles
    encodedkey`varchar(32)`The encoded key for this database entry.
    id`varchar(255)`The id of the client role
    idpattern`varchar(32)`The patterm used to generate IDs when new clients are created.
    index`int(11)`The index giving the order of the roles
    name`varchar(255)`The name of the client role
    requireid`bit(1)`Whether it is mandatory for the client to have an ID
    usedefaultaddress`bit(1)`Field to indicate if this the default address should be used
    ## columnconfiguration > stores a configuration for loans/savings/clients/groups according to the specified list type. it keeps track of the column order, for the given list, can be shared with other users or can include the computed totals (for the number columns). Primary key: `encodedkey`
    Column Name Data Type Description
    customconfigurationinfo_encodedkey_oid`varchar(32)`Foreign key to `customConfiguration` table with reference to the entity holding common information for the custom configuration enitites
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    includetimestamp`bit(1)`Whether to include timestamp or not.
    includetotals`bit(1)`Specifies whether to include total values for the numeric and money columns
    sortingcolumn_encodedkey_oid`varchar(32)`Foreign key to the `fieldColumn` table pointing the column used for sorting.
    sortingorder`varchar(256)`Order of sorting, can be:
    - `ASCENDING`
    - `DESCENDING`
    ## comment > for each entity available in the application (client, group, account, user, branch etc.) there can be posted comments, by the users. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the comment has been created.
    encodedkey`varchar(32)`The globally unique encoded key for this comment.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    parentkey`varchar(32)`The parent of the comment is the object it belong to (eg, a client)
    text`mediumtext`The comment text.
    userkey`varchar(32)`The user who left the comment.
    ## contract > table used to model the concept of contract. further a contract can have multiple accounts mapped to it.
    Column Name Data Type Description
    creationdate`datetime(6)`Date when the contract was created. **UTC**
    encodedkey`varchar(32)`Primary key of the contract table.
    lastmodifieddate`datetime(6)`Date when the contract was last time modified. **UTC**
    oldcontractkey`varchar(32)`Encoded key of the old contract entity (i.e SavingsAccount).
    productkey`varchar(32)`Encoded key of the product used by the contract.
    userkey`varchar(32)`Encoded key of the user which triggered the action to create the contract.
    ## contractaccount > table used to hold the mapping between a contract entity and associated accounts.
    Column Name Data Type Description
    accountkey`varchar(32)`Identifier of the account which is mapped to the contract.
    accountmnemo`varchar(256)`Indicate the type of the account which is mapped to the contract (i.e `MAIN`, `OVERDRAFT`, etc)
    closeddate`datetime(6)`Date when the account was closed, null if the the account is not closed yet. **In Organization Time Zone**
    contractkey`varchar(32)`Encoded key of the contract to which the account belongs.
    creationdate`datetime(6)`Date when the account mapping was created. **UTC**
    encodedkey`varchar(32)`Primary key for this table.
    lastmodifieddate`datetime(6)`Date when the account mapping was last time modified. **UTC**
    userkey`varchar(32)`Encoded key of the user which determined the account mapping to be created.
    ## currency > holds details about the currency being used by the mfi. not user configurable. Primary key: `code`
    Column Name Data Type Description
    code`varchar(3)`Official ISO 4217 code, for example: CAD, USD or EUR. For more information, see ISO 4217 on Wikipedia.
    creationdate`datetime`UTC date of creation
    currencysymbolposition`varchar(256)`Possible values:
    - `BEFORE_NUMBER`
    - `AFTER_NUMBER`
    digitsafterdecimal`int(11)`Number of digits which the currency has after the decimal places for display
    isbasecurrency`bit(1)`Whether the currency is the base one used by the organization
    lastmodifieddate`datetime`Date of last modification. As UTC.
    name`varchar(256)`Name of the currency, for example “Canadian dollar”
    symbol`varchar(256)`Short symbol like ‘$’
    ## currencymapping > holds a list of currencies associated to this product. an account for the product can use only the currencies associated to this product. Primary key: `parentkey` + `index`
    Column Name Data Type Description
    currencycode`varchar(32)`The currency code associated to this product. **Required**
    index`int(11)`Column used to sort currencies inside list. **Required**
    parentkey`varchar(32)`The encoded key of the parent, foreign key to the `currency` table.
    ## customconfigurationinfo > entity holding common information used in the custom configuration entities customview, customfilter or columnconfiguration. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`UTC date of creation
    dataviewtype`varchar(256)`View type for this configuration:
    - `LOANS`
    - `SAVINGS`
    - etc.
    encodedkey`varchar(32)`The encoded key for this configuration, this is an autogenerated and globally unique ID.
    indexinlist`int(11)`Specifies the position in an outside collection of custom configurations.
    lastmodifieddate`datetime`UTC last modified date
    name`varchar(256)`The name of the custom configuration
    shared`bit(1)`Specfiies whether this configuration is shared with all users.
    userkey`varchar(32)`The key of the user who created this configuration
    ## customfield > a custom field is a user-defined field which is applicable for any other type of object such as a client or group. the customfield define a type (such as `education`) and the customfieldvalue defined the individual stored value for any given client (such as `bachelors`) Primary key: `encodedkey`
    Column Name Data Type Description
    amounts`mediumblob `With our custom fields, it’s easy to assign value amounts to certain field selections. This is really beneficial for social performance monitoring. It assigns values to custom fields selections and allow performing reporting and interface analysis on them.
    availableforall`tinyint(1)`The field that stores the value for the "Available for all" toggle under the Custom Field setup.
    builtincustomfieldid`varchar(255)`The field that is part of the builtIn custom fields (custom fields whose values are store in entity table for example Client.firstName).
    creationdate`datetime`The date when the custom field was created - Stored as UTC
    customfieldset_encodedkey_oid`varchar(32)`Links this entry to a custom field set definded in the `customfieldset` table.
    datatype`varchar(256)`Type of value which is to be stored (refers to the representation of CustomFieldValue.value). Must be one of:
    - `STRING`
    - `SELECTION`
    **Required**
    description`varchar(256)`A short description of the specific custom field.
    editusagerightskey`varchar(32)`The usage rights that describes the edit access to the Custom Field. Foreign key to the `usageRights` table.
    encodedkey`varchar(32)`The encoded key of this custom field. **Please note:** this is an automgenerated ID and not the same as the user defined custom field ID.
    id`varchar(32)`Unique, user-defined ID for the custom field object
    id_generated`int(10) unsigned auto_incremented`Unique identifier, non-editable, auto-incremented. Currently not in use.
    indexinlist`int(11)`Index of the custom field in the list of all custom fields with the same type; -1 means that this custom field was never ordered by the application
    isdefault`bit(1)`Whether the field is to be displayed as a default field when creating the client/group/etc. **Required**
    isrequired`bit(1)`Whether the field is required when creating the client/group/etc. **Required**
    lastmodifieddate`datetime`The last date when the custom field was changed - Stored as UTC
    name`varchar(256)`The name of the custom field. Such as ‘Education’**Required**
    state`varchar(256)`Custom field state
    - `NORMAL` - The default state for a custom field
    - `DEACTIVATED` - Used to mark the custom field as deactivated
    temporaryid`varchar(32)`Temporary field, valid form of the id
    type`varchar(256)`Type of custom field. Defines for whom this field is applicable. Some fields are for clients, whereas other are for groups, etc.
    Must be one of:
    - `CLIENT_INFO`
    - `GROUP_INFO`
    - `BRANCH_INFO`
    - `CREDIT_OFFICER_INFO`
    **Required**.
    unique`bit(1)`Indicates that the values for this custom field needs to be unique. It can be used only for text type custom fields
    validationpattern`varchar(256)`If validation has been set for the custom field, for example, the value should only be digits or should be in the format 123-456, the validation pattern will be held in this field.
    valuelength`varchar(256)`Whether the custom field is `SHORT` or `LONG`, this mostly has an impact on how the data from this custom field is displayed in the Mambu UI, generally all custom field values have a maximum length of 2048 characters.
    values`mediumblob `Used to store the predefined values for the dataType.SELECTION customFields. For example: - name = ‘Occupation’; - values = ‘Teacher’, ‘Student’;
    viewusagerightskey`varchar(32)`The usage rights that describes the view access to the Custom Field. Foreign key to the `usageRights` table.
    ## customfieldlink > information about the availability of a custom field for another entity (product, client role) Primary key: `encodedkey`
    Column Name Data Type Description
    customfieldlinks_encodedkey_own`varchar(32)`The key to the custom field. **Required**
    encodedkey`varchar(32)`The encoded key for this link, this is an autogenerated and globally unique ID.
    entitylinkedkey`varchar(32)`The key to the loan, savings product, or client type, this custom field might be assigned to. When the key is set, the custom field can be used for the accounts made after that product. **Required**
    isdefault`bit(1)`Whether the linked custom field is displayed by default when creating a new entity. **Required**
    isrequired`bit(1)`Whether the linked custom field is displayed by default for the linked entity. **Required**
    linktype`varchar(32)`Specifies the link type, like product or a client role. **Required**
    ## customfieldselection > entity holding a selection value for a custom field of type `customfield.datatype.selection`. the entity will also keep the score for that given value and if the parent custom field has a dependency on another custom field the dependency rule will be kept in the `customfilterconstraint`. Primary key: `encodedkey`
    Column Name Data Type Description
    constraintkey`varchar(32)`The key of the constraint that keeps the dependency on the parent custom field. Can be null if no parent is assigned.
    customfieldkey`varchar(32)`The key of the custom field associated with this selectible value
    encodedkey`varchar(32)`The encoded key for this selectible value, this is an autogenerated and globally unique value.
    id`varchar(32)`An automatically generated ID for the selectible value.
    score`decimal(19,0)`The score for the selectible value (credit scoring feature).
    selectionindex`int(11)`The index in list for this selectible value.
    value`varchar(255)`Value that appears in the dropdown and can be selected by the user.
    ## customfieldset > defines a set of custom fields for grouping them on the interface Primary key: `encodedkey`
    Column Name Data Type Description
    builtintype`varchar(255)`Represents the special sets which contains the configurations for fields that are part of the entities
    createddate`datetime`The date when this set was created (as UTC).
    encodedkey`varchar(32)`The encoded key for this set of custom fields, this is an autogenerated and globally unique ID.
    id`varchar(32)`The custom field set identifier.
    indexinlist`int(11)`Index of the set in the list of all sets with the same type.
    lastmodifieddate`datetime`The date when this set was last modified (as UTC).
    name`varchar(256)`The name of the custom field set. **Required**
    notes`mediumtext`A short description of the specific custom field set.
    temporaryid`varchar(32)`Temporary field, valid form of the id
    type`varchar(256)`Type of custom field set. Defines for whom this set is applicable to. Some fields are for clients, whereas other are for groups, etc.
    Must be one of:
    - `CLIENT_INFO`
    - `GROUP_INFO`
    - `BRANCH_INFO`
    - `CREDIT_OFFICER_INFO`
    **Required**.
    usage`varchar(32)`Custom field set usage. Enum used for deciding how the Custom field set will be used in the UI and how the custom field values will be stored.
    - `SINGLE` - Default behavior, when the custom field set is displayed in the UI and can be used only once on one entity. The custom fields can be add/removed from the custom field set.
    - `GROUPED` - Custom field set is allowed multiple times for the same entity. The entity can have multiple custom field values for the same custom field.
    ## customfieldvalue > to store the value for a custom field for a client or group. for instance, if the customfield is `education` then the value may store the string `bachelor's degree` Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`With our custom fields, it’s easy to assign value amounts to certain field selections. This is really beneficial for social performance monitoring. It assigns values to custom fields selections and allow performing reporting and interface analysis on them.
    customfieldkey`varchar(32)`Foreign key to the CustomField. **Required**
    customfieldsetgroupindex`int(11)`Field used for deciding which is the order of the custom field sets for {@link CustomFieldSet.Usage}.GROUPED. Where a custom field set can be duplicated and used multiple times for the same entity
    encodedkey`varchar(32)`The encoded key for the value of this custom field, this is an autogenerated and globally unique ID.
    indexinlist`int(11)`Order of the address if the parent holder has multiple addresses (for display/formatting purposes. That is, 0 is displayed before 1, etc.
    linkedentitykeyvalue`varchar(32)`Key of the linked entity stored as value for the custom field
    parentkey`varchar(32)`Foreign key to the holder of this custom field. That is, may refer to the Client.encodedKey or Group.encodedKey, etc. **Required**
    value`varchar(2048)`Value of the field (such as `Bachelors` if the CustomField was `Education`)
    ## customfilter > represents a filter saved by a user for a certain list displayed in the application. Primary key: `encodedkey`
    Column Name Data Type Description
    customconfigurationinfo_encodedkey_oid`varchar(32)`Foreign key to the entry in the `customConfigurationInfo` table containing a configuration information for the current filter
    encodedkey`varchar(32)`The encoded key for this filter, this is an autogenerated and globally unique ID.
    ## customfilterconstraint > represents a filtering condition as example ‘client age between 15 and 100’. Primary key: `encodedkey`
    Column Name Data Type Description
    customfieldkey`varchar(32)`The custom field key after which the filtering is done. A reference to the `customfield` table.
    datafieldtype`varchar(256)`Field type:
    - `NATIVE`
    - `CUSTOM`
    datafieldvalue`varchar(256)`The name of the data field. For example the constraint “Loan Purpose EQUALS Agriculture Loan” will have as data field value Loan Purpose.
    dataitemtype`varchar(256)`Item type:
    - `LOANS`
    - `SAVINGS`
    - etc.
    datatype`varchar(256)`Data type:
    - `BIG_DECIMAL`
    - `DATE`
    - `LONG`
    - `MONEY`
    - etc.
    encodedkey`varchar(32)`The encoded key for this row, used as the primary key for this table.
    filterconstraints_encodedkey_own`varchar(32)`A reference to the `encodedkey` field of the entry in the `customfilter` table to which this constraint relates.
    filterconstraints_integer_idx`int(11)`If one or more filter constraints are set for the same custom filter, this field shows their position in the list. The first constraint having index 0, the second 1 and so on.
    filterelement`varchar(256)`Filter element:
    - `EQUALS`
    - `MORE_THAN`
    - `LESS_THAN`
    - `STARTS_WITH`
    - `BETWEEN`
    - `ON`
    - `AFTER`
    - `BEFORE`
    - `TODAY`
    - `THIS_WEEK`
    - `THIS_MONTH`
    - `THIS_YEAR`
    - `LAST_DAYS`
    groupnumber`int(11)`Specifies the group expression number for which this constraints is part of.
    linkingoperator`varchar(32)`The operator on which this constraint is linking to the previous expression. Eg. `AND loan.id='B'` it is the `AND` operator part
    - `AND`
    - `OR`
    secondvalue`varchar(2048)`The first filtering value of the filter. For example the constraint “Loan Purpose `EQUALS` Agriculture Loan And Science” has as second value “Science”.
    value`varchar(2048)`The first filtering value of the filter. For example the constraint “Loan Purpose `EQUALS` Agriculture Loan And Science” has as (first) value “AgricultureLoan”.
    ## custommenuitem > entity class for holding information about a custom menu item. it offers the possibility to customize what menus are to be displayed in the navigation bar along with their name and other defining properties. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the custom menu item was created - Stored as UTC
    encodedkey`varchar(32)`The encoded key for this menu item, this is an autogenerated and globally unique ID.
    includecollections`bit(1)`Whether to include collections item in custom transactions menus
    lastmodifieddate`datetime`The last date when the custom menu item was changed - Stored as UTC
    name`varchar(255)`The name of the custom menu item
    state`varchar(255)`Holds the state which defines the accessibility for the current custom menu item
    type`varchar(255)`The type of the custom menu item (LOANS, SAVINGS etc)
    userkey`varchar(32)`The key of the user who created this menu item.
    viewusagerightskey`varchar(32)`Foreign key to the `usageRights` table entry containing the usage rights that describes the view access to the Custom Menu Item.
    ## custommenuitempostion > model used for maintaining the index of a custom menu item in a parent. list. Primary key: `encodedkey`
    Column Name Data Type Description
    custommenuitempositions_encodedkey_own`varchar(32)`Foreign key linking to an entry in the `userpreferences` table.
    encodedkey`varchar(32)`A unique key for this row.
    index`int(11)`The index of this row.
    menuitemkey`varchar(32)`The ID of the menu item. Foreign key to the `custommenuitem` table.
    ## custompaymentamount > model capable of holding the custom payment amount introduced by a client for a specific payment amount type. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The custom payment amount introduced by the client.
    custompaymentamounts_encodedkey_own`varchar(32)`The key of the entry in the `loantransaction` table recording this repayment.
    custompaymentamounts_integer_idx`int(11)`Index in a list when the total sum of this custom payment is allocated to more than one type of charge (eg, interest and princpal or late payment fees and pentalties).
    custompaymentamounttype`varchar(32)`Indicates to which part of the loan this portion of the custom payment relates (`UPFRONT_DISBURSEMENT_FEE`, `INTEREST`, `PRINCIPAL`, `MANUAL_FEE`, `LATE_REPAYMENT_FEE`, `PAYMENT_DUE_FEE`, `PENALTY`, etc).
    encodedkey`varchar(32)`A unique key for this row.
    taxonamount`decimal(50,10)`the tax over the custom payment amount introduced by the client.
    ## custompredefinedfee > entity class which "customize" a specific predefined fee. when a custom predefined fee is used the details of the predefined fee can be obtained directly from the referenced predefined fee entity or some of the settings as the amount can be customized and obtained directly from this custom predefined fee entity. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`Custom amount for the fee
    encodedkey`varchar(32)`The encoded key for this fee, this is an autogenerated and globally unique ID.
    predefinedfeekey`varchar(32)`Foreign key to the entry int the `predefinedFee` table containing the predefined fee to be customized.
    ## custompredefinedfeemapping > list of fees that should be applied at the disbursement time. Primary key: `parentkey` + `custompredefinedfeekey` + `index`
    Column Name Data Type Description
    custompredefinedfeekey`varchar(32)`The encoded of the predefined fee to be applied. Foreign key to `custompredefinedfeekey` table.
    index`int(11)`
    parentkey`varchar(32)`Link to the entity that caused the fee to be charged, for example, if the fee is incurred on disbursement, this will link to an entry in the `disbursementdetails` table.
    ## custompreference > model used to maintain custom preferences for a user. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this set of preferences, this is an autogenerated and globally unique ID.
    indexinlist`int(11)`Index of the user custom preference in the list of all custom preferences with the same type; -1 means that this custom preference was never ordered by the application
    preferencetype`varchar(32)`Containing values for the opening columns in Trial Balance report.
    preferenceviewtype`varchar(32)`Containing view that offer column preferences functionalities
    usercustompreferences_encodedkey_own`varchar(32)`Foriegn key to link this entry to one in the `userpreferences` table.
    value`bit(1)`If the column is displayed or not.
    ## customrepaymentsettings > holds a link between a repayment and a type of settings which were customized by the user for the repayment. Primary key: `encodedkey`
    Column Name Data Type Description
    customsettings_encodedkey_own`varchar(32)`
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    loantransactionkey`varchar(32)`The key of the loan transaction which caused this custom settings
    source`varchar(32)`The source of the settings (how the custom settings were created).
    - `USER_INPUT`,
    - `INSTALLMENT_PAID`
    **Required**
    type`varchar(32)`The type of the settings which were customized by the user for the repayment to which this entity is linked.
    - `CUSTOM_DUE_DATE`
    - `CUSTOM_PRINCIPAL`
    **Required**
    ## customrepaymenttransactionsettings > records settings for a custom repayment type transaction. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key.
    installmentkey`varchar(32)`The key of the installment.
    prepaymentrecalculationmethod`varchar(256)`one of:
    - `NO_RECALCULATION`,
    - `RESCHEDULE_REMAINING_REPAYMENTS`,
    - `RECALCULATE_SCHEDULE_KEEP_SAME_NUMBER_OF_TERMS`,
    - `RECALCULATE_SCHEDULE_KEEP_SAME_PRINCIPAL_AMOUNT`,
    - `RECALCULATE_SCHEDULE_KEEP_SAME_TOTAL_REPAYMENT_AMOUNT`,
    - `REDUCE_AMOUNT_PER_INSTALLMENT`,
    - `REDUCE_NUMBER_OF_INSTALLMENTS`,
    - `REDUCE_NUMBER_OF_INSTALLMENTS_NEW`.
    repaymenttransactionkey`varchar(32)`Foreign key linking to an entry in the `loantransaction` table
    ## customreport > stores a custom report created by the user including all the indicators which are in the report, summary, etc. these reports can be created for branches, centres, officers, loan products or savings products.

    read more about creating custom reports for our ui on our support page. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date on which this report was created. As UTC.
    description`mediumtext`A description of this report. This will show up to users when they view the report in the Mambu UI.
    encodedkey`varchar(32)`The encoded key for this report, this is an autogenerated and globally unique ID.
    filter`varchar(256)`Indicates the entity covered by this report. Can be one of `BRANCH`, `SAVINGS_PRODUCT`, `LOAN_PRODUCT`, `CENTRE`, `OFFICER`.
    indicators`mediumblob `An array of indicators used in the report.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    name`varchar(256)`The name of the report.
    ## customview > entity holding information about a custom view. a custom view represents a composition between a customfilte, a columnconfiguration and a datafield used for sorting purposes. it is used for displaying data represented by data items by offering information for filtering, sorting, arranging and paginating this data. Primary key: `encodedkey`
    Column Name Data Type Description
    columnconfiguration_encodedkey_oid`varchar(32)`The columns used by the view
    customconfigurationinfo_encodedkey_oid`varchar(32)`Holds view data like name, view type
    encodedkey`varchar(32)`The encoded key for this view, this is an autogenerated and globally unique ID. This ID is used to call up this view in our UI.
    filter_encodedkey_oid`varchar(32)`The custom filter used by the view
    parentmenuitemkey`varchar(32)`The key of the custom menu item under which this custom view can be found. **Required**
    viewmode`varchar(255)`The mode in which the custom view is shown:
    - `DETAIL`
    - `LIST`
    **Required**
    viewusagerightskey`varchar(32)`The usage rights that describes the view access to the Custom View. **Required**
    ## customviewposition > maintains the index of a custom view. Primary key: `encodedkey`
    Column Name Data Type Description
    customviewspositions_encodedkey_own`varchar(32)`The encoded key of an entry in the `userpreferences` table to which these position settings belong.
    encodedkey`varchar(32)`The ID of this entry.
    favoritecustomviewspositions_encodedkey_own`varchar(32)`
    index`int(11)`Index in list for the corresponding view.
    parentkey`varchar(32)`The key of the parent entity relative to which the custom views ordering takes place. Currently, it represents the key of the parent CustomMenuItem or Dashboard for favorited custom views displayed in the dashboard.
    viewkey`varchar(32)`The encoded key of the view from the `customview` table.
    ## customviewpreferences > holds specific user preferences related to a custom view. Primary key: `encodedkey`
    Column Name Data Type Description
    customviewkey`varchar(32)`Foreign key pointing to an entry in the `customview` table which defines this view.
    encodedkey`varchar(32)`A unique key for this row.
    isfavorite`bit(1)`Whether or not this view has been marked as a favourite by the user.
    userkey`varchar(32)`The encoded key of the user who has set these preferences.
    ## dashboard > stores the user dashboard setting preferences. Primary key: `encodedkey`
    Column Name Data Type Description
    activitytypes`mediumblob `An array of activity types displayed on this dashboard.
    createdbyuserkey`varchar(32)`Unique key of the user who created this dashboard. Foreign key pointing to an entry in the `user` table.
    creationdate`datetime`The date on which this dashboard was created. **UTC**
    encodedkey`varchar(32)`A unique key for this row.
    filterloggedinuseractivities`bit(1)`Whether the dashboard activity widget diplays all activities or has been filtered.
    filterloggedinuserfavoriteviewsdata`bit(1)`Whether there has been a filter applied to the favourite views widget on this dashboard.
    filterloggedinuserindicators`bit(1)`Whether there is a filter applied to the indicators displayed on this dashboard.
    indicators`mediumblob `An array of indicators displayed on this dashboard, for example, the number of active clients or gross loan portfolio.
    lastmodifieddate`datetime`The date on which this dashboard was last edited. **UTC**
    ## dashboardconfiguration Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime(6)`
    dashboardconfigurations_encodedkey_own`varchar(32)`
    encodedkey`varchar(32)`
    name`varchar(256)`
    ## databasechangelog > this table acts as an audit log of changes made to the database schema. for more detailed information on changes check our release notes which are published in advance of any changes being made.
    Column Name Data Type Description
    author`varchar(255)`The database user who created the change.
    comments`varchar(255)`Any comments relating to the changes made. In most cases our release notes will contain more information.
    contexts`varchar(255)`Whether the changes are `pre_migration` or
    dateexecuted`datetime`The date and time at which the change was made.
    description`varchar(255)`Indicates what kind of change was made.
    exectype`varchar(10)`Jobs are run `pre_migration` and `post_migration`. Post migration jobs are generally to check consistency of data once everything has been migrated to a new schema.
    filename`varchar(255)`The file containing the script to execute and details of the changes.
    id`varchar(255)`An id for reference.
    labels`varchar(255)`This column is not used.
    liquibase`varchar(20)`The liquibase version used to make the changes.
    md5sum`varchar(35)`A hash used as a checksum.
    orderexecuted`int(11)`An index starting at `1` and increasing by `1` for each time the database schema was changed.
    tag`varchar(255)`Tags are sometimes used to provide additional
    ## databasechangeloglock Primary key: `id`
    Column Name Data Type Description
    id`int(11)`
    locked`bit(1)`Whether or not the DB is locked.
    lockedby`varchar(255)`
    lockgranted`datetime`
    ## datamigrationevent > captures a data migration event (import/export) performed by a user. includes information about the details of the event as well as (for import) the state of the event if it was accepted or reverted. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date on which this data import oeration was executed.
    encodedkey`varchar(32)`The encoded key of this data migration event.
    numcentresimported`int(11)`The number of centres imported as part of this operation.
    numclientsimported`int(11)`The number of clients who were imported as part of this migration.
    numglaccountsimported`int(11)`The number of general ledger accounts which were imported as part of this job.
    numgroupsimported`int(11)`The number of groups which were imported in this operation.
    numloanrepaymentsimported`int(11)`The number of loan reapayments which were imported as part of this job.
    numloansimported`int(11)`The number of loan accounts which were imported as part of this operation.
    numloantransactionsimported`int(11)`The number of loan transactions which were imported as part of this operation.
    numsavingsimported`int(11)`The number of savings and deposit accounts which were imported during this job.
    state`varchar(256)`The state of the data migration, indicates whether it is pending, has been successfully completed or failed. Can be `DRAFT`, `APPROVED`, or `REVERTED`.
    type`varchar(256)`Whether this is an `IMPORT` or `EXPORT` data migration.
    ## dbschemaupgradeprogress > this table tracks jobs relating to upgrading the mambu database. this generally happens when new versions of mambu are released. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this step
    endsteptime`datetime(3)`The time at which the steo completed. **UTC**
    failurereason`varchar(3000)`The reason in the case that the upgrade process failed.
    releaseversion`varchar(32)`The mambu release version.
    stepstarttime`datetime(3)`The time at which this step started. **UTC**
    stepstatus`varchar(256)`The current status of this step. `SUCCESS` indicates the was step completed.
    upgradestarttime`datetime(3)`The start time of the upgrade job that this step belongs to.
    upgradestep`varchar(256)`Which stage of the upgrade this step was; `PRE_MIGRATION`, `MIGRATION`, `POST_MIGRATION`.
    ## decimalintervalconstraints > holds for keeping decimal min/max/default constraints. Primary key: `encodedkey`
    Column Name Data Type Description
    defaultvalue`decimal(50,20)`The constraint default value
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    maxvalue`decimal(50,20)`The constraint maximum value
    minvalue`decimal(50,20)`The constraint minimum value
    ## disbursementdetails > entity class which holds the informations related to the disbursement details as disbursement date, first repayment date, disbursement fees. Primary key: `encodedkey`
    Column Name Data Type Description
    disbursementdate`datetime`The activation date, the date when the disbursement actually took place. Stored as Organization Time.
    encodedkey`varchar(32)`The encoded key for this disbursement, this is an autogenerated and globally unique ID.
    expecteddisbursementdate`datetime`The expected disbursement date of the account. Stored as Organization Time.
    firstrepaymentdate`datetime`The date of the first repayment. Stored as Organization Time.
    transactiondetailskey`varchar(32)`Foreign key to the `transactionDetails` table containing the details for the disbursement transaction.
    ## document > represents a document stored in mambu. the actual document data is not stored here in the database but externally in a different file stored, refernced to by the location. the location path is not multi-tenant aware. so even though document may be stored as tenantid/folder/file.jpeg the location will refer to folder/file.jpg and it is up to the remote file retrieval system to retrieve the document Primary key: `encodedkey`
    Column Name Data Type Description
    createdbyuserkey`varchar(32)`The key of the user who created the document
    creationdate`datetime`UTC date represents creation date for the document
    description`mediumtext`Additional notes about the document
    documentholderkey`varchar(32)`Who is the holder of this document, if null then no holder for the document
    documentholdertype`varchar(256)`Type of the holder. Valid values:
    - `CLIENT`
    - `GROUP`
    - `LOAN_PRODUCT`
    - `SAVINGS_PRODUCT`
    - `CENTRE`
    - `BRANCH`
    - `USER`
    - `LOAN_ACCOUNT`
    - `DEPOSIT_ACCOUNT`
    encodedkey`varchar(32)`The encoded key for this document. This is an autogenerated and globally unique ID.
    filesize`bigint(20)`Size of the file in bytes
    id`bigint(20)`The id of the document
    lastmodifieddate`datetime`UTC date represents last modification date for the document
    location`varchar(256)`Location of the document where it can be found /a/b/cc.jpg
    name`varchar(256)`Document name (provided)
    originalfilename`varchar(256)`Specifies the filename
    type`varchar(256)`Extension type of the document
    ## documenttemplate > representing a document template which can be associated to an entity (ex: templates for savings or lending products). Primary key: `encodedkey`
    Column Name Data Type Description
    content`mediumtext`The actual template content as HTML.
    creationdate`datetime`The date on which this template was first created.
    encodedkey`varchar(32)`The encoded key for this document template. This
    lastmodifieddate`datetime`The date on which this template was last modified. As UTC.
    name`varchar(255)`The name of this template.
    type`varchar(32)`Indicates what this template will be available for; `TRANSACTION` or `ACCOUNT`.
    ## documenttemplatemapping > a list with templates associated to this product. Primary key: `parentkey` + `index`
    Column Name Data Type Description
    index`int(11)`The index where multiple templates are associated to the same product.
    parentkey`varchar(32)`The encoded key of a product which has assocated document templates.
    templatekey`varchar(32)`The ID of a template.
    ## duplicatefieldconstraint > stores a duplicate constraint which will be applied when saving entities. Primary key: `encodedkey`
    Column Name Data Type Description
    active`bit(1)`Whether or not this constraint is active.
    datafield`varchar(255)`Indicates the field for which these constraints will be valid. For example for a client constraint, the field may be `EMAIL_ADDRESS`, `MOBILE_PHONE_NUMBER`
    dataitemtype`varchar(255)`Indicates for which kind of entity these constraints are used, eg, `CLIENT`, `IDENTIFICATION_DOCUMENT` etc.
    duplicateclientchecks_encodedkey_own`varchar(32)`Unique key of an entry in the `generalsettings` table for which these field constraints are used.
    encodedkey`varchar(32)`A unique key for this row.
    groupindex`int(11)`Indicates whether checks are related, for example the combination of a first name and last name or a last name and a birthday.
    indexinlist`int(11)`Index for this row.
    ## emailnotificationsettings > containing the credentials and settings for the email notifications. Primary key: `encodedkey`
    Column Name Data Type Description
    emailauthentificationmethod`varchar(255)`The authentication method used for this connection. `AUTH_LOGIN` for normal username and password authentication.
    emailcredentialsprovider`varchar(255)``CUSTOM` indicates that your instance will use their own custom email settings.
    emailtransportencryptionmethod`varchar(255)`Indicates which method is used to encrypt communication between mambu and your email service provider. One of `STARTTLS` or `SSL/TLS`.
    encodedkey`varchar(32)`The encoded key for these settings.
    fromemail`varchar(255)`The email address which will appear as the sender for emails sent from your organization.
    fromname`varchar(255)`The name which as appear as the sender for emails sent by your organization.
    lastmodifieddate`datetime`The date on which these settings were last modified.
    orgemailusedasfromaddress`bit(1)`If set to true then the email address set for your organization in the `generalSettings` table is to be used as the sender email address for emails sent by your organization.
    password`varchar(255)`The password required to access the email service provider.
    replaytoemail`varchar(255)`The email address which will appear in the reply to field for emails sent by your organization.
    smtphost`varchar(255)`The url used to connect to the email service provider using smtp.
    smtpport`int(11)`The post used to connect to the email service provider using smtp
    username`varchar(255)`The username used to log in to the email service provider.
    ## entityfeaturetoggle > Some features will be released to a small number of customers as part of a beta testing phase. This table holds information on such features and whether they have been enabled for a particular mambu instance and entity. If there is an entry in this table for a given entity, the feature toggle is on for that entity.
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    entitykey`varchar(32)`The encoded key of the entity for which the toggle is put in place.
    entitytype`varchar(50)`The type of entity for which the feature is available, for example `LOAN_ACCOUNT`, `CLIENT` or `GROUP`.
    feature`varchar(256)`The feature in question.
    ## exchangerate > entity class for holding information about an exchange rate entry. the exchange rate is defined between two currencies (currently between the base currency and another available currency) and offers the rates at which the target currency is sold or bought at a given time by the organization. Primary key: `encodedkey`
    Column Name Data Type Description
    buyrate`decimal(50,20)`The rate at which the organization accepts money (e.g. incoming repayments, deposits). **Required**
    encodedkey`varchar(32)`The encoded key for this entry, this is an autogenerated and globally unique ID.
    enddate`datetime`The date when the rate ended to be valid (as Organization Time).
    fromcurrencycode`varchar(3)`The base currency used in the exchange rate. **Required**
    sellrate`decimal(50,20)`The rate at which the organization gives money (e.g. disbursals, withdrawals). **Required**
    startdate`datetime`the date when the rate starts to be used (as Organization Time). **Required**
    tocurrencycode`varchar(3)`The target currency used in the exchange rate. **Required**
    userkey`varchar(32)`The user who added the exchange rate.
    ## failedattempt > holds login failed attempts Primary key: `encodedkey`
    Column Name Data Type Description
    count`int(11)`Consecutive failed attempts count
    dates`mediumblob `Maintained in UTC. Stores dates of failed attempts.
    encodedkey`varchar(32)`The encoded key for this failed attempt, this is an autogenerated and globally unique ID used to index this table.
    type`varchar(256)`Indicates whether the login attempt was via `USERNAME` or an API Consumer key, which will have the value `IP`.
    value`varchar(255)`Value to help identify the actor behind the failed attempt eg. the username if the login form was used
    ## federatedauthenticationsettings > holds organization settings about the federation of user authentication. holds configuration, as example the url of the saml 2.0 identity provider along with a certificated in order to externalize the user authentication. check our support page for more information oin using federated authentication with mambu. Primary key: `encodedkey`
    Column Name Data Type Description
    acsurl`varchar(2048)`An optional field for added ability to use proxies when using IdP with a dedicated environemnt. This will correlate the Response with the original AuthRequest.
    certificate`varchar(4096)`The certificate from your identify provider.
    certificateexpirydate`datetime(6)`The date on which the certificate is set to expire.
    creationdate`datetime(6)`The date on which these settings were first created.
    enablesinglelogout`bit(1)`Whether Single Log Out is enabled, meaning that when a user logs out of one service, they are logged out of all services.
    encodedkey`varchar(32)`The encoded key for these settings. A unique ID
    federationstate`varchar(256)`Whether federated authentiation is `ACTIVE` or `INACTIVE` for this Mambu instance.
    federationusage`varchar(256)`Identifies the type of federation (for `REGULAR` or support users).
    idpissuerid`varchar(2048)`The issuer ID from your identity provider.
    idplogouturl`varchar(2048)`The URL for intitiating a single logout request. This field should not be changed.
    lastmodifieddate`datetime(6)`The date on which this row was last modified. As UTC.
    name`varchar(256)`The name for this connection to an identity provider.
    url`varchar(2048)`The Single Sign-on Endpoint from your identity provider.
    privateIdP`tinyint(1)`Allows you to use and configure a private IdP in the Mambu Federated Authentication module. Private IdPs are not visible or pingable on the Internet.
    isAccessible`tinyint(1)`This field marks if the IdP settings are accessible or not. This is used for Mambu delivery users as the settings should expire after a certain time period.
    deactivateDate`datetime(6)` This field marks the date when the IdP settings should automatically expire. This is used for Mambu delivery users as the settings should expire after a certain time period.
    ## fieldchangeitem > a field change log which is associated with an activity. it stores the name of the changed field, the original and the new value of the field. Primary key: `id`
    Column Name Data Type Description
    fieldchangename`varchar(256)`
    fieldchanges_encodedkey_own`varchar(32)`The `encodedkey` for a row in the `activities` table where this change was recorded.
    fieldchanges_integer_idx`int(11)`
    fielddetailkey`varchar(32)`
    fielddetailname`varchar(256)`
    id`bigint(20)`
    newvalue`mediumtext`The new value of the field.
    originalvalue`mediumtext`The original value of the field.
    ## fieldcolumn > entity for storing a datafield column into the database. Primary key: `encodedkey`
    Column Name Data Type Description
    customfieldkey`varchar(32)`If this row is relating to a custom field then this will hold the unique key of that custom field in the `customfield` table.
    datafield`varchar(255)`Field containing the information for this custom field. For example, for a group custom field this could be `NUMBER_OF_MEMBERS` or `CREDIT_OFFER_NAME`.
    dataitemtype`varchar(255)`Indicates the type of entity the configuration relates to, for example `CLIENT`, `GROUP`, `LOANS`, `SAVINGS`, `TRANSACTION`, …
    encodedkey`varchar(32)`A unique key for this row.
    fieldcolumns_encodedkey_own`varchar(32)`Points to an entry in the `columnconfiguration` table containing some settings for this column.
    fieldcolumns_integer_idx`int(11)`Index if there is more than one row in this column relating to the same entry in the `columnconfiguration` table.
    ## generalsettings > common settings for a mambu instance which are configured under the mambu admin. in here we can specify the default transaction channel key used in the organization, or the end of day processing method used. Primary key: `encodedkey`
    Column Name Data Type Description
    accountingcutofftime`varchar(256)`The cutoff time for daily accounting if one has been configured in Administration > Financial Setup > EOD Processing
    approvaldisbursaltwomanruleenabled`bit(1)`If there are required separate users for approvals and disbursals
    arrearsdaysbeforewriteooff`int(11)`Number of days that are required before an account can be written off.
    assignmentconstraints`mediumblob `List of required assignments for Clients and Groups
    automatedaccountingclosuresinterval`int(11)`The interval (number of days) between the execution of automated accounting closures. If this number is 0, no automated closure is performed. **Required**.
    clientidformat`varchar(256)`Pattern for generating client ids (uses letter & digit symbols as defined in IDGenerator)
    dateformats`mediumblob `The possible values the type of a date format can take (`DATE_FORMAT` or `DATE_TIME_FORMAT`) together with the format of the date (eg. “dd-MM-yyyy”)
    decimalseperator`varchar(256)`Whether numbers are interpreted such as "$10.20" or "$10,20" to mean 10 dollars and 20 cents.
    - `COMMA`
    - `DECIMAL`
    defaultclientrolekey`varchar(32)`Specifies the organization default client role of the current tenant.
    defaultclientstate`varchar(256)`The state that a client is set when first created
    - `PENDING_APPROVAL`
    - `INACTIVE`
    - `ACTIVE`
    - `EXITED`
    - `BLACKLISTED`
    - `REJECTED`
    defaultgrouprolekey`varchar(32)`Specifies the organization default group role of the current tenant.
    defaultlineofcreditstate`varchar(256)`The state that a line of credit is set when it’s first created
    - `PENDING_APPROVAL`
    - `APPROVED`
    - `ACTIVE`
    - `CLOSED`
    - `WITHDRAWN`
    - `REJECTED`
    defaulttransactionchannelkey`varchar(32)`Specifies the default transaction channel of the current tenant
    duplicateclientconstraintaction`varchar(255)`Action to be taken when the duplicate client validation fails
    - `NONE`
    - `WARNING`
    - `ERROR`
    enabledcomponents`mediumblob `The list of all the enabled components for the current tenant
    - `LOANS`
    - `DEPOSITS`
    - `BRANCHES`
    - `CENTRES`
    - `CLIENTS`
    - `GROUPS`
    - `ACCOUNTING`
    - `CREDIT_OFFICERS`
    encodedkey`varchar(32)`A unique key for this row.
    eodprocessingmethod`varchar(256)`Specifies EOD processing settings whether is automatic, runs every midnight or manual, runs when the client initiates the action from the interface.
    - `AUTOMATIC`
    - `MANUAL`
    exposureamount`decimal(50,10)`How much (number value) a client can have in outstanding loans with the organization at any time.
    exposuretype`varchar(256)`How much a client can have in outstanding loans with the organization at any time.
    - `UNLIMITED`
    - `SUM_OF_LOANS`
    - `SUM_OF_LOANS_MINUS_SAVINGS`
    groupidformat`varchar(256)`Pattern for generating group ids (uses letter & digit symbols as defined in IDGenerator)
    groupsizelimittype`varchar(256)`Group size limitation type
    interbranchtransferglaccountkey`varchar(32)`The key of the GL Account which will be used for inter-branch transfers.
    lineofcreditidformat`varchar(32)`Pattern for generating line of credit ids (uses letter & digit symbols as defined in IDGenerator)
    maxallowediddocumentattachments`int(11)`The maximum number of identification documents which can be attached to an entity.
    maxallowedjournalentrydocumentattachments`int(11)`The maximum number of attachments for a journal entry. **Required**.
    maxallowedundoclosureperiod`int(11)`Maximum of days we allow users to undo of close obligations met for a loan account. **Required**.
    maxgroupsizelimit`int(11)`Maximum group size allowed; null values causes ignoring of the limit.
    mingroupsizelimit`int(11)`Minimum group size allowed; null values causes ignoring of the limit.
    multiplegroupmemberships`varchar(256)`Constraint on whether clients can belong to more than one group or not.
    - `UNLIMITED`
    - `ONE_GROUP`
    multipleloans`varchar(256)`Shows if multiple loans are allowed or not:
    - `UNLIMITED`
    - `ONE_LOAN`
    otheriddocumentsenabled`bit(1)`Whether the other id documents are enabled or not
    overdraftinteresteodbalancedate`datetime`The format for displaying dates and times.
    tillidformat`varchar(256)`Pattern for generating till ids (uses letter & digit symbols as defined in IDGenerator)
    ## glaccount > for organizations with accounting enabling, this represents the general ledger account Primary key: `encodedkey`
    Column Name Data Type Description
    activated`bit(1)`Whether the account is activated and may be used. **Required**
    allowmanualjournalentries`bit(1)`Whether the gl account accepts journal entries logged manually. The default value is true.
    creationdate`datetime`The date on which the GL account was created. UTC
    currencycode`varchar(3)`Foreign key to a the Currency table.
    description`mediumtext`Detailed (text) description of the gl account
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `generalsettings`, `glaccountingrule`, `gljournalentriessummary`, `gljournalentry` and `interbranchtransferrule` tables.
    glcode`varchar(32)`Unique general ledger code for this account. **Required**
    lastmodifieddate`datetime`The date on which the GL was last modified. UTC
    migrationeventkey`varchar(32)`Foreign key to a specific Migration Event. A gl account might be imported using the Data Import feature and all the data imported from a file will be a part of a specific migration event (when this event will be reverted, all the data associated with it will be removed from the system)
    name`varchar(256)`The name of the GL account. **Required**
    striptrailingzeros`bit(1)`Whether the trailing zeros should be stripped or not when computing accounting reports for Header GL Accounts.
    type`varchar(256)`Type of GL Account. Must be one of:
    - `ASSET`
    - `LIABILITY`
    - `EQUITY`
    - `INCOME`
    - `EXPENSE`
    **Required**
    usage`varchar(256)`What the account is used for. Either a detailed account which is actually usable for deposits or as a header account which is just for display/organizational purposes. Must be one of:
    - `DETAIL`
    - `HEADER`
    **Required**
    ## glaccountingrule > holds the accounting definitions for the loan and savings product. a rule associates an accounting resource with a glaccount and also a transactionchannel with a glaccount. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    financialresource`varchar(256)`The financial resource associated with this rule.
    glaccountkey`varchar(32)`The account that is mapped to the financialResource.
    index`int(11)`Used for ordering of the product rules when they make part from a list.
    predefinedfeekey`varchar(32)`The key of the predefined fee that uses this rule. If this field is null, this rule is not used by a predefined fee.
    productkey`varchar(32)`Product key associated with this product rule.
    producttype`varchar(256)`Product type (eg: loan or savings) that is being referred to by the product key:
    - `LOAN`
    - `SAVINGS`
    transactionchannelkey`varchar(32)`The key of the transaction rule that uses this rule.
    ## glaccountsclosure > an accounts closure is used to limit backdating of accounting operations. it simulates the accounting action of "book closing". Primary key: `encodedkey`
    Column Name Data Type Description
    branchkey`varchar(32)`The branch for which the accounts were closed.
    closuredate`datetime`The date on which the closure was performed. UTC
    createdbyuserkey`varchar(32)`The ID of the user who initiated this closure.
    creationdate`datetime`The date on which this closure was first performed. UTC
    encodedkey`varchar(32)`The encoded key for this database entry.
    lastmodifieddate`datetime`The date on which this closure was last modified. Generally the notes can only be modified after a closure has been performed.
    notes`varchar(256)`Notes entered about the closure.
    trigger`varchar(256)`Indicates whether the closure was `MANUAL` or `AUTOMATIC`.
    ## gljournalentriessummary > keeps the last states of a bucket of gljournalentry unique identified by a branch, glaccount and a product. Primary key: `encodedkey`
    Column Name Data Type Description
    balance`decimal(50,10)`The balance of this journal entries summary
    branchkey`varchar(32)`The key of the assigned branch for this journal entries summary
    creationdate`datetime`UTC date for the creation time
    encodedkey`varchar(32)`The encoded key for this database entry.
    entrydate`datetime`The date for which the summary was generated (as Organization Time)
    glaccountkey`varchar(32)`The key of the assigned gl account for this journal entries summary
    type`varchar(256)`The type of the snapshot `CREDIT` or `DEBIT`
    ## gljournalentry > a journal entry is an accounting’s version of a transaction. it records an event being written to the general ledger. every entry is a credit or a debit and as part of a set of a journalentries called a transaction. within such a transaction, the debits must match the credits to ensure the balance sheets balance. Primary key: `encodedkey`
    Column Name Data Type Description
    accountkey`varchar(32)`The key to the account (loan or savings) associated with this journal action. May be null if it’s just a manual journal entry. Set only for On The Fly Closures
    amount`decimal(50,10)`Amount which was debited or credited. **Required**
    assignedbranchkey`varchar(32)`Foreign key of the branch where this journal entry was logged for.
    creationdate`datetime`Date stamp of when the transaction occured. For instance this may be when a loan repayment was actually made by the client and the entryDate would be when this was recorded in Mambu (the exact time) (UTC)**Required**
    encodedkey`varchar(32)`The encoded key for this GL journal entry.
    bookingDate`datetime`The date and time when an entry is posted to an account on the account servicer's accounting books. As **Organization Time**. **Required**
    entryid`bigint(20)`A unique auto-increment id for the gl journal entry. **Required**
    glaccount_encodedkey_oid`varchar(32)`Foreign key to the GLAccount which was debited or credit as part of this transaction. **Required**.
    notes`varchar(256)`Optional notes entered by the user when they logged the entry
    productkey`varchar(32)`The Product associated with this journal entry.
    producttype`varchar(256)`The product/account type which the accountKey is referring to. Must be one of:
    - `LOAN`
    - `SAVINGS`
    reversalentrykey`varchar(32)`Foreign key (to self) to the entry where the reversal was made. If it’s null the entry wasn’t reversed, else it contains the key of the reversal entry.
    transactionid`varchar(32)`An id for the transaction. Note that this ‘id’ is not unique for any given journal entry. Multiple journal entries may have the same transaction ID which is used for grouping them together. For instance a repayment results in multiple journal entries but will all have the same transaction ID.
    type`varchar(256)`The entry type of the Journal Entry, `DEBIT` or `CREDIT`.
    userkey`varchar(32)`Foreign key to the User who performed the journal entry (or the transaction which lead to the automatic journal entry).
    ## gljournalentryforeignamount > stores foreign currency amount for gl journal entries. Primary key: `encodedkey`
    Column Name Data Type Description
    accountingratekey`varchar(32)`The encoded key of the exchange rate between this foreign currency and the organization base currency.
    amount`decimal(50,10)`The amount in the currency specified in the `currencyCode` field.
    currencycode`varchar(3)`the ISO currency code of this journal entry.
    encodedkey`varchar(32)`The encoded key for this database entry.
    gljournalentrykey`varchar(32)`The GL journal entry that this currency conversion relates to.
    ## gljournalentryinterestaccruallog > entity directly linked to a gljournalentry used to keep track of some journal entries. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    interestaccruedaccountingmethod`varchar(255)`Indicates whether `CASH` or `ACCRUAL` accounting was used.
    lastexecutiondate`datetime`The date on which interest was last accrued. UTC
    producttype`varchar(255)`The product type that this accrual relates to. Can be either `SAVINGS` or `LOAN`.
    transactionid`varchar(255)`The ID of the transaction.
    ## gljournalentryreconciliation > A technical table which may be used when discrepancies are noticed in general ledger journal entries and need to be manually reconciled. Primary key: `encodedkey`
    Column Name Data Type Description
    accountingratekey`varchar(32)`Encoded key of an entry in the `accountingrate` table containing details of the exchange rate if the journal entry is in a different currency to the base currency.
    accountkey`varchar(32)`The key to the account (loan or savings) associated with this journal action. May be null if it’s just a manual journal entry. Set only for On The Fly Closures
    amount`decimal(50,10)`Amount which was debited or credited. **Required**
    assignedbranchkey`varchar(32)`Foreign key of the branch where this journal entry was logged for.
    creationdate`datetime`Date stamp of when the transaction occured. For instance this may be when a loan repayment was actually made by the client and the entryDate would be when this was recorded in Mambu (the exact time) (UTC)**Required**
    encodedkey`varchar(32)`The encoded key for this GL journal entry.
    entrydate`datetime`Date/time stamp when the entry was recorded. As **Organization Time**. **Required**
    entryid`bigint(20)`A unique auto-increment id for the gl journal entry. **Required**
    foreignamount`decimal(50,10)`The amount if the currency is different to the base currency.
    foreigncurrencycode`varchar(3)`The currency code if the amount is in a currency other than the base currency.
    glaccount_encodedkey_oid`varchar(32)`Foreign key to the GLAccount which was debited or credit as part of this transaction. **Required**.
    id`bigint(20)`
    notes`varchar(256)`Optional notes entered by the user when they logged the entry
    originalencodedkey`varchar(32)`The unique key of the original journal entry.
    processedflag`int(1)`Whether the current journal entry has been processed.
    productkey`varchar(32)`The Product associated with this journal entry.
    producttype`varchar(256)`The product/account type which the accountKey is referring to. Must be one of:
    - `LOAN`
    - `SAVINGS`
    reconciliationnotes`varchar(256)`Any relevant notes added during the reconciliation process.
    reversalentrykey`varchar(32)`Foreign key (to self) to the entry where the reversal was made. If it’s null the entry wasn’t reversed, else it contains the key of the reversal entry.
    transactionid`varchar(32)`An id for the transaction. Note that this ‘id’ is not unique for any given journal entry. Multiple journal entries may have the same transaction ID which is used for grouping them together. For instance a repayment results in multiple journal entries but will all have the same transaction ID.
    type`varchar(256)`The entry type of the Journal Entry, `DEBIT` or `CREDIT`.
    userkey`varchar(32)`Foreign key to the User who performed the journal entry (or the transaction which lead to the automatic journal entry).
    ## group > stores details about a group of client. a group itself contains a new and a few fields similar to those of clients. then, the relationships to the groups (between clients and groups) are described in groupmember and grouprole tables Primary key: `encodedkey`
    Column Name Data Type Description
    assignedbranchkey`varchar(32)`Foreign key to the Branch table indicating which branch the client belongs to
    assignedcentrekey`varchar(32)`Foreign key to the Centre table indicating to which centre the group belongs to.
    assigneduserkey`varchar(32)`Foreign key to the Users table indicating who the the user assigned to the client is (ie: which credit officer is responsible for them)
    clientrolekey`varchar(32)`The key of the role this group belongs to
    creationdate`datetime`The date on which this group was first created.
    emailaddress`varchar(256)`The email address of the group.
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used with our API to get details on or update a specific group.
    groupname`varchar(256)`Name of the group. **Required**
    homephone`varchar(256)`The home phone number of the group.
    id`varchar(32)`Unique id for the group. Automatically generated by Mambu when groups are stored. **Required**
    lastmodifieddate`datetime`The date on which this data relating to this group was last modified.
    loancycle`int(11)`For group which receive loans, this is the current cycle of the group loan
    migrationeventkey`varchar(32)`Foreign key to a specific Migration Event. A group might be imported using the Data Import feature and all the data imported from a file will be a part of a specific migration event (when this event will be reverted, all the data associated with it will be removed from the system)
    mobilephone1`varchar(256)`The mobile phone number of the group.
    notes`mediumtext`HTML-formatted notes about the group
    preferredlanguage`varchar(32)`The language preference for this group. Must be one of `ENGLISH`, `PORTUGUESE`, `RUSSIAN`, `SPANISH`, `FRENCH`, `CHINESE`, `GEORGIAN`, `INDONESIAN`, `ROMANIAN`, `BURMESE`, `GERMAN`.
    ## groupcustomvalue > Holds values for custom information for groups. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## groupmember > represents a join table between a group and it’s members. connects the clients & groups tables togethers Primary key: `encodedkey`
    Column Name Data Type Description
    clientkey`varchar(32)`Foreign key to the Client which this relationship describes. **Required**
    creationdate`datetime`The date on which the client was first set as a member of this group.
    encodedkey`varchar(32)`The encoded key for this database entry.
    groupkey`varchar(32)`Foreign key to the Group which this relationship describes. **Required**
    indexinlist`int(11)`Order of the client in the group clients list. That is, 0 is displayed before 1, etc.
    ## grouprole > represents a relationship of a client in a group as to what their role is. for instance a client may be a president of a group. Primary key: `encodedkey`
    Column Name Data Type Description
    clientkey`varchar(32)`Foreign key to the Client which this relationship describes. **Required**
    encodedkey`varchar(32)`The encoded key for this database entry.
    groupkey`varchar(32)`Foreign key to the Group which this relationship describes. **Required**
    grouprolenamekey`varchar(32)`Foreign key to the GroupRoleName which this relationship describes. **Required**
    indexinlist`int(11)`Indicates which position in the list of group roles this Role will occupy.
    ## grouprolename > entity holding role names for a group. example: secretary, president, etc. referred to by the grouprole table. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    name`varchar(256)`The name of the group role
    ## guaranty > entity holding information about a client guaranty entry. it can be defined based on another client which guarantees (including or not a savings account whether it is a client of the organization using mambu or not) or based on a value the client holds (an asset/collateral) Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The amount used by the client for the guaranty
    assetname`varchar(256)`The name of a value the client guarantees with (populated when the guaranty type is `ASSET`)
    discriminator`varchar(32)`
    encodedkey`varchar(32)`A unique key for this row.
    funds_encodedkey_own`varchar(32)`The unique key of an entry in the `loanaccount` table for which this guaranty has been provided when this guaranty is used as a funding source for the account.
    funds_integer_idx`int(11)`Index if there is more than one guaranty for the same loan account.
    guarantees_encodedkey_own`varchar(32)`The unique key of an entry in the `loanaccount` table for which this guaranty has been provided.
    guarantees_integer_idx`int(11)`Index if there is more than one guaranty for the same loan account.
    guarantorkey`varchar(32)`The key of the client used as the guarantor (populated when the guaranty type is `GUARANTOR`)
    guarantortype`varchar(255)`The type of the guarantor (`CLIENT` or `GROUP`)
    id`varchar(32)`Investor fund identifier. All versions of an investor fund will have same id.
    interestcommission`decimal(50,20)`The Interest commission that is used for funds.
    investmentpercentage`decimal(50,20)`The investment percentage to be considered for collection of amounts upon repayment for this investor fund
    savingsaccountkey`varchar(32)`The key of the savings account used by the guarantor (populated when the guaranty type is `GUARANTOR`). It can be null
    state`varchar(255)`Starting with P2P fractionalization, this entity is also used to hold the history of an investment fund. Having
    multiple versions, the state is one of the fields that can differentiate or give information regarding the
    investment fund. Must be one of:
    - `PENDING` - Default state for the investor fund.
    - `ACTIVE` - State for the case when the loan amount has been funded.
    - `PARTIALLY_BOUGHT` - Partially bought state for an investor fund for which a newer version exists due to buying amount
    - `PARTIALLY_SOLD` - Partially sold state for an investor fund for which a newer version exists due to selling amount
    - `CLOSED` - State denoting the fact that the fraction itself is closed (the loan is closed)
    - `REVERTED` - State for the case when this specific Investor entry should be ignored as it was reverted.
    - `TOTALLY_SOLD` - State for the case when the Investor sells the loan fraction entirely.
    type`varchar(256)`Guaranty type
    - `GUARANTOR` - Value used when the guaranty is created using a client (guarantor)
    - `ASSET` - Value used when the guaranty is created using an asset
    validfrom`datetime`The date when the investor started funding the loan account (Organization time)
    validuntil`datetime`The date when the investor stopped funding the loan account (Organization time)
    ## guarantycustomvalue > Holds values for custom information for loan guarantees. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## holiday > stores details about user-defined holidays which affect things like repayment scheduling. Primary key: `encodedkey`
    Column Name Data Type Description
    branchholidays_encodedkey_own`varchar(32)`If this holiday applies to one branch only this field will contain that branch’s encoded key.
    branchholidays_integer_idx`int(11)`The number in the list of holidays applying only to a single branch. The first will be 0, the second 1 and so on. If a holiday is general and does not only apply to one specific branch this index will be -1.
    creationdate`datetime`The time at which this holiday was added to the system.
    dayofmonth`int(11)`The day of the month on which this holiday falls.
    encodedkey`varchar(32)`The encoded key for this holiday.
    generalholidays_encodedkey_own`varchar(32)`If this holiday applies to all branches this is the encoded key of the general settings for the organization.
    generalholidays_integer_idx`int(11)`The index in the list of general holidays. The first will have index 0, the second 1 and so on. If a holiday is not general and instead only applies to a specific branch, its index will be -1.
    isannualyrecurring`bit(1)`Whether or not this is a yearly repeating holiday.
    keyid`bigint(20)`An internal ID stored for portability reasons.
    monthofyear`int(11)`The month on which this holiday falls as integer, ie. 1 is January, 7 is July.
    name`varchar(256)`The name of this holiday.
    year`int(11)`The year on which this holiday falls.
    ## identificationdocument > stores identification documents associated with individual clients. a client may have an number of identification documents Primary key: `encodedkey`
    Column Name Data Type Description
    clientkey`varchar(32)`Foreign key to Client to which this identification document belongs to. **Required**.
    documentid`varchar(256)`The document id such as the Passport # (“ABC123”)
    documenttype`varchar(256)`Type of document: eg: Passport
    encodedkey`varchar(32)`The encoded key for this document, this is an autogenerated and globally unique ID.
    identificationdocumenttemplatekey`varchar(32)`Points to the entry in the `identificationdocumenttemplate` table that corresponds to this ID; ie. if this document is a passport, it will point to the template for passports.
    indexinlist`int(11)`Order of the ID document if the parent holder has multiple documents (for display/formatting purposes). That is, 0 is displayed before 1, etc.
    issuingauthority`varchar(256)`Who issued this document (Such as “Government”)
    validuntil`datetime`Expiry date of the document (Organization Time)
    ## identificationdocumenttemplate > represents a template for identification documents, which defines default document type, issuing authority and adds a constraint to the identification document id. Primary key: `encodedkey`
    Column Name Data Type Description
    allowattachments`bit(1)`Whether this template allow files to be attached or not.
    documentidtemplate`varchar(256)`The document id template constraint, that contains letters (@) and digits (#) symbols used to validate the id and can also contain any other static character.
    documenttype`varchar(256)`Type of document: eg: Passport.
    encodedkey`varchar(32)`The encoded key for this template, this is an autogenerated and globally unique ID.
    issuingauthority`varchar(256)`Who issued this document (Such as “Government”).
    mandatoryforclients`bit(1)`Whether this template it’s mandatory for all the clients or not.
    ## image > stores an image which can be used in mambu in various places such as displaying client profile photos. images are stored in multiple sizes depending on the display needs. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`UTC creation date
    description`mediumtext`Description of the image contents
    encodedkey`varchar(32)`The encoded key for this image, this is an autogenerated and globally unique ID.
    largeimage`mediumblob `Image data up to 750px in the longest dimension. **Required**
    largeimagelocation`varchar(256)`The location of large images, which may be held in a service such as Amazon Web Services S3 or Google Cloud Platform equivalent if the file size is particularly large.
    lastmodifieddate`datetime`Last modified date. As UTC
    mediumimage`mediumblob `Image data up to 300px in the longest dimension**Required**
    mediumimagelocation`varchar(256)`The location of medium sized images, which may be held in a service such as Amazon Web Services S3 or Google Cloud Platform equivalent if the file size is particularly large.
    smallthumbnail`mediumblob `Image data exactly 50px by 50px in size**Required**
    smallthumbnaillocation`varchar(256)`The location of image thumbnails, which may be held in a service such as Amazon Web Services S3 or Google Cloud Platform equivalent if the file size is particularly large.
    tinythumbnail`mediumblob `Image data exactly 32px by 32px in size. **Required**
    tinythumbnaillocation`varchar(256)`The location of tiny thumbnail images, which may be held in a service such as Amazon Web Services S3 or Google Cloud Platform equivalent if the file size is particularly large.
    title`varchar(256)`Name of the image
    type`varchar(256)`This is is the sdrfaqwesraserffafweefr asde as. May be one of: ‘png’, ‘jpeg’, ‘gif’, etc. **Required**
    ## importedreport > more complex reports can be created via jaspersoft studio and imported into mambu. this table contains information on such reports. Primary key: `encodedkey`
    Column Name Data Type Description
    accessiblebyallusers`bit(1)`Indicates whether all users can access this report.
    createdbyuserkey`varchar(32)`Encoded key of the user who imported this report.
    creationdate`datetime`Date on which this report was first imported.
    dataitemtype`varchar(256)`The type of Mambu entity that is reported on, for example `LOAN_ACCOUNT`, `SAVINGS_TRANSACTION` or `CLIENT`.
    description`mediumtext`A description of the report that has been provided as HTML.
    encodedkey`varchar(32)`The encoded key of this imported report used as the primary key for this table.
    index`int(11)`
    lastmodifieddate`datetime`The date on which this report was last modified. As UTC.
    name`varchar(256)`The name of the report.
    productkey`varchar(32)`If the report relates to a specific loan or deposit product the encoded key of that product will be linked here.
    reportfile`mediumblob `The actual jrxml file containing this Jaspersoft Studio report.
    rolekeys`mediumblob `The list of roles who have been granted permission to view this report.
    type`varchar(256)`The type of report, eg. `JASPER` for a report created with Jaspersoft Studio.
    ## importedreportcode
    Column Name Data Type Description
    codeexpressions`mediumtext`
    encodedkey`varchar(32)`A unique key.
    importedreportkey`varchar(32)`
    jasperlanguages`varchar(256)`
    name`varchar(256)`
    sqlstatements`mediumtext`
    ## indexrate > index value used as a base interest rate in some organizations for the calculation of the loan interest rate as relative to this value. the amount they give it out for is fixed, but they or an external source such as the government, etc, may change the base interest rate and this means that the loans need to be updated so that the interest rate value should be changed as well. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this index rate, this is an autogenerated and globally unique ID.
    indexinterestratesource_encodedkey_oid`varchar(32)`The encodedkey of the entry in the `indexratesource` table which serves as the source for this index rate.
    notes`mediumtext`Comments
    rate`decimal(50,10)`The value of the index interest rate
    startdate`datetime`The date from when this index should be used (Organization Time)
    userkey`varchar(32)`The key of the user who added this index interest rate
    ## indexratesource > the set of possible sources for an index interest rate that can come from (ex: one source may be libor) or for a tax rate. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this source, this is an autogenerated and globally unique ID and can be used with our API to get details on a specific Index Rate Source. This ID is also used as a foreign key in a number of other tables including the `loanproduct`, `savingsaccount`, `interesrate` and `interestproductsettings` tables.
    name`varchar(256)`Name of the rate source
    notes`mediumtext`Comments
    type`varchar(256)`The types of the Index rate source currently in use by both Loan and Savings products and accounts.
    Values
    - `INTEREST_RATE` - Percentage applied on top of the interest
    - `TAX_RATE` - Rate percentage applied for calculating the taxes
    - `WITHHOLDING_TAX_RATE` - Rate percentage applied for calculating the taxes for a Savings Product (the Withholding ones)
    ## interbranchtransferrule > class for associating inter branch gl accounts. the relation between the branches is bidirectional, depending on the actual accounting action. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    glaccountkey`varchar(32)`The general ledger account
    leftbranchkey`varchar(32)`Returns the encoded key of the left branch. A value of null means ‘Unassigned’.
    rightbranchkey`varchar(32)`Returns the encoded key of the right branch. A value of null means ‘Unassigned’.
    ## interestaccountsettings > class for all the entities grouping settings related to how is the interest accrued and applied Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this set of settings, this is an autogenerated and globally unique ID.
    interestrate`decimal(50,20)`The rate based on which the interest is accrued and applied for accounts with fixed interest rate
    interestspread`decimal(50,20)`The rate based on which the interest is accrued and applied for accounts with index interest rate
    ## interestbasesettings > base class for all the entities grouping settings related to how is the interest accrued and applied Primary key: `encodedkey`
    Column Name Data Type Description
    accrueinterestaftermaturity`bit(1)`If the product support this option, specify if the interest should be accrued after the account maturity date.
    encodedkey`varchar(32)`The encoded key for this set of settings, this is an autogenerated and globally unique ID.
    interestchargefrequency`varchar(255)`The interval used for determining how often is interest charged (e.g. x [weeks])
    interestchargefrequencycount`int(11)`The count of units to apply over the interval (e.g. [x] weeks)
    interestratereviewcount`int(11)`Interest rate review frequency unit count
    interestratereviewunit`varchar(255)`Interest rate review frequency measurement unit
    interestratesource`varchar(255)`Interest calculation method: fixed or (interest spread + active organization index interest rate)
    interestrateterms`varchar(256)`The option for how is the interest rate determined when being accrued for an account. **Required**
    ## interestproductsettings > base class for all the entities grouping settings related to how is the interest accrued and applied Primary key: `encodedkey`
    Column Name Data Type Description
    allownegativeinterestrate`tinyint(1)`Whether the interest rate for this product is allowed to go into negative.
    compoundingfrequency`varchar(32)`How often interest compounds for this product.
    defaultinterestrate`decimal(50,20)`Default interest rate(for fixed interest rate)/spread(for index interest rate) used by the product
    encodedkey`varchar(32)`The encoded key for this set of settings, this is an autogenerated and globally unique ID.
    indexsourcekey`varchar(32)`Index rate source key for the product
    interestrateceilingvalue`decimal(50,20)`Interest spread + index interest rate can’t be more than this amount (valid only for index interest rate products)
    interestratefloorvalue`decimal(50,20)`Interest spread + index interest rate can’t be less than this amount (valid only for index interest rate products)
    maxinterestrate`decimal(50,20)`Maximum interest rate(for fixed interest rate)/spread(for index interest rate) used by the product
    mininterestrate`decimal(50,20)`Minimum interest rate(for fixed interest rate)/spread(for index interest rate) used by the product
    ## interestratechanges > table which stores interest rate changes on deposit accounts with fixed rate terms. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    endingday`int(11)`The day on which this interest rate stopped applying.
    interestaccountsettingskey`varchar(32)`The `encodedkey` of an entry in the `interestaccountsettings` table containing the settings for the deposit account whose interest rate changed.
    interestrate`decimal(50,20)`The value of the interest rate.
    ## interestratetier > useful for tiered interest rates, holds the values to define how is the interest computed for one of this steps. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this interest rate tier.
    endingbalance`decimal(50,10)`The top-limit value for the account balance in order to determine if this tier is used or not
    endingday`int(11)`The top-limit value for the account period since activation in order to determine if this tier is used or not
    index`int(11)`The index of the interest rate tier.
    interestrate`decimal(50,20)`The rate used for computing the interest for an account which has the balance less than the ending balance
    interestratetiers_encodedkey_own`varchar(32)`Foreign key to an entry in the `interestbasesettings` table which used this tier.
    interestratetiers_integer_idx`int(11)`The index for this tier, ie. the first tier will be 0, the second 1 and so on.
    ## lineofcredit > a maximum loan amount that can be approved or disbursed for a client or a group. it is a limit also for the period under which the clients/groups are allowed to make loans or overdrafts. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The amount that client can be exposed to.
    approveddate`datetime`The date when the line of credit was approved if the LOC wasn’t approved yet. Stored as Organization Time. Nullable
    clientkey`varchar(32)`The key of the client associated with the line of credit
    closeddate`datetime`The date when the line of credit was closed (Organization Time)
    creationdate`datetime`Creation date UTC
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    expiredate`datetime`Expire date of this line of credit; after this date no other loans/overdrafts (Organization Time)
    exposurelimittype`varchar(256)`The calculation method for exposure limit:
    - `APPROVED_AMOUNT`
    - `OUTSTANDING_AMOUNT`
    groupkey`varchar(32)`The key of the group associated with the line of credit
    id`varchar(32)`Auto generated unique ID based on pattern defined in GeneralSettings for the line of credit that can be used for identifying the Line Of Credit or for fetching lines of credit from API calls
    lastmodifieddate`datetime`The date when the line of credit was modified - UTC
    notes`mediumtext`Comments
    startdate`datetime`The line of credit start date(UTC) - it must not be null. Represents the starting date from which the line of credit becomes active
    state`varchar(256)`The state of the line of credit:
    - `PENDING_APPROVAL`
    - `APPROVED`
    - `ACTIVE`
    - `CLOSED`
    substate`varchar(256)`The sub state of the Line of Credit
    - `WITHDRAWN`
    - `REJECTED`
    ## lineofcreditcustomvalue > Holds values for custom information for lines of credit, also referred to as credit arrangements. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## livemigrationprocess > An internal table to track the status of various jobs which will be carried out as part of the release process for new features, for example, when new fields are added to entities, new methods of interest calculation are added or a feature was enabled for your Mambu instance. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    enddate`datetime`The time at which the process was completed in UTC.
    iscleanupdone`bit(1)`Whether the cleanup process was completed successfully after the migration was completed.
    numfailedentities`bigint(20)`The number of entities for which the migration process failed for any reason.
    numsuccessfulentities`bigint(20)`The number of entities which were successfully processed as part of this migration.
    startdate`datetime`The date and time, in UTC, at which this process was started. Generally, this will be the rollout date and time of the version containing the feature mentioned in the `type` field.
    type`varchar(128)`A human readable name for this process.
    ## loanaccount > stores a loan account or a loan application (which is just a loan account which is not yet active). a loan account always belongs to a client or group and must be of a certain loan product type. loan accounts store the detailed breakdown of the amounts due & paid. this is redundant and must match with the amounts for all the repayments for the accounts. like clients and groups, loan accounts are also assigned to users (credit officers) and branches. Primary key: `encodedkey`
    Column Name Data Type Description
    accountarrearssettingskey`varchar(32)`Arrears settings available for the current account.
    accountholderkey`varchar(32)`Foreign key reference to the Client or Group which is holding on this account. **Required**
    accountholdertype`varchar(256)`The type of account holder this group has. Must be one of the following:
    - `CLIENT`
    - `GROUP`
    and direct to the key referred to by accountHolderKey
    **Required**
    accounts_integer_idx`int(11)`
    accountstate`varchar(256)`The current state of the loan account. Must be one of the following:
    - `PARTIAL_APPLICATION` - account has not yet been approved and is pending more information (in draft form)
    - `PENDING_APPROVAL` - account is ready to be approved by users with permission to do so
    - `APPROVED` - account has been approved and is now ready to be disbursed to the client
    - `ACTIVE` - account has been been disbursed and is now active and in good standing
    - `ACTIVE_IN_ARREARS` - the account has been disbursed and is active but is in arrears (e.g.: has repayments which are late)
    - `CLOSED` - the account is no longer active (see accountSubState field for sub-states)
    - `CLOSED_WRITTEN_OFF` - Account has been closed and any remaining balance due has been written off
    - `CLOSED_REJECTED` - Account has gone through the application process and has been rejected
    **Required**
    accountsubstate`varchar(256)`This field holds a second state for the account. Must be one of the following:
    - `PARTIALLY_DISBURSED` - Related to `ACTIVE` state; the account is only partially disbursed.
    - `REFINANCED` - Related to `CLOSED` state; the account was closed and refinanced.
    - `RESCHEDULED` - Related to `CLOSED` state; the account was closed and further rescheduled.
    - `WITHDRAWN` - Related to `CLOSED` state; the account was closed before activation.
    - `LOCKED` - Related to `ACTIVE` or `ACTIVE_IN_ARREARS` states; the account is locked and may not be used further unless unlocked, in this state; no amount is **automatically** applied to the account, ie. no **automatic** interest is applied, fees, penalties or transfer transactions logged; interest **is accrued**; rate change transactions **are logged**.
    - `LOCKED_CAPPING` - Related to `ACTIVE_IN_ARREARS` state; an account will be set to this substate when it is in arrears and the total owed for interest, fees and penalties has exceeded the threshold allowed by your organization’s risk settings. Please see our article on internal controls for more information on managing thresholds and what is and is not possible when an account is in this substate.
    accruedinterest`decimal(50,10)`How much interest has accrued to the account but is not yet posted
    accruedpenalty`decimal(50,10)`Specifies the amount of penalty that has been accrued in the account
    accrueinterestaftermaturity`bit(1)`If the product support this option, specify if the interest should be accrued after the account maturity date
    accruelateinterest`bit(1)`Indicates whether the option to continue to accrue interest after the repayment date for late payments. See our support article for more information on this subject.
    activationtransactionkey`varchar(32)`The key of the transaction that activated this account
    allowoffset`bit(1)`Specify if the account is allowing offset links
    applyinterestonprepaymentmethod`varchar(256)`Apply interest on prepayment method copied from loan product on which this account is based.
    approveddate`datetime`The date when the loan account has been approved. Stored as Organization Time.
    arrearstoleranceperiod`int(11)`The tolerance period, in days, before an account will be marked as being arrears.
    assignedbranchkey`varchar(32)`Foreign key to the Branch that this account is assigned to
    assignedcentrekey`varchar(32)`Foreign key to the Centre table indicating to which centre the loan account belongs to.
    assigneduserkey`varchar(32)`Foreign key to the User (Credit Officer) who is assigned to his account
    closeddate`datetime`Date when the account was closed or null if never closed (OrganizationTime)
    creationdate`datetime`The date when the account was created. Stored as UTC
    defaultfirstrepaymentduedateoffset`decimal(50,20)`The amount of days which will be automatically added to the first repayment date. So if, for example, this number is 5 and repayments should be made on the 1st of the month, the **first** repayment will instead be scheduled for the 5th.
    disbursementdetailskey`varchar(32)`The key of an entry in the `disbursementdetails` table containing information about the disbursement of this loan account.
    elementsrecalculationmethod`varchar(256)`the method by which individual elements will be recalculated
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used with our API to get details for or update a specific Loan Account. This field should not be changed as it is used as a foreign key to link with other tables.
    feesbalance`decimal(50,10)`How much fees are still due on the account (relevant for fixed accounts only)
    feesdue`decimal(50,10)`The total fees due for this loan account. **Required**
    feespaid`decimal(50,10)`The total fees paid for this loan account. **Required**
    fixeddaysofmonth`mediumblob `Specifies the days of the month when the repayment due dates should be. Only available if the Repayment methodology is `FIXED_DAYS_OF_MONTH`
    futurepaymentsacceptance`varchar(256)`Whether or not a customer can pay in advance. Will be one of `ACCEPT_OVERPAYMENTS` or `NO_FUTURE_PAYMENTS`.
    graceperiod`int(11)`Grace period for the loan account in the number of installments. Ignored if grace period is none or null.
    graceperiodtype`varchar(256)`
    Type of Grace period or null if no grace period. Must be one of:
    - `NONE`
    - `PAY_INTEREST_ONLY` - interest is charged and paid for the repayments (but capital repayment is 0)
    - `INTEREST_FORGIVENESS` - interest is neither charged nor paid. a pure grace period
    hascustomschedule`bit(1)`Flag used when the repayments schedule for the current account was determined by the user, by editing the due dates or the principal due
    holdbalance`decimal(50,10)`The amount currently being held for pending card transactions. See our support page for more information.
    id`varchar(32)`Unique ID of the loan account. **Required**
    interestapplicationmethod`varchar(256)`The method used by the loans defining how the interest gets applied
    - `ON_DISBURSEMENT` - All the interest amount gets applied only once, on disbursement time. There is no way of applying interest manually, through the cron jobs, or when performing repayments
    - `ON_REPAYMENT` - The interest gets applied on each repayment and there are multiple ways of performing this. There is an accrued interest, which gets accumulated every day, this determining how much interest needs to be applied on the repayments. The interest can be applied by the cron jobs in the due date of a repayment. The interest can also be applied manually: behind the scenes, when performing a repayment or explicitly by using the UI function available for this.
    interestbalance`decimal(50,10)`The total interest currently owed and outstanding for the client (total interest accrued for account - interest paid)
    interestbalancecalculationmethod`varchar(32)`Option which determines the way the balance for the account’s interest is computed.
    interestcalculationmethod`varchar(256)`The method used for calculating the interest on this loan account. Must be one of:
    - `FLAT`
    - `DECLINING_BALANCE`
    - `DECLINING_BALANCE_DISCOUNTED` - also known as the french declining balance method
    **Required**
    interestchargefrequency`varchar(256)`Defines how the interest is charge on this loan account. For instance if the interest rate is 5% and the charge frequency is EVERY_DAY then 5% is charged every day to this account when determining the repayment schedule. Must be one of:
    - `ANNUALIZED` - annual repayment schedule (1/yr)
    - `EVERY_MONTH` - monthly interest (12/yr)
    - `EVERY_FOUR_WEEKS` - interest calculated every 4 weeks (13/yrs)
    - `EVERY_DAY` - interest calculate every day (365/yr)
    **Required**
    interestcommission`decimal(50,20)`The value of the interest booked by the organization from the accounts funded by investors. Null if the funds are not enabled.
    interestdue`decimal(50,10)`How much interest it’s due for the account at this moment. **Required**
    interestfromarrearsaccrued`decimal(50,10)`The amount of interest from arrears that has been accrued in the account
    interestfromarrearsbalance`decimal(50,10)`the total interest from arrears which is currently owed and outstanding for this account, (total interest from arrears due - interest from arrears paid)
    interestfromarrearsdue`decimal(50,10)`how much interest from arrears is due for the account at this moment
    interestfromarrearspaid`decimal(50,10)`total interest from arrears paid into the account
    interestpaid`decimal(50,10)`The total interest paid for this loan account. **Required**
    interestrate`decimal(50,20)`The interest rate for the loan account. See the charge frequency for how it is used. **Required**
    interestratereviewcount`int(11)`Indicates how often the index rate for this account should be reviewed in the units specified in the `interestratereviewunit` column.
    interestratereviewunit`varchar(256)`The unit (`DAYS`, `WEEKS`, `MONTHS`) indicating how often the index rate should be checked.
    interestratesource`varchar(256)`Whether the account uses a default `FIXED_INTEREST_RATE` or is linked to an `INDEX_INTEREST_RATE`
    interestroundingversion`varchar(256)`Holds the possible values for the version of the algorithm used for applying rounding on the loan accounts interest values:
    - `VERSION_1`
    - `VERSION_2`
    - `VERSION_3`
    interestspread`decimal(50,10)`Interest to be added to active organization index interest rate in order to find out actual interest rate
    interesttype`varchar(255)`The loan account interest type. Must be one of the following:
    - `SIMPLE_INTEREST` - the interest is applied on the schedule when it is applied in the account
    - `CAPITALIZED_INTEREST` - the interest is capitalized on the schedule. It will be converted into principal when applied
    lastaccountappraisaldate`datetime`When/if the account had last been evaluated for interest, principal, fees and penalties calculations (UTC)
    lastinterestapplieddate`datetime`Last date when interest was applied (posted) to the account (Organization Time)
    lastinterestreviewdate`datetime`The date on which the last review was carried out for accounts using an index interest rate.
    lastlockeddate`datetime`Date when the account was set for the last time in the `LOCKED` sub-state. If null, the account is not locked anymore or it was never locked (OrganizationTime).
    lastmodifieddate`datetime`The date when the account was modified the last time. Stored as UTC.
    lastsettoarrearsdate`datetime`Date when the account was last set to In Arrears standing or null ifnever set (Organization Time)
    lasttaxratereviewdate`datetime`When/if the account had last tax rate checked (as Organization Time)
    latepaymentsrecalculationmethod`varchar(256)`Method used by loan accounts to have the schedule recalculated when late payments are posted on declining balance equal installments accounts: `LAST_INSTALLMENT_INCREASE` - this option will only recalculate the interest due for the next installment (the one where the extra interest caused by the late payment, will be added) and `OVERDUE_INSTALLMENTS_INCREASE` - this option will recalculate all the next installments, in order to keep the same total expected on the installments.
    lineofcreditkey`varchar(32)`The key to the line of credit where this account is registered
    loanamount`decimal(50,10)`The original loan amount given out to the client. **Required**
    loangroup_encodedkey_oid`varchar(32)`The loan group this account belongs to (if part of a hybrid loan account or null otherwise).
    loanname`varchar(256)`Display name of the loan account. Often just the same as the product name. **Required**.
    loanpenaltycalculationmethod`varchar(256)`Specifies on what amount are the penalties calculated (Eg. `OVERDUE_BALANCE`, `OVERDUE_BALANCE_AND_INTEREST`)
    lockedoperations`mediumblob `A list with operations which are locked when the account is in `LOCKED` sub-state:
    - `APPLY_INTEREST`
    - `APPLY_FEES`
    - `APPLY_PENALTIES`
    migrationeventkey`varchar(32)`Foreign key to a specific Migration Event. A loan account might be imported using the Data Import feature and all the data imported from a file will be a part of a specific migration event (when this event will be reverted, all the data associated with it will be removed from the system)
    notes`mediumtext`HTML notes and details about this loan account/application
    paymentmethod`varchar(256)`The method used by the loans defining how the payments get performed
    - `HORIZONTAL` - The payment is done horizontally, on the repayments, following the repayment allocation elements order.
    - `VERTICAL` - The payment is done vertically, into the account, following the repayment allocation elements order.
    penaltybalance`decimal(50,10)`How much fees are still due on the account (relevant for fixed accounts only)
    penaltydue`decimal(50,10)`The total penalty due for this loan account. **Required**
    penaltypaid`decimal(50,10)`The total penalty paid for this loan account. **Required**
    penaltyrate`decimal(50,20)`Specifies the rate (in percent) which is charged as a penalty
    periodicpayment`decimal(50,10)`The periodic payment amount for the accounts which have balloon payments
    prepaymentacceptance`varchar(256)`Whether the pre-payments are allowed or not for this account
    Must be one of the following:
    - `ACCEPT_PREPAYMENTS` - The pre-payments can be posted
    - `NO_PREPAYMENTS` - No pre-payments are accepted (no repayments posting before due)
    prepaymentrecalculationmethod`varchar(255)`repayment recalculation method copied from the loan product on which this account is based. Holds the possible options for how are the pre-payments affecting the number of installments and the amount allocated per installment for a repayments schedule belonging to a DYNAMIC loan account
    - `NO_RECALCULATION`
    - `RESCHEDULE_REMAINING_REPAYMENTS`
    - `RECALCULATE_SCHEDULE_KEEP_SAME_NUMBER_OF_TERMS`
    - `RECALCULATE_SCHEDULE_KEEP_SAME_PRINCIPAL_AMOUNT`
    - `RECALCULATE_SCHEDULE_KEEP_SAME_TOTAL_REPAYMENT_AMOUNT`
    - `REDUCE_AMOUNT_PER_INSTALLMENT`
    - `REDUCE_NUMBER_OF_INSTALLMENTS`
    principalbalance`decimal(50,10)`The total principal currently owed and outstanding for the client for this account (principal disbursed - principal paid)
    principaldue`decimal(50,10)`How much principal is currently due for this account. **Required**
    principalpaid`decimal(50,10)`Total principal paid into the account
    principalpaidinstallmentstatus`varchar(255)`Defines the installment status after the principal was paid off as part of an over-payment.
    - `PARTIALLY_PAID`
    - `PAID`
    - `ORIGINAL_TOTAL_EXPECTED_PAID`
    principalpaymentsettingskey`varchar(32)`Points to an entry in the `principalPaymentSettings` table containing further settings for this account.
    principalrepaymentinterval`int(11)`Once at how many repayments has the principal to be paid.
    producttypekey`varchar(32)`Foreign Key to the LoanProduct with which this account was created. **Required**
    redrawbalance`decimal(50,10)`The total redraw amount available to the client
    repaymentinstallments`int(11)`How many installments are required to pay back the loan. Must be same number as number of repayments when loan is initially disbursed. **Required**
    repaymentperiodcount`int(11)`How often the loan is to be repaid. for instance “1” with the unit being “Days” means every day. Determines the repayment schedule. **Required**
    repaymentperiodunit`varchar(256)`Unit in which the repaymentPeriodCount is being represented. Must be one of:
    - `DAYS` - repaid on a daily basis
    - `WEEKS` - repaid every x weeks
    - `MONTHS` - repaid every x months
    - `YEARS` - repaid every x years
    **Required**
    repaymentschedulemethod`varchar(256)`The method used by the loans to compute the repayment schedule
    - `FIXED` - The repayment schedule is fixed and doesn’t change all over the loan account’s lifecycle. More detailed, the principal and interest due which get computed for each repayment doesn’t ever change, even if a repayment is pre-paid or paid later. Penalties and fees can be applied only on repayments. Still, reduction operations can be performed over the principal, interest, fees and penalties amounts (only with special settings enabled)
    - `DYNAMIC` - The repayment schedule is dynamic and will change over the loan account’s lifecycle e.g. when entering repayments, on holidays changes or interest rates changes. For example, if paying an amount greater that what is due at a given time will cause the interest balance to be recomputed and will be lower that the amount initially computed. Penalties and fees can be applied only straight into the account
    rescheduledaccountkey`varchar(32)`Foreign key to another LoanAccount if this account has been closed with state `CLOSED_RESCHEDULED`. Or null if not rescheduled
    scheduleduedatesmethod`varchar(256)`The methodology used by this product to compute the due dates of the repayments
    - `INTERVAL` - the repayments will be made on a specified interval (e.g. Every 2 Months)
    - `FIXED_DAYS_OF_MONTH` - The repayments will be made each month on some given dates (for example, each month on 10th and 20th means that each month there will be two installments, one made on 10 of that month and one on 20)
    shortmonthhandlingmethod`varchar(256)`Determines how to handle the short months, if they select a fixed day of month > 28. Will be null if no such date is selected and also for the Interval methodology. Only available if the Repayment Methodology is `FIXED_DAYS_OF_MONTH`
    taxrate`decimal(50,10)`The current tax rate of the account
    ## loanaccount_billingcycledays > Holds the day on which the billing cycle rolls over for revolving credit type loans. Primary key: `accountkey` + `days`
    Column Name Data Type Description
    accountkey`varchar(32)`The encoded key of the revolving credit account.
    day`tinyint(2)`The day on which the billing cycle rolls over each month.
    ## loanaccount_repaymentdays > Holds days on which repayments will become due for loan accounts. Primary key: `accountkey` + `days`
    Column Name Data Type Description
    accountkey`varchar(32)`The encoded key of a loan account.
    day`tinyint(2)`The day of the month on which loan repayments become due.
    ## loanaccountchangedevent Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The key for this database entry
    ## loanaccountcustomvalue > Holds values for custom information for loan accounts. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## loanaccountnumericid
    Column Name Data Type Description
    numericid`decimal(32,0)`The numeric ID of a given loan account.
    ## loanaccountredrawsettings > this table relates an upcoming feature and will be documented closer to release. Primary key: `encodedkey`
    Column Name Data Type Description
    accountkey`varchar(32)`Unique key of the entry in the `loanaccount` table for which these redraw settings are valid.
    encodedkey`varchar(32)`A unique key for this row.
    restrictnextduewithdrawal`tinyint(1)`Indicates whether withdrawing amounts that reduce the next due instalment repayment is restricted or not.
    ## loangroup > for the hybrid group product type, this is the model which captures the relationship between a group any any number of loan accounts. a loan group is simply a logical grouping of loan accounts. in the hybrid model, all loan accounts must have the same properties, repayment schedules, etc except that they may have different amounts. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date on which this loan group was created. UTC
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    group_encodedkey_oid`varchar(32)`Foreign key of the Group that this loan group belongs to **Required**.
    lastmodifieddate`datetime`The date on which this loan group was last modified. UTC
    name`varchar(256)`Name of the loan group. **Required**
    notes`mediumtext`HTML Notes about the loan group.
    ## loanproduct > stores templates that specify some predefined information and constraints that are then applied to the loan accounts, associated with the loan products. each loan account has to use one product. products can be defined for individuals, pure groups or hybrid groups, can specify a default amount, interest rate, number of installments and also can constrain these fields to some minimum and maximum values. it also defines the interest details and the repayments frequency. Primary key: `encodedkey`
    Column Name Data Type Description
    accountingmethod`varchar(256)`The current accounting state for this product
    - `NONE` - accounting is deactivated
    - `CASH` - uses cash accounting
    - `ACCRUAL` - uses accrual accounting
    accountinitialstate`varchar(32)`Specifies the initial states for the accounts that will be created using this product.
    Available states:
    - `PENDING_APPROVAL`
    - `PARTIAL_APPLICATION`
    - etc.
    accountlinkingenabled`bit(1)`Whether this product can be linked to others
    accruelateinterest`bit(1)`Indicates whether this product continues to accrue intersest on late payments, see here for more details.
    activated`bit(1)`Whether this loan product is activated or not (can be used or not).
    allowarbitraryfees`bit(1)`Only if true users will be able to apply fees, for current object, of type ‘Other’; these fees can have any amount
    allowcustomrepaymentallocation`bit(1)`Indicates whether a customer will be allowed to freely allocate repayments or parts of repayments towards specific costs. See our support article for more information.
    amortizationmethod`varchar(32)`Method used by loan accounts for repayments schedule generation. It indicates whether the user wants to define a periodic payment, and round the remaining principal into the last installment, or they want to allocate the whole principal on the schedule
    - `STANDARD_PAYMENTS` - This option will allow spreading the whole principal amount over the repayments schedule
    - `BALLOON_PAYMENTS` - This option will allow the user defining a periodic payment amount, which will be used on all the installments, except the last one where the remaining principal amount will be posted
    applyinterestonprepaymentmethod`varchar(256)`Whether the interest on prepayment is applied manual or automatic.
    arrearssettingskey`varchar(32)`Loan product arrears settings
    autocreatelinkedaccounts`bit(1)`Whether account links should be automatically created
    autolinkaccounts`bit(1)`Whether accounts should be automatically linked if possible on creation
    cappingapplyaccruedchargesbeforelocking`bit(1)`Specifies if the accrued charges should be applied before locking (capping)
    cappingconstrainttype`varchar(255)`Specifies constraint types for capping charges. Must be one of the following:
    - `SOFT_CAP` - Interest, fees, penalty are applied. Account is locked in Locked(Capping) state
    - `HARD_CAP` - Interest, fees, penalty are not applied. Account is locked in Locked(Capping) state.
    cappingmethod`varchar(255)`Specifies how principal will be used when calculating capping charges. Must be one of the following:
    - `OUTSTANDING_PRINCIPAL_PERCENTAGE` - As percentage from the outstanding principal
    - `ORIGINAL_PRINCIPAL_PERCENTAGE` - As percentage from the original principal
    cappingpercentage`decimal(50,20)`Specifies the percentage of principal that cannot be exceeded by the sum of interest, fees and penalty balances
    category`varchar(256)`The category of this loan product. This helps organise products into business areas. Can be `PERSONAL_LENDING`, `PURCHASE_FINANCING`, `RETAIL_MORTGAGES`, `SME_LENDING`, `COMMERCIAL`, `UNCATEGORIZED`.
    creationdate`datetime`The date when the loan product was created. Stored as UTC
    currencycode`varchar(3)`The currency which will be compatible with this product. Only relevant for customers offering multicurrency.
    daysinyear`varchar(256)`Days in a year methodology used for loan interest calculations for this product
    - `ACTUAL_365_FIXED`
    - `ACTUAL_364`
    - `ACTUAL_360`
    - `E30_360`
    defaultfirstrepaymentduedateoffset`decimal(50,20)`How many days the first repayment due date should be extended (all other due dates from the schedule are relative to first repayment due date - they will also be affected by the offset)
    defaultgraceperiod`int(11)`The default grace period that will be defined for the loan accounts that will use this product (if the grace period type is not `NONE`).
    defaultloanamount`decimal(50,10)`A default amount for the product (most of the loan accounts are using this default amount).
    defaultnuminstallments`int(11)`The default number of the repayments.
    defaultpenaltyrate`decimal(50,20)`Rate (in percent) which is set as default for new accounts.
    defaultprincipalrepaymentinterval`int(11)`Frequency at which repayments should be paid on this loan product
    defaultrepaymentperiodcount`int(11)`The repayments frequency. Example: the repayment is due once at 10 days (repayment period units). **Required**
    dormancyperioddays`int(11)`Specifies the number of days for an account to be fully paid in order to auto close it
    elementsrecalculationmethod`varchar(256)`Determines how the schedule elements are recalculated:
    - `FIXED_PRINCIPAL_EXPECTED` - the principal expected is kept the same as before, when a prepayment is posted
    - `FIXED_TOTAL_EXPECTED` - The total expected (principal + interest) is kept the same, when a prepayment is posted, interest is recalculated based on the new principal balance and principal is adjusted to match the PMT
    encodedkey`varchar(32)`The encoded key for this loan product. This ID can be used with our ID to work with this specific Loan Product.
    fixeddaysofmonth`mediumblob `Specifies the days of the month when the repayment due dates should be. Only available if the Repayment methodology is `FIXED_DAYS_OF_MONTH`
    forallbranches`bit(1)`Field to indicate if this product is available for all branches
    forhybridgroups`bit(1)`Field to indicate if this product is available for hybrid groups, true if available, false otherwise, never null
    forindividuals`bit(1)`Field to indicate if this product is available for individuals, true if available, false otherwise, never null
    forpuregroups`bit(1)`Field to indicate if this product is available for pure groups, true if available, false otherwise, never null
    futurepaymentsacceptance`varchar(256)`Whether future payments are accepted or not by the accounts created for a given loan product
    - `ACCEPT_FUTURE_PAYMENTS` - Future payments can be posted
    - `NO_FUTURE_PAYMENTS` - Whether the future payments are accepted
    graceperiodtype`varchar(256)`The type of grace period which is possible for a loan account:
    - `NONE` - no grace period
    - `PAY_INTEREST_ONLY` - A grace period during which interest is charged and paid (i.e. an interest only loan for a period, still generates a full loan repayment schedule but during the grace period the capital repayment is $0)
    - `INTEREST_FORGIVENESS` - interest is neither charged nor paid: a pure grace period
    id`varchar(32)`Unique ID of the loan product (specified by the user). **Required**
    idgeneratortype`varchar(256)`The type of the ids that will be generated:
    - `RANDOM_PATTERN` - uses a given pattern to generate IDs
    - `INCREMENTAL_NUMBER` - increments a given number to generate IDs
    idpattern`varchar(256)`The pattern, containing ‘@’ for letters and ‘#’ for digits, for the `RANDOM_PATTERN` or the starting number for the `INCREMENTAL_NUMBER`.
    interestaccrualcalculation`varchar(256)`The accounting interest calculation option selected for the product. One of `BREAKDOWN_PER_ACCOUNT`, `AGGREGATED_AMOUNT`, `NONE`.
    interestaccruedaccountingmethod`varchar(32)`Method being used for maintaining the interest accrued method for the loan product (`NONE`, `DAILY`, `MONTHLY`).
    interestapplicationmethod`varchar(256)`The method used by the loans defining how the interest gets applied
    - `ON_DISBURSEMENT` - All the interest amount gets applied only once, on disbursement time. There is no way of applying interest manually, through the cron jobs, or when performing repayments
    - `ON_REPAYMENT` - The interest gets applied on each repayment and there are multiple ways of performing this. There is an accrued interest, which gets accumulated every day, this determining how much interest needs to be applied on the repayments. The interest can be applied by the cron jobs in the due date of a repayment. The interest can also be applied manually: behind the scenes, when performing a repayment or explicitly by using the UI function available for this.
    interestbalancecalculationmethod`varchar(32)`Option which determines the way the balance for the account’s interest is computed.
    interestcalculationmethod`varchar(256)`The method that is used to compute the interest:
    - `FLAT` - interest is calculated only on the original balance and remains unchanged through out the loan
    - `DECLINING_BALANCE` - interest is paid on the remaining balance
    - `DECLINING_BALANCE_DISCOUNTED` - interest is paid on the remaining balance and the repayments schedule is balanced to create equal repayments
    interestratesettingskey`varchar(32)`Points to a row in the `interestproductsettings` table containing interest rate settings for this product.
    interesttype`varchar(255)`Specifies interest type for the loan product. Must be one of the following:
    - `SIMPLE_INTEREST` - the interest is applied on the schedule when it is applied in the account
    - `CAPITALIZED_INTEREST` - the interest is capitalized on the schedule. It will be converted into principal when applied
    lastmodifieddate`datetime`The date when the loan product was modified last time. Stored as UTC.
    latepaymentsrecalculationmethod`varchar(256)`Method used by loan accounts to have the schedule recalculated when late payments are posted on declining balance equal installments accounts: - `INCREASE_LAST_INSTALLMENT` - this option will only recalculate the interest due for the next installment (the one where the extra interest caused by the late payment, will be added) - `INCREASE_OVERDUE_INSTALLMENTS` - this option will recalculate all the next installments, in order to keep the same total expected on the installments.
    lineofcreditrequirement`varchar(255)`Specifies whether accounts created after this product can/should be part of a line of credit
    Possible values:
    - `OPTIONAL` - account can be part of a line of credit
    - `REQUIRED` - account should be part of a line of credit
    - `NOT_REQUIRED` - account should not be part of a line of credit
    linkablesavingsproductkey`varchar(32)`Which savings product this account is linked to
    loanpenaltycalculationmethod`varchar(256)`Method used for calculating the loan penalty on this product.
    - `NONE`
    - `OVERDUE_BALANCE`
    - `OVERDUE_BALANCE_AND_INTEREST`
    loanpenaltygraceperiod`int(11)`Number of days to wait before applying the loan penalty amounts
    loanproducttype`varchar(255)`Specifies the type of the loan product
    lockperioddays`int(11)`Specifies the number of days for in which the account will be locked if it stays in arrears
    maxfirstrepaymentduedateoffset`decimal(50,20)`Maximum number of days the first repayment due date should be extended (all other due dates from the schedule are relative to first repayment due date - they will also be affected by the offset)
    maxgraceperiod`int(11)`The maximum grace period that has to be defined for the loan accounts that will use this product (if the grace period type is not `NONE`).
    maxloanamount`decimal(50,10)`The maximum loan amount for the loan account, to be able to use this product.
    maxnumberofdisbursementtranches`int(11)`Maximum number of disbursement tranches a loan account account made after this product can have
    maxnuminstallments`int(11)`The maximum number of repayments for the loan account, to be able to use this product
    maxpenaltyrate`decimal(50,20)`Maximum penalty rate which can be set for accounts.
    minfirstrepaymentduedateoffset`decimal(50,20)`Minimum number of days the first repayment due date should be extended (all other due dates from the schedule are relative to first repayment due date
    mingraceperiod`int(11)`The minimum grace period that has to be defined for the loan accounts that will use this product (if the grace period type is not `NONE`).
    minloanamount`decimal(50,10)`The minimum loan amount for the loan account, to be able to use this product.
    minnuminstallments`int(11)`The minimum number of repayments for the loan account, to be able to use this product.
    minpenaltyrate`decimal(50,20)`Minimum penalty rate which can be set for accounts.
    offsetpercentage`decimal(50,20)`Stores the percentage to be used as offset for the loan account schedule calculation.
    paymentmethod`varchar(256)`The method used by the loans defining how the payments get performed
    - `HORIZONTAL` - The payment is done horizontally, on the repayments, following the repayment allocation elements order.
    - `VERTICAL` - The payment is done vertically, into the account, following the repayment allocation elements order.
    prepaymentacceptance`varchar(256)`Whether the pre-payments are allowed or not for this product (if there can be posted repayments before the due date of that repayment)
    prepaymentrecalculationmethod`varchar(255)`Holds the possible options for how are the pre-payments affecting the number of installments and the amount allocated per installment for a repayments schedule belonging to a DYNAMIC loan account
    - `NO_RECALCULATION`
    - `RESCHEDULE_REMAINING_REPAYMENTS`
    - `RECALCULATE_SCHEDULE_KEEP_SAME_NUMBER_OF_TERMS`
    - `RECALCULATE_SCHEDULE_KEEP_SAME_PRINCIPAL_AMOUNT`
    - `RECALCULATE_SCHEDULE_KEEP_SAME_TOTAL_REPAYMENT_AMOUNT`
    - `REDUCE_AMOUNT_PER_INSTALLMENT`
    - `REDUCE_NUMBER_OF_INSTALLMENTS`
    principalpaidinstallmentstatus`varchar(255)`Defines the installment status after the principal was paid off as part of an over-payment.
    - `PARTIALLY_PAID`
    - `PAID`
    - `ORIGINAL_TOTAL_EXPECTED_PAID`
    principalpaymentsettingskey`varchar(32)`Foreign key to the `principalPaymentSettings` table containing options for the current product
    productdescription`mediumtext`A short description of the product (why is it recommended, who can use it etc.)
    productname`varchar(256)`The name of the product.
    productsecuritysettingskey`varchar(32)`Foreign key to the `productSecuritySettings` table containing the security settings (guarantors, collateral, investor funds) available for the current product.
    redrawsettingskey`varchar(32)`Foreign key to the `productRedrawSettings` table
    repaymentallocationorder`mediumblob `An array list of the order of which to allocate repayments including principal, interest, fees and penalty
    repaymentcurrencyrounding`varchar(256)`Specifies if the repayment schedule should be rounded to the nearest whole unit
    - `NO_ROUNDING`
    - `ROUND_TO_NEAREST_WHOLE_UNIT`
    repaymentelementsroundingmethod`varchar(256)`Determines how the repayment currency rounding is handled on each element from the schedule:
    - `NO_ROUNDING`
    - `ROUND_ALL`
    - `PAYMENT_DUE`
    repaymentperiodunit`varchar(256)`The frequency of loan repayment:
    - `DAYS`
    - `WEEKS`
    - `MONTHS`
    - `YEARS`
    repaymentreschedulingmethod`varchar(256)`The repayment rescheduling method used in calculations
    repaymentscheduleeditoptions`mediumblob `Which rights do users have when editing the schedule of this product (relevant for fixed products only)
    repaymentschedulemethod`varchar(256)`The repayment schedule method. Represents the method that determines whether the schedule will be fixed all over the loan account’s life cycle or will be dynamically recomputed when required.
    roundingrepaymentschedulemethod`varchar(256)`Specifies if the repayment schedule should be rounded to the nearest whole unit
    - `NO_ROUNDING`
    - `ROUND_TO_NEAREST_WHOLE_UNIT`
    scheduleduedatesmethod`varchar(256)`Method used by the loan accounts to determine the due dates of the repayments:
    - `INTERVAL` - the repayments will be made on a specified interval (e.g. Every 2 Months)
    - `FIXED_DAYS_OF_MONTH` - the repayments will be made each month on some given dates (for example, each month on 10th and 20th means that each month there will be two installments, one made on 10 of that month and one on 20)
    scheduleinterestdayscountmethod`varchar(256)`Methods that determine how the number of interest days for a repayment are computed (currently only used by `FIXED` methods)
    - `USING_REPAYMENT_PERIODICITY` - The number of days in the repayment are ignored .Instead, the number of days is computed by considering that there’s no inconsistency between the first repayment length and the repayment frequency
    - `USING_ACTUAL_DAYS_COUNT` - the actual number of days between the first repayment due date and the disbursement date are considered when computing the interest
    settlementoptions`varchar(32)`Specifies how the nightly job will transfer from the due amounts from the linked savings account to the loan account
    Available options:
    - `FULL_DUE_AMOUNTS`
    - `PARTIAL_DUE_AMOUNTS`
    shortmonthhandlingmethod`varchar(256)`Determines how to handle the short months, if they select a fixed day of month > 28. Will be null if no such date is selected and also for the Interval methodology. Only available if the Repayment Methodology is `FIXED_DAYS_OF_MONTH`
    taxcalculationmethod`varchar(256)`The method used by the loans to compute the taxes for the revenues:
    - `INCLUSIVE` - The tax amount is included in the original computed amount.
    - `EXCLUSIVE` - The tax amount is not included on the computed amount.
    taxesonfeesenabled`bit(1)`Whether taxes on fees are enabled for this product or not
    taxesoninterestenabled`bit(1)`Whether taxes on interest are enabled for this product or not
    taxesonpenaltyenabled`bit(1)`Whether taxes on penalties are enabled for this product or not.
    taxsourcekey`varchar(32)`The tax source from where the loan account taxes will be updated
    ## loanproduct_billingcycledays > Holds information on the billing cycle for revolving credit type products. Primary key: `productkey` + `days`
    Column Name Data Type Description
    day`tinyint(2)`The day on which the billing cycle rolls over.
    productkey`varchar(32)`The encoded key of the product for which this setting is valid.
    ## loanproductbranch > stores the association between a loan product and the branches where it is available. Primary key: `encodedkey`
    Column Name Data Type Description
    branchkey`varchar(32)`The key of the branch that is associated with a loan product
    encodedkey`varchar(32)`The encoded key for this association, this is an autogenerated and globally unique ID.
    productkey`varchar(32)`The loan product that is associated with a branch
    ## loanproductstartids > the id settings allows you to customize the ids generated for any loan accounts which will later be created under this product.

    you can either choose a random pattern or incremental numbers for your account ids. Primary key: `productencodedkey`
    Column Name Data Type Description
    idpattern`varchar(256)`The template for IDs for this loan product.
    numericid`decimal(32,0)`If IDs are numeric, newly created accounts for this product started at this mumber.
    productencodedkey`varchar(32)`The encoded key of the product which uses this configuration.
    ## loanrisklevel > capture the a loan account risk level band. a band is considered a range of days in arrears for an account (eg: from 5 to 10 days) and a risk level should also have a defined provisioning percentage. this percentage represents the amount that should be provisioned at this loan risk level" Primary key: `encodedkey`
    Column Name Data Type Description
    arrearsfrom`int(11)`The starting day for this band.
    arrearsto`int(11)`The ending day for this band.
    encodedkey`varchar(32)`They encoded key for this row.
    name`varchar(256)`The name of this rule.
    provisioningpercent`decimal(50,10)`The percentage of capital which should be provisioned for loans in this risk level.
    ## loantranche > in some cases organizations may approve loans but not disburse the full amount initially. they would like to spread the disbursement (and risk) over time.

    likewise for the client, they may not need the full loan amount up front. they may want to have a loan to buy some equipment for their business but will make one purchase today and another purchase in a few months. in these cases, they don’t need the full amount and wouldn’t want to pay interest on cash they don’t need yet.
    a solution for this matter is the usage of disbursement in tranches. this class holds the information required for one of this tranche. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The amount this tranche has available for disburse. **Required**
    disbursementtransactionkey`varchar(32)`A link to the entry in the `loantransaction` table pointing to the transaction disbursing this tranche.
    encodedkey`varchar(32)`A unique ID for this loan tranche.
    expecteddisbursementdate`datetime`The date when this tranche is supposed to be disbursed (as Organization Time)
    index`int(11)`The index which gives the order of tranches
    tranches_encodedkey_own`varchar(32)`The encoded key of the loan account for this tranche.
    tranches_integer_idx`int(11)`The index which gives the order of tranches
    ## loantransaction > keeps track of all transactions which occur with loan accounts such as state changes, repayments, fees, etc. Primary key: `encodedkey`
    Column Name Data Type Description
    advanceposition`decimal(50,10)`Captures the advance (prepaid) amount
    amount`decimal(50,10)`The amount of the transaction. Compare the previous `balance` to the current `balance` to see if the amount increases or decreases the balance. The amount may be null for certain transactions - such as state changes.
    arrearsposition`decimal(50,10)`Captures the arrears position amount for the account in arrears
    balance`decimal(50,10)`The balance of the loan account after the transaction
    branchkey`varchar(32)`Foreign key to the branch where this transaction was performed.
    centrekey`varchar(32)`Foreign key to the centre where this transaction was performed.
    comment`varchar(256)`The comment which could be provided for a loan transaction.
    creationdate`datetime`Date when the transaction occurred (UTC). **Required**
    deferredinterestamount`decimal(50,10)`How much interest pre-paid was added/removed in account, within this transaction (including taxes)
    deferredtaxoninterestamount`decimal(50,10)`How much taxes on the interest that was pre-paid were added/removed in account, within this transaction. If there is any deferred tax on interest amount set in this transaction, that amount should be included in this field.
    details_encodedkey_oid`varchar(32)`Details about transaction.
    encodedkey`varchar(32)`The encoded key for this transaction.
    entrydate`datetime`Date of the entry (eg date of repayment or disbursal, etc.). As **Organization Time**.
    expectedprincipalredraw`decimal(50,10)`Captures the difference between principal balance and redraw balance after each transaction performed on the loan account
    externalid`varchar(36)`The ID added by the customers that accepts alpha-numeric characters, underscore and dash. Can be null
    feesamount`decimal(50,10)`How much fees was added/removed in account, within this transaction.
    fundersinterestamount`decimal(50,20)`Amount of interest that goes to the funders (only for P2P accounts with split methodology)
    indexinterestrate_encodedkey_oid`varchar(32)`Foreign key to `indexRate` table: Index value used for the calculation of the loan interest rate.
    interestamount`decimal(50,10)`How much interest was added/removed in account, within this transaction.
    interestfromarrearsamount`decimal(50,10)`How much interest from arrears was applied/paid in account, within this transaction (including taxes).
    interestrate`decimal(50,20)`The new interest rate for a loan account
    loantransactiontermskey`varchar(32)`Foreign key to `loansTransactionTerms` table: Reference to entity which holds specific information related to loan transactions.
    migrationeventkey`varchar(32)`Points to an entry in the `datamigrationevent` table if this transaction was imported rather than having been generated in the Mambu system itself.
    organizationcommissionamount`decimal(50,20)`Amount of interest that goes to the organization (only for P2P accounts with split methodology)
    originalamount`decimal(50,10)`the amount that was posted in a foreign currency. This amount was converted using the exchange rate available at entry date and set into the amount field
    originalcurrencycode`varchar(3)`the currency in which this transaction was posted. The amounts are stored in the base currency, but the user could have enter it in a foreign currency
    parentaccountkey`varchar(32)`Foreign key to the loan account this transaction refers to. **Required**
    parentloantransactionkey`varchar(32)`The key of the parent loan transaction. Right now, we link `DEFERRED_INTEREST_APPLIED` with REPAYMENT transactions and `DEFERRED_INTEREST_PAID` with `INTEREST_APPLIED` transactions, because this transaction comes as a result of logging the parent transaction. Usually, when the parent is reversed, the child should be reversed as well.
    penaltyamount`decimal(50,10)`How much penalty was added/removed in account, within this transaction.
    principalamount`decimal(50,10)`How much principal was added/removed in account, within this transaction.
    principalbalance`decimal(50,10)`The total principal owed by the client, at the current time (principal disbursed - principal paid)
    producttypekey`varchar(32)`Store the key of the loan product to which the account owning this transaction belongs.
    redrawbalance`decimal(50,10)`The total redraw amount available to the client, at the current time
    reversaltransactionkey`varchar(32)`Foreign key to another loan transaction (to self - LoanTransaction.encodedKey) where the reversal of the current transaction was made. It’s null if the transaction wasn’t reversed. Example: This transaction represents a penalty applied transaction. If this transaction will be reversed, another transaction will be logged and this transaction will remember the key of that one.
    taxonfeesamount`decimal(50,10)`How much taxes on the fees that were paid in this transaction were added/removed in account, within this transaction
    taxoninterestamount`decimal(50,10)`How much taxes on the interest that was paid in this transaction were added/removed in account, within this transaction
    taxoninterestfromarrearsamount`decimal(50,10)`The amount of taxes on the interest from arrears that were applied/paid in account, within this transaction.
    taxonpenaltyamount`decimal(50,10)`how much taxes on the penalties that were paid in this transaction were added/removed in account, within this transaction
    taxrate_encodedkey_oid`varchar(32)`Foreign key to `indexRate` table: Tax rate that was set or changed in this transaction.
    tillkey`varchar(32)`The till key associated with this transaction
    transactionid`bigint(20)`Auto-increment unique ID of the loan transaction. **Required**
    type`varchar(256)`Type of the transaction. Must be one of:
    - `CREATION` - the loan account was created
    - `EDIT` - the loan account was modified
    - `DISBURSEMENT` - the loan account was disbursed
    - `STATE_CHANGE` - the loan account state changed (eg for an Approval)
    - `REPAYMENT` - a repayment was applied to the account
    - `FEE_APPLIED` - a fee was applied to the account
    - `PENALTY_APPLIED` - a penalty was applied to the account
    - `PAYMENT_RESCHEDULE` - a repayment balance was rescheduled
    - `REPAYMENT_ADJUSTMENT` - a previously entered repayment amount was corrected
    - `FEE_ADJUSTMENT` - a previously applied fee was adjusted
    - `PENALTY_ADJUSTMENT` - a penalty amount was adjusted
    - `BRANCH_CHANGED` - marks the moment when the parent account is assigned to a different branch
    - `DEFERRED_INTEREST_APPLIED` - before interest that’s not applied in the account yet gets pre-paid, this transaction will be logged in the same time with the repayment transaction, to justify the pre-paid interest amount in account’s balance
    - `DEFERRED_INTEREST_APPLIED_ADJUSTMENT` - reversal for `DEFERRED_INTEREST_APPLIED` transaction
    - `DEFERRED_INTEREST_PAID` - after interest that was pre-paid gets applied in the account, this transaction will be logged with the interest that was pre-paid and now applied, to justify why that applied interest is not reflected in account’s balance.
    - `DEFERRED_INTEREST_PAID_ADJUSTMENT` - reversal for `DEFERRED_INTEREST_PAID` transaction
    - `DISBURSEMENT_ADJUSTMENT` - reversal of disbursement
    - `FEE_CHARGED` - a fee being charged to the loan account;
    - `FEE_LOCKED` - when fees on the account are set to locked
    - `FEE_REDUCTION_ADJUSTMENT` - reversal for the `FEES_DUE_REDUCED` transaction
    - `FEE_UNLOCKED` - when the fees on the account are set to unlocked
    - `FEES_DUE_REDUCED` - a decrease over the fees due
    - `IMPORT` - an account being imported
    - `INTEREST_APPLIED` - transaction logged when the accrued interest it’s applied to the account interest balance
    - `INTEREST_APPLIED_ADJUSTMENT` - reversal for the `INTEREST_APPLIED` transaction
    - `INTEREST_DUE_REDUCED` - a decrease over the interest due
    - `INTEREST_LOCKED` - when the interest on account is set to locked
    - `INTEREST_RATE_CHANGED` - the interest for an account has been recomputed
    - `INTEREST_REDUCTION_ADJUSTMENT` - reversal for the `INTEREST_DUE_REDUCED` transaction
    - `INTEREST_UNLOCKED` - when the interest on account is set to unlocked
    - `PENALTIES_DUE_REDUCED` - a decrease over the penalties due
    - `PENALTY_LOCKED` - when the penalties on the account are set to locked
    - `PENALTY_REDUCTION_ADJUSTMENT` - reversal for the - `PENALTIES_DUE_REDUCED` transaction
    - `PENALTY_UNLOCKED` - when the penalties on the account
    - `TAX_RATE_CHANGED` - the tax for an account has been changed
    - `TERMS_CHANGED` - marks the moment when some loan terms have changed for a loan account
    - `TRANSFER` - when principal gets transferred from a loan to another loan
    - `TRANSFER_ADJUSTMENT` - a transfer being adjusted (reversed)
    - `WRITE_OFF` - loan account being closed off
    - `WRITE_OFF_ADJUSTMENT` - the loan account closure being reversed
    **Required**
    userkey`varchar(32)`Foreign key to the User who performed this transaction. If null, it means this was a system-performed transactions (such as an automatic penalty)
    ## loantransactioncustomvalue > Holds values for custom information for loan transactions. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## loantransactionexternalhistory > Table which tracks loan transactions that were made asynchronously by microservices. Primary key: `externalrequestid`
    Column Name Data Type Description
    creationdate`datetime(6)`Date and time, in UTC, when the transaction occurred.
    errors`varchar(512)`Will contain a log of the errors if the transaction has a status of `FAILED`.
    externalrequestid`varchar(32)`A unique ID generated by the service
    loantransactionencodedkey`varchar(32)`The encoded key of the loan transaction.
    status`varchar(16)`Status of the current transaction. Will be one of `FAILED` or `SUCCEEDED`
    ## loantransactionpenaltydata > Stores information about penalties as a JSON representation. Primary key: `encodedkey`
    Column Name Data Type Description
    content`json`A JSON representation of a loan penalty.
    encodedkey`varchar(32)`A unique key for this row.
    parenttransactionkey`varchar(32)`The encoded key of the parent loan transaction.
    ## loantransactionpenaltydetails > stores penalty settings at the loan transaction level. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for an entry in the `loantransaction` table.
    penaltyrate`decimal(50,20)`The penalty rate in effect at the time of this transaction.
    ## loantransactionterms > entity class which holds specific information related to loan transaction terms which may change over the lifetime of a loan, e.g. principal payment value (amount or percentage) for credit card accounts or revolving credit or balloon payment type loans. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this row, this is an autogenerated and globally unique ID. This will be linked to from an entry in the `loanaccount` table.
    periodicpayment`decimal(50,10)`Tracks changes in loans with associated payment plans.
    principalpaymentamount`decimal(50,10)`The principal payment flat amount logged when change it for a revolving credit loan
    principalpaymentpercentage`decimal(50,20)`The principal payment percentage value logged when change it for a revolving credit loan
    ## mambuapp > represents an app in mambu - an external application added and provided by a 3rd party developer. check our user guide pages for more information on creating and installing apps. Primary key: `encodedkey`
    Column Name Data Type Description
    apiuser_encodedkey_oid`varchar(32)`The encoded key of a user in the `user` table which this app uses to authenticate with Mambu.
    appkey`varchar(32)`The app key used to sign requests between the app and Mambu.
    creationdate`datetime`The date when the app was created. Stored as UTC
    encodedkey`varchar(32)`A unique key for this app.
    extensionpoints`mediumblob `Extension points indicate where the app will appear in the Mambu user interface. See this page for a list of extension points.
    id`varchar(256)`The unique id of the application. This is used as the App ID for authenticating API calls.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    name`varchar(256)`The display name of the app.
    properties`mediumblob `The properties of the app.
    state`varchar(256)`Whether the app is `ENABLED` or `DISABLED`.
    ## mambufeatureentity > contains information about mambu features. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime(6)`The date when the mambu feature was created (stored as UTC). **Required**.
    encodedkey`varchar(32)`The encoded key for this feature, this is an autogenerated and globally unique ID.
    lastmodifieddate`datetime(6)`The date when the mambu feature was last modified (stored as UTC).
    name`varchar(256)`The name of the mambu feature. **Required**.
    status`varchar(32)`The status of the mambu feature.
    usage`varchar(32)`Indicates if mambu feature is used.
    ## mambuservices > services which are enabled/disabled for different editions/tiers of mambu and different subscription plans and clients Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    mambuedition`varchar(256)`The product teir of this mambu instance.
    maxclients`int(11)`The maximum number of clients that can be supported by this instance.
    maxusers`int(11)`The maximum number of users for this instance.
    trialexpirydate`datetime`The date on which the free trail will expire
    ## mccexpiration > contains information on how much an authorizationhold can be maintained in the system before expiring it, based on the mcc (merchant category code). Primary key: `encodedkey`
    Column Name Data Type Description
    daystoexpiration`int(11)`The number of days to wait before expiring an authorization hold with this entity’s MCC
    description`varchar(256)`The description of the MCC expiration. Unique.
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    mcc`int(11)`The Merchant Category Code to hold the expiration information for
    ## messagetemplate > a template for a notification which can be sent by mambu. also used by task templating functionality. Primary key: `encodedkey`
    Column Name Data Type Description
    activated`bit(1)`If the messate template is activated or not
    authorization`varchar(255)`Specifies authorization type (basic or no authorization).
    contenttype`varchar(255)`The header to be used when posting the webhook notification.
    creationdate`datetime`The creation date of the message template. Stored as UTC.
    customfilter_key`varchar(32)`A reference to the custom filter based on which the notification message is created of not
    encodedkey`varchar(32)`The encoded key for this template. Can be used with our API to generate populated templates programatically, see here for more information.
    event`varchar(256)`Event associated with this notification. **Required**
    lastmodifieddate`datetime`The date on which this row was last modified. Stored as UTC.
    name`varchar(255)`Name of this message template. **Required**
    option`varchar(256)`Subscription option for this notification - whether clients opt in or opt out of it.
    password`varchar(255)`Password to be used in authentication token when web hook notification is posted.
    recipientkey`varchar(32)`The entity that is going to receive the message. May be a client, group, credit officer or a linked custom field.
    requesttype`varchar(32)`The HTTP method to be used when sending the webhook notification.
    subject`varchar(256)`The subject of the message template.
    targettype`varchar(32)`Indicates the type of entity which will trigger this notification, eg. `CLIENT`, `GROUP`, `SAVINGS`, `LOANS`
    template`mediumtext`The content of the template.
    topic`varchar(256)`The topic to which a client can subscribe in order to receive the events
    trigger`varchar(255)`The trigger of the message template.
    triggerdays`int(11)`Number of days before/after the trigger when the notification will be sent.
    type`varchar(256)`The type of notification, `EMAIL`, `SMS` or `TASK`.
    url`varchar(512)`The URL of the message template.
    username`varchar(255)`User name to be used in authentication token when web hook notification is posted.
    ## messagetemplaterecipient > model that maintains the relation between a message template and the recipient type that is going to receive the message. Primary key: `encodedkey`
    Column Name Data Type Description
    customfieldkey`varchar(32)`Which user link related to the target (client/group) should receive notifications of events.
    encodedkey`varchar(32)`The encoded key for this relationship, this is an autogenerated and globally unique ID.
    grouprolenamekey`varchar(32)`Which group role (user defined, as president/secretary/etc.) related to the target (client/group) should receive notifications of events.
    recipienttype`varchar(256)`Describe the type of the recipient that is going to receive the message. May be a client, group, credit officer etc.
    ## messagetemplaterequestheader > A table holding custom header keys and values for automated webhook notifications. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    headerkey`varchar(256)`The key of the custome header, for example, `Accept` or `X-Mambu-Custom-Header`.
    headervalue`varchar(1024)`The value this header will take.
    messagetemplatekey`varchar(32)`The key of an entry in the `messagetemplate` table to which this custom header will be added when sent.
    ## messaginglog Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime(3)`The time at which this message was logged.
    encodedkey`varchar(32)`The encoded key for this database entry.
    messageid`varchar(36)`The ID for this message.
    ## nonworkingday > represents a day from the week which is non-working for the organization Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the non working day was created (as UTC)
    dayofweek`varchar(256)`The day of the week which is non-working for the organization, eg `MONDAY`, `SATURDAY`.
    encodedkey`varchar(32)`The encoded key for this entry in this table.
    nonworkingdays_encodedkey_own`varchar(32)`Encoded key of the entry in the `generalsettings` table which uses this set of non-working days. Essentially your mambu instance.
    nonworkingdays_integer_idx`int(11)`Index for this non working day, ie. the first non working day will have index 0, the second 1 and so on.
    ## notificationbrokerqueue Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the row was created. Stored as UTC
    encodedkey`varchar(32)`
    failurecause`varchar(2048)`
    failurereason`varchar(256)`
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    notificationmessagekey`varchar(32)`
    state`varchar(256)`
    ## notificationeventdetails Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime(3)`The date when the event was created. Stored as UTC
    encodedkey`varchar(32)`
    isread`tinyint(1)`Whether or not this message has been marked as read.
    lastmodified`datetime(3)`
    message`mediumtext`
    subscriberid`varchar(32)`
    taskid`varchar(32)`
    type`varchar(32)`
    ## notificationeventitem > this entity holds the information necessary to display notification events for clients. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime(3)`The date when the notification event was created (stored as UTC). **Required**.
    encodedkey`varchar(32)`The encoded key for this notification, this is an autogenerated and globally unique ID.
    isread`bit(1)`Flag to determine whether the notification was read by the user. **Required**.
    lastmodified`datetime(3)`The date when the notification event was last modified (stored as UTC). **Required**.
    status`varchar(32)`The state of the Event.
    subscriberid`varchar(32)`The userKey of the user that owns the job. **Required**.
    taskid`varchar(32)`The taskKey of the job. **Required**.
    type`varchar(32)`The type of the Event.
    ## notificationmessage > a log of sent notification messages of different types, including the state of the notification, to whom it was sent. Primary key: `encodedkey`
    Column Name Data Type Description
    body`mediumtext`The actual contents (body) of the message.
    clientkey`varchar(32)`Whom the message was sent to.
    creationdate`datetime`When the message was created either for immediate sending of queued (as UTC).
    destination`varchar(1024)`The destination (phone number or email address) this notification was sent to.
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used with our API to receive details on a specific message.
    event`varchar(256)`The event this message was sent for, if any.
    failurecause`varchar(256)`A failure code if the message failed to send.
    failurereason`varchar(255)`Maintains the reason of the notification message failure.
    groupkey`varchar(32)`What group the message was sent to.
    id`varchar(256)`The id of the notification message.
    loanaccountkey`varchar(32)`If the notification was about a loan account this is set to that account.
    numretries`int(11)`Number of retries to send the message
    repaymentkey`varchar(32)`If the notification was about a repayment -then this is set to that account.
    savingsaccountkey`varchar(32)`If the notification was about a savings account - then this is set to that account.
    senddate`datetime`When the message was actually sent (as UTC).
    senderkey`varchar(32)`Who sent the message. Or null if done automatically by Mambu.
    state`varchar(256)`The state of the message. **Required**.
    subject`varchar(256)`The subject of the message.
    templatekey`varchar(32)`Key of the associated MessageTemplate.
    type`varchar(256)`What type of notification is. **Required**.
    userkey`varchar(32)`What user the message was sent to.
    ## notificationmessagegljournalentry Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`
    gljournalentrykey`varchar(32)`
    notificationmessagekey`varchar(32)`
    ## notificationmessagehistory Primary key: `encodedkey` + `creationdate`
    Column Name Data Type Description
    body`mediumtext`
    creationdate`datetime`The date when the entry was created. Stored as UTC
    destination`varchar(1024)`
    encodedkey`varchar(32)`
    event`varchar(256)`
    gljournalentrykey`varchar(32)`
    id`varchar(256)`
    numretries`int(11)`
    senddate`datetime`
    templatekey`varchar(32)`
    type`varchar(256)`
    ## notificationmessagequeue > this entity holds a notification message that is queued in the fact that it is ready to be sent by the jobs responsible for actual message sending (email, sms, web hook services). the corresponding table is scanned periodically by jobs that will send out the notifications. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the message was created. Stored as UTC
    encodedkey`varchar(32)`The encoded key for this message in the queue.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    notificationmessage_encodedkey_oid`varchar(32)`
    state`varchar(256)`The state of the message.
    ## notificationmessagestreaming Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`
    id`bigint(20)`
    messageid`varchar(36)`
    notificationmessage_encodedkey_oid`varchar(32)`
    partitionkey`varchar(256)`
    ## notificationmessagestreamingqueue Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the notification was created. Stored as UTC
    encodedkey`varchar(32)`
    id`bigint(20)`
    lastmodifieddate`datetime`The last time at which this notification was modified.
    notificationmessage_encodedkey_oid`varchar(32)`
    state`varchar(256)`
    ## notificationrequest > used for request for notifications. requests may be tied to clients or group and are associated with a specific notification template. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`the id for this request
    ownerkey`varchar(32)`
    ownertype`varchar(256)`
    template_encodedkey_oid`varchar(32)`
    ## notificationsdrdata Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`
    notificationmessagekey`varchar(32)`
    ## objectlabel > captures the settings of custom object labels, for example ‘clients’ being referred to as ‘members’. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    language`varchar(256)`The language in which the object label is displayed. **Required**.
    pluralvalue`varchar(256)`The plural form of the type which is displayed. **Required**.
    singularvalue`varchar(256)`The singular form of the type which is displayed. **Required**.
    type`varchar(256)`The type of the object label which can be user-customised:
    - `CLIENT`
    - `GROUP`
    - `BRANCH`
    - `CENTRE`
    - `CREDIT_OFFICER`
    **Required**.
    ## organization > stores details about the organization itself such as it’s name, address, time zone, etc. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when the organization was created (as Organization Time).
    emailaddress`varchar(256)`The email address of the organization
    encodedkey`varchar(32)`The encoded key for this database entry.
    lastmodifieddate`datetime`The date of the last modify performed over the organization (as Organization Time).
    name`varchar(256)`The name of the organization
    phoneno`varchar(256)`The phone number of the organization
    timezoneid`varchar(256)`Canonical time zone ID of the organization. See http://en.wikipedia.org/wiki/List_of_tz_database_time_zones for valid formats. **Required**.
    ## organizationbranding > an organization can store it’s own logo (stored as 300x50 px) and also a small icon, stored as (16x16 px), that will replace the mambu logos from the website. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    iconimage`mediumblob `The image that will replace the Mambu logos from the website
    logoimage`mediumblob `The logo of the organization. Stores a logo of 300x50.
    ## organizationsnapshot > holds a snapshot of all organization indicators at a given point in time. used in the historical analysis graphs Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date on which this snapshot was taken.
    encodedkey`varchar(32)`The encoded key for this database entry.
    indicators`mediumblob `A hashmap of key performance indicators and their values at the time of the snapshot.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    ## passwordresetrequest > stores the password reset requests. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    identifier`varchar(255)`Identifier for the password request - used instead of the encodedKey.
    requestdate`datetime`The date on which this password reset request was made.
    state`varchar(256)`Contains the state of the request. Before the change has been made, the state will be `PENDING`. Once the user has successfully changed their password this field should contain `COMPLETED`. If the account owner did not change their password within the allotted timeframe, the state will be `EXPIRED`.
    targetclientkey`varchar(32)`If the request relates to a client and their password for the portal, this field will contain the encoded key for that client.
    targetuserkey`varchar(32)`If the request relates to a user of the system then this field will contain the encoded key of that user.
    userkey`varchar(32)`The encoded key of the user who intitated the password reset request.
    ## paymentdetails > Holds details of payments made via the Mambu payments gateway including SEPA Direct Debit and Credit Transfers Primary key: `encodedkey`
    Column Name Data Type Description
    creditoraccountcurrency`varchar(3)`The currency code of the creditor account
    creditoraccountiban`varchar(34)`The IBAN of the account sending funds as part of the transaction.
    creditoraccountotheridentification`varchar(34)`Any other ID provided to identify the sender.
    creditoraccountotherscheme`varchar(35)`The type of ID if `creditoraccountotheridentification` has been provided.
    creditoragentbic`varchar(35)`The bank identifier code of the agent used by the sender.
    creditorname`varchar(140)`The name of the holder of the account sending funds in this transaction.
    debtoraccountcurrency`varchar(3)`The currency of the receiving account.
    debtoraccountiban`varchar(34)`The IBAN of the receiver of the transcation.
    debtoraccountotheridentification`varchar(34)`Any other ID provided to identify the receiver.
    debtoraccountotherscheme`varchar(35)`The type of ID if `debtoraccountotherscheme` has been provided.
    debtoragentbic`varchar(35)`The bank identifier code of the agent used by the receiver.
    debtorname`varchar(140)`The name of the holder of the account receiving the transaction.
    encodedkey`varchar(32)`A unique key used to identify this payment.
    endtoendidentification`varchar(35)`Identifier assigned by the initiating party to the transaction.
    instructionidentification`varchar(35)`Identifier of a payment instruction.
    remittanceinformationstructuredreference`varchar(35)`The reference information of the creditor’s underlying documents.
    remittanceinformationstructuredreferenceissuer`varchar(35)`The entity that assigns the reference type.
    remittanceinformationstructuredreferencetype`varchar(35)`The type of creditor reference.
    remittanceinformationunstructured`varchar(140)`Information supplied to match the items of the payment in an unstructured form.
    savingstransactionkey`varchar(32)`The matching transaction in a Mambu deposit account.
    servicelevelcode`varchar(35)`The code for a pre-agreed service or level of service between the parties.
    transactionidentification`varchar(35)`Identifier unique for a period assigned by the first initiating party to the transaction.
    ## periodicpayment > entity defining a line from the payment plan, holding the pmt value used to compute the principal and interest for a specific defined number of installments when the schedule is generated. See our payment plans support article for more information. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    endinginstallmentposition`int(11)`The last installment up to which this band of the payment plan will be used.
    index`int(11)`The index of the payment amount in the plan, for example, the payment amount for payments 1-5 will be index `0`, for payments 6-10 will be index `1` and so on.
    paymentplan_encodedkey_own`varchar(32)`The encoded key of the loan account to which this payment plan is linked.
    paymentplan_integer_idx`int(11)`The index of the payment amount in the plan, for example, the payment amount for payments 1-5 will be index `0`, for payments 6-10 will be index `1` and so on.
    pmt`decimal(50,10)`The actual payment amount used for installments in this band up to the `endinginstallmentposition`.
    ## periodintervalsettings > holds settings for defining period intervals. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    frequency`varchar(256)`Frequency settings of the fee amortization. **Required**.
    intervalcount`int(11)`Total number of intervals
    intervaltype`varchar(256)`Defines the options for an interval. Can be:
    - `FULL_TERM` - The number of intervals is determined programmatically considering a loan account’s maturity date
    - `PREDEFINED_INTERVALS` - The number of intervals is provided by the user
    periodcount`int(11)`Period count used in conjunction with periodUnit to determine the next date of the interval
    periodunit`varchar(256)`Amortization unit to determine the interval between amortizations
    ## permission > A table containing available permissions for users of the Mambu system.
    Column Name Data Type Description
    creationdate`datetime(6)`The date on which this permission was added, in UTC.
    encodedkey`varchar(32)`A unique key for this permission
    lastmodifieddate`datetime(6)`The last date and time at which this permission was modified, in UTC.
    permission`varchar(256)`The name of the permission, for example, `CREATE_SAVINGS_ACCOUNT` or `APPROVE_LOANS`
    ## permissions > stores permissions associated with a user of mambu. Primary key: `encodedkey`
    Column Name Data Type Description
    canmanageallbranches`bit(1)`Whether or not this user is allowed to manage clients and services from all branches.
    canmanageentitiesassignedtootherofficers`bit(1)`Whether or not the user can edit clients, accounts and other entities which are assigned to other Mambu users. Will be 1 for Administrators.
    encodedkey`varchar(32)`The encoded key for this set of permissions. Used as a foreign key in the `user` table to link a user to a set of permissions.
    permissions`mediumblob `A list of permissions granted to the user via our UI such as `VIEW_COMMENTS`, `EDIT_BRANCH` and so on as a JAVA array.
    permissionvalues`text`A list of permissions granted to the user via our UI such as `VIEW_COMMENTS`, `EDIT_BRANCH` and so on as text.
    ## permissionsassociation > Maps permissions to permission sets that include them.
    Column Name Data Type Description
    permissionencodedkey`varchar(32)`The encoded key of a permission.
    permissionsencodedkey`varchar(32)`The encoded key of a permission set in the `permissions` table that includes the permmission indicated by `permissionencodedkey`.
    ## portalgeneralsettings > general settings for the portal module including the portal state, what to show for clients and organization stylesheet. Primary key: `encodedkey`
    Column Name Data Type Description
    cnameurl`varchar(256)`The custom domain configured for the client portal.
    encodedkey`varchar(32)`Encoded key for these settings.
    iconimage`mediumblob `The image which will be used as the favicon for the portal.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    logoimage`mediumblob `The logo which should appear on the login screen.
    maxclientaccounts`int(11)`The maximum number of client accounts supported by the portal.
    portalenabled`bit(1)`Whether the portal is enabled or not. **Please note:** even if enabled there may be further steps to complete before the portal is usable, including setting up password recovery email templates and communication flows.
    shownaccountstates`mediumblob `An array of the activities which will be displayed on the portal (for example `PENDING_APPROVAL`, `ACTIVE` etc.).
    shownactivities`mediumblob `An array of the activities which will be displayed on the portal (for example `LOAN_ACCOUNT_CREATED`, `CLIENT_EMAIL_SENT` etc.).
    stylesheet`mediumblob `Map containing link to general CSS template, custom colour scheme and background which have been configured for the portal.
    ## portalpreferences > a user’s individual portal setting preferences including language, password (encrypted) and whether the portal is actually enabled. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    lastloggedindate`datetime`The date on which this user last logged in to the portal.
    password`varchar(256)`The encrypted password of the user.
    portalstate`varchar(256)`Whether the portal is `ENABLED` or `DISABLED`.
    ## predefinedfee > fee with a defined name and a fixed value Primary key: `encodedkey`
    Column Name Data Type Description
    active`bit(1)`If the fee is active or not
    amortizationintervalsettingskey`varchar(32)`Interest Rate Settings holds information about interest rate applied to the product
    amortizationprofile`varchar(256)`The type of amortization profile used for fee
    - `NONE`
    - `SUM_OF_YEARS_DIGITS`
    - `STRAIGHT_LINE`
    - `EFFECTIVE_INTEREST_RATE`
    amount`decimal(50,10)`The amount of the fee
    amountcalculationmethod`varchar(256)`The amount from which the fee is calculated using percentage amount:
    - `FLAT` - a fix value independent from account to which it is applied (used both for loans and savings)
    - `LOAN_AMOUNT_PERCENTAGE` - a percentage from the loan amount of the loan account to which it is applied (used only for loans)
    - `REPAYMENT_PRINCIPAL_AMOUNT_PERCENTAGE`-a percentage from the repayment amount of the loan account to which it is applied(used only for loans)
    applydatemethod`varchar(256)`When should a fee be applied; to be used with monthly deposit fees:
    - `MONTHLY_FROM_ACTIVATION`
    - `FIRST_OF_EVERY_MONTH`
    creationdate`datetime`The date when the fee was created (as UTC).
    encodedkey`varchar(32)`The encoded key for this predefined fee.
    feeamortizationuponrescheduleoption`varchar(256)`Indicates if fee amortization should be continued or finished at account reschedule/refinance. Will be one of `END_AMORTIZATION_ON_THE_ORIGINAL_ACCOUNT` or `CONTINUE_AMORTIZATION_ON_THE_RESCHEDULED_REFINANCED_ACCOUNT` depending on the option which has been selected.
    feeapplication`varchar(256)`The type of fee application when disbursement is applied:
    - `REQUIRED` - fee will be automatically applied into account at disbursement
    - `OPTIONAL` - fee can be applied into account at disbursement. User decide this.
    **Required**.
    id`varchar(256)`The ID given to this fee.
    lastmodifieddate`datetime(3)`The date on which this row was last modified. As UTC.
    loanfees_encodedkey_own`varchar(32)`If this fee is for a loan account, this field will contain the encoded key of the product to which it applies.
    loanfees_integer_idx`int(11)`Shows the index for this fee if there are more than one fee defined for a given loan product.
    name`varchar(256)`The name of the fee
    nontaxablefee`bit(1)`Indicates whether the fee is exempt from tax.
    percentageamount`decimal(50,20)`The amount of the fee in percents applied to percent source
    savingsfees_encodedkey_own`varchar(32)`If this fee is for a savings/deposit account, this field will contain the encoded key of the product to which it applies.
    savingsfees_integer_idx`int(11)`Shows the index for this fee if there are more than one fee defined for a given savings/deposit product.
    taxratesourcekey`varchar(32)`If tax must be applied to this fee, this field will include the encoded key of the tax.
    trigger`varchar(256)`The event that will trigger a fee:
    - `MANUAL` - Not automated, initiated by an user action
    - `DISBURSEMENT` - Applied at loan disbursement. Disbursement fees are subtracted from loan amount at disbursement
    - `CAPITALIZED_DISBURSEMENT` - Applied at loan disbursement. Capitalized fees are not subtracted from loan amount at disbursement
    - `LATE_REPAYMENT` - Applied once for a repayment when it’s due date expired and that repayment was not paid off
    - `MONTHLY_FEE` - Applied every month per account depending on the apply date method
    - `PAYMENT_DUE` - Applied every time a repayment becomes due
    - `ARBITRARY` - Used for the displaying logic of the transactions with arbitrary fees
    ## predefinedfeeamount > an amount of predefined fee that was applied or paid on an account:

    - when a fee is applied, the transaction will have a single `predefinedfeeamount` entry created, that will point to the applied predefined fee

    - when a fee is paid/reduced, the transaction might have multiple `predefinedfeeamount` entries created, one for each fee that was paid/reduced Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`The amount of the fee that was applied/paid in the transaction for the given predefined fee
    encodedkey`varchar(32)`The encoded key for this predefined fee amount.
    fee_encodedkey_oid`varchar(32)`The predefined fee for which the amount was applied/paid. Foreign key to the `predefinedKey` table.
    loanpredefinedfeeamounts_encodedkey_own`varchar(32)`If the fee was applied to a loan account this field will contain the encoded key of the related transaction.
    loanpredefinedfeeamounts_integer_idx`int(11)`If this is one of a number of applied applied for the same transaction then this field will show the index of this particular fee amount, ie. the first amount will have index 0, the second will have index 1 and so on.
    savingspredefinedfeeamounts_encodedkey_own`varchar(32)`If the fee was applied to a savings/deposit account this field will contain the encoded key of the related transaction.
    savingspredefinedfeeamounts_integer_idx`int(11)`If this is one of a number of applied applied for the same savings/deposit account transaction then this field will show the index of this particular fee amount, ie. the first fee will have index 0, the second will have index 1 and so on.
    taxamount`decimal(50,10)`The amount of the taxes on fee that was applied/paid in the transaction.
    transactionid`bigint(20)`Used for capturing the transaction Id of the transaction originally generating this predefined fee amount.
    ## principalpaymentaccountsettings > entity holding the required information for the principal payment process of an account Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`Fixed amount for being used for the repayments principal due
    encodedkey`varchar(32)`The encoded key for this set of settings, this is an autogenerated and globally unique ID.
    percentage`decimal(50,20)`Percentage of principal amount used for the repayments principal due
    ## principalpaymentbasesettings > base class for all the entities grouping settings related to the principal payment process Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID and is used as foreign key to link this row to the `principalpaymentaccountsettings` and `principalpaymentproductsettings` tables.
    includefeesinflooramount`bit(1)`If true, the fee will be included along with the principal in the repayment floor amount, for a revolving credit account.
    includeinterestinflooramount`bit(1)`If true, the interest will be included along with the principal in the repayment floor amount, for a revolving credit account
    principalceilingvalue`decimal(50,10)`The maximum principal due amount a repayment made with this settings can have
    principalfloorvalue`decimal(50,10)`The minimum principal due amount a repayment made with this settings can have
    principalpaymentmethod`varchar(255)`The method of principal payment for revolving credit
    ## principalpaymentproductsettings > entity holding the required information for the principal payment settings stored on a product Primary key: `encodedkey`
    Column Name Data Type Description
    defaultamount`decimal(50,10)`The default principal payment amount for the accounts made after the product using this settings
    defaultpercentage`decimal(50,20)`The default principal payment percentage for the accounts made after the product using this settings
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID. This ID is also used as a foreign key to link to the `loanproduct` table.
    maxamount`decimal(50,10)`The maximum principal payment amount for the accounts made after the product using this settings
    maxpercentage`decimal(50,20)`The maximum principal payment percentage for the accounts made after the product using this settings
    minamount`decimal(50,10)`The minimum principal payment amount for the accounts made after the product using this settings
    minpercentage`decimal(50,20)`The minimum principal payment percentage for the accounts made after the product using this settings
    ## productaccountsettings > this table is for an upcoming feature and more documentation will be provided as the release progresses.
    Column Name Data Type Description
    accountserviceenabled`bit(1)`Whether the account service is enabled. This is an upcoming feature.
    encodedkey`varchar(32)`A unique key.
    productkey`varchar(32)`The unique key of the product.
    producttype`varchar(128)`The type of product.
    ## productarrearssettings > table used for holding the arrears settings for a product. Primary key: `encodedkey`
    Column Name Data Type Description
    defaulttolerancepercentageofoutstandingprincipal`decimal(50,20)`The default tolerance allowed as a percentage of outstanding principal which has been configured for this product and will be suggested for all newly created accounts.
    defaulttoleranceperiod`int(11)`Default tolerance period
    encodedkey`varchar(32)`The encoded key for these settings.
    maxtolerancepercentageofoutstandingprincipal`decimal(50,20)`The mximum tolerance allowed as a percentage of outstanding principal which has been configured for this product.
    maxtoleranceperiod`int(11)`Maximum tolerance period
    mintolerancepercentageofoutstandingprincipal`decimal(50,20)`The minimum tolerance allowed as a percentage of outstanding principal which has been configured for this product.
    mintoleranceperiod`int(11)`Minimum tolerance period
    monthlytoleranceday`int(11)`Represents the monthly arrears tolerance day value..
    ## productinterestratesettings > Stores the interest settings to be used in an adjustable interest rates context. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkeyvarchar(32)The unique primary key for each entry.
    interestproductsettingskeyvarchar(32)The encoded key of the loan product.
    interestratetypevarchar(256)The type of interest rate source (FIXED_INTEREST_RATE or INDEX_INTEREST_RATE).
    indexsourcekeyvarchar(32)The encoded key of the index rate source.
    defaultinterestratedecimal(50,20)The default interest rate defined at product for FIXED interest type.
    maxinterestratedecimal(50,20)The maximum value of FIXED interest rate.
    mininterestratedecimal(50,20)The minimum value of FIXED interest rate.
    interestrateceilingvaluedecimal(50,20)The maximum (ceiling) value of INDEX interest rate.
    interestratefloorvaluedecimal(50,20)The minimum (floor) value of INDEX interest rate.
    interestrateviewcountintInterest rate review frequency unit count.
    interestratereviewunitvarchar(255)Interest rate review frequency measurement unit DAYS, WEEKS, MONTHS.
    ## productoffsetsettings > stores loan product offset settings Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key.
    isoffsetenabled`tinyint(1)`Whether the offset feature is enabled for this product.
    loanproductkey`varchar(32)`The encoded key of the loan product.
    ## productpaymentholidayssettings > **DEPRECATED** Primary key: `encodedkey`
    Column Name Data Type Description
    allowinterestaccrual`tinyint(1)`If set to true then accounts will continue to accrue interest during the payment holiday period.
    encodedkey`varchar(32)`A unique key for these settings.
    productkey`varchar(32)`The encoded key of the loan product.
    ## productredrawsettings > table used for storing the redraw settings available for a product. Primary key: `encodedkey`
    Column Name Data Type Description
    allowredraw`bit(1)`Flag which indicates if the product has the redraw functionality enabled
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID, used as the primary key for this table.
    ## productsecuritysettings > the security settings (guarantors, collateral, investor funds) available for an entity. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID.
    funderinterestcommissionallocationtype`varchar(255)`Define how the Interest is allocated to the investors(if the investors can define their own percentages for their own contribution to the loan, or if all of them are using the same percentage)
    funderinterestcommissionkey`varchar(32)`Constraints for funder interest commission. Foreign key to the `decimalIntervalConstraints` table.
    iscollateralenabled`bit(1)`Whether collateral (assets or other goods) are accepted in order to reach required securities percentage from loan amount, as defined in this product
    isguarantorsenabled`bit(1)`Whether guarantors (other clients) are accepted in order to reach the required securities percentage from loan amount, as defined in this product
    isinvestorfundsenabled`bit(1)`Whether investor funds are accepted in order to allow external funding for an account
    lockfundsatapproval`bit(1)`Whether investor funds are locked or not at the loan account’s approval
    organizationinterestcommissionkey`varchar(32)`Constraints for organization interest commission. Foreign key to the `decimalIntervalConstraints` table.
    requiredguaranties`decimal(50,20)`The securities percentage from loan amount that is needed in order for this account to be approved.
    requiredinvestorfunds`decimal(50,20)`The required investor funds percentage, for opening an account with external funding
    ## repayment > captures the details about repayments which are both due and have been paid off. all repayments belong to a loan account but are also themselves assigned to creditofficer & branches (for performance look-up reasons). a repayment captures the schedule and state of repayment, while the actual transactions are captured in the loantransaction model. Primary key: `encodedkey`
    Column Name Data Type Description
    assignedbranchkey`varchar(32)`Foreign key to the Branch that this account is assigned to
    assignedcentrekey`varchar(32)`Foreign key to the Centre table indicating to which centre the repayment belongs to.
    assigneduserkey`varchar(32)`Foreign key to the User (Credit Officer) who is assigned to his account
    duedate`datetime`Date when this repayment is due (ex: ‘2011-09-07 00:00:00’) (Organization Time). **Required**
    encodedkey`varchar(32)`The unique key for this repayment.
    feesdue`decimal(50,10)`How much fees were originally due on this repayment (for fixed accounts only). This is equivalent to the **Fees Expected** column in the Mambu UI, it will not change with partial payments and always reflect the amount originally due.
    feespaid`decimal(50,10)`How much fees are have been paid on this repayment (for fixed accounts only)
    fundersinterestdue`decimal(50,10)`P2P accounts only - the amount of interest allocated to funders
    interestdue`decimal(50,10)`The amount of interest that was due for this repayment. **Required**.
    interestpaid`decimal(50,10)`The amount of interest paid for this repayment. **Required**.
    lastpaiddate`datetime`Date when the newest repayment has been entered for this repayment (eg, if multiple partial payments - then the latest of those. Null if not paid yet (Organization Time)
    lastpenaltyapplieddate`datetime`Set to the newest date whenever a penalty is applied to this repayment. Or null if no penalty applied (Organization Time)
    notes`varchar(256)`Notes about this repayment. Unused.
    organizationcommissiondue`decimal(50,10)`P2P accounts only - the amount of interest originally due and allocated to organization as commission
    parentaccountkey`varchar(32)`Foreign key to the loan account this repayment belongs to. **Required**
    penaltydue`decimal(50,10)`How much penalty were originally due on this repayment (for fixed accounts only). This is equivalent to the **Penaltiy Expected** column in the Mambu UI, it will not change with partial payments and always reflect the amount originally due.
    penaltypaid`decimal(50,10)`How much penalty has been paid on this repayment (for fixed accounts only)
    principaldue`decimal(50,10)`The amount of principal originally due for this repayment. **Required**. This is equivalent to the **Principal Expected** column in the Mambu UI, it will not change with partial payments and always reflect the amount originally due.
    principalpaid`decimal(50,10)`The amount of principal paid for this repayment. **Required**.
    repaiddate`datetime`Date when this repayment has been fully repaid. Null if not fully repaid yet (Organization Time)
    state`varchar(256)`State of the repayment. Must be one of:

    - `PENDING` - the payment is upcoming and is awaiting to be paid back on the dueDate
    - `LATE` - the repayment is now late (past its due date)
    - `PAID` - the repayment has been paid in full
    - `PARTIALLY_PAID` - the repayment has been partially paid, but not in full
    - `RESCHEDULED` - the repayment balances have been rescheduled into other repayments
    - `GRACE` - this repayment is part of a grace period or it has been reduced through the Reduce Number of Installments (RNI) prepayment recalculation method
    taxfeesdue`decimal(50,10)`The amount originally due as tax for fees. This is included in the **Taxes Expected** column in the Mambu UI, it will not change with partial payments and always reflect the amount originally due.
    taxfeespaid`decimal(50,10)`The amount of taxes paid relating to fees charged on the account.
    taxinterestdue`decimal(50,10)`The amount of taxes that are due at a specified moment in time relating to interest payments. This is included in the **Taxes Expected** column in the Mambu UI, it will not change with partial payments and always reflect the amount originally due.
    taxinterestpaid`decimal(50,10)`The amount of taxes that were paid by the user relating to an interest payment
    taxpenaltydue`decimal(50,10)`The amount of tax due relating to a penalty payment. This is included in the **Taxes Expected** column in the Mambu UI, it will not change with partial payments and always reflect the amount originally due.
    taxpenaltypaid`decimal(50,10)`The amount of tax paid relating to a penalty payment.
    ## repaymentdays > stores a loan account’s fixed days of month settings.
    Column Name Data Type Description
    accountkey`varchar(32)`The encoded key of the loan account. Links to the `loanaccounts` table.
    day`tinyint(2)`The day of the month on which the repayment should fall.
    ## repaymentfeedetails > a model used to keep fee details (fee due, fee paid and taxes per predefinedfee type) for a specific repayment. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The unique ID for these repayment fee details.
    feedue`decimal(50,10)`The total fee due for the linked PredefinedFee on this repayment.
    feepaid`decimal(50,10)`The total fee paid for the linked PredefinedFee on this repayment.
    feereduced`decimal(50,10)`The amount of fees when they have been reduced, for example, during a grace period.
    loantransactionkey`varchar(32)`The key of the loan transaction of LoanTransactionType FEE type which contains the predefined fee (in PredefinedFeeAmount) for which the amount was applied/paid for the linked repayment
    repaymentfeedetails_encodedkey_own`varchar(32)`The encoded key of a repayment in the `repayments` table to which these details relate.
    repaymentfeedetails_integer_idx`int(11)`If there are more than one fee for the same repayment then this will show this fee’s index in that list.
    taxonfeedue`decimal(50,10)`The amount of tax on fee due for the linked PredefinedFee on this repayment.
    taxonfeepaid`decimal(50,10)`The amount of tax on fee paid for the linked PredefinedFee on this repayment.
    taxonfeereduced`decimal(50,10)`The amount of tax due on fees when they have been reduced, for example, during a grace period.
    ## repaymentsscheduleversioning Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    id`bigint(20)`
    loanaccountchangedeventkey`varchar(32)`Key of an entry in the `loanaccountchangedeventkey` table.
    loantransactionkey`varchar(32)`The ID of the loan transaction. Foreign key, an entry in the `loantransaction` table.
    parentaccountkey`varchar(32)`The encoded key of an account in the `loanaccount` table.
    versioningcontent`json`
    ## repaymentunappliedfeedetails > a model used to keep fee details for unapplied fee (fee due and taxes per predefined fee type) for a specific loan repayment. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key.
    feedue`decimal(50,10)`The total fee due for the linked predefinedfee of this repayment
    indexinlist`int(11)`An index for cases where there is more than one unapplied fee for a single repayment.
    predefinedfeekey`varchar(32)`The key of the entry in the `predefinedfee` containing the type of fee which contains the predefined fee amount (in the `predefinedfeeamount` table) that was not applied for the linked repayment.
    repaymentkey`varchar(32)`The key of the entry in the `repayment` table to which this entity belongs.
    taxonfeedue`decimal(50,10)`The amount of tax due for this repayment.
    ## revolvingproductsettings > Holds revolving loan products specific settings. Primary key: `productkey`
    Column Name Data Type Description
    billingcycleenabled`tinyint(1)`Indicates whether a periodic billing cycle is enabled for this loan product.
    productkey`varchar(32)`The encoded key of the product.
    ## role > holding information about roles for users. Primary key: `encodedkey`
    Column Name Data Type Description
    accessrights`mediumblob`An encoded representation of the permissions assigned to this role.
    creationdate`datetime`The date when the role was created. Stored as UTC
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `user` and `usagerightsroleassignment` tables.
    id`varchar(256)`The manually entered ID for this role.
    isadministrator`bit(1)`Whether the role is for a user who should have administrator privileges.
    iscreditofficer`bit(1)`Whether the role is for a Credit Officer type user.
    isdelivery`bit(1)`Whether the role is for members of the Mambu delivery team who may assist in setting up your Mambu system.
    issupport`bit(1)`Whether the role is for a support user.
    isteller`bit(1)`Whether or not this user has the ‘teller’ role.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    name`varchar(256)`The name of the role.
    notes`mediumtext`Notes about the role which have been entered via the Mambu UI.
    permissions_encodedkey_oid`varchar(32)`Links to the an entry in the `permissions` table containing more permissions and whether they are enabled for this role.
    ## savingsaccount > a savings account representing also a daily account, a term-deposit or a checking account is essentially the current account of the client where deposits and withdrawals can be made. Primary key: `encodedkey`
    Column Name Data Type Description
    accountholderkey`varchar(32)`Foreign key reference to the Client or Group which is holding on this account. **Required**
    accountholdertype`varchar(256)`The type of account holder this group has. Must be one of the following and direct to the key referred to by accountHolderKey
    - `CLIENT`
    - `GROUP`
    **Required**
    accountstate`varchar(256)`Current state of the account. Must be on one of:
    - `PENDING_APPROVAL` - created but not active and is pending approval
    - `APPROVED` - approved but not yet active (ie, no transaction have yet occurred)
    - `ACTIVE` - account is active and is collecting interest, deposits and withdrawals may be made
    - `ACTIVE_IN_ARREARS` - Account is active but has outstanding balance
    - `MATURED` - only for fixed deposits or savings plan: the account has matured and the money may be withdrawn
    - `LOCKED` - the account is locked and may not be used further unless unlocked
    - `DORMANT` - Savings account state used for accounts that had been inactive for a number of days (Defined in savings product)
    - `CLOSED` - the account was full emptied and closed because it was no longer being used
    - `CLOSED_WRITTEN_OFF` - Account has been closed and any remaining balance due has been written off
    - `WITHDRAWN` - if the client withdrawn the original application for the account
    - `CLOSED_REJECTED` - Account has gone through the application process and has been rejected
    **Required**
    accounttype`varchar(256)`
    Type of savings account. This must be one of:
    - `REGULAR_SAVINGS` - a current account
    - `FIXED_DEPOSIT` - a deposit is made for a certain time period until it reaches maturity
    - `SAVINGS_PLAN` - deposits are made over a time until a target or time period is reached
    Required
    accruedinterest`decimal(50,10)`How much interest has been accrued into the account.
    activationdate`datetime`Date when this saving account was activated (Organization Time)
    allowoverdraft`bit(1)`Whether this account may be overdrawn
    approveddate`datetime`The date on which the account was approved.
    assignedbranchkey`varchar(32)`Foreign key to the Branch that this account is assigned to
    assignedcentrekey`varchar(32)`Foreign key to the Centre table indicating to which centre the savings account belongs to.
    assigneduserkey`varchar(32)`Foreign key to the User (Credit Officer) who is assigned to his account
    balance`decimal(50,10)`The current balance of the account. **Required**.
    blockedbalance`decimal(50,10)`The amount of this account’s funds which are unavailable for use because they are blocked.
    closeddate`datetime`Set to when the account was closed (or null if never) (Organization Time)
    creationdate`datetime`The date when the savings account was created.Stored as UTC.
    currencycode`varchar(32)`The currency code associated to this product.Required.
    encodedkey`varchar(32)`The encoded key for this database entry. This ID can be used with our API to get details on or update a specific Savings Account.
    feesdue`decimal(50,10)`How much fees is due to be paid on this account
    forwardavailablebalance`decimal(50,10)`Stores the positive hold balance for a savings account.
    holdbalance`decimal(50,10)`Hold balance of the account (it is included in balance). **Required**
    id`varchar(32)`Unique ID of the savings account. **Required**
    interestdue`decimal(50,10)`How much interest is due to be paid on this account
    interestpaymentdates`mediumblob `List of all dates on which the interest is payed into savings account
    interestpaymentpoint`varchar(256)`Specifies when the interest should be paid to the account (Eg. `FIRST_DAY_OF_MONTH`, `EVERY_3_MONTHS`, etc)
    interestsettingskey`varchar(32)`Foreign key to the `interestaccountsettings` table where the configuration for interest for this account is stored.
    lastaccountappraisaldate`datetime`Date when the account has last been evaluated for interest calculation/maturity. Null if never (UTC)
    lastinterestcalculationdate`datetime`Date when/if this account has the interest last calculated. Null if never (Organization Time)
    lastintereststoreddate`datetime`Date when the account had last the interest applied (that is, stored from accrued to the balance). Null if never (Organization Time)
    lastmodifieddate`datetime`The date when the savings account was modified last time. Stored as UTC.
    lastoverdraftinterestreviewdate`datetime`When the overdraft interest was last time reviewed (as Organization Time)
    lastsettoarrearsdate`datetime`The last time this account went into arrears.
    lineofcreditkey`varchar(32)`The key to the line of credit where this account is registered
    lockedbalance`decimal(50,10)`Locked balance of the account(it is included in balance). No operation can modify the balance of the account and get it lower than this locked balance
    lockeddate`datetime`The date when the account was locked(null if not closed). Saved as Organization Time.
    maturitydate`datetime`For a fixed or compulsory savings plan, this is when the account matures (Organization Time)
    maxdepositbalance`decimal(50,10)`The maximum depisit balance, if set.
    maxwidthdrawlamount`decimal(50,10)`The max amount that can be withdrawn at any time (or null if no limit)
    migrationeventkey`varchar(32)`Foreign key to the `dataMigrationEvent` table: references the particular operation if this account was created as part of a data import.
    name`varchar(256)`The name of the loan account. Often same as the savings product name. **Required**.
    negativeinterestaccrued`decimal(50,10)`The amount of interest accrued when the interest rate is negative.
    notes`mediumtext`HTML notes about this savings account.
    overdraftamount`decimal(50,10)`How much money has been taken out in overdraft
    overdraftexpirydate`datetime`The date after which the account is considered in arrears (as Organization Time)
    overdraftinterestaccrued`decimal(50,10)`The amount of overdraft interest that has been accrued in the account
    overdraftinterestsettingskey`varchar(32)`References the entry in the `interestaccountsettings` table where settings concerning overdrafts are configured for this account.
    overdraftlimit`decimal(50,10)`how much may be taken out as overdraft.
    producttypekey`varchar(32)`Foreign key to the SavingsProduct which this account is based on. **Required**
    recommendeddepositamount`decimal(50,10)`For account which have a recommended deposit amount
    targetamount`decimal(50,10)`For savings plans, this is the savings target amount
    technicalinterestdue`decimal(50,10)`How much interest is due to be paid on this account due to technical overdraft
    technicaloverdraftamount`decimal(50,10)`How much money has been taken from unplanned overdraft. This balance is usually used when doing advice cards operation(offline cards transactions)
    technicaloverdraftinterestaccrued`decimal(50,10)`The amount of technical overdraft interest that has been accrued in the account
    withholdingtaxsourcekey`varchar(32)`The tax source from where the account withholding taxes will be updated. Can be null, in which case the account will not have withholding taxes
    ## savingsaccountcustomvalue > Holds values for custom information for savings accounts. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## savingsaccountdailyaccruedinterest > stores daily interest accrual for savings accounts. Primary key: `id`
    Column Name Data Type Description
    accountkey`varchar(32)`The unique key of the account.
    accruedinterest`decimal(60,20)`The amount of accrued interest.
    id`bigint(20)`Primary key for rows in this table.
    lastinterestcalculationdate`datetime`The date and time at which the accrued interest was last calculated.
    lastmodifieddate`datetime`The last time this row was modified. **UTC**
    negativeinterestaccrued`decimal(60,20)`The amount of interest accrued when the interest rate is negative.
    overdraftinterestaccrued`decimal(60,20)`The amount of interest accrued due to the account being overdrawn.
    technicaloverdraftinterestaccrued`decimal(60,20)`The amount of interest accrued due to technical overdraft of the account.
    ## savingsproduct > stores templates that specify some predefined information and constraints that are then applied to the savings accounts, associated with a specific savings product. products can be defined for individuals and groups and has a specified interest rate and the interest calculation frequency. Primary key: `encodedkey`
    Column Name Data Type Description
    accountingmethod`varchar(256)`The current accounting state for this product
    - `NONE` - accounting is deactivated
    - `CASH` - uses cash accounting
    - `ACCRUAL` - uses accrual accounting
    activated`bit(1)`Whether this product can be used or not.
    allowarbitraryfees`bit(1)`Only if true users will be able to apply fees, for current object, of type ‘Other’; these fees can have any amount
    allowoffset`bit(1)`Specify if the product allow to create accounts which can be used as offset for loans
    allowoverdraft`bit(1)`Whether the accounts for this product may be overdrawn
    allowtechnicaloverdraft`bit(1)`Indicates whether these accounts are allowed to go into technical overdraft, which can happen, for example, in accounts with credit or debit cards.
    category`varchar(256)`The category of this savings product. This helps organise products into business areas. Can be `UNCATEGORIZED`, `PERSONAL_DEPOSIT`, `BUSINESS_DEPOSIT`, `DAILY_BANKING_ACCOUNTS`, `BUSINESS_BANKING_ACCOUNTS`, `STORED_VALUE_ACCOUNTS`.
    collectinterestwhenlocked`bit(1)`Whether locked accounts still collect Interest or not (default is true)
    creationdate`datetime`The date when the savings product was created. Stored as UTC
    defaultmaturityperiod`int(11)`How long a fixed deposit or a savings plan can have a maturity period (the default period)
    defaultopeningbalance`decimal(50,10)`The constraint for the default opening balance for a saving account using this product
    description`mediumtext`The savings product description
    dormancyperioddays`int(11)`Specifies the number of days for an account to change the state to Dormant
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case the `predefinedfee`, `savingsproductbranch`, `savingsaccount` and `savingstransaction` tables.
    forallbranches`bit(1)`Field to indicate if this product is available for all branches
    forgroups`bit(1)`If the product is available for groups
    forindividuals`bit(1)`If the product is available for individual entities
    id`varchar(32)`Unique ID of the savings product (specified by the user). **Required**
    idgeneratortype`varchar(256)`The type of the ids that will be generated:
    - `RANDOM_PATTERN` - uses a given pattern to generate IDs
    - `INCREMENTAL_NUMBER` - increments a given number to generate IDs
    idpattern`varchar(256)`The pattern, containing ‘@’ for letters and ‘#’ for digits, for the `RANDOM_PATTERN` or the starting number for the `INCREMENTAL_NUMBER`
    interestaccruedaccountingmethod`varchar(32)`Method being used for maintaining the interest accrued method for the loan product
    interestcalculationbalance`varchar(256)`The balance which is used for the Interest calculation
    - `MINIMUM` - the minimum balance during that time period
    - `AVERAGE` - the average balance during that time period
    interestdaysinyear`varchar(256)`How many days in a year should be used for interest calculations
    interestpaidintoaccount`bit(1)`Whether the accounts for this product have interest paid into account
    interestpaymentdates`mediumblob `List of all dates on which the interest is applied into savings account
    interestpaymentpoint`varchar(256)`Specifies when the interest should be paid to the account:
    - `FIRST_DAY_OF_MONTH` - interest is paid on day 1 of each month
    - `EVERY_WEEK` - for every week, interest should be paid out each 14 days, first time is after 14 days since the account went active
    - `EVERY_OTHER_WEEK` - for every 2 weeks, interest should be paid out each 14 days, first time is after 14 days since the account went active
    - `EVERY_MONTH` - interest should be paid out after a month since activation. e.g. May 12th went active, so post on June 12th, July 12th
    - `EVERY_3_MONTHS` - interest should be paid out after 3 months (quarterly) since activation. e.g. May 12th went active, so post on August 12th
    interestratesettingskey`varchar(32)`Foreign key to the `interestProductSettings` table: Settings for the account interest rate.
    lastmodifieddate`datetime`The date when the savings product was modified last time. Stored as UTC.
    lineofcreditrequirement`varchar(255)`Specifies whether accounts created after this product can/should be part of a line of credit
    Possible values:
    - `OPTIONAL` (account can be part of a line of credit)
    - `REQUIRED` (account should be part of a line of credit)
    - `NOT_REQUIRED` (account should not be part of a line of credit)
    maturityperiodunit`varchar(256)`How long a fixed deposit or a savings plan can have a maturity period:
    - `DAYS`
    - `WEEKS`
    - `MONTHS`
    maximumbalance`decimal(50,10)`The maximum balance this account can hold
    maxmaturityperiod`int(11)`How long a fixed deposit or a savings plan can have a maturity period (the maximum period)
    maxopeningbalance`decimal(50,10)`The constraint for the maximum opening balance for a saving account using this product
    maxoverdraftinterestrate`decimal(50,10)`The maximum overdraft interest account which can be set for accounts created using this product.
    maxoverdraftlimit`decimal(50,10)`How much money may be taken out for the account to go negative
    maxwidthdrawlamount`decimal(50,10)`Maximum amount per withdrawal
    minmaturityperiod`int(11)`How long a fixed deposit or a savings plan can have a maturity period (the minimum period)
    minopeningbalance`decimal(50,10)`The constraint for the minimum opening balance for a saving account using this product
    minoverdraftinterestrate`decimal(50,10)`The minimum overdraft interest account which can be set for accounts created using this product.
    name`varchar(256)`The name of the product.
    overdraftdaysinyear`varchar(256)`Number of days in year for which to accrue interest for overdraft account
    Days in a year methodology used for interest calculations for this product
    - `ACTUAL_365_FIXED`
    - `ACTUAL_364`
    - `ACTUAL_360`
    - `E30_360`
    overdraftinterestcalculationbalance`varchar(256)`Which calculation will be used to calculate overdraft interest: `MINIMUM` - the lowest balance the account had that day, `END_OF_DAY` - the balance recorded after completion of all end of day jobs.
    overdraftinterestratesettingskey`varchar(32)`Foreign key to the `interestProductSettings` table: Settings for the overdraft interest rate.
    producttype`varchar(256)`The type of savings product/account. This influences the behavior and possible parameters of the account.
    The savings type can be:
    - `CURRENT_ACCOUNT` - a current which fully allows withdrawals/deposits and overdrafts
    - `REGULAR_SAVINGS` - a standard savings which fully allows withdrawals/deposits
    - `FIXED_DEPOSIT` - a fixed deposit where one deposit is made for a certain time period until it reaches maturity
    - `SAVINGS_PLAN` - a savings plan where savings deposits are made over a certain time period usually with the goal of reaching some savings target. once the time period has expired the account is ‘matured’ and withdrawals can be made


    recommendeddepositamount`decimal(50,10)`Recommended amount for a deposit
    withholdingtaxenabled`bit(1)`Whether withholding taxes are enabled for this product or not
    ## savingsproductbranch > stores the association between a savings product and the branches where it is available. Primary key: `encodedkey`
    Column Name Data Type Description
    branchkey`varchar(32)`Foreign key to `branch` table: The key of the branch that is associated with a savings product.
    encodedkey`varchar(32)`The encoded key for this database entry.
    productkey`varchar(32)`Foreign key to `savingsProduct table: The savings product that is associated with a branch.
    ## savingstransaction > keeps track of all transactions which occur with savings accounts such as state changes, repayments, fees, etc. Primary key: `encodedkey`
    Column Name Data Type Description
    amount`decimal(50,10)`Amount of the transaction. For example, this may be the amount of repayment or for certain transactions may be null (for state changes for instance.) The amount is expressed relative to how it affects the balance. If a repayment is adjusted (reduced) the amount will be a negative balance
    balance`decimal(50,10)`Running balance for the savings account including this current transaction.
    branchkey`varchar(32)`Foreign key to the branch where this transaction was performed.
    centrekey`varchar(32)`Foreign key to the centre where this transaction was performed.
    comment`varchar(256)`Comment for the savings transaction.
    creationdate`datetime`When the transaction occurred (as UTC)
    currencycode`varchar(32)`Currency code for current transaction.
    details_encodedkey_oid`varchar(32)`Details about the current savings transaction
    encodedkey`varchar(32)`The encoded key for this database entry.
    entrydate`datetime`Date of the entry (eg date of repayment or disbursal, etc.). As **Organization Time**
    externalid`varchar(36)`The ID set by the customers that accepts alpha-numeric characters, underscore and dash. Can be null
    feesamount`decimal(50,10)`Amount of fees involved in a transaction that affects an account with positive balance
    fractionamount`decimal(50,10)`In a case of an Loan Fraction Bought transactions, this represent the fraction amount which was bought from another investor.
    fundsamount`decimal(50,10)`Balance change amount involved in a transaction that affects an accountwith positive balance
    interestamount`decimal(50,10)`Amount of interest involved in a transaction that affects an account with positive balance
    interestrate`decimal(50,20)`The interest rate that was set or changed in this transaction. Used on product interest rate changes or interest tier switches.
    linkedloantransactionkey`varchar(32)`Foreign key to the LoanTransaction which is associated with this transaction (for example a transfer which causes a repayment)
    linkedsavingstransactionkey`varchar(32)`Foreign key to the SavingsTransaction which is associated with this transaction (for example a transfer which causes a deposit)
    migrationeventkey`varchar(32)`Foreign key to the `dataMigrationEvent` table: If this transaction was created during import, track which `migrationevent` they came from.
    overdraft_indexrate_key`varchar(32)`Foreign key to the `indexRate` table: The index overdraft interest rate that was set or changed in this transaction.
    overdraftamount`decimal(50,10)`Balance change amount involved in a transaction that affects an overdraft
    overdraftfeesamount`decimal(50,10)`Fees amount involved in a transaction that affects an overdraft
    overdraftinterestamount`decimal(50,10)`Interest amount involved in a transaction that affects an overdraft
    overdraftinterestrate`decimal(50,20)`The overdraft interest rate that was set or changed in this transaction. Used on product interest rate changes or interest tier switches.
    overdraftlimit`decimal(50,10)`The overdraft limit that was set or changed in this transaction
    parentaccountkey`varchar(32)`Foreign key to the savings account this transaction refers to. **Required**
    paymentorderid`varchar(36)`The payment order ID for transactions which were created via the Mambu Payments Gateway, for example, a SEPA Direct Debit or Credit Transfer.
    preciseinterestamount`decimal(50,20)`Interest amount without rounding(for now populated only for P2P).
    producttypekey`varchar(32)`Link to the product to which the account owning this transaction belongs to.
    reversaltransactionkey`varchar(32)`Foreign key to another savings transaction (to self - SavingsTransaction.encodedKey) where the reversal of the current transaction was made. It’s null if the transaction wasn’t reversed.Example: This transaction represents a fee applied transaction. If this transaction will be reversed, another transaction will be logged and this transaction will remember the key of the one where the reversal was made.
    taxrate_encodedkey_oid`varchar(32)`Foreign key to the `indexRate` table: The tax rate that was set or changed in this transaction.
    technicaloverdraftamount`decimal(50,10)`Balance change amount involved in a transaction that affects an technical overdraft
    technicaloverdraftinterestamount`decimal(50,10)`Interest amount involved in a transaction that affects an technical overdraft
    tillkey`varchar(32)`The till key associated with this transaction
    transactionid`bigint(20)`Auto-increment unique ID of the savings transaction. **Required**
    transactionperformerkey`varchar(32)`
    type`varchar(256)`Type the transaction. Must be one of:
    - `CREATION` - the account was created (**DEPRECATED**)
    - `EDIT` - the account was modified (**DEPRECATED**)
    - `STATE_CHANGE` - the account’s state changed, eg for an Approval (**DEPRECATED**)
    - `DEPOSIT` - a deposit into the account
    - `WITHDRAWAL` - a withdrawal from the account
    - `ADJUSTMENT` - an adjustment on a deposit
    - `INTEREST_APPLIED` - accrued interest has been applied to the account
    - `FEE_APPLIED` - a fee was applied to the account
    - `FEE_ADJUSTED` - a previously applied fee was adjusted
    - `WRITE_OFF` - an account written off
    - `WITHDRAWAL_ADJUSTMENT` - an adjustment to a withdrawal
    - `ADJUSTMENT` - reversal of a deposit
    - `BEGIN_MATURITY_PERIOD` - the start of a maturity period for an account (**DEPRECATED**)
    - `BRANCH_CHANGED` - marks the moment when the parent account is assigned to a different branch
    - `FEE_REDUCTION_ADJUSTMENT` - reversal for `FEES_DUE_REDUCED`
    - `FEES_DUE_REDUCED` - a fee being decreased
    - `IMPORT` - an account being imported
    - `INTEREST_APPLIED_ADJUSTMENT` - reversal for the `INTEREST_APPLIED` transaction
    - `INTEREST_RATE_CHANGED` - there was a change to the interest rate for this account
    - `LOAN_FUNDED` - investor funds amount being transferred to the linked loan account
    - `LOAN_FUNDED_ADJUSTMENT` - reversal for the `LOAN_ACCOUNT_FUNDED` transaction
    - `LOAN_REPAID` - investor funds amount being collected from the linked loan account
    - `LOAN_REPAID_ADJUSTMENT` - reversal for the `LOAN_REPAID` transaction
    - `OVERDRAFT_INTEREST_RATE_CHANGED` -the overdraft interest rate has changed
    - `TRANSFER` - a transfer being made
    - `TRANSFER_ADJUSTMENT` - a transfer being adjusted (reversed)
    - `UNDO_BEGIN_MATURITY_PERIOD` - reversing the start of the maturity period for the account (**DEPRECATED**)
    - `WITHDRAWAL` - a withdrawal being made
    - `WITHDRAWAL_ADJUSTMENT` - a withdrawal being adjusted
    - `WITHHOLDING_TAX` - tax being applied over an interest amount (the interest which the clients earn, not the one from the overdrafts)
    - `WITHHOLDING_TAX_ADJUSTMENT` - reversal for the `WITHHOLDING_TAX` transaction
    - `WRITE_OFF_ADJUSTMENT` - the overdraft write off being adjusted
    **Required**
    userkey`varchar(32)`Foreign key to the User who performed this transaction. If null, it means this was a system-performed transactions (such as an automatic penalty)
    ## savingstransactioncustomvalue > Holds values for custom information for savings transactions. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## savingstransactionguarantymapping > saves mapping information between investorfund and savingstransaction Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    newguarantykey`varchar(32)`Foreign key to the `guaranty` table: The ID of the new guaranty settings after a change.
    oldguarantykey`varchar(32)`Foreign key to the `guaranty` table: The ID of the original guaranty settings.
    savingstransactionkey`varchar(32)`Foreign key to the `savingsTransaction` table: The ID of the transaction to which these guaranty settings relate.
    ## savings_transactions_daily_summary > Entity holding daily aggregated transaction and balance summaries for savings accounts. :::note This table is partitioned by range based on the year and month of the `entry_date`, and has an index on the `entry_date` column for performance. ::: Primary key: `saving_account_encodedkey` + `entry_date`
    Column Name Data Type Description
    saving_account_encodedkey`varchar(32)`The encoded key of the associated savings account.ß
    entry_date`date`The specific date for which the transactions and balances are aggregated.
    avg_balance`decimal(50,20)`The average balance of the savings account for the given entry date.
    total_balance`decimal(50,20)`The total or closing balance of the savings account for the given entry date.
    min_balance`decimal(50,20)`The lowest recorded balance of the savings account during the entry date.
    transactions_number`int`The total number of transactions that occurred on the savings account on the entry date.
    ## savingstransactiontoexternal > This is an internal table which may be used to record when transactions are simultaneously transmitted to other services, such as when new features are being tested and you have elected to be part of a pre-release testing programme. Primary key: `savingstransactionencodedkey`
    Column Name Data Type Description
    creationdate`datetime(6)`When the transaction occurred (as UTC).
    errors`varchar(512)`Whether any errors ocurred during the process of syncing this transaction to an ancialliary service.
    externalencodedkey`varchar(255)`
    externaltype`varchar(16)`Details about the external system to whom is the request sent, for example `MBU_LENDING` for the Mambu lending module.
    savingstransactionencodedkey`varchar(32)`The external key of the savings transaction.
    status`varchar(16)`Status of the current transaction, `CREATED`, `SUCCEEDED` or `FAILED`.
    updatedate`datetime(6)`When the transaction was updated (as UTC).
    ## scheduledjobsummary > this table holds details on scheduled jobs including those run as eod processes. Primary key: `encodedkey`
    Column Name Data Type Description
    backgroundprocesskey`varchar(32)`Foreign key to an entry in the `backgroundprocess` table. Many jobs in this table can be related to one background process.
    creationdate`datetime(3)`The date when this job was created. Stored as UTC
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    enddate`datetime(3)`The date and time at which the job was completed. **UTC**
    noentities`bigint(32)`The number of entities which were affected by this scheduled job.
    processingtime`bigint(32)`The time taken to complete the job, in seconds.
    scheduledjobcategory`varchar(32)`Whether the job is a general `ORGANIZATION` task, relates to `ACCOUNTS`, `LOANS`, `SAVINGS`, or `OTHER`.
    scheduledjobtype`varchar(128)`The type of job which has been scheduled.
    startdate`datetime(3)`The date and time at which the job started. **UTC**
    ## scheduledprocess > model for a scheduled process (one time run, at midnight) like the job of updating all account settings from a savingsproduct. this kind of jobs are currently initiated by changes in the products that need to be mirrored also in the accounts. Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when this row was created. Stored as UTC
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    enddate`datetime`The time at which the scheduled process ended.
    entitykey`varchar(32)`Link to the entity, for example, the savings product, where settings are held.
    startdate`datetime`The date and time at which the scheduled process started.
    status`varchar(255)`The status of this process, for example started, completed, etc..
    type`varchar(255)`The process type, the job type used to correlate the process with the actual jobs that needs to be executed. For example `UPDATE_SAVINGS_ACCOUNTS_SETTING_FROM_PRODUCT`, `UPDATE_LOAN_ACCOUNTS_SETTINGS_FROM_PRODUCT`, `UPDATE_JOURNAL_ENTRIES_FOR_INTEREST_ACCRUAL`.
    ## securitysettings > stores the custom organization security settings (session timeout, password complexity, ip address restrictions, maximum number of consecutive failed logins allowed, failed login wait time, password reset link expiration time, whether to re-authenticate on critical actions, the password expiration days etc.). Primary key: `encodedkey`
    Column Name Data Type Description
    creationdate`datetime`The date when these settings were created. Stored as UTC
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables.
    failedloginwaittime`int(11)`The time a user will have to wait before attempting to log in after a failed attempt.
    ipaddressrestrictions`mediumblob `If the option to restrict access by IP has been enabled, this field will hold the list of allowed IP addresses.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    lockuserafterfailedloginattempts`int(32)`Indicates the number of failed login attempts a user is allowed before their account is locked. Once locked it can only be unlocked by an administrator.
    lockuserafterfailedloginattemptswithinminutes`int(32)`Indicated the number of minutes over which failed login attempts will be counted. For example, if set to 10 minutes, the count of failed attempts will reset to 0 10 minutes after the last attempt.
    maxfailedloginscountbeforecaptcha`int(11)`The number of failed login attempts a user will be allowed before they will need to prove they are human by completing captcha.
    minpasswordlength`int(11)`The minimum length of a password created for a user account.
    passwordexpirationactivationdate`datetime`The first day from which the password expiration countdown started.
    passwordexpirationdays`int(32)`The number of days before a user will be prompted to change their password.
    passwordresetlinkexpiretimehours`int(11)`The amount of time before the link to reset a password included in an email will expire.
    reauthenticateoncriticalactions`bit(1)`Indicates whether users will be asked to enter a password when performing certain actions via our UI.
    restrictedsecuritygroups`mediumblob `If IP address whitelisting has been enabled, this contains an array of the user types (admins, users and API users) to which this restriction will be applied.
    restrictuseraccessip`bit(1)`Whether access to the UI, API or Admin functions should be restricted only to certain IP addresses.
    sessiontimeout`int(11)`The number of minutes before a session expires. This value only applies to the Mambu UI.
    ## sequence_table > This is a technical table which tracks the next available number for entities or processes which are assigned sequential IDs. Primary key: `sequence_name`
    Column Name Data Type Description
    next_val`bigint(20)`The next value available to be used for sequential numbering.
    sequence_name`varchar(255)`The name of the process with sequential numbering, for example, tasks, documents or activites.
    ## smsnotificationsettings > containing the credentials and settings for the sms notifications. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry.
    fromnumber`varchar(255)`The telephone number which will appear as the sender on the recipient’s device.
    gateway`varchar(255)`Indicates which of the supported SMS gateway providers, Twilio or Infobip, you are using to send SMS.
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    password`varchar(255)`The password to your account at the SMS gateway provider.
    username`varchar(255)`The username used to log in to your SMS gateway provider.
    ## task > represents a human task that can be assigned by a user to another one. it can be related to a client or a group and also a due date can be specified for it. Primary key: `encodedkey`
    Column Name Data Type Description
    assigneduserkey`varchar(32)`User assigned to the task. Foreign key to the `user` table.
    completiondate`datetime`Organization time states the date the task was completed
    createdbyuserkey`varchar(32)`The key of the user who created the task
    creationdate`datetime`UTC date of creation of the task
    description`longtext,`Description, notes of the task
    duedate`datetime`Organization time states the due date of the task
    encodedkey`varchar(32)`The encoded key for this task. This field should not be changed as it may be used as a foreign key to link with other tables as well as act as the index for this table.
    id`bigint(20)`The id of the task
    lastmodifieddate`datetime`UTC date of last modification
    status`varchar(256)`ask status with valid values:
    - `OPEN`
    - `COMPLETED`
    tasklinkkey`varchar(32)`Specifies who is the link to this task. If null, means nobody is linked to this task
    tasklinktype`varchar(256)`Type of the link. Valid values:
    - `CLIENT`
    - `GROUP`
    - `LOAN_PRODUCT`
    - `SAVINGS_PRODUCT`
    - `CENTRE`
    - `BRANCH`
    - `USER`
    - `LOAN_ACCOUNT`
    - `DEPOSIT_ACCOUNT`
    title`varchar(256)`Title, summary of the task
    ## tenant Primary key: `id`
    Column Name Data Type Description
    connectionpassword`varchar(64)`
    connectionurl`varchar(512)`
    connectionusername`varchar(64)`
    creationdate`datetime`The date when this tenant was created. Stored as UTC
    id`varchar(64)`
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    name`varchar(128)`The tenant name.
    ## till > a till represents a concept introduced by the tellering feature. it can be a physical cash box a teller uses, or just a concept such as a when a manager hands cash to a credit officer who leaves for the day (he is then a ‘virtual’ till)
    the typical process is that at the beginning of the work day a manager takes out cash from the vault at a branch and distributes it to various tills. they need to keep track how much is in each till. the tills are then assigned to staff (tellers) who perform transactions during the day with the cash.
    at the end of the day, they close the till by counting up all the cash, checking it against the transactions that occurred and ensuring there’s no discrepancy. the teller may be held responsible for any shortage of cash. the manager then may choose to transfer the cash back to the vault (or it might stay in the till overnight). Primary key: `encodedkey`
    Column Name Data Type Description
    balance`decimal(50,20)`The amount of money existing in the till (expected cash in till)
    balanceconstraintstype`varchar(32)`One of:
    - `HARD` - if a new transaction posted brings the balance in the Till beyond the specified thresholds, the Teller will get an error message and it will not be possible to post the transaction,
    - `SOFT` - if a new transaction posted brings the balance in the Till beyond the specified thresholds, then the Teller will get a warning message, but the transaction will still be posted,
    - `NONE`- no limits on the balance.
    balancedifference`decimal(50,10)`The difference between the closing amount of the till and the expected amount
    closeddate`datetime`The date when the till was closed (as Organization Time).
    closingbalance`decimal(50,10)`The amount entered by the user as the available amount in till at its closing time
    creationdate`datetime`The date when this till was created. Stored as UTC
    encodedkey`varchar(32)`The encoded key for this database entry, this is an autogenerated and globally unique ID and is not the same as any internal ID you may have given your till. This field should not be changed as it may be used as a foreign key to link with other tables.
    id`varchar(32)`The id of the till
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    maxbalance`decimal(50,10)`The fields specifies the maximum balance. When tellers reach the maximum allowed balance, they should transfer to vault.
    minbalance`decimal(50,10)`This field specifies the minimum till balance. Tellers shouldn’t be able to post a withdrawal if they don’t have enough cash balance => minimum balance should be zero.
    openeddate`datetime`The date when the till was opened (as Organization Time).
    originaltillkey`varchar(32)`Used for when reopening a till. When the till is reopened this field is populated with the encoded key of the closed till
    state`varchar(256)`Till state:
    - `OPEN` - Value used after a till was created. When in this state a till can have money added or removed from the opening amount and its balance can be affected by transactions logged by the assigned teller
    - `CLOSED` - Value used to mark the till as not-required. In this state, the till cannot have its opening amount or balance changed anymore.
    tellerkey`varchar(32)`The key of the teller for which this till is assigned to
    userkey`varchar(32)`The key of the user who created this till
    vaultamount`decimal(50,10)`The amount placed in the till. It can be changed by adding or removing money from it, but the user doing this requires special permissions
    ## transactionchannel > stores the definition of payment types. organizations often need to collect payments (and make deposits and withdrawals and disbursements) from different payment forms. for instance different bank sources, various payment gateways or agents or simple cash and cheques ( (eg. cash, cheque, bank or receipt). these payment types specify, on a product level, which sources are allowed for that product. Primary key: `encodedkey`
    Column Name Data Type Description
    activated`bit(1)`States whether this transaction channel is active and can be used when entering repayments
    createdbyuserkey`varchar(32)`The key of the user who created the channel
    creationdate`datetime`Date of creation
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, for example, this ID will be referenced in entries in the `transactiondetails` table.
    id`varchar(32)`32 character String hold the ID of the transaction channel
    index`int(11)`Transaction channel position in the list of transaction channels displayed in administration
    loan_custom_filter_constraint_key`varchar(32)`Foriegn key to the `customFilter` table. Maintains the custom constraints, if limited usage selected, the transaction channel on loan transactions.
    loanconstraintsusage`varchar(255)`States the limited/unlimited usage of the transaction channel for loan transactions. Enumeration with the types of constraints available for Transaction Channels.
    - `UNCONSTRAINED_USAGE`
    - `LIMITED_USAGE`
    name`varchar(255)`Name of this transaction channel, will be used in display forms when entering payments
    savings_custom_filter_constraint_key`varchar(32)`Foreign key to the `customFilter` table. Maintains the custom constraints, if limited usage selected, the transaction channel on savings transactions.
    savingsconstraintsusage`varchar(255)`States the limited/unlimited usage of the transaction channel for savings transactions. Enumeration with the types of constraints available for Transaction Channels.
    - `UNCONSTRAINED_USAGE`
    - `LIMITED_USAGE`
    usagerightskey`varchar(32)`The usage rights that describes the transaction channel.
    ## transactiondetails > stores the common details about any financial transaction such as what type of transaction it was, receipt numbers, etc. referred to by loantransaction and savingstransaction models. fields are optional and are used for tracking and auditing purposes only. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables, in this case, the `loantransaction`, `savingstransaction` and `discbursementdetails` tables.
    internaltransfer`bit(1)`Indicates whether the transaction was transferred between loans and savings accounts owned by the same customer.
    targetsavingsaccountkey`varchar(32)`Foreign key to the `savingsAccount` table: In case of a transaction to a savings account this represent the savings account key for which the transaction was made.
    transactionchannelkey`varchar(32)`Foreign key to the `transactionChannel` table: Associated payment type for the transaction.
    ## transactionpaymentholidaysdetails > holds details about the payment holiday’s impact over the parent loan transaction. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    interestamount`decimal(50,10)`The amount of interest payable.
    taxoninterestamount`decimal(50,10)`The amount ofd tax payable on the amount.
    transactionkey`varchar(32)`Foreign key. An entry in the `loantransaction` table.
    ## unusedloanidinterval > table containing unused numeric loan account ids. any creation of a loan account with a numeric id will be reflected in this table. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    endid`bigint(32)`The last ID in an unused range.
    startid`bigint(32)`The first ID in the sequence which should be skipped.
    version`bigint(32)`
    ## unusedloanidintervalupdate > details for `unusedloanidinterval` update operation. contains data about update input and update result.
    Column Name Data Type Description
    encodedkey`varchar(32)`A unique key for this row.
    splitresultendid`bigint(32)`Split interval result end id. Can be `null`. If `splitResultStartId` also `null`. This means that after updating the interval the interval was not split, otherwise is considered an infinite value.
    splitresultstartid`bigint(32)`Split interval result start id. Can be `null`, this means that after update the interval the interval was not split.
    updatedendid`bigint(32)`Updated interval end id. Can be `null` for the last unused interval. In this case is considered an infinite value.
    updatedstartid`bigint(32)`Updated interval start id. Can’t be `null`.
    updatedwithendid`bigint(32)`End id to update interval. Can be `null` if the update operation is not triggered by live migration and the interval is updated with only one value. In this case should consider having same value as `updatedWithStartId`.
    updatedwithstartid`bigint(32)`Start id to update interval. Can’t be `null`.
    updateresultendid`bigint(32)`Updated interval end id. Can be `null` for the last unused interval. In this case is considered an infinite value
    updateresultstartid`bigint(32)`Updated interval result start id. Can be `null`, this means that after update the interval was deleted.
    ## usagerights > entity used to maintain the relation between a usage-rights enabled entity and the roles that can edit it. Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field should not be changed as it may be used as a foreign key to link with other tables
    isaccessiblebyallusers`bit(1)`Whether or not all users can access this entity.
    ## usagerightsroleassignment Primary key: `rolekey` + `usagerightskey`
    Column Name Data Type Description
    idx`int(11)`
    rolekey`varchar(32)`The role ID.
    usagerightskey`varchar(32)`
    ## user > a user is the entity that can access the mambu application. it can be a person: the manager of the organization, a credit officer or another stuff memeber, or it can be another application (that access the api). each usert may have some predefined permissions, to be able to access specific sections of the application, or it can be an administrator. it can have an assigned branch (for the credit officers is mandatory to be a part of a branch). Primary key: `encodedkey`
    Column Name Data Type Description
    accessrights`mediumblob `The access rights an user can have:
    - `MAMBU`
    - `MOBILE`
    - `APIS`
    alias`varchar(32)`Any alias provided for this user.
    assignedbranchkey`varchar(32)`Foreign key to the Branch table indicating which branch the user belongs to
    creationdate`datetime`The date when the user was created. Stored as UTC
    email`varchar(256)`The email of the user.
    encodedkey`varchar(32)`The encoded key for this database entry, it can be used in our API to get data on a specific user of the system. This field is globally unique and should not be changed.
    failedloginscount`int(11)`Stores the number of consecutive failed logins
    failedloginsdates`mediumblob `Stores the dates of failed logins. Maintained in UTC.
    firstname`varchar(256)`User’s first name
    homephone`varchar(256)`The home phone number of the user
    id`bigint(20)`The id of the user (it’s auto-incremented after each created user).
    isadministrator`bit(1)`Whether this user is an administrator
    iscreditofficer`bit(1)`Whether this user is a credit officer
    isdelivery`bit(1)`Whether this user is a member of the Mambu delivery team who may assist in initially setting up your Mambu system.
    issupport`bit(1)`Flag indicating the user is in charge with the Mambu technical support
    isteller`bit(1)`Flag indicating if the user is a teller
    language`varchar(256)`The language used for the interface. It can be:
    - `ENGLISH` (default)
    - `PORTUGUESE`
    - `SPANISH`
    - `RUSSIAN`
    - `FRENCH`
    lastloggedindate`datetime`The date when the user last logged in the application (UTC)
    lastmodifieddate`datetime`The date on which this row was last modified. As UTC.
    lastname`varchar(256)`User’s last name
    lastpasswordresetdate`datetime`The date on which this user’s password was last reset.
    mobilephone1`varchar(256)`The mobile phone number of the user
    notes`mediumtext`A short description of the user.
    password`varchar(256)`The encrypted password.
    permissions_encodedkey_oid`varchar(32)`The permissions of this user. Foreign key the `permissions` table.
    provisionedthroughfederation`bit(1)`If set to true, when editing, the editor must edit the password of the user. It will only be true after a user was provisioned from federated authentication.
    role_encodedkey_oid`varchar(32)`References the set of roles this user has which is held in the `roles` table.
    title`varchar(256)`The title of the user, for example, MR, MRS &c.
    transactionlimits`mediumblob `Larger organizations may want to be able to restrict different users to different transaction limits, such as some users can’t approve accounts over a certain amount or make large withdrawals. An organization can have transactions limits for each user, for approving and disbursing loans, entering repayments, making deposits and withdrawls or for applying fees.
    twofactorauthentication`bit(1)`For any users, a user may set, whether they require to be authenticated with both their phone number as well as an SMS code which they receive
    username`varchar(254)`The username (Unique)
    userpreferenceskey`varchar(32)`References the user’s preferences which is held in the `userpreferences` table.
    userstate`varchar(256)`Whether a user can have access to his Mambu account. Possible states are:
    - `ACTIVE`
    - `INACTIVE`
    ## usercustomvalue > Holds values for custom information for users. **Please note**: This table is for an upcoming feature and may not contain any data for your organization. Primary key: `parentkey`
    Column Name Data Type Description
    definitionids`mediumtext`Holds the list of the custom field encodedkeys generated from the JSON held in the `values` column.
    linkedentitykeys`mediumtext`Holds the list of `linkedentitykeys` generated from the JSON held in the `values` column. These will be the entities to which this custom field is linked for custom fields of type `CLIENT_LINK`, `GROUP_LINK` or `USER_LINK`.
    parentkey`varchar(32)`The `encodedkey` of the entity holding the custom values within the `values` JSON column. This will be the `encodedkey` of the entity with which these custom field values are associated.
    values`json`Holds all the custom field data in a JSON structure, including keys, IDs, values and indexes.
    ## usermanagedbranch > entity class for holding information about user’s managed branch. it keeps a relation of 1 to 1 => 1 user 1 branch. the user can manage multiple branches so it will have a collection of usermanagedbranch entities. Primary key: `encodedkey`
    Column Name Data Type Description
    branchkey`varchar(32)`The key of the managed branch
    encodedkey`varchar(32)`The encoded key for this database entry. This field is autogenerated and should not be changed.
    indexinlist`int(11)`Index of the branch in the list of all branches with the same type; -1 means that this branch was never ordered by the application
    managedbranches_encodedkey_own`varchar(32)`The key of the user
    ## userpreferences > the preferences for a specific user, regarding the list column configurations (for clients, groups, loans, savings and transactions lists) and other configurable components Primary key: `encodedkey`
    Column Name Data Type Description
    defaultactivitieslookupcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing activites in the UI.
    defaultclientcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing clients in the UI.
    defaultdashboardkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the dashboard in the UI.
    defaultdepositscollectioncolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the deposits collection screen, availble under Deposit Transactions in the UI.
    defaultgroupcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing groups in the UI.
    defaultinterestaccrualbreakdowncolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing interest accrual breakdowns in the UI.
    defaultjournalentriescolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing general ledger journal entries in the UI.
    defaultlineofcreditcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing lines of credit in the UI.
    defaultloancolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing loan accounts in the UI.
    defaultloanrepaymentscollectioncolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the loan repayments collection screen, available under Loan Transactions in the UI.
    defaultnotificationmessagecolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing notifications in the UI.
    defaultorganizationbranchesconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the list of branches in the UI.
    defaultorganizationcentresconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the list of centres in the UI.
    defaultorganizationusersconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the list of users in the UI.
    defaultrepaymentcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing loan repayment schedules in the UI.
    defaultrepaymentscollectioncolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing the repayments collection screen in the UI.
    defaultsavingscolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing savings accounts in the UI.
    defaultsavingstransactionslookupcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing savings account transactions in the UI.
    defaulttaskscolumnconfiguration`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing tasks in the UI.
    defaulttransactionslookupcolumnconfigurationkey`varchar(32)`The key of an entry in the `columnconfiguration` table holding this user’s default settings for viewing transactions in the UI.
    encodedkey`varchar(32)`A unique key for this set of defaults.
    helpenabled`bit(1)`Whether or not help is enabled for this user.
    ## webhooknotificationsettings > containing settings for web hook notifications Primary key: `encodedkey`
    Column Name Data Type Description
    encodedkey`varchar(32)`The encoded key for this database entry. This field can be used with our API to get details on an individual notification.
    lastmodifieddate`datetime`The date on which the settings were last modified.
    notificationstate`varchar(255)`Whether the Webhook feature is `ENABLED` or `NONE`.
    --- # Mambu Extract URL: https://docs.mambu.com/docs/mambu-extract/ Mambu Extract is a near real-time data replication solution between Mambu and the customer that is designed with high throughput and reliability. Mambu Extract outperforms other methods of data extraction, such as database backups via API, the Stitch ETL connector, and streaming data, by incrementally syncing only the latest data to the customer data store. These syncs happen on a regular cadence to ensure that the target data store is as close as possible to the live data on the Mambu banking platform. ## Architecture Mambu Extract’s architecture is based on AWS Data Migration Service ([DMS Serverless](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.html)), which over the last year evolved to support ongoing replication or change data capture (CDC), and database schema conversion. It offers a serverless option, reducing operational overhead and costs while natively providing high availability. :::note Mambu Extract is currently only available for AWS environments. ::: Mambu Extract uses the customer production RDS MySQL Master database as its source, and replicates data to an AWS S3 bucket on the customer side as the target. This setup allows the customer to have full control over the data and further downstream integrations - for example, the Data Warehouse or Data Lake - without any dependencies with Mambu. The architectural flow is described in the following diagram: 1. Customer sends request to Mambu Core Banking Engine APIs. 2. Core Banking Engine commits the change to the database (RDS MySQL). 3. AWS Data Migration Service captures the change in the database, transforms to Parquet file and uploads to customer S3 bucket. 4. Customer downloads the Parquet file. ## File and S3 bucket configurations ### S3 bucket folder structure S3 object storage is used as a target for the data extraction, and must be configured in the customer’s AWS account. The folder structure in the bucket will be pre-created automatically by Mambu Extract & AWS DMS service as follows: ```json { "CsvRowDelimiter": "\n", "CsvDelimiter": ",", "CompressionType": "NONE", "DataFormat": "parquet", "ParquetVersion": "parquet-2-0", "TimestampColumnName": "timeMigration" } ``` ## Operations ### Data upload Upload frequency is configurable per environment. By default, files during the full load phase (initial full database replication) will be roughly 650MB for each Parquet file. During the CDC phase, the minimum Parquet file size is set to 32MB and 1 minute intervals, meaning when the CDC is ongoing transactions are batched together (cached) and Parquet file writing is triggered by whichever parameter condition (either 32MB file size or 1 minute interval) is met first. Transactions Parquet files will be under the specific table folder and under the date when the row changes happened. ## High availability and disaster recovery To ensure that the Mambu Extract service remains highly available, we configure the AWS DMS service with a [Multi-AZ configuration](https://aws.amazon.com/rds/features/multi-az/). In case of a single availability zone failure, the DMS service will be automatically switched to the next available Availability Zone. :::info Customer requirements Customers must configure their S3 bucket for the production (primary) region as well as the disaster recovery region. S3 is a regional AWS service, so buckets per region must be created. ::: ## Mambu table list Mambu Extract allows you to extract all tables. However to minimize the size of transferred data and exposure of raw data, Mambu recommends that customers use the following standard list of tables: Table names: * loanaccount * loantransaction * gljournalentry * customfield * customfieldvalue * client * customfieldset * savingsaccount * savingstransaction * loanproduct * repayment * transactiondetails * transactionchannel * activity * lineofcredit For more details about data structures, please refer to the following page: [Data Dictionary](/docs/mambu-data-dictionary). --- # Mambu Payment Gateway URL: https://docs.mambu.com/docs/mambu-payment-gateway/ The purpose of Payment Order capability is to orchestrate the movement of money between an account in Mambu and an account at a third-party financial institution (both domestic as well as international). The orchestration includes triggering Payment Execution on the user-specified date, debiting / crediting the account in Mambu (i.e. calling transaction API), storing-and-forwarding the credit / debit instruction for settlement in a third party financial institution via the Mambu Payment Gateway (MPG), that in turn sends it out to Payment Network. The tools needed to operate the payments functionality are: * Mambu UI * API development environment (e.g Postman) * Mambu Payment Gateway UI ## Logging in Depending on the level of security enabled for your instance you will either log in using regular authentication using just a username and password or multi-factor authentication (MFA) where a one time passcode is sent to a mobile phone number associated with your account. For more information, see [User Administration and Audit Trail - Multi-factor authentication](/docs/user-management-and-audit-trail#multi-factor-authentication-mfa). ## Navigation menu * * * The navigation menu is located on the left of the page. The navigation menu gives access to the following sections: * **Incoming** - Payment messages received (e.g Payments received from the financial network) * **Outgoing** - Payment messages received (e.g Payments sent to the financial network) * **Pending** - Payment messages that require manual intervention of PG users * **Configuration** - System configurations such as Tenant BIC, AML enabling * **Security** - Users management and audit trail ## Gateway Status * * * | Action | From State | To State | Post-Conditions | Notes | | --- | --- | --- | --- | --- | | Receive | N/A | Received | The bulk credit instruction file (pacs.008) is received | - | | Debulk | Received | Debulked | The bulk file is divided into each individual credit transfer instruction | - | | Return | Received / Debulked | Returned | Individual credit transfer instruction is returned and corresponding pacs.004 file is generated | - | | Send | Returned | Sent | Generated pacs.004 file is sent to CSM via Mambu Payment Gateway Webhook | - | | Send | - | Bulked | Payments are grouped/bulked in a sepa file | If message doesn't proceed this status please check your webhook settings | | Send | Bulked | Sent | Message is available on the outgoing section | - | ## Compliance checks * * * ### Incoming AML Incoming Anti-money laundering (AML) allows banks and other financial institutions to send **incoming** payment details to the external third party AML provider (AML TPP) so that they can reduce the risk of money laundering with a frictionless flow in the **Mambu Payment Gateway**. The MPG sends the transactions details and holds the payment process until it gets an AML result to the payments sent. The screening of a payment on the AML TPP can generate three types of results: * **Accepted**: No flags were raised on the AML TPP and payment can proceed the flow - crediting the beneficiary. * **Suspended**: Some flags were raised on the AML TPP and further analysis is being run on the AML TPP. The payment must be on hold until either an accepted or rejected is received. * **Rejected**: Payment was tagged on the AML TPP with a AML flag that lead to a rejection. The payment flow is stopped and the beneficiary is not credited. ![image.png](@site/static/img/support/image%2842%29.png) **Send payment details** ```xml AML1 2020-01-02T10:40:13 1 1 2020-01-02 CLRG ST2 CECAESMMXXX BTRLRO22 NOT1 NOT1 NOT1 SEPA 1 SLEV Jane Doe ES GFA RO10INGBCBN4EVKASDJ8YNGT CECAESMMXXX BTRLRO22 John Doe ES V94025590 RO71BTRLV67M9G4ASDEJ5D2 Incoming Payment ``` **processAmlResponse** Accepts AML check results for Payment Orders. ```json { "groupHeader": { "messageIdentification": "SCTORD200020190305ORD000011122" }, "transactions": [ { "status": "Accepted", "paymentIdentification": { "transactionIdentification": "00730100631BHGCSDW" }, "debtorAgent": { "institutionIdentification": { "bicfi": "BTCLYU23" } }, "interbankSettlementDate": "2019-06-28T00:00:00.000Z" } ] } ``` **Responses** | Code | Code Description | Result | | --- | --- | --- | | 200 | OK | The AML check result has been prepared for processing. | | 400 | Bad request | Validation error occurred. This code will cover malformed syntax in request or incorrect data in payload. | | 405 | Method Not Allowed | This code is only sent when the HTTP method (PUT, POST, DELETE, GET etc.) is not supported on a specific endpoint. It has nothing to do with the consent, payment or account information data model. | | 415 | Unsupported Media Type | A media type which the serves does not support has been supplied. | | 500 | Internal Server Error | Internal server error occurred | | 415 | Service Unavailable | The server is currently unavailable. Generally, this is a temporary state. | | Business field | Business description | Format | M/O | XML / JSON tag | Example | | --- | --- | --- | --- | --- | --- | | Message Id | Message reference created by the sender and forwarded in the SEPA message | text | M | msgId | 22b8f938c6154877886a0c1fc| | Creation Date Time | Date and time at which the message was created | dateTime | M | creDtTm | 2019-05-22T12:24:13 | | Number of transactions | Number of transactions in a given request | text [0-9] | M | nbOfTxs | 2 | | BIC | Financial Institution Identification | text [A-Z][A-Z2-9][A-NP-Z0-9]([A-Z0] | M | bic | ABVRATW1XXX | | Instruction Identification | Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. | text | M | instrId | 82d7125b36014c2e8cc442a3 | | End To End Identification | It is generated by the originator bank to unambiguously identify the transaction. | text | M | endToEndId | NOT PROVIDED | | Transaction Identification | It is generated by the Debtor bank, to unambiguously identify the transaction. | text | M | txId | 4112f6688c846a89bee2b2c476f1145 | | Total Interbank Settlement Amount | Total amount of money moved between the originator bank and the beneficiary bank | 0 <= decimal | M | value | 100 | | Currency |The currency of the payment | text[A-Z] | M | ccy | EUR | | Acceptance Date Time | Point in time when the payment order from the initiating party meets the processing conditions of the originator bank. This means that the originator bank has received the payment order and has applied checks such as authorisation, availability of funds, and so on. | date | M | accptncDtTm | 2019-04-11 06:08:45 | | Debtor | Party that owes an amount of money to a beneficiary. Name by which a party is known and which is usually used to identify that party. | text | M | nm | John Doe | | Postal Address | Information that locates and identifies a specific address, as defined by the postal services | text [A-Z] | O | Ctry | ES | | Private Identification | Unique and unambiguous identification of a person, like passport. Important Note: Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed | Text if ID or Date/text if DoB and PoB | O | BirthDt | V94025590 | | Creditor Account | Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. | text[A-Z][0-9][a-zA-Z0-9] | M | iban | RO75BTRLBSIJS00RPQWYLYWL | --- # Mambu Payments URL: https://docs.mambu.com/docs/mambu-payments/ :::note Removal of Mambu Payment Gateway At Mambu we are committed to delivering cutting-edge financial technology. Our recent acquisition of Numeral allows us to provide you with an even more powerful and efficient payment solution with advanced [payment capabilities](https://mambu.com/en/payments-numeral). Therefore we have made the decision to discontinue the development and support of Mambu Payment Gateway. Our teams are available to discuss your options, including a potential migration to Numeral. We understand the implication that this change may have on your operations and are committed to supporting you throughout the transition period. For all technical information about the new Mambu Payments product, refer to the documentation: * [Mambu Payments functional documentation](https://docs.numeral.io/docs/get-started) * [Mambu Payments API documentation](https://docs.numeral.io/reference/introduction) ::: For customers who are still using Mambu Payment Gateway, refer to the pages below for the technical documentation. --- # Mambu Release Cycle URL: https://docs.mambu.com/docs/mambu-release-cycle/ ## Release Process Mambu uses a continuous delivery model for product updates, which allows us to seamlessly provide updates and to react quickly if an issue should occur. Our release process is designed to ensure that you will have no downtime in almost every case. Application releases do not result in downtime. A small number of infrastructure updates may require very short periods of downtime, but they are always scheduled in advance. Releases are first rolled out to sandbox environments and then to production environments, usually a day or so after they are released to sandbox. The exact timing depends on various factors, and it can range from several hours to a couple of days. Application releases are typically performed outside business hours. If an application version rollback is necessary, customers are informed via the [Status Page](/docs/mambu-status) once it starts. Our [Status Page](https://status.mambu.com/) provides additional information on when release versions are deployed in each region - scroll down to the [Past Incidents](https://status.mambu.com/#past-incidents) section of the page for details. ## Versioning We use a loose versioning system similar to [semantic versioning](https://semver.org/), using the following structure: **major.minor.patch** Unlike semantic versioning, in our release versioning system, **breaking changes may occur in minor releases**. Major version changes include substantial, large-scale changes, while minor versions are generally released weekly. Patch releases are generally bug fixes. You will be notified in advance by email of any breaking change. They are also clearly indicated in our release notes. For more information, see [Release Notes](#release-notes) below. ## Breaking changes Breaking changes are changes that require that you take action to continue using a feature without interruption. Breaking changes may involve changes to API contracts, such as changes to the definition of API inputs, outputs, and specifications, or any other change to existing functionality. ### Planning and notifications Whenever possible, when we release a breaking change, we maintain the old, deprecated version of the feature in parallel with the new version in order to provide you with more time for migration. In such cases, we maintain the old version for a minimum of three months, and then remove it. If it is not possible to maintain a deprecated feature, we will send out an announcement at least three months before we release the change with details on what will be changed and with an estimated release date. In this case, the support for the old feature version is dropped at the same time that the new version is released. You will have to update your workflows and integrations before the release date to maintain uninterrupted operation. :::note If you are not using the updated feature or endpoint, you will not need to prepare for a breaking change release. ::: ## Feature Release Status Major features or capabilities are usually in one of three stages in our release cycle: * Generally Available * Early Access * Non-Production Preview Documented features may be in limited release without being in one of these three formal stages. Any feature that is not generally available is identified in our documentation. ### Generally Available A feature or capability in the *Generally Available* stage is available to all customers, provided the feature is included in their contract and is compatible with their cloud service provider. Some features or capabilities in this stage are automatically enabled. If you would like to request access to a Generally Available feature or capability that is not automatically enabled for your environment, please get in touch with your Mambu Customer Success Manager to discuss your requirements. There may be additional commercial agreements or other additional requirements that need to be fulfilled. :::warning The availability of some features or endpoints may depend on your contract. ::: ### Early Access The main purpose of this stage is to collect another round of feedback before a feature or capability is made generally available. A feature or capability in the *Early Access* stage is available to a limited number of customers. If you would like to request access to an Early Access feature or capability, please get in touch with your Mambu Customer Success Manager to discuss your requirements. You may process production data with Early Access features and capabilities. :::warning A feature or capability in this stage may have certain limitations. For more information, refer to the relevant clauses regarding the Early Access stage in your contract. ::: ### Non-Production Preview In some cases, we give a limited number of customers access to features or capabilities in the *Non-Production Preview* stage. The main purpose of the Non-Production Preview stage is to allow selected tenants to test the functionality so that our team can collect feedback. If your organization has access to a feature or capability in this stage, then you will be able to preview its functionality, but you should not process production data with it. ### How do we identify the stage of a feature? Any feature that is not generally available is identified in our documentation. You can see a list of Early Access features and Generally Available features by going to the **Administration** screen in the Mambu UI. ![Administration screen Mambu with Early Access and Generally Available features](@site/static/img/support/release-cycle-and-compatibility--early-access-features-administration.png) Features that are enabled for your system have a **Check mark** next to them. Features that are not enabled have a **Cross** . ### Beta API Mambu uses the term "beta" only to describe APIs. Beta APIs are provided to customers as fully-functioning demos, and are used to collect feedback. Note that if an API is in beta, its schema is subject to change. Beta APIs do not have a stable API contract, and they may be updated with backwards-breaking changes. Mambu typically accounces beta APIs on our [Community page](https://community.mambu.com/). ## Release Notes For release notes describing breaking changes, new features, improvements, and bug fixes, see the [Release Notes section](https://community.mambu.com/c/release-notes/) of our Community forum. Our release notes also describe database changes and audit trail contract changes. ### Database Changes Whenever Mambu updates the database structure, we publish these changes in our release notes under the category "Database Changes". These release notes show the SQL operation that defines the actual change to the database. Database structure changes may impact the following areas: * Data Import * Jasper Reports ### Audit Trail UI Contract Changes Audit Trail provides access to records of all activities carried out in the Mambu UI, API v1, or API v2. For more information, see [Audit Trail](/docs/audit-trail). All Audit Trail changes are published in our release notes under the category “Audit Trail UI Contract”. Changes are divided into added and removed actions. Note that if a tracked action is changed, it will appear in both "removed" and "added," showing the old action that was changed, and the new action it was changed to. The impact will be visible when retrieving the events registered in Audit Trail. These changes do not impact events that were previously registered in Audit Trail. ## Mambu Release/Incident Notifications Mambu notifies customers on upcoming releases or possible incidents via our [status page](https://status.mambu.com/). In order to make sure that you are always up to date with our releases and possible incidents, please ensure that at least one key person from your organization is subscribed to our notifications, by following the steps below. ### Subscribing to notifications 1. If your organization is on a Shared Environment, go to [https://status.mambu.com/](https://status.mambu.com/) . :::note For Private Environments, please reach out to our support team, they will gladly provide you with the link to your dedicated Status Page, in order to receive notifications for your environment. ::: 2. Select **Subscribe to Updates** ![Subscribe to updates](@site/static/img/support/subscribe-to-updates.png) 3. Choose how you wish to be notified, such as via email or RSS/Atom feed. ![Choose a subscription](@site/static/img/support/subscription-choice.png) 4. After subscribing, you will receive an email confirmation. You can follow the link in that email for Managing Subscriptions to subscribe for the region (component) you need, otherwise you will be notified for all regions. ![Manage subscription](@site/static/img/support/manage-subscription.png) Once your details have been submitted, you will be notified automatically about release dates and times. --- # Mambu Search URL: https://docs.mambu.com/docs/mambu-search/ The search box allows users to either search all categories, or filter by category. When you select the search box, a drop-down dialog opens with all the categories listed. ![search all categories](@site/static/img/support/magic-search-box.png) On the right side of the search input field, you can click **X** to remove the input text. If you select a category, search results will be refined. You can select multiple categories, and the results will be listed per category. ![results per category](@site/static/img/support/results-per-category%281%29.png) :::note We recommend searching with **one** category - rather than none or multiple - for the best possible performance. ::: If you hover over a search result in the list, a Copy icon will be visible to the right. Clicking this will copy the result ID to your clipboard. ![copy icon](@site/static/img/support/copy-icon.png) If you log out and in again to your Mambu tenant, the last search query text will persist. ## Search rules For keywords such as names, you must enter a minimum of three alphanumeric characters. For strings such as account number, you must enter a minimum of five digits. The search box will also suggest that you select a category in cases where search results are taking too long. ![suggest category](@site/static/img/support/suggest-category.png) You can search using the full name or, as stated above, by entering at least three letters of a name. The results will include names that begin with the letters you enter, and you can use up to three search terms per query. :::note Certain search fields are case-sensitive. Incorrect capitalization may return no results. Refer to the [Searchable fields](#searchable-fields-list) section for specific case sensitivity details. ::: |Field|Value| | --- | --- | |First Name|Frederick| |Middle Name|Michael| |Last Name|Smith| In this case, for example, you may enter `Fre`, `Fre Mic` or `Fre Mic Smi`, or any combination of the three such as `Mic Smi`, `Smi Mic Fre`, in the search box for more refined results. If a single field contains multiple words separated by spaces, they will behave like a single word. This means that your search input must match the beginning of the database entry. Case sensitivity and word order matters. For example, if the first name of a client (`firstName` - which is case sensitive) is 'Frederick Michael,' searches for 'Fred,' 'Frederick,' or 'Frederick Michael' will return results, while 'Mich,' 'Michael,' 'Michael Frederick', or 'FREDERICK MICHAEL', will not. ## Keyboard navigation The following keyboard shortcuts can be used to navigate search: * ↑ and ↓ to select result items * ↑ to the top to focus on the input box * When result item is selected, press **Enter** to navigate to the result * When input box is focused, press **Enter** to do instant search * MacOS **⌥ + Space** or Windows **Alt + Space** to focus on input box and select all search text. * **Escape** to close the drop-down. ## Searchable fields list The following list shows which fields can be searched, per category: **Client (`client`)** | Column/field | Case-sensitive | | --- | --- | | First name | true | | Middle name| false | | Last name | true | | ID | false | | Document ID | false| **Group (`group`)** | Column/field | Case-sensitive | | --- | --- | | Group name| true | | ID | false | **User (`user`)** | Column/field | Case-sensitive | | --- | --- | | First name | true | | Last name | true | | User name | true | **Branch(`branch`)** | Column/field | Case-sensitive | | --- | --- | | ID | false | |Name | true| **Loan account (`loanaccount`)** | Column/field | Case-sensitive | | --- | --- | | ID | false | **Savings account (`savingsaccount`)** | Column/field | Case-sensitive | | --- | --- | | ID | false | **Centre(`centre`)** | Column/field | Case-sensitive | | --- | --- | | ID | false | |Name | true | **Line of credit (`lineofcredit`)** | Column/field | Case-sensitive | | --- | --- | | ID | true | :::note In case-sensitive searches, the first character of the query is still case-insensitive. ::: ## Searching for Accounts You may search for loan or deposit accounts in two ways: with the search box, or by using the filter options from the Loans or Deposits view. To find an account using the search box, enter the unique account ID. Use the filter options of the **All Loan Accounts** or **All Deposit Accounts** views to see all loans or deposits accounts of a specified category. You can filter accounts by: * Branch * Credit Officer * Account State * Loan Product * Loan Balance * Creation date For more information, see [Editing filters and columns on a custom view page](/docs/custom-views#editing-filters-and-columns-on-a-custom-view-page). --- # Mambu Status URL: https://docs.mambu.com/docs/mambu-status/ ## [status.mambu.com](https://status.mambu.com) ![status page header with green "All Systems Operational" status bar and blue "subscribe to updates" button](/img/support/release-cycle-and-compatibility--mambu-status-page-header.png) Our [status page](https://status.mambu.com) provides you with real-time status updates for all of our multi-tenant production and sandbox servers. You will also find information about upcoming maintenance and releases, active and historical incidents, and can access our latency and availability reports. :::warning If your organization has a dedicated environment, Mambu has provided you with an individual status page. Please contact us through [Mambu Support](/docs/mambu-support) for any questions about your status page. ::: ### Subscribe to Updates ![Subscribe to updates button with webhook option displayed](/img/support/mambu-status-page.png) Click **Subscribe to Updates** to receive updates from our status page. Updates are available in the following formats:
    Format Update types
    Email Notifications for new, updated, or resolved incidents, maintenances, information notices, and component status changes.
    RSS/Atom feed Notifications for new, updated, or resolved incidents, maintenances, information notices, and component status changes.
    For additional subscription options, please contact your Customer Success Manager (CSM). ![Subscribe for updates](/img/support/subscribe-for-updates.png) ![Subscribe to get updates](/img/support/subscribe-to-get-updates.png) The **Subscribe to get updates** form allows you to configure how you receive notifications from the status page. * **Email field** – Enter your email address to subscribe. * **Notification types** – Choose what kind of updates you want to receive (e.g., incident, maintenance, information notice). If none are selected, you’ll receive all types by default. * **Services/Components** – Select the services or components you want to be notified about. You can choose All or select specific services. * **Verification** – Confirm you are human with the security check. * **Subscribe button** – Click to finalize your subscription. You’ll receive a confirmation email with a link to manage or modify your subscription at any time. To modify your subscription, use the **Subscribe to Updates** form and enter your email address. You’ll receive a link to update your preferences. ### Availability Reports ![Availability reports for the past 30 days and current year](/img/support/release-cycle-and-compatibility--availability-summary-report.png) Availability reports are available for the past 30 days and for the current year. ## `/healthcheck` endpoint The `/healthcheck` endpoint is a convenient way to manually or automatically check the status of a specific Mambu server. If the Mambu server is available, it will return response code `200` together with the message `OK`. You can enter the URL into a web browser or call the API endpoint using your tool of choice. ### Tenant URL and endpoint `https://TENANT_NAME.mambu.com/healthcheck` ### Request `GET https://TENANT_NAME.mambu.com/healthcheck` ### Responses
    Response Code Text Description
    200 OK Server is functioning properly
    500 Internal Server Error Server is not available
    503 Service Temporarily Partially Unavailable Database maintenance in progress; server is not ready to handle all requests. General API calls may succeed.

    Ignoring false positives

    Errors can happen due to a range of issues from network connectivity issues - which are minimal in impact and most of the times produce false positives - up to server overload, which should be taken seriously.

    Therefore we recommend that you implement a detection mechanism that ignores isolated healthcheck 5xx errors, and instead focuses on incidences of continuous 5xx errors. As a guideline, you can configure the healthcheck mechanism to query every 3-5 seconds, and if it returns 10 sequential 5xx errors, you should report this to Mambu.

    --- # Getting Support URL: https://docs.mambu.com/docs/mambu-support/ :::warning Never send login credentials, API keys, or other confidential information through unencrypted email. Never post this information to any public forum such as Mambu Community or Stack Overflow. For details on how to safely share sensitive information with Mambu, see [Sending Secure Information](/docs/sending-secure-information). ::: ## General Support ### Customer Service Portal You can raise support cases in the Customer Service Portal that can be accessed at [https://mambu.my.site.com](https://mambu.my.site.com). For more information, see [Customer Service Portal - Raising a support case](/docs/customer-service-portal#raising-a-support-case). This is our preferred channel of communication. If you need to request new users for the Customer Service Portal, see [Customer Service Portal - Managing Users](/docs/customer-service-portal#managing-users) for more information. ### Web Form for Support Cases You can also get in touch with our support team by submiting a support case using our Web Form for Support Cases that can be accessed at [https://cloud.mambu.com/contact-support](https://cloud.mambu.com/contact-support). Enter all the required information and select **Submit**. ### Mambu Community [Mambu Community](https://community.mambu.com) is a place for Mambu employees, customers, and partners to share experiences, give feedback and advice, and get up-to-date information on relevant topics. It is also where you can read all our release notes. ### Mambu Status You can check the status of our service, subscribe to updates, and view reports at the [Mambu Status](http://status.mambu.com/). ### Error Reports Error reports are created when an unexpected error occurs in your system. You will be asked to fill out the error report form which will be submitted to us. This report will have system data and error logs attached to it. Please add replication steps to the form to help us with the diagnosis. After submitting an error report please contact Mambu Support. ## Granting access to your account with the Mambu Support user To solve some issues, we may need access to your Mambu system to view your configuration and replicate errors. To grant us this access, you must activate the **Mambu Support** user. This user is deactivated by default. The Mambu Support user has read access only. In other words, the user can only view your system to identify potential problems and cannot make any changes. To activate the Mambu Support user, enable the **Mambu Support Access** toggle. The Mambu Support user is automatically disabled after five days of inactivity. That is, if no Mambu Support user logs in for five days after it is enabled, or five days after its last access, the Mambu Support Access toggle is automatically disabled. Once the **Mambu Support Access** toggle is disabled, the support users' state will also be automatically switched to deactivated. To enable the **Mambu Support Access** toggle: ![Set the Mambu Support Access toggle](@site/static/img/support/mambu-delivery-deactivation-date-set-400x57.png) 1. On the main menu, go to **Administration** > **Access** > **Users**. 2. Turn on the **Mambu Support Access** toggle. 3. If your Mambu instance is running and you are in the onboarding process, you can set the **Mambu Delivery Access** toggle on or off and set a deactivation date of a maximum of 90 days. **Mambu Delivery Access** will be automatically disabled on the set date. You can always edit or re-activate this feature, as long as you are still in the delivery process. ![Set delivery access deactivation date](@site/static/img/support/set-delivery-access-deactivation-date-402x239.png) ### Access Policy We will only access your environment if you have explicitly requested that we do so, usually by contacting support and raising a support ticket. When we log in, we will inform you that we are doing so. ### Mambu Support role permissions The type of view permissions that the **Mambu Support** user has are controlled by a role called **Mambu Support**. By default the role has all view permissions enabled. To edit the Mambu Support role permissions: 1. On the main menu, go to **Administration** > **Access** > **Roles**. 2. Got to the Mambu Support role and select **Actions** > **Edit**. 3. In the **Editing Role Mambu Support** dialog, under the **Permissions** section, choose the view permissions you would like the Mambu Support role to have. 4. Select **Save Changes**. ![Editing Role Mambu Support dialog](@site/static/img/support/mambu-support--editing-role-mambu-support.png) ### Federated Authentication Certificate Expiry The Mambu Support user uses federated authentication (FA) to login. To be able to login with FA you need to have an active certificate fingerprint. The expiry date for the certificate fingerprint is displayed next to the Mambu Support Access toggle in the DD/MM/YYYY format. The certificate will not automatically renew and extension to its validity date needs to be explicitly requested. To renew this certificate, [contact our support team](mailto:support@mambu.com) and we will assist you in this process. ## Mambu Delivery users while onboarding During the onboarding process, our customer support team may use **Mambu Delivery** user accounts to assist you in setting up your Mambu instances. Mambu Delivery users are user accounts that have the Mambu Delivery role assigned to them. This role has all permissions enabled by default, but they can be edited. For more information on modifying user permissions, see [Understanding Users, Roles and Permissions](/docs/understanding-users-roles-and-permissions). The Mambu Delivery users are only able to access your instances as long as the **Mambu Delivery Access** toggle is enabled. This toggle is visible and automatically enabled when you begin the onboarding process and then it is disabled and removed from the UI once you complete the onboarding process. To view the Mambu Delivery Access toggle while it is available, on the main menu go to **Administration** > **Access** > **Users**. ![delivery.png](@site/static/img/support/delivery.png) While the toggle is available you can view the Mambu Delivery role in your roles list as well as the Mambu Delivery users with their email and name in your users list. Once the toggle is removed, the role and all users assigned with the role are removed. However, all events that occured while they were active are tracked by our [Audit Trail](/docs/audit-trail) capability. If you require any support after the delivery process is complete, then Mambu Support users may assist you. For more information, see [Granting access to your account with the Mambu Support User](/docs/mambu-support#granting-access-to-your-account-with-the-mambu-support-user). ## Capturing Network Traffic For some kinds of problems, it can be very helpful to capture network traffic to include in your support case. You can do so with an HTTP proxy such as [charles](https://www.charlesproxy.com/), if your internal security policies allow, or by using some browsers. To capture network traffic with Google Chrome: 1. Open the Mambu UI in a new window. 1. Right click on the browser window and click **Inspect** or press the **F12** key to open the developer tools. 1. In the developer tools, go to the **Network** tab. 1. Reproduce the issue that you are contacting support about. 1. Once the issue is reproduced, there will be a list of calls/events. Wait a while until all the calls/events are listed. 1. Select all the calls/events and right click to bring up the context menu. 1. Select **Save all as HAR with content** in the menu. 1. Share the HAR file with us for further investigation. For more information, see [Inspect network activity](https://developer.chrome.com/docs/devtools/network/) in the Chrome Developers documentation. ## Customer case non-response policy To ensure timely case resolution, Mambu Customer Support actively engages with customers who report issues. However, prolonged inactivity from customers may delay the resolution process. To manage this effectively, we follow the process outlined below: * **Response Timeline**: If no customer response is received, Mambu will send follow-up messages every 24 hours over a 72-hour period (excluding weekends). * **Case Closure**: If no response is received within 72 hours, we will notify the customer and proceed to close the case. This approach helps us maintain an efficient support process while encouraging timely collaboration. Customers can always reopen closed cases if further assistance is required. ## Documentation For answers to many commonly-asked questions, be sure to start by checking our comprehensive documentation. ### User Guide The User Guide is the [support.mambu.com](http://support.mambu.com/) site, with comprehensive documentation about Mambu’s products, with a particular focus on the UI. ### API Reference The API Reference is the [api.mambu.com](/api/) site, containing all the information required to work with Mambu's APIs. --- # Mambu UI Management Overview URL: https://docs.mambu.com/docs/mambu-ui-management-overview/ The Mambu UI is our browser-based core banking user interface. It is used to set up, administer, configure, and access your organization's branches, users, clients, financial products and services, and more. ![Sample Mambu UI screen - currency tab under Financial Setup in Administration screen.](@site/static/img/support/managing-the-mambu-ui--currency-configuration.png) Several elements of the Mambu UI are customizable by your organization and by individual users. This section describes how to configure the dashboard, page layout, labels, display language, and more. The Mambu UI display includes the following components: * The **top bar**, which contains the search field, **View** menu, **Create** menu, and more. * A **navigation bar** containing **menu items**, which can be used to navigate to different pages in the Mambu UI. * The currently-selected page, which may be further divided into selectable tabs, as in the **Administration** page. For more information, see [Navigating in the Mambu UI](/docs/navigating-in-mambu). ## Supported browsers The Mambu UI should only be viewed in one of the supported browser versions defined below: | Browser | Minimum version | | --------------- | --------------- | | Google Chrome | 109+ | | Microsoft Edge | 121+ | | Mozilla Firefox | 115+ | | Safari | 15.4+ | | Opera | 95 | ## Dashboard The dashboard is the landing page you see when you log in to the Mambu UI. The dashboard is composed of functional widgets, which can be enabled or disabled, either for all users or selectively, based on access control settings. For more information, see [Dashboard](/docs/dashboard). ## Menu items and custom views Menu items and views are two related features that offer a flexible set of tools for customizing your UI and creating lightweight reports. *Menu items* are simply the words displayed on the navigation bar that describe categories of links. When you mouseover most menu items, you will see a menu of links to relevant pages, as shown below: ![Client menu item with custom views and all clients page](@site/static/img/support/managing-the-mambu-ui--clients-dropdown-menu.png) Several default menus link to core entities such as loans, branches, and clients. These menus include links to two types of pages: 1) Pages that display all entities of their type, such as the **All Loans**, **All Branches**, or **All Clients** pages; and 2) Pages that display a filtered subset of its type, such as the **Active Clients** or **Inactive Clients** pages. *Views* or *custom views* are our terms for customizable pages that display a filtered subset of an entity. Other examples of custom views include: * A page showing all clients that are in a pending state. * A page showing all loan accounts that are 90 days in arrears. * A page showing all withdrawal transactions higher than USD700,000. Custom views and labels may be created, modified, or deleted. You can customize labels and custom views to create your own UI sections and pages. Custom views can be used as lightweight reports, or as a way to easily access information that you frequently need. They can also be referenced in Mambu v1 API `GET` requests to filter results. For more information, see [Custom Views and API v1](/docs/custom-views-and-api-v1). Some custom views are provided by default. Whether you create them yourself or they already exist in Mambu, when you mouseover a menu item with associated custom views, you will see them listed in the menu, as in the **Clients** menu shown above. Not all menu items support custom views. For example, if you mouseover the **Administration** menu item, you will see that your only option is to select the menu item to navigate to the corresponding page. For more information, see [Menu Items](/docs/menu-items) and [Custom Views](/docs/custom-views). ## Labels Labels define the terms that are used to refer to various basic entities and concepts in the Mambu UI, such as clients, groups, and branches. Some of these terms are customizable. For more information, see [Labels](/docs/labels). ## Columns You can customize your own column configurations in Mambu UI pages such as All Clients, All Groups, All Accounts, Journal Entries, and Transactions Lookup. For more information, see [Columns](/docs/customizing-columns). --- # Management Reports URL: https://docs.mambu.com/docs/management-reports/ Mambu provides various management reports via the Mambu UI under the **Reporting** menu item. A user must have the necessary permissions to view these reports - see [Permissions and management reports](#permissions-and-management-reports) below for more information. The Reporting page gives you access to seven tabs that represent the management reports available: * [Indicators](#indicator-reports) * [Portfolio](#portfolio-report) * [Organization](#organization-report) * [Earning](#earnings-report) * [Cashflow](#cashflow-report) * [Outreach](#outreach-report) * [Risk](#risk-report) ![The management reports available under the Reporting menu item](@site/static/img/support/data-and-reporting--management-reports.png) In addition to these management reports, Mambu provides additional reporting capabilities. For more information, see [Custom Views](/docs/custom-views), [Jasper Reports Overview](/docs/jasper-reporting-overview), and [Accounting Reports](/docs/accounting-reports). ## Permissions and management reports In order to access the **Reporting** menu item, you must have the **View Historical Data** (`VIEW_INTELLIGENCE`) and **View Reports** (`VIEW_REPORTS`) permissions. The following permissions control what you are able to do with management reports: * **View Historical Data** `VIEW_INTELLIGENCE` * **View Reports** `VIEW_REPORTS` * **Create Reports** `CREATE_REPORTS` * **Edit Reports** `EDIT_REPORTS` * **Delete Reports** `DELETE_REPORTS` For more information, see [Permissions](/docs/permissions) and [Menu item types and permissions](/docs/menu-items#menu-item-types-and-permissions). ## Indicator reports Mambu provides a set of default indicators based on five different entities: * Branches * Deposit products * Loan products * Centres * Credit officers ### Creating an indicator report To create an indicator report: 1. Select the entity for which you want to create the indicator. 2. Select **Create New Report**. 3. In the **Creating New Report** dialog, enter all the necessary information. For more information on fields, see [Indicator report fields](#indicator-report-fields). 4. Select **Save Changes**. To view the indicator report, select the name of the report in the list. ![Create New Report dialog for indicator report](@site/static/img/support/data-and-reporting--creating-new-report.png) ### Indicator report fields | Field | Description | Required | | --- | --- | --- | | Name | The name for the report. Maximum length of 255 characters. | ✔ | | Type | The indicator report entity. The type is determined when selecting a tab before creating the report, and it cannot be modified. The available entities are: branch, centre, loan product, deposit product, and credit officer. | ✔ | | Indicators | The list of indicators to be included in the report. The list is determined by the entity type selected. For more information about the available indicators, see [Indicators](/docs/indicators). | ✘ | | Description | The description for the report. | ✘ | ### Editing indicator reports To edit an indicator report, either: * Find the indicator report in the list of reports and select **Edit** . * Visit the indicator report page and select **Actions** > **Edit**. To edit reports, you must have the **Edit Reports** (`EDIT_REPORTS`) permissions assigned to your user. To remove an indicator used in the report, select **Delete** next to the indicator. ### Deleting indicator reports To delete an indicator report, either: * Find the indicator report in the list of reports and select **Delete** . * Visit the indicator report page and select **Actions** > **Delete**. To be able to delete reports, you must have the **Delete Reports** (`DELETE_REPORTS`) permissions assigned to your user. ### Exporting indicator reports The table generated from the indicator report can be exported as an `xlsx` Excel spreadsheet file. However, the graphs and diagrams cannot be exported. ## Portfolio report Portfolio reports provide an overview of your loan portfolio. You can see the number of accounts, their accumulated balance, and how they have changed across time. To generate a portfolio report: 1. Use the **Branch** field to select a branch. 2. Use the **From** and **To** fields to select the start and end dates. Maximum date range of one year allowed. 3. Use the **At Intevals** dropdown to select the interval - daily or weekly. 4. Select **Generate Report** . The charts cannot be modified or customized. The information is divided in three sections: *Overview*, *Accounts* and *Historical*. ### Overview report This section is an overview of your organization, mainly regarding its size and account distribution. The report is divided in two sections. At the header, you will find general indicators that provide a quick overview of your organization. In the main body below, you will find a visualization of your account growth and distribution by number of accounts and balances. ![Reporting, Portfolio Overview for all Branches between specific dates.](@site/static/img/support/data-and-reporting--portfolio-overview-report.png) ### Accounts report Three interactive graphs show the evolution of your accounts portfolio: **Created Accounts**, **Disbursed Loans**, and **Written Off Loans**. ![Accounts Report for a specific branch and period of time.](@site/static/img/support/data-and-reporting--accounts-report.png) ### Historical report This report shows changes over time in several interactive graphs: **Loans by Status**, **Capital Structure**, **Portfolio Risk**, and **Average Loan Balance**. When you select **Weekly** reporting, the data points shown are from the same day of each week, for the duration of the time interval selected. :::note When the interval does not correspond to full weeks, the report will be made until the last day of a full week. ::: ![Historical Report for a specific period of time.](@site/static/img/support/weekly-report-accounting%281%29.png) When you select **Monthly** reporting, each month in the selected time range has one data point in the graph, which always corresponds to the same day of the month. For example, when selecting the interval June 6, 2020 to October 6, 2020, the data points correspond to June 6, July 6, August 6, September 6, and October 6. ![Reporting | Historical | Monthly](@site/static/img/support/monthly-report-accounting.png) ## Organization report The organization report provides information about your organization, including: * Number of branches * Number of credit officers * Loans per branch * Loans per credit officer To generate the organization report: 1. Use the **From** and **To** fields to select the start and end dates. Maximum date range of one year allowed. 2. Use the **At Intevals** dropdown to select the interval - daily or weekly. 3. Select **Generate Report** . ![Organization Report for a specific period.](@site/static/img/support/data-and-reporting--organization-report-dashboard.png) ## Earnings report The earnings report gives you a view of revenues and expenses related to your financial products, showing their growth, distribution and mix for each product and per branch. To generate the earnings report: 1. Use the **Branch** field to select a branch. 2. Use the **From** and **To** fields to select the start and end dates. Maximum date range of one year allowed. 3. Use the **At Intevals** dropdown to select the interval - daily or weekly. 4. Select **Generate Report** . ![Earnings Report for a specific period of time](@site/static/img/support/data-and-reporting--earnings-report.png) ## Cashflow report :::warning This report only provides information entered in the base currency of your organization. Data entered in a different currency will be omitted. Moreover the cashflow report provided here does not include all the information included in a regular cashflow report. You may need to procure other cashflow reports for your accounting needs. ::: The cashflow report displays information for indicators related to receipts, payments, and the changed balance. To generate the cashflow report: 1. Use the **Branch** field to select a branch. 2. Use the **From** and **To** fields to select the start and end dates. Maximum date range of one year allowed. 3. Use the **At Intevals** dropdown to select the interval - daily or weekly. 4. Select **Generate Report** . ![Reporting - Cashflow for all branches and a specific period of time.](@site/static/img/support/data-and-reporting--cashflow-report.png) ### Indicators in the cashflow report #### Income * **Interest from Loans:** The amount of paid interest of all repayments. * **Fees from Loans** The amount of paid fees of all repayments and fee charged transactions. Includes all type of fees, including the disbursement fees. * **Loan Penalties:** The amount of paid penalties of all repayments. * **Interest on Deposits:** The amount of interest applied on deposit accounts. The value is positive if interest was charged, or zero. * **Fees on Savings:** The difference between the savings fees that were applied and the savings fees reduced amounts. #### Expenses * **Interest Earned on Overdrafts:** A negative value means that interest was charged. In this case, it is calculated as described above for interest on deposit. * **Extraordinary Write-Off:** The sum of overdraft amounts from all savings transactions that have been written-off during this period, to which we also add: * The difference between loan amount - principal paid, if a loan account is in closed written off state, and * The principal amount from the write off transaction, if the a loan account is in closed rescheduled or refinanced state. #### Balance Changed * **Principal Collected:** Amount of principal of all repayments. * **Principal Disbursed:** Amount of principal that was disbursed. * **Change in Portfolio (assets):** Principal disbursed - principal collected. * **Change in Deposits (liabilities):** Sum of all savings transactions amounts. ## Outreach report The outreach report provides information about: * The number of clients * The number of groups * The number of borrowers * The number of savers * The percentage of female borrowers ## Risk report For more information on the risk report, see [Risk Report](/docs/risk-report) under the managing risk section of Loans. ## Other reports The **Other Reports** tab gives you access to Jasper Reports that you have imported and that are not assigned to an entity. For more information, see [Jasper Reports Overview](/docs/jasper-reporting-overview). ## Modifying chart data You can easily show or hide products or data in the management reports charts in Mambu. When viewing a chart, you can select the item in the chart summary box to either hide or show it. ![Reporting - Portfolio reports view](@site/static/img/support/data-and-reporting--portfolio-reporting-dashboard.png) --- # Managing Clients URL: https://docs.mambu.com/docs/managing-clients/ This page describes how to manage individual clients. For general information on individual clients, see [Clients and Groups Overview](/docs/clients-and-groups-overview). ## Client native fields *Native fields* are fields Mambu provides by default. As a general rule, you are not able to edit native fields. For more information, see [Native Fields](/docs/native-fields). If you want to create specific fields for your organizations then you must use [custom field definitions](/docs/custom-fields). The exception to this rule is a set of native fields that are associated with the client entity and that are part of the **General** or **Details** section of some client forms. :::warning You can edit the specific client fields that are an exception to the rule in the same way as [Placeholder](/docs/placeholders) custom field definitions, from the **Administration > Fields** tab, but they are not custom field definitions. ::: You can edit the name, ID, format, some of the usage settings, and the rights settings for these fields. These are the same settings used to manage custom field definitions. For more information, see [Fields for custom field definitions](/docs/custom-fields#fields-for-custom-field-definitions). To edit these client native fields: 1. On the main menu, go to **Administration** > **Fields**. 2. Select the **Client** entity and use the **Custom Field Set** dropdown to select either **General** or **Details**. 3. Find the field you want to edit and select **Actions** > **Edit**. We provide some editing capabilities for these fields to provide more flexibility in capturing client information and to allow you to determine who has access to manage this information. ### Managing the client native fields The type of information captured by these fields must stay the same. Changing the name or ID of these fields, will change how they are displayed in some places in the Mambu UI - but it won't change how the fields are displayed in: - [Requests and responses](/api/pages/api-v2/responses) when using the API - [Placeholders](/docs/placeholders) - [Condition settings](/docs/notifications-overview) used for notifications - [Custom view filter settings](/docs/custom-views#filters) For example, the **Birth Date** client native field will always be associated with the `birthDate` field in API requests and responses. Even if you change the name of the field to **Marriage Date** in the Mambu UI, the value of this property will still be associated with the `birthDate` key in any JSON response. :::note The usage settings for first name and last name are not editable. ::: ## Editing a client You may change a client's information anytime you need. To edit a client: 1. Open the client's profile. 2. On the right-hand side of the screen, click **Edit**. 3. Make the changes. 4. Click on **Save Client**. ![Edit action that can be done via the Edit button or directly from client overview.](@site/static/img/support/clients-and-groups--client-overview.png) ### Editing notes and custom field values To edit notes: 1. Go to the bottom of the client's overview page. 2. Hover over the notes area to reveal **Edit** and select it. 3. Enter the information in the text box. 4. Select **Check** to save. If you would not like to save your changes then select **Deny** . To edit a custom field value: 1. Go to the bottom of the client's overview page. 2. Hover over the custom field value area to reveal **Edit** and select it. 3. Enter the information you would like to edit for the custom field value. 4. Select **Check** to save. If you would not like to save your changes then select **Deny** . :::note If you want to add new custom field definitions to a client, you can also do so by selecting **More** > **Add Field**. ::: ### Reassign a client To reassign a single client: 1. Open the client's profile. 2. On the right side of the screen, click **Edit** and open the **Association** section. ![reassign client](@site/static/img/support/reassign-client.png) 3. Make the changes as required. 1. If the _Keep association for accounts_ checkbox is selected, Mambu will move the client to the new branch, but the accounts will still be associated with their current branch. 2. If the _Keep association for accounts_ checkbox is not selected, a pop-up will appear to confirm that the accounts will also be reassigned. Click **Save Anyway** to confirm the choice. 4. Click **Save Client**. :::note Client reassignments from the **All Clients** view below will move all their accounts to the new branch. ::: ## Reassign multiple clients If you need to assign several clients or groups to a different credit officer or to a different branch: 1. On the top menu, go to **Clients** > **All Clients**. 2. Use the filtering options to see the list of clients you're searching for. 3. Check the boxes that correspond to the clients you want to reassign. 4. Click **Actions** > **Reassign**. 5. Choose the new branch, center, and/or the credit officer. 6. Click **Assign**. ![Clients reassignment can be done via Actions button.](@site/static/img/support/clients-and-groups--reassign-multiple-clients.png) All the selected clients will then be assigned to the new branch, center, or to the new credit officer. :::note When bulk reassigning multiple clients or groups, if the centre or credit officer fields are left empty, Mambu will not update the centre or the credit officer for the selected clients. This allows you to change the branch of some clients or groups and keep their existing centre or credit officer. ::: :::warning Only users with the permissions to Edit Clients and to Edit Groups can make a clients' bulk assignment to credit officers and branches. ::: ## Deleting a client You can delete clients as long as they have no accounts. When you delete clients, all their personal details will be permanently removed from the system. To delete a client: 1. Open the client's profile. 2. On the right-hand side of the screen, click **More** > **Delete**. 3. Confirm. ![Client information screen with More button menu displayed and Delete button highlighted in red](@site/static/img/support/clients-and-groups--client-details-overview-with-delete-menu.png) ## Internal controls for individual clients You may want to manage your exposure to individual clients, for example, in the case that they default on their loans. To manage risk, you can set *Internal Controls* which are accessible at **Administration** > **General Setup** > **Internal Controls**. Examples of internal controls that you can set are: * Setting whether clients may receive multiple loans. * Determining if clients may be in more than one group. * Selecting the characteristics for which you check for duplicate client creation. For more information, see [Internal Controls](/docs/internal-controls). --- # Managing Corrections and Adjustments in Tills URL: https://docs.mambu.com/docs/managing-corrections-and-adjustments-in-tills/ ## Undo close Till When adjusting a transaction that is associated with a till that has already been closed, you will receive the following error message: ![Error message when adjusting a transaction that is associated with a closed Till](@site/static/img/support/tellers--deposit-transaction-adjustment-error.png) In order to adjust past transactions that have been processed through an already closed till, you must first undo the closure of the till. This is available under **Actions** > **Undo Close Till**. In order to see closed tills, the **Show Closed Tills** checkbox needs to be selected. ![Undo Close Till option from Actions drop-down menu](@site/static/img/support/tellers--closed-till-actions-menu.png) :::warning You can Undo Close Till only if you have no other opened tills, since you can have only one active till at any given time. ::: ## Adjust transactions Once you undo the closure of the till, you can adjust the transaction. You cannot adjust a transaction through the Tellering widget. Adjustments must be made directly from the account where the transaction was posted. :::warning We recommend closing the till again after making the adjustment. ::: To read more about how to adjust transactions, please go to [Adjusting Transactions](/docs/adjusting-transactions). --- # Managing credit arrangements URL: https://docs.mambu.com/docs/managing-credit-arrangements/ ## View a credit arrangement Once a credit arrangement is created, it will be displayed as a separate tab on the client or group **Overview** page (similar to the way a loan account is displayed). If you open the tab, you can see the credit arrangement details and a list of all the accounts managed under the credit arrangement. You can also add notes or change the credit arrangement parameters. Any changes made to the credit arrangement are captured and stored in the audit log, which is always accessible in the **Activity** tab. The **Details** section of the credit arrangement tab includes the following information: * **Available Credit Amount** for **Original (approved) loan/overdraft amount** * Calculated as: `Credit Arrangement limit - ( Sum of all linked original loan amounts + Sum of all linked Overdraft Limits)` * **Consumed Credit Amount** for **Original (approved) loan/overdraft amount** * Calculated as: `Sum of all linked original loan amounts + Sum of all linked Overdraft Limits` * **Available Credit Amount** for **Current (outstanding) loan/overdraft balances** * Calculated as: `Credit Arrangement limit - (Sum of all linked Loan Accounts Balances - Sum of all linked Overdrafts Balances)` * **Consumed Credit Amount** for **Current (outstanding) loan/overdraft balances** * Calculated as: `Sum of all linked Loan Accounts Balances - Sum of all linked Overdrafts Balances` * **Approved Credit Amount** - the sum of all loan and overdraft amounts of approved and active accounts linked to the credit arrangement. * **Accounts Summary** - shows information of accounts linked to the credit arrangement. * **General information and Details** - show detailed information about the credit arrangement parameters. * **State** - shows the current state of the credit arrangement: *Pending Approval*, *Approved*, *Active*, or *Closed*. A credit arrangement moves to the *Active* state when accounts are added to it. * **Approval Date** - the date when the credit arrangement was approved. ![Credit Arrangement view from Details tab](@site/static/img/support/credit-arrangements--credit-arrangement-details.png) *** ## Edit a credit arrangement Credit arrangements can be adjusted at any time, even after accounts are linked to them. For example, the credit arrangement **Amount** can be increased and the **Valid Until** date extended. The parameters of the credit arrangement can be edited by selecting the **Edit** button on the right-hand side of the screen. Editing a credit arrangement allows you to change the following: * **Amount** - the new amount can be higher, lower, or equal to the sum of total loan & overdraft amounts of accounts linked to the credit arrangement. When the credit arrangement amount is below the exposure limit, the available credit balance becomes negative. Any changes made to the credit arrangement limit will be logged in Mambu and can be viewed in the **Activity** tab. * **ID** - can be changed at any time. * **Start Date** - must be a date before the earliest disbursement / activation date across all the loan and overdraft accounts linked to the credit arrangement. * **End Date** - must be a date after the latest maturity / overdraft expiry date across all the loan and overdraft accounts linked to the credit arrangement. *** ## Reschedule or refinance accounts that are linked to a credit arrangement Accounts that are linked to a credit arrangement can only be rescheduled or refinanced into a different product if the new product also allows for its accounts to be linked to a credit arrangement. As with any account, the balance, start date, and end date constraints (outlined in [Adding accounts to a Credit Arrangement](/docs/adding-accounts-to-a-credit-arrangement)) need to be met. The rescheduled or refinanced loan will remain linked to the original loan's credit arrangement. *** ## Close a credit arrangement Credit arrangements that are past their **Valid Until** dates no longer need to be closed. This option is only available for credit arrangements where every account linked to them is closed. After a credit arrangement is closed, it will no longer be possible to add or remove accounts, edit, or delete it. Closed credit arrangements will be displayed under the **Closed Accounts** tab in the client's profile. :::note Any account linked to a closed credit arrangement cannot be reopened unless the credit arrangement itself is reopened first. ::: *** ## Reopen a credit arrangement Closed credit arrangements can be reopened at any time by users with the "Close Credit Arrangement" permission. *** ## Delete a credit arrangement A credit arrangement can only be deleted from the system if no accounts are associated with it. Once the accounts have been activated, the credit arrangement cannot be deleted. *** --- # Managing Deposit Products URL: https://docs.mambu.com/docs/managing-deposit-products/ ## Editing deposit products If you need to make changes to a deposit product: 1. On the main menu, go to **Administration** > **Products** > **Deposits**. 2. Find the product you want to edit and, on the right-hand side of the row, select **Actions** > **Edit**. 3. Make the changes you need. If the deposit product is already in use, some fields won't be editable. 4. Save the Product. ![Edit Deposit Product from Administration tab.](@site/static/img/support/deposits--deposit-products-list-3.png) ### Effects on deposit accounts When you make any changes to a deposit product, all the deposit accounts created under that product will be automatically updated as soon as you save the product. :::note If changes are made to the Interest Rate, when saving the changes on the product, you will be asked to which accounts the new interest setting applies. ::: ![Confirm Changes Made to Daily Savings pop-up with "Which accounts should the new interest settings apply to? option."](@site/static/img/support/deposits--confirm-changes-made-to-daily-savings.png) #### Example 1 You have a deposit product with an interest rate of 3% and you want to increase the interest rate to 3.5%. If you choose to apply the new interest settings to **All Existing and New Accounts**, the clients with deposit accounts under this product will have their currently accrued interest recalculated with the new interest rate of 3.5%. Already applied interest remains unaffected. The change will be visible on the account after next EOD cronjobs are completed. :::warning Changing the interest rate in the middle of the period affects existing accruals If you change the interest rate interest on the product level in the middle of the period, Mambu will recalculate existing accruals from the date when the interest has been applied last time. If the interest has never been applied, Mambu will recalculate interest acrrued from the activation date. Therefore, we recommend you to change the interest rate on the same date as the interest application date or to use the [`/changeInterestRate`](/api/api-v2/deposits/change-interest-rate/) API endpoint for changing fixed rates on the account level instead. If you encounter any issues with this behaviour, please contact Mambu Support Team. ::: #### Example 2 You have a deposit product with an interest rate of 3% and interest paid into account every week. There is an account created under this product - either manually at creation or or when the [`/changeInterestRate`](/api/api-v2/deposits/change-interest-rate/) API endpoint was called - which currently has an interest rate of 3.5%. You wish to change the product such that interest is paid into account every month. If you choose to apply to **All Existing and New Accounts**, all accounts under this product will receive the new interest settings, including the interest rate. Therefore, the account which has an interest rate of 3.5% will have have its interest rate updated to the product default of 3% according to **Example 1** above and interest paid into the account every month. The change will be visible on the account after the next EOD cronjobs are completed. If you have any concerns or uncertainties related to this behaviour, please contact Mambu Support Team. :::warning Default interest rate is applied to all accounts even if the value is not changed You may change any of the following interest-related fields: * "How is the interest rate charged?" * "When is the interest paid into the account?" You will be prompted to choose whether to apply these changes to only new accounts or to existing ones as well. If you do choose to apply to existing accounts as well, take into consideration that if a default interest rate is set on the product, even if its value was not modified in the current product editing session, it will be applied to all existing accounts. This means that any already existing accounts that currently hold a different rate than the default one set on the product will have their interest reset to this value, backdated to the date when the interest was last applied. ::: ## Activating and deactivating deposit products You can deactivate or activate deposit products from **Administration** > **Products** > **Deposits**: * **Deactivate**: Find the product you want to deactivate and, on the right-hand side of the row, select **Actions** > **Deactivate**. * **Activate**: Find the product you want to activate and, on the right-hand side of the row, select **Actions** > **Activate**. If you have Accounting switched on, before activating your deposit products you need to link them with your General Ledger Accounts as described in [Product Rules](/docs/linking-products-to-accounting#deposit-product-rules-under-cash-basis-accounting). By doing this you're making sure that the transactions associated to your deposit products will be automatically logged in Accounting as they occur. ![Deactivate Deposit Product from Administration tab.](@site/static/img/support/deposits--deposit-products-administration.png) When you deactivate a Deposit Product it will disappear from the list of products to offer to your clients, so you won't be able to create more accounts under that product. ![Show Deactivated Products option checked.](@site/static/img/support/deposits--deposit-products-list.png) :::note When you activate a product you'll see that the product's state changes and a pop-up is displayed letting you know that the product was activated. ::: In case you had active accounts using that product, they will remain active for the remaining term length. ## Deleting deposit products You can only delete products that have never had accounts associated to them. In case the product you're trying to delete has been or is being used, you'll get a warning message preventing you from deleting the product. To delete a deposit product: 1. On the main menu, go to **Administration** > **Products** > **Deposits**. 2. Find the product you want to delete and, on the right-hand side of the row, select **Actions** > **Delete**. 3. Confirm. ![Deleted button from Administration tab](@site/static/img/support/deposits--deposit-products-list-with-actions-menu.png) --- # Managing Fees in Deposit Accounts URL: https://docs.mambu.com/docs/managing-fees-in-deposit-accounts/ Mambu supports three types of fees you can set up when creating a deposit product and later apply to deposit accounts, monthly fees, manual fees, and arbitrary fees. ## Applying fees Monthly fees are applied automatically on the account, either on the first day of each month or on the same day of the month the account was first created, according to the **Apply Date Method** you selected when you set up the deposit product, but manual or arbitrary fees are applied on an ad-hoc basis by following these steps: 1. Open the deposit account. 2. On the right-hand side of the screen, select **More** > **Apply Fee**. 3. Enter the details of the fee. 4. Select **Apply Fee**. ![More drop-down with Apply fee option selected](@site/static/img/support/deposits--organizational-client-account-details.png) ### Applying fees when there's not enough balance By default, manual and monthly fees cannot be applied if there is not enough available balance in the account. Such fees will **not** consume ovedraft balance either. The following table shows what happens if you try to apply fees when there is not enough balance on the account, depending on the product configuration: | Product configuration | Results | | --- | --- | | No overdraft, no technical overdraft | You cannot apply fees, the account balance can't go below zero. | | Overdraft, no technical overdraft | You can apply fees on the account even with insufficient available balance. Account goes into `In arrears` state. | | No overdraft, technical overdraft | You cannot apply fees, the account balance can't go below zero. | | Overdraft, technical overdraft | You can apply fees on the account even with insufficient available balance. Account goes into `In arrears` state. | #### Applying fees to current accounts in overdraft There is however an additional functionaility that can be enabled to allow you to apply manual and monthly fees regardless of the balance for current accounts. You must have Overdraft enabled at product level but the overdraft limit can be set to 0 if no arranged overdraft with the end client was made. If this functionality is enabled, then if an account has a positive balance of USD20, it is possible to apply a USD25 fee, in which case the balance will go down to USD0 and the missing USD5 will become "Fees Due". For more information, see [Overdraft Products](/docs/overdraft-products). :::warning This functionality is irreversible. ::: ## Adjusting fees To adjust or reverse a transaction involving fees that have been applied by mistake or with the wrong amount: 1. Open the account. 2. Go to **Transactions**. 3. Find the transaction you want to adjust in the list and then, on the right-hand side of the row, select **Actions** > **Adjust**. 4. Enter the reason for the adjustment. 5. Select **Adjust Fee**. The transaction will be reversed. ## Deactivating and reactivating fees If a fee is not applicable anymore, you can deactivate it by selecting the small green square next to it and then saving your changes. When the fee is deactivated, the small green square will turn from green to grey. ![Product fees section with Activate/Deactivate dot.](@site/static/img/support/loans--product-fees-configuration-3.png) To reactivate a fee, follow the same procedure: select the grey square, then save your changes. When the fee is reactivated, the small grey square will turn from grey to green. --- # Managing Groups URL: https://docs.mambu.com/docs/managing-groups/ This page describes how to manage groups. For general information on groups and how they are used, see [Clients and Groups Overview](/docs/clients-and-groups-overview). Once a group has been created you can visit the group's profile to continue managing and editing it. For more information about creating groups, see [Creating a Group](/docs/creating-a-group). ![Group menu item](@site/static/img/support/clients-and-groups--groups-administration-menu.png) To view a list of all your groups to visit a group profile you can either use the **Groups** menu item in the navigation bar or select the **Groups** item in the **View** menu in the top bar. ![Group item in View menu in top bar](@site/static/img/support/clients-and-groups--clients-navigation-menu.png) ## Editing a group If you have the `EDIT_GROUP` permission, you can make changes to a group. For example, you can change the group type of a group. To edit a group: 1. Go to view the group's profile. 2. On the right-hand side of the screen, select **Edit**. 3. Make the changes. 4. Select **Save Group**. ![Group profile](@site/static/img/support/clients-and-groups--company-group-overview.png) ### Assigning loan and deposit products Once a group is created you can assign loan and deposit products to it. Only the loan and deposit products that were set as available to groups will be visible as options. For more information, see [Setting Up New Deposit Products - Product Availability](/docs/setting-up-new-deposit-products#product-availability) and [Setting Up New Loan Products - Product availability](/docs/setting-up-new-loan-products#product-availability). To assign loan or deposit products to a group: 1. In the top right-hand corner, select **New Account** . 2. Then select **New Deposit Account** or **New Loan Account** depending on what you want to set up. 3. Enter all the necessary information. 4. Select **Save Changes**. ### Editing notes and custom field values To edit notes: 1. Go to the bottom of the group's overview profile. 2. Hover over the notes area to reveal the edit icon and select it. 3. Enter the information in the text box. 4. Select the check icon to save. If you would not like to save your changes then select the deny icon . To edit a custom field value: 1. Go to the bottom of the group's overview profile. 2. Hover over the custom field value area to reveal the edit icon and select it. 3. Enter the information you would like to edit. 4. Select the check icon to save. If you would not like to save your changes then select the deny icon . If you want to add new custom field values to a group, you can do so by selecting **More** > **Add field**. ## Deleting a group If you have the `DELETE_GROUP` permission, you can delete a group as long as its members have no accounts. When you delete a group, all the details will be permanently removed from the system. To delete a group: 1. Go to the group's profile. 2. On the right-hand side of the screen, select **More** > **Delete**. 3. Select **Confirm**. ![Group information screen with More button menu displayed and Delete button highlighted in green](@site/static/img/support/clients-and-groups--company-group-details.png) ## Internal controls for groups You may want to manage your exposure to individual clients within groups, for example, in the case that they default on their loans. To manage risk, you can set *Internal Controls* which are accessible at **Administration** > **General Setup** > **Internal Controls**. Examples of internal controls that you can set are: * Setting whether clients and groups are required to be assigned to branches, centres, and credit officers. * Determining if clients may be in more than one group. * The size limit for a group. For more information, see [Internal Controls](/docs/internal-controls). ## Custom views for groups The **Groups** menu item also contains default views, also referred to as custom views, for groups. Custom views are customizable pages in the Mambu UI that can be used to create your own UI displays or to generate reports. For more information on how to create more custom views to have easy access to information about groups, see [Custom Views](/docs/custom-views). --- # Managing Islamic Deposit Accounts URL: https://docs.mambu.com/docs/managing-islamic-deposit-accounts/ ## Observation To observe Islamic deposit accounts for a particular Islamic product, follow these steps: 1. Navigate to **Islamic Products**. 2. Select **Actions** for the specific product of interest. 3. Choose **View Accounts**. All deposit accounts that are using Islamic deposit products can be observed here - Navigate to **Accounts**. ## Add Islamic rules Here you can define the account's **Profit sharing** rule - IPS account type: 1. Select **Actions** and **Edit** for specific account 2. Save your edits by clicking **Save**. ![account-id](@site/static/img/support/account-id.png) ## Link accounts to Class Here you can set associations of account with **Profit sharing** Class: 1. Select **Account** or **Accounts**. 2. Select **Set association**. ![accounts](@site/static/img/support/accounts.png) 3. Select or delete **Class** from the list. ![Edit association](@site/static/img/support/edit-association.png) ## Islamic accounts parameters | **Parameter** | **Description** | **Required** | | -- | -- | -- | | Effective date | The date when the change should be implemented. | YES | | Product | The deposit product to use for this deposit account. | YES | | IPS Account type | The account type for profit sharing calculations. Customer account - client account (as a partner in investment). Bank investment - bank account (as a partner in investment) ***NOTE***: default value - Customer account. | YES | | Class | The linking of an account to a class for profit-sharing calculations. If an account is not associated with a class, it will not be included in profit calculations. | NO | --- # Managing Loan Products URL: https://docs.mambu.com/docs/managing-loan-products/ ## Editing loan products When you edit a loan product, the new terms and conditions will only affect any new accounts created under that product. To edit any loan product: 1. On the main menu, go to **Administration** > **Products** > **Loans**. 2. Find the product you want to change then on the right-hand side of the row, select **Actions** > **Edit**. 3. Make the changes. 4. Save the product. ![List of Loan products showing the "Edit" option under "Actions"](@site/static/img/support/edit-loan-products.png) ### Effects in loan accounts Existing accounts can only be changed to reflect the new product terms if they are "Pending Approval". In that case, go to the account > select **More** > **Edit Account** > make the changes > save. ### Change existing accounts' terms To change an account which has been aproved and disbursed already you need to first click on **More** > **Undo Disburse** or **Undo Approval**. The account state will go back to **Pending Approval** and you will be able to edit it. ### Tracking Changes in Loan Products For auditing purposes, all changes that occur in a product, will be tracked and displayed both under the Activity feed on the dashboard and on the actual product's activity feed. As with all other activities, these changes will be stored with the details about date, time and the user who edited the product providing a complete audit trail for every product. ## Activating and deactivating loan products When you create a loan product, you can select to either create the product as **Active** or activate it later, for example, after settings have been checked by another user under the four-eyes principle. To activate or deactivate your products: 1. On the main menu, go to **Administration** > **Products** > **Loans**. 2. Find the product you want to activate or deactivate then, on the right-hand side of the row, select **Actions** > **Activate** or **Deactivate**. ![List of Loan products showing the Activate option under Actions](@site/static/img/support/activate-loan-product.png) When you deactivate a product, it will no longer be available to create new loan accounts under. However, any active loan accounts that were part of the now deactivated product will remain active. ## Deleting loan products You can only delete products that have never had accounts associated to them. In case the product you're trying to delete has been or is being used, you'll get a warning message preventing you from deleting the product. To delete an existing loan product: 1. On the main menu, go to **Administration** > **Products** > **Loans**. 2. Find the product you want to delete then, on the right-hand side of the row, select **Actions** > **Delete**. 3. Confirm. --- # Managing Profit Sharing Deposit Product URL: https://docs.mambu.com/docs/managing-profit-sharing-deposit-products/ The main actions for Profit Sharing Deposit Products, such as editing, deleting or deactivating, can be performed in the same way as for standard deposits. However, certain criteria specific to profit sharing arrangements may apply, limiting some actions based on agreed terms. ## Editing profit sharing accounts ## Closing, deleting, withdrawing, and rejecting profit sharing accounts ## Locking, unlocking, and re-opening profit sharing accounts | Editing action | Standard deposit products | Profit sharing deposit products | | --- | --- | --- | | **Profit sharing attribute** | No | No | | **Interest rate** | Yes | No| --- # Managing Users under Federated Authentication URL: https://docs.mambu.com/docs/managing-sso-provisioned-users/ There are two types of authentication available in Mambu, *Mambu login* and *federated authentication*. Federated authentication allows users to connect to Mambu using Single Sign-On (SSO). With SSO, users authenticate through an Identity Provider (IdP) such as Okta, Azure Active Directory, Centify, OneLogin, or Google. Then they are able to access a variety of web applications without re-entering their username and password. If the federated authentication feature is enabled, the way you manage users in Mambu will change. :::warning Once federated authentication is enabled, it cannot be disabled. ::: ## Regular users *Regular users* are Mambu users who do not have admin rights. If your organization has already created Mambu users before enabling federated authentication, you will have two kinds of users after the feature is enabled: users created in Mambu, and users created in your IdP. Users created in Mambu will now switch from using Mambu login to using SSO to log in to Mambu. Users initially created in your IdP will only log in to Mambu using SSO. ### Creating regular users Once you enable federated authentication, you must create new regular users from your IdP. You will no longer be able to create new regular users from the Mambu UI, even if you previously had the `Create Users` permission. The option to create users will no longer be available in the **Create** dropdown or in **Administration** > **Access** > **Users**. ### Managing regular users created in Mambu Once federated authentication is enabled, regular users will no longer be able to log in to Mambu with their username and password. They will have to log in to Mambu using SSO. For each user with access to Mambu who was initially created in the Mambu UI, you must create a corresponding user in your IdP using the same email address and assign them to the Mambu SAML App. Please refer to the documentation for your IdP for more information on how to set up new users. These users will have Mambu credentials, but they will no longer be able to use them to log in to Mambu. If they attempt to do so, they will receive the error message "Sorry, your username and password appears to be incorrect. Please try again or contact your admin." For any user created in Mambu, the first name, last name, display language, branch, and role defined in the IdP will override the values previously defined in Mambu. ### Managing regular users created in your IdP After federated authentication is enabled, you must create new regular users from your IdP. Please refer to the documentation for your particular IdP for more information on how to set up new users. Make sure that each user has a unique email address, and once you have created them, assign them to the Mambu SAML App. If your user does not have a unique email address, then you will receive the message "Email address of the users is not unique. Email duplication is not allowed." You must also define the display language for the Mambu UI in your IdP. For more information, see [Language Settings](/docs/language-settings). Finally, when you create a new user you must assign them a role. ## API Users Every Mambu API user must have a username and password in order to make API calls. However, users created in your IdP will not have a password managed by Mambu. For this reason, API users must have **API Access** as their only assigned role. Otherwise, when you attempt to create an API user that also has access to Mambu, you will receive the error message: `{ "returnCode": 3500, "returnStatus": "CANNOT_CREATE_NEW_USER_IN_FEDERATED_CONTEXT" }` To create a new API user: 1. On the main menu, go to **Administration** > **Access** > **Roles**. 2. Either edit an existing role, or select **Add Role** to create a new role. 3. Create a role and select **API** under **Access Rights**. You must leave the **Mambu** checkbox unselected, as shown below. 4. Use the users endpoint, and make sure to assign the role you created in the last step. ![Editing Role dialog with only API access right checkbox selected.jpg](@site/static/img/support/5%20copy.jpg) In addition to API users, you may also use API Consumers as an alternative to user-based access control, and we recommend that anyone using federated authentication use API Consumers to request access credentials instead of users. For more information, see [API Consumers](/docs/api-consumers). ## Admin Users When you enable federated authentication, regular users may no longer log in to Mambu using their username and password. However, admin users may continue to do so. Because admin users may continue accessing Mambu using their username and password settings, we advise them to use an email address, although this is not yet mandatory. This will enable administrator users to recover their password in case they forget it. If the admin user is provisioned via IdP, ensure that the Attributes & Claims section contains a mapping for the email. ### Creating admin users There are two ways to create a new admin user: * Assign an existing user the **Administrator** user type, or * Assign an existing user a role that includes Administrator permissions. For more information on roles, see [Roles](#roles) below. To assign the Administrator user type to an existing user: 1. Create a new user in your IdP. 2. Log in to Mambu with the new account to provision the user in Mambu. The user will have no role or permissions, and therefore no access to the Mambu platform. 3. Log out, and log back in to Mambu with any administrator account. 4. On the main menu, go to **Administration** > **Access** > **Users**. 5. Find the new user you created in your IdP in the list of users and select **Actions** > **Edit**. 6. In **User Rights**, select the **Administrator** checkbox. 7. Select **Save Changes**. To create a new user with a role that includes Administrator permissions: 1. If you do not already have an appropriate Mambu role with Administrator permissions that you can assign to the new user, create one now. 2. Create a role in your IdP and give it the same name as the Mambu role that has Administrator permissions. 3. Create a new user in your IdP. In the `RoleID` attribute, assign the role with Administrator permissions. 4. Log out, and log back in to Mambu with your new user credentials. After the first successful login, a new user with admin rights will be provisioned in Mambu. ## Roles Every user in Mambu is assigned *permissions*, which determine what the user is able to see and do. You can group a set of permissions together in a *role*, and assign roles to users. ### Setting up user roles To set up user roles: 1. **Create roles in Mambu**: you must create all the roles you want to use in the Mambu UI. For more information on creating roles, see [Roles](/docs/roles). 2. **Create roles in IdP**: you must create all the roles you have in Mambu UI that you want to use in your IdP as well. The SAML attribute in the IdP will be called `RoleID`. The value of the `RoleID` attribute should be the *role name*. 3. **Assign roles to users in IdP**: every user must have a role assigned to them from your IdP even if they previously had a role defined in Mambu. :::note The mapping system that links the roles in Mambu to your IdP uses the *role name*. That is why the value for the `RoleID` attribute is the *role name*. It is not the role ID. ::: We check the `RoleID` attribute at each login so any changes to a user's role made in the IdP will be reflected in Mambu as well. Moreover, different IdPs may use different terms to describe what we call "roles". For example, roles are called [Groups in Okta](https://developer.okta.com/docs/api/resources/groups) or [appRoles in Azure AD](https://docs.microsoft.com/en-gb/azure/active-directory/develop/active-directory-enterprise-app-role-management). ### Managing user roles You **must** assign a role with the `RoleID` attribute to every user in your IdP, whether they were created in Mambu or from you IdP. After federated authentication is enabled, in case of a conflict, roles assigned in the IdP override roles that were previously assigned in Mambu. You will also no longer be able to edit a user's roles in Mambu. If you select to edit a user and open the **Edit User** dialog, you will find the **Role** dropdown is not available. ![The role dropdown in the edit user dialog is not available..jpg](@site/static/img/support/edit%20user%20dialog%20copy.jpg) If you do not specify a role in your IdP using the `RoleID` attribute and your user has no other permissions, then your user will not be able to access Mambu. If they were created in Mambu with a role defined in Mambu, then that role will be automatically removed. ![Role dropdown is blank in Edit User dialog.jpg](@site/static/img/support/edit%20user%20dialog%20copy%202.jpg) If the user attempts to log in to Mambu they will not be able to log in and they will receive the warning message "Please ask the administrator to assign the appropriate permissions into *`ORGANIZATION_NAME`* as per your role. This will ensure you'll get access to the most common features and you are ready to start enjoying the range of services available in *`ORGANIZATION_NAME`*." ![users-and-access-control--welcome-to-my-bank-okta.png](@site/static/img/support/users-and-access-control--welcome-to-my-bank-okta.png) ## Branch assignment For customers that have federated authentication enabled, branch assignment is managed using your identity provider (IdP). The following are the general steps to assign a branch to an existing user using your IdP: 1. In your IdP, create a custom attribute with the label `BranchID`. 2. If necessary, set up the mapping for the `BranchID` custom attribute in your IdP to the `BranchID` attribute in Mambu. This process is similar to the process of mapping the `RoleID` custom attribute. 3. Go to each user profile in your IdP and add the relevant value for `BranchID` using the ID of an existing branch. Any further updates to the branch a user is assigned to must be carried out using your IdP. For more information on how to carry out branch assignment using a specific IdP, see the following relevant sections: * [Branch assignment using Azure AD as your IdP](/docs/entra-id-as-idp#branch-assignment) * [Branch assignment using Google as your IdP](/docs/google-as-idp#branch-assignment) ### Branch assignment and branch access Only branch assignment is managed using your IdP. Branch access is still managed using the Mambu UI or API v2. Branch assignment is managed in the **Assigned To** section of the user form. Whereas, branch access is managed in the **Access Rights** section of the user form. ![assigned_to_and_access_rights_section_of_user_form.png](@site/static/img/support/assigned_to_and_access_rights_section_of_user_form.png) For more information about these sections of the user form, see [Creating a User](/docs/creating-new-users). ## Access Preferences ### Managing session expiration time You can define a session expiration time for your IdP and for Mambu UI. In Mambu, the timeout session field sets the amount of time a user can be inactive before they are automatically logged out. The session expirations times for Mambu and your IdP are independent from one another. Once you log in to Mambu, the system will only take into account your Mambu session expiration time. To define the Mambu session expiration time: 1. On the main menu, go to **Administration** > **Access** > **Preferences**. 2. Under **Timeout Session**, enter the amount of minutes you want your session time to last. 3. Select **Save Changes**. ![Access Preferences](@site/static/img/support/users-and-access-control--access-preferences-security-settings.png) ### Managing critical action re-authentication A **critical action** is a function that Mambu considers business critical. For more information on critical actions, and a list of them, see [Actions considered critical in Mambu](/docs/access-preferences#actions-considered-critical-in-mambu). If critical action re-authentication is enabled, users are required to authenticate when they perform critical actions in the system. When federated authentication is enabled, regular users are redirected to their IdP to authenticate. Admin users may also use Mambu credentials to authenticate. If federated authentication is not enabled, a **Confirm Identity** dialog appears and users are required to provide their credentials when they perform critical actions in the system. Note that some IdPs (such as Google) use pre-logged-in sessions instead of enforcing re-authentication. To enable or disable critical action re-authentication: 1. On the main menu, go to **Administration** > **Access** > **Preferences**. 2. Under **Critical Actions Re-Authentication**, select or clear the **Require Admin Password** checkbox. 3. Select **Save Changes**. --- # Working with Tills URL: https://docs.mambu.com/docs/managing-tills-tellering-widget/ To manage tills, use the **Tellers** widget accessible from the Dashboard. :::warning Not all of the actions described below are necessarily available to every Teller user, depending on their permissions. ::: ## Open a till With this permission, a Vault Teller (Supervisor) can open new tills for other tellers. This option is available from the bottom-right corner of the **Tellers** widget on the Mambu Dashboard, as highlighted on the screenshot below. ![Teller widget with Open Till button](@site/static/img/support/tellers--open-a-till.png) When opening a till, fill out the following information: **Till ID**: each newly opened till will be given a unique ID by Mambu according to a predefined format: `@@@###` (3 letters followed by 3 numbers). The ID can be overwritten, as long as the format is kept. **Teller**: the user to whom the till will be assigned. The users who will appear in the drop-down will only be the ones of “Teller” User Right Type. **Opening Amount**: opening balance of the new till (can be zero). **Balance Constraint Type**: allows you to specify minimum and maximum balance thresholds for the amount of money in the till. This is calculated as the sum of the Opening Amount and all transactions posted through the till. These thresholds can be enforced in the following ways: * **None** - no limits on the balance * **Soft** - if a new transaction posted brings the balance in the till beyond the specified thresholds, then the teller will get a warning message, but the transaction will still be posted. * **Hard** - if a new transaction posted brings the balance in the till beyond the specified thresholds, the teller will get an error message and it will not be possible to post the transaction. ![Open till pop-up with ID, Teller, Opening Amount, Balance Constraint Type, Minimum Balance, Maximum Balance](@site/static/img/support/tellers--open-till.png) :::note Each teller can be assigned to only one open till at any given time. ::: ## Undo Open Till If a till was opened by mistake and no transactions have been processed through the till yet, you can undo the Open Till operation. As a result, the till will be deleted. ## Add or remove cash To add or remove cash, your user must have the Add Cash (`ADD_CASH`) and/or Remove Cash (`REMOVE_CASH`) permissions. This allows them to manage the balance within a till by adding or removing cash. This is available under **Actions** > **Add Cash** (or **Remove Cash**). :::warning When adding or removing cash to or from a till there will be no transaction log and no accounting entries. ::: ## View a till’s details Allows you to view a log of all transactions posted through a given till, together with the opening and closing balances. This is available under **Actions** > **View Till**. ## Close a till This action closes a till, so that no new transactions can be posted through it. This function is available under **Actions** > **Close Till** as highlighted in the screenshot below. ![Actions button from Tellers widget with Close Till option.](@site/static/img/support/tellers--till-actions-menu.png) A new window opens showing the opening and the closing balance (“Cash in Till”) details along with its transaction log to confirm the closure and help with any reconciliations. ![Close Till screen with Cash in Till fields and Transactions Log section.](@site/static/img/support/tellers--close-till.png) Once a till is closed, it will no longer appear in the Tellers widget unless the **Show Closed Till** checkbox is selected. Once a till is closed, transactions processed through that till can’t be reversed (see more details [here](/docs/managing-corrections-and-adjustments-in-tills) about how to proceed if you need to make corrections to transactions in a closed Till). ## Reopen a till Closed tills can be reopened by navigating to **Actions** > **Reopen Till**. When a till is reopened it will have the same balance constraints as when it was originally created and the **Reopening Amount** will be the **Cash in Till** balance from when it was previously closed. :::warning Reopen Till vs Undo Close Till From the system's perspective, a reopened till is effectively a *new* till, but with the same ID as the old till. Therefore, you will not be allowed to make any corrections of past transactions in a reopened till. In case any corrections (reversals) are needed, the closure of the previous till needs to be undone (please see [Managing corrections and adjustments in tills](/docs/managing-corrections-and-adjustments-in-tills) page for more details). For the above reasons, we do not recommend using the **Reopen Till** functionality. Instead, it's better to use **Undo Close Till** as it has the same effect as Reopen Till, but with the added advantage that it allows you to reverse transactions and therefore effectively and fully work again with the previously closed till. ::: --- # Managing your Organization Overview URL: https://docs.mambu.com/docs/managing-your-organization-overview/ An *organization* refers to the entirety of your business, along with all of your branches and staff members. Mambu provides configuration options for your organization that define everything from your organization's name and logo to the time zone used to date transactions and schedule automated processes. This page provides a brief overview of some of the main functional categories of available configuration options for your organization. ## Corporate identity You may configure Mambu to use your organization's name and logo. For more information, see [Branding](/docs/branding). For information on configuring your organization's contact information, see [Organization Contact Details and Time Zone](/docs/organization-contact-currency-and-timezone). ## Organizational structure You may subdivide your organization into branches and centres. *Branches* are an organization's subdivision operating locally or having a particular function. They often represent a geographical subdivision of an organization or a product line. Each branch can have multiple centres assigned to it. *Centres* are subdivisions of a branch, and they may be used for a variety of reasons. Clients may be assigned to a centre, which can be useful if you want to collect centre-specific reporting. For more information, see [Branches and Centres](/docs/branches-and-centres). ## Financial settings Any currency you want to support must be configured in Mambu. If you want to support multiple currencies, it is up to you to define the exchange rates between those currencies, as well as to define the base currency used for accounting. For more information, see [Currencies](/docs/currencies). You may also configure three types of index and tax rates for your loan and deposit products in Mambu: * Interest rates * Value-added tax rates * Withholding tax rates For more information, see [Customizing Index Interest Rates and Tax Rates](/docs/customizing-index-rates). ## System configuration Several Mambu entities can be customized with *custom field definitions* to store any additional information that you want to associate with the entity and record. For example, if you wanted to track which of your clients are students so that you could easily retrieve or view the data associated only with students, you could create a *student* custom field. Custom field definitions are robustly supported throughout the Mambu UI and API. Custom field values may be retrieved and manipulated via API v2. For more information, see [Custom Fields](/docs/custom-fields). Mambu also provides some configuration options for automated jobs that regularly run to ensure that all account states, days in arrears, penalties, and fees are up to date and consistent with any transactions that have been posted. For more information, see [End of Day Processing and Cron Jobs](/docs/automatic-end-of-day-actions). --- # Manual and Automated EOD Process URL: https://docs.mambu.com/docs/manual-and-automated-eod-process/ In the automated EOD process, the profit is automatically approved and prepared for the profit application process. Profit will be applied on each account on the last day of the account payment cycle or on the next day after it. EOD processes can also be configured to execute at a manually-scheduled time or be triggered via the API. This allows for precise control over the timing of profit calculation, approval, and application - specifically on the last day of the profit period. **Booking Date vs. Processing Time** The system distinctly separates the processing time (when the job physically runs) from the value date (the accounting/booking date). This ensures operational flexibility while maintaining full Shari'ah compliance. For example, even if the job executes at 9:00 AM on the 1st of the new month, the profit transaction is booked with the correct value date (e.g., the 1st of the month at 00:00:00). This alignment is controlled by the *Profit Application Point* parameter at the Product level, ensuring customer records and accounting remain accurate for the closed profit period. ### Automated EOD process Mambu executes a daily series of automated tasks outside of business hours, alongside an hourly series of processing tasks. The profit calculation workflow is an integral part of this End-of-Day (EOD) process. 1. **Proposal Generation:** A default proposal is generated on the second day of the profit calculation cycle. 2. **Mid-Cycle Visibility:** Throughout the cycle, users can view indicative information covering the period from the start date to the present. 3. **Finalisation:** At the end of the profit cycle, the calculation is finalized and distributed to relevant accounts. 4. **Application:** In the automated workflow, profit is automatically approved and prepared for application. It is applied to each account on the last day of the account payment cycle or the following day. ### Manual EOD process Islamic Profit Sharing (IPS) jobs are designed to run during the core banking system's EOD process. To accommodate manual adjustments (such as backdated entries), use the following procedure: 1. **Switch EOD to Manual:** Before midnight, on the last day of the month, the operational team should switch the main core banking EOD process from "Automated" to "Manual." This pauses the entire EOD batch. 2. **Perform manual actions** After midnight, post any necessary Incomes / Expenses journal entries for ended profit period (using backdated) or perform other required actions. 3. **Trigger EOD Manually:** Once adjustments are complete (e.g., 9:00 am the next morning), an operator manually triggers the EOD run. 4. **Execution:** The Final Profit Amount Application Job executes as part of this run, posting the profit to customer accounts. 5. **Revert to Automated:** After completion, switch the main EOD process back to "Automated" for the next night's cycle. --- # Manual Email Notifications URL: https://docs.mambu.com/docs/manual-email-notifications/ This page describes how to manage manual email notifications. For more information about email notifications in general, see [Notifications Overview](/docs/notifications-overview). Manual email notifications let you send an email to communicate with individual clients or groups at any moment. You can send from a client or group profile, or from a related loan or deposit account section. When sending a manual email, you can either select a template or compose the message directly. Templates support placeholders and advanced formatting. ## Creating manual email notification templates To create or edit manual email notification templates, you must have the following permissions: - **Create templates**: Create Templates (`CREATE_COMMUNICATION_TEMPLATES`) and View Administration Details. - **Edit templates**: Edit Templates (`EDIT_COMMUNICATION_TEMPLATES`) and View Administration Details. To create a manual email notification template: 1. On the main menu, go to **Administration** > **Templates** > **Emails**. 2. Select **Add Template**. 3. Enter the required information (see field descriptions below). 4. Select **Save Changes**. ![Manual Email Notifications List](@site/static/img/support/notifications--email-templates-list.png) ## Fields for manual email notification templates The following fields are available when creating manual email notification templates. ![Dialog to create manual email notification template](@site/static/img/support/notifications--edit-account-warning-template.png) ### Email name The template name must be unique and a maximum of 255 characters. Leading and trailing spaces are removed automatically. ### Email target The target indicates what entity the notification relates to. For manual email templates, the available targets are: - Client - Group - Loans - Savings The target type determines both: - Which placeholders are available in the template, and - Where the template is shown in the UI. For example: - When sending from a **client** profile, you see **Client** templates. - When sending from a **group** profile, you see **Group** templates. - When sending from a **loan** account, you see **Loans** templates. - When sending from a **deposit/savings** account, you see **Savings** templates. > Note: Even when sending from an account section, the email is addressed to the account holder’s email address (client or group). ### Email contents The email contents consist of a subject line and the message body. - The **subject** can include text and placeholders. The subject has a maximum length of 255 characters. We recommend keeping subjects around 50 characters for better preview and deliverability, but this is a guideline, not an enforced limit. - The **body** can include text, images, links, and placeholders when using a template. When you create or edit a template, you can work with: - A rich text editor, and - An HTML editor. For more information on how to use these editors, see [Content Editors](/docs/content-editors). When you compose a message directly in the send dialog (without selecting a template), a rich text editor is available. ## Sending manual email notifications You can send manual emails via the Mambu UI or via API. For the API, see the Communications Messages endpoint: [Communications](/api/api-v2/communications_messages/communications-messages). To send manual email notifications, you must have the **Send Manual Email** (`SEND_MANUAL_EMAIL`) permission. ![Sending manual email from a client profile](@site/static/img/support/notifications--client-profile-action-menu.png) To send a manual email notification: 1. Open the profile of the client or group you want to contact. Alternatively, open a related loan or deposit account and use the **Send** action there. 2. Select **Send** > **Send Email**. The option appears only if: - Email notifications are enabled for your organization, and - The client or group has an email address on their profile. 3. In the **Send Email** dialog, either: - Select a template (filtered based on the context: Client, Group, Loans, or Savings), or - Compose a message directly. 4. If you select a template: - You can adjust the contents before sending if you have the **Edit Templates** permission. - If you do not have the Edit Templates permission, the template content is read-only. 5. Select **Send Email**. :::note If you want to include styling or custom HTML, use an email template. For more information, see [Content Editors](/docs/content-editors). ::: ![Send Email dialog with fields](@site/static/img/support/notifications--send-email.png) ### API parity The Communications Messages API supports sending manual emails with similar behavior to the UI, including permission checks and template/target validation. Ensure your API user has the `SEND_MANUAL_EMAIL` permission and that email notifications are enabled and configured for your organization. ## Troubleshooting - **The Send Email button doesn’t appear** Check that: - Email notifications are enabled for your organization. - The client or group has an email address on their profile. - Your user role has the `SEND_MANUAL_EMAIL` permission. - **Message not sent** Check: - Your email provider configuration. - That the destination email address is valid. - If you are using a template, that all required placeholders can be resolved for the recipient. --- # Manual SMS Notifications URL: https://docs.mambu.com/docs/manual-sms-notifications/ This page describes how to manage manual SMS notifications. For more information about SMS notifications in general, see [Notifications Overview](/docs/notifications-overview). Manual SMS notifications let you send an SMS to communicate with individual clients or groups at any moment. You can send from a client or group profile, or from a related loan or deposit account section. When sending a manual SMS, you can either select a template or compose the message directly. ## Creating manual SMS notification templates To create manual SMS notification templates, you must have the following permissions: - **Create:** Create Templates (`CREATE_COMMUNICATION_TEMPLATES`) and View Administration Details. - **Edit:** Edit Templates (`EDIT_COMMUNICATION_TEMPLATES`) and View Administration Details. To create a manual SMS notification template: 1. On the main menu, go to **Administration** > **Templates** > **SMS**. 2. Select **Add Template**. 3. Enter the required information (see field descriptions below). 4. Select **Save Changes**. ![Manual SMS notification templates list](@site/static/img/support/notifications--sms-notification-templates.png) ## Fields for manual SMS notification templates The following fields are available when creating manual SMS notification templates. ![Creating SMS notification template dialog](@site/static/img/support/notifications--edit-sms-notification-template.png) ### SMS name The template name must be unique and a maximum of 255 characters. Leading and trailing spaces are removed automatically. ### SMS target The target indicates what entity the notification relates to. For manual SMS templates, the available targets are: - **Client** - **Group** - **Loans** - **Savings** The target type determines both: - Which placeholders are available in the template, and - Where the template is shown in the UI. For example: - When sending from a **client** profile, you see templates with target **Client**. - When sending from a **group** profile, you see templates with target **Group**. - When sending from a **loan** account section, you see templates with target **Loans**. - When sending from a **deposit** account section, you see templates with target **Savings**. > Note: Even when sending from an account section, the SMS is sent to the account holder’s phone number (client or group). There is no separate “account phone number”. ### SMS contents Enter the body of your SMS message. You can include plain text and placeholders. For details, see [Placeholders](/docs/placeholders). #### About SMS length and billing - SMS providers automatically split long messages into multiple segments. For example, GSM-7 messages are usually split roughly every 160 characters and Unicode messages around 70 characters. - Segmentation and billing are handled by your SMS provider. Longer messages may result in more segments and higher costs. - Mambu does **not** enforce a functional limit of 160 or 1600 characters. A high technical maximum is enforced to prevent overly large payloads. If this limit is exceeded, the message will not be sent and an error will be shown. - We recommend keeping messages concise to reduce segmentation and costs. ## Sending manual SMS notifications You can send manual SMS via the Mambu UI or via the API. For information on sending SMS via API, see the [Communications](/api/api-v2/communications_messages/communications-messages) endpoint in our API Reference. To send manual SMS notifications, you must have the **Send Manual SMS** (`SEND_MANUAL_SMS`) permission. ![Send SMS option in client profile](@site/static/img/support/notifications--client-profile-action-menu-3.png) To send a manual SMS notification: 1. Open the profile of the client or group you want to contact. Alternatively, open a related loan or deposit account and use the **Send** action there. 2. Select **Send** > **Send SMS**. The option appears only if: - SMS notifications are enabled and configured for your organization, and - The client or group has a phone number defined on their profile. 3. In the **Send SMS** dialog, either: - Select an SMS template (filtered based on the current context: Client, Group, Loans, or Savings), or - Compose a message directly. 4. If you selected a template, you can adjust the contents before sending, as long as you have the **Edit Templates** (`EDIT_COMMUNICATION_TEMPLATES`) permission. 5. Select **Send SMS**. ![Send SMS dialog](@site/static/img/support/notifications--send-sms.png) ## Troubleshooting - **The “Send SMS” button doesn’t appear** - Check that SMS notifications are enabled and correctly configured for your organization. - Make sure the client or group has a phone number on their profile. - Confirm that your user role includes the `SEND_MANUAL_SMS` permission. - **The message is not sent** - Verify the destination phone number is valid. - Check your SMS provider configuration and credentials. - Keep the message reasonably short to avoid unexpected segmentation and costs. Extremely large messages may be rejected and will not be sent. --- # Marqeta Integration URL: https://docs.mambu.com/docs/marqeta-integration/ We partner with [Marqeta](https://www.marqeta.com) to provide card issuing and processing services. Marqeta is a card issuing platform providing an Open API. The Marqueta integration is for Mambu customers who want to offer debit cards to their clients. Using the Marqeta integration means you do not need to build out your own gateways or deal with messaging standards such as ISO 8583. Marqeta is live across North America, Australia, and Europe and integrated with the Visa, Mastercard, and Discover networks - allowing you or your clients to make the best choice of a card product. For more information about Marqeta see [Mambu Marketplace](https://mambu.com/partner/marqeta) or the [Marqeta website](https://www.marqeta.com/). The Mambu-Marqeta integration is used to process payment card authorization requests and accept payment card clearing transactions and reversal instructions sent by Marqeta. The integration supports funding card transactions via Marqeta’s Just-in-Time (JIT) Funding solution. You can manage card authorization via the Marqeta JIT Funding gateway. When a transaction is initiated, funds are moved from a funding account to the card account and the transaction is then settled, following a successful authorization via the JIT gateway. This setup supports use cases with multiple combinations of authorization and settlement business flows. ### Prerequisites Before working with cards, make sure you have your Mambu environment set up. There may be additional setup to be done in Marqeta if you intend to use their simulation APIs for testing purposes. ### Architecture The Mambu-Marqeta integration is built around the Marqeta JIT Funding concept, which can be described as a method of automatically funding an account in real-time during the transaction process. Through the Gateway JIT Funding approach, the Marqeta platform applies spend controls to make authorization decisions and forwards funding requests to the bank’s core system, through the gateway, so that funding decisions can be made. Mambu receives these funding requests and approves or denies them using the core system’s backend business rules. The Marqeta platform exchanges the following types of messages with Mambu: * **JIT Funding requests:** Actionable messages for authorization requests sent by Marqeta to create a hold for the requested amount, check payment card account, or get the account balance. Mambu responds promptly to these requests. * **JIT Funding responses:** Sent by Mambu to the Marqeta platform in response to an actionable message to approve or deny an authorization request. * **JIT Funding notifications:** Transaction event messages sent by the Marqeta platform to Mambu's JIT Informative Notifications endpoint. These asynchronous messages contain the entire transaction and information about its final outcome. These batches are to be stored and then processed asynchronously. * **JIT Funding notification responses:** Sent by the JIT Informative Notifications endpoint after a batch of transactions has been validated for the presence of all required parameters. Communication is done using the following endpoints. #### Gateway endpoint This endpoint is designed to receive and respond to actionable requests. To approve a request, a `200 OK` status code is sent and the `jit_funding` object is included as the response body. To deny a request, a `402 Payment Required` status code is sent and the `jit_funding` object is included as the response body with a reason for declining. #### Informative notifications endpoint To handle Informative JIT Funding messages, Mambu uses an endpoint for receiving event notifications. Shortly after each transaction, the Marqeta platform sends webhook notifications to this endpoint to enable tracking of requests, maintaining account balances, and resolving timeout issues. Mambu validates the presence of mandatory parameters for clearing messages and responds to each JIT Informative request through a dedicated API Gateway with a `200 OK` status code if the validation of the batch of transactions has passed. Otherwise, it sends back a `402 Payment Required` status code, at which point Marqeta will resend the events. ## JIT actionable requests The following JIT actionable requests are supported:
    Transaction type Method Purpose
    authorization pgfs.authorization To create a new reservation for the requested amount, if it is available on the card account.
    authorization.atm.withdrawal
    authorization.cashback
    authorization.quasi.cash
    pindebit.authorization
    account.funding.authorization
    authorization.incremental pgfs.authorization.incremental To increase a reservation with the requested amount, if it is available on the card account.
    original.credit.authorization pgfs.original.credit.authorization
    Conventional Funds    		 To check a payment card and approve the credit authorization.
    refund.authorization pgfs.refund.authorization
    balanceinquiry pgfs.balanceinquiry To return account balances.
    pindebit.balanceinquiry
    pindebit pgfs.auth_plus_capture To debit card account with the requested amount, if it is available on the card account.
    pindebit.atm.withdrawal
    pindebit.cashback
    original.credit.auth_plus_capture pgfs.original.credit.auth_plus_capture To credit card account with the requested amount.
    original.credit.authorization pgfs.original.credit.authorization
    Fast Funds
    ## JIT informative notifications The following JIT informative notifications are supported:
    Transaction type Method State Purpose
    authorization.clearing pgfs.authorization.capture
    pgfs.force_capture    		 COMPLETION To debit a card account and remove or reduce the debit hold if it is present.
    authorization.clearing.atm.withdrawal
    authorization.clearing.cashback
    authorization.clearing.quasi.cash
    pindebit.authorization.clearing
    account.funding.authorization.clearing
    original.credit.authorization.clearing pgfs.original.credit.authorization.clearing
    Conventional Funds    		 COMPLETION To credit a card account and remove the credit hold if it is present.
    refund.authorization.clearing pgfs.refund.authorization.clearing
    refund pgfs.refund
    pindebit.refund PENDING
    original.credit.authorization.clearing pgfs.original.credit.authorization.clearing
    Fast Funds    		 COMPLETION To credit a card account.
    authorization.advice pgfs.reversal PENDING To reduce or remove the debit hold.
    authorization.reversal CLEARED
    authorization.reversal.issuerexpiration
    pindebit.authorization.reversal.issuerexpiration pgfs.authorization.reversal
    account.funding.authorization.reversal
    authorization.standin pgfs.authorization.standin PENDING To create a hold without checking the available balance.
    original.credit.authorization.reversal pgfs.original.credit.authorization.reversal
    Conventional Funds    		 CLEARED To remove the credit hold.
    refund.authorization.reversal pgfs.refund.authorization.reversal
    original.credit.authorization.reversal pgfs.original.credit.authorization.reversal
    Fast Funds    		 CLEARED To debit a payment card account, if a credit transaction has been executed.
    authorization pgfs.authorization DECLINED / CLEARED To remove the debit hold.
    authorization.atm.withdrawal
    authorization.cashback
    authorization.quasi.cash
    pindebit.authorization
    account.funding.authorization
    authorization.incremental pgfs.authorization.incremental DECLINED To reduce the debit reservation.
    original.credit.authorization pgfs.original.credit.authorization
    Conventional Funds    		 DECLINED / CLEARED To remove the credit hold.
    refund.authorization pgfs.refund.authorization
    original.credit.authorization pgfs.original.credit.authorization
    Fast Funds    		 DECLINED/CLEARED To debit a payment card account, if a credit transaction has been executed.
    pindebit.reversal pgfs.auth_plus_capture.reversal COMPLETION To credit a payment card account, if a debit transaction has been executed.
    original.credit.auth_plus_capture.reversal pgfs.original.credit.auth_plus_capture.reversal COMPLETION To debit a payment card account, if a credit transaction has been executed.
    pindebit.refund.reversal pgfs.refund.reversal
    pindebit pgfs.auth_plus_capture DECLINED To credit a payment card account, if a debit transaction has been executed.
    pindebit.atm.withdrawal
    pindebit.cashback
    original.credit.auth_plus_capture pgfs.original.credit.auth_plus_capture DECLINED To debit a payment card account, if a credit transaction has been executed.
    authorization.clearing.chargeback pgfs.authorization.capture.chargeback COMPLETION To credit a card account.
    authorization.clearing.chargeback.completed
    pindebit.chargeback pgfs.pindebit.chargeback
    pindebit.chargeback.completed
    authorization.clearing.chargeback.reversal pgfs.authorization.capture.chargeback.reversal CLEARED To debit a payment card account, if a credit transaction has been executed.
    pindebit.chargeback.reversal pgfs.pindebit.chargeback.reversal
    authorization.clearing.representment pgfs.authorization.capture.chargeback.reversal
    pgfs.force_capture    		 COMPLETION To debit a payment card account.
    authorization pgfs.authorization PENDING
    COMMANDO    		 To create a new debit hold for the requested amount without checking the available balance.
    authorization.atm.withdrawal
    authorization.cashback
    authorization.quasi.cash
    pindebit.authorization
    account.funding.authorization
    authorization.incremental pgfs.authorization.incremental PENDING
    COMMANDO    		 To increase a hold with the requested amount without checking the available balance.
    original.credit.authorization pgfs.original.credit.authorization
    Conventional Funds    		 PENDING
    COMMANDO    		 To create a new credit hold.
    refund.authorization pgfs.refund.authorization
    pindebit pgfs.auth_plus_capture PENDING
    COMMANDO    		 To debit card account with the requested amount without checking the available balance.
    pindebit.atm.withdrawal
    pindebit.cashback
    original.credit.auth_plus_capture pgfs.original.credit.auth_plus_capture PENDING
    COMMANDO    		 To credit card account with the requested amount.
    original.credit.authorization pgfs.original.credit.authorization
    Fast Funds
    --- # Maximum Deposit Account Balance URL: https://docs.mambu.com/docs/maximum-deposit-account-balance/ Defining a *maximum balance* for deposit accounts allows you to create an account balance limit, above which Mambu will not allow a client to post further deposits. You can use this to protect your organization against money laundering based on the information gathered during Know Your Customer (KYC) and Anti-Money Laundering (AML) checks. As the maximum balance can differ depending on the assessed risk level, you can define this parameter on an account level. ## Define maximum balance You can define `maxDepositBalance` on account creation as well as modify `maxDepositBalance` for existing accounts via API. Below you will find API endpoints, with a JSON excerpt: ``` POST /deposits PATCH /deposits/\ PUT /deposits/\ "internalControls": { "maxDepositBalance": 25000.00 } ``` For more information, see the [API Documentation](/api/api-v2/deposits/create/) related to deposit accounts. :::note When you change the maximum account balance, Mambu will log this action as savings account activity with an old and new value. ::: ## Transactions checked against maximum balance Maximum deposit account balance will be checked if you post the following transaction types: * Deposit * Transfer * Disbursement from a loan account * Authorization hold with positive value and advice=false * Settlement of authorization hold with positive value and advice=false Mambu does not check the maximum balance when posting: * Withdrawal adjustment * Fee adjustment * Interest adjustment (when overdraft interest is adjusted) * Transfer adjustment * Bulk deposit * Positive balance interest application * Positive authorization hold and its settlement when advice=true * Increase or decrease of the positive authorization hold :::warning When the balance is exceeded: * UI error: *The balance of the account may not go beyond the maximum deposit balance* * API response: "MAXIMUM_DEPOSIT_BALANCE_EXCEEDED" ::: :::note The Maximum Deposit balance feature does not support the *Funding Account* product type. If you need to set the maximum balance for this product type, please contact Mambu Support. ::: --- # Menu Items and Custom Views Showcase URL: https://docs.mambu.com/docs/menu-items-and-custom-views-showcase/ Menu items and associated custom views are related concepts in the Mambu UI that allow you to make customizable UI sections. Used together, they can provide easy access to the information most relevant to you. In this showcase, we will walk through a typical use case that shows how these two features work, and how they can be used together. We will cover the two main steps for creating your own new sections: creating a custom menu item and creating associated custom views. For more information on these features, see [Menu Items](/docs/menu-items) and [Custom Views](/docs/custom-views). In our example, we are going to create a menu item for **clients by type**. Under this menu item we will create separate custom views to list clients of specific types such as students and prospective clients. The finished result will look like this: ![Clients by type menu item with two custom views](@site/static/img/support/managing-the-mambu-ui--manage-my-views-3.png) This showcase assumes you already have the client types **students** and **prospects** set up in your tenant. In practice, you could use any client types you wish. For more information about client types and how to create them, see [Client Types](/docs/client-types). ## Step 1: Create a custom menu item Every custom menu item you create is added to the navigation bar. You may create as many custom menu items as you like. To create the **Clients by type** menu item: 1. Hover over the navigation bar until **Settings** is revealed, and select it to go to the **Manage My Views** page. 1. Next to the **Parent Menu** dropdown, select the plus icon to add a new menu item. 1. In the **Creating A New Menu Item** dialog, enter **Clients by type** as the **Name** and select **Clients** as the **Type**. Under the **Usage Rights** section, either select **All Users** or select the roles that should have access to this menu item. 1. Select **Save Menu Item**. ![Creating a new menu item dialog](@site/static/img/support/managing-the-mambu-ui--creating-a-new-menu-item-3.png) Once you create the new menu item, you will return to the **Manage My Views** page with your new view selected in the **Parent Menu** dropdown. A new menu item does not yet have any custom views created for it, so you will see no associated views for it yet. You can also view the menu item in the navigation bar. ![Clients by type menu item with no custom views](@site/static/img/support/managing-the-mambu-ui--manage-my-views.png) Now that we have created our menu item, we are ready to move on to the second step of the process to create custom views. ## Step 2: Creating custom views Custom views may be associated with menu items. We are going to create two custom views for our clients by type menu item: one listing all students and one listing all prospective clients. This showcase assumes you already have the client types **students** and **prospects** set up in your tenant. To create the custom view listing students: 1. Use the **Parent Menu** dropdown to select the **Clients by type** menu item. If you are continuing from the previous step, it will already be selected. 1. Select **Create New View**. 1. In the **Create a New View** dialog, enter **Students** as the **Name**. ![Create a New View intro section](@site/static/img/support/managing-the-mambu-ui--creating-a-new-view.png) 1. For the filter enter "Where **Client Type** **equals** **Students**". ![Create a New View filter section](@site/static/img/support/managing-the-mambu-ui--filter-configuration-panel.png) 1. For the fields, use the **Available Columns** dropdown to select **Full Name**, **ID**, **Client Type**, and **Created**. You may choose to select additional fields if you like. Using the **Sort By** dropdown select **Created**. This will sort the results by the **Created** field. ![Create a New View fields section](@site/static/img/support/managing-the-mambu-ui--fields-configuration-panel.png) 1. For the usage rights, either select **All Users** or select the roles that may have access to this custom view. ![Create a New View usage rights section](@site/static/img/support/managing-the-mambu-ui--usage-rights-configuration.png) 1. Select **Save View**. Once you create the custom view, you will be redirected to view it. The **Students** custom view is now available from the **Clients by type** menu item in the navigation bar. ![Students custom view available from clients by type menu item](@site/static/img/support/managing-the-mambu-ui--students-custom-client-view.png) ### Creating additional custom views To create another custom view for prospective clients, simply follow the same steps you took to create the students custom view for any client type that you have already set up for prospective clients. Below is an example of what the **Clients by type** menu item would look like if we made an additional custom view for **Prospective clients**. ![Clients by type menu item with two custom views](@site/static/img/support/managing-the-mambu-ui--manage-my-views-3.png) --- # Menu Items URL: https://docs.mambu.com/docs/menu-items/ The navigation bar displays menu items. Menu items are closely related to *views*, which are customizable pages in the Mambu UI that can be used to create your own UI displays or to generate reports. *Views* are also referred to as *custom views*. For more information, see [Custom Views](/docs/custom-views). There are two categories of menu items: *menu items with views* and *menu items without views*. If a user selects a menu item with a view in the navigation bar, they will navigate to the associated custom view. Selecting menu items without views navigates to a preset page that cannot be edited. For more information on how menu items and views are commonly used and for an illustration of how they relate to one another, see [Menu Items and Custom Views Showcase](/docs/menu-items-and-custom-views-showcase). ## Menu items without views The menu items without views are Dashboard, Products, Reporting, Accounting, and Administration. These menu items are predefined and cannot be modified or removed from the navigation bar. The Mambu UI display that comes up when you click these menu items depends on your user permissions. For more information, see [Permissions](/docs/permissions). | Name | Description | Required Permissions | | --- | --- | --- | | Dashboard | The homepage view with your existing widgets. | None | | Products | All deposit and loan products that you have created in Mambu. | None | | Reporting | Lists the out-of-the-box reports that come with Mambu. | **View Historical Data** (`VIEW_INTELLIGENCE`) \n **View Reports** (`VIEW_REPORTS`) | | Accounting | Includes some financial reports, journal entries, and navigation to certain configurations pertaining to accounting in Mambu. | None | | Administration | Where you carry out most of the setup of your Mambu tenant. | None | ## Menu items with views There are two kinds of menu items with views: predefined menu items with views and new menu items with views that you create yourself. Predefined menu items with views may have existing custom views set up. They are available when your tenant is set up. The following predefined menu items with views are available: * Clients * Groups * Loans * Deposits * Loan Transactions * Deposit Transactions * Activities ## User access to menu items with views There are three factors that determine whether you will be able to view or manage a menu item: * The menu item type and your account permission settings. See [Menu item types and permissions](#menu-item-types-and-permissions). * Your user type. See [User types and menu items](#user-types-and-menu-items). * The usage rights settings of the menu item. See [Usage Rights](#usage-rights). ### Menu item types and permissions There are 13 types of menu items with views. The type determines what views can be listed under each menu item and some of the permissions and role assignments that are necessary to view the menu item and the views. For more information on other potential requirements to view or manage a menu item, see [User access to menu items with views](#user-access-to-menu-items-with-views). | Menu Item Type | Description | Required Permissions | | --- | --- | --- | |Clients| Information pertaining to clients that are individuals. For more information, see [Clients and Groups Overview](/docs/clients-and-groups-overview).| View Client Details (`VIEW_CLIENT_DETAILS`) | |Groups| Information pertaining to clients that are groups, in other words, non-individuals. For more information, see [Clients and Groups Overview](/docs/clients-and-groups-overview).| View Group Details (`VIEW_GROUP_DETAILS`) | |Credit Arrangements| Information regarding credit arrangements. For more information, see [Creating a new credit arrangement](/docs/creating-a-new-credit-arrangement). | View Credit Arrangement Details (`VIEW_LINE_OF_CREDIT_DETAILS`) | |Loan Accounts| Loan accounts details, together with the clients or group account holder details. For more information, see [Creating a New Loan](/docs/creating-a-new-loan).| View Loan Account Details (`VIEW_LOAN_ACCOUNT_DETAILS`) | |Loan Transactions|Loan transaction details together with the parent account and account holder details.| View Loan Account Details (`VIEW_LOAN_ACCOUNT_DETAILS`) | |Installments|Loan account installments, together with the parent account and account holder details.| View Loan Account Details (`VIEW_LOAN_ACCOUNT_DETAILS`) | |Deposit Accounts|Deposit accounts details, together with the clients or group account holder details. For more information, see [Creating a Deposit Account](/docs/creating-a-deposit-account).| View Deposit Account Details (`VIEW_SAVINGS_ACCOUNT_DETAILS`) | |Deposit Transactions|Deposit transaction details, together with the parent account and account holder details.| View Deposit Account Details (`VIEW_SAVINGS_ACCOUNT_DETAILS`) | |System Activities|Details related to the system activities log. For more information on activities, see [Tracking Activities](/docs/tracking-activities).| Audit Transactions (`AUDIT_TRANSACTIONS`) | |Branches| Details related to the branches of your organization. For more information, see [Branches and Centres](/docs/branches-and-centres).| View Branch Details (`VIEW_BRANCH_DETAILS`)| |Centres|Details related to the centres of your organization.| View Centre Details (`VIEW_CENTRE_DETAILS`) | |Users| Details related to the users in your organization. For more information, see [Creating New Users](/docs/creating-new-users).| View User Details (`VIEW_USER_DETAILS`) | |Communications|Details related to messages sent (SMS, emails and webhooks). For more information, see [Communicating with Clients](/docs/notifications-overview).| View Communication History (`VIEW_COMMUNICATION_HISTORY`) | ### User types and menu items Regular users and administrator users (admins) have different view, creation, and editing rights regarding menu items. Admins are users with the **Administrator** type, while regular users are non-admins. For more information, see [Creating a User - User Rights](/docs/creating-new-users#access-rights). #### Regular users As a regular user, you may only view menu items that you have created, that have been set by an admin to be viewable by all users, or that have been set by an admin to be viewable by regular users with a role that you have been assigned. Menu items that you create are viewable by you and any admin. You can only edit or delete the menu items you have created. Regular users do not have access to the usage rights settings of a menu item. To manage menu items, you may visit the **Manage My Views** page in two ways: * Select your profile name in the top right-hand corner of the top bar and then select **My Views**, or * Hover over the navigation bar until the **Settings** icon is revealed and select it. Visiting **Manage My Views** through profile name: ![Visiting Manage My Views through profile name](@site/static/img/support/data-and-reporting--manage-my-views.png) Visiting **Manage My Views** with the **Settings** icon in navigation bar: ![Visiting Manage My Views through cog in navigation bar](@site/static/img/support/data-and-reporting--top-navigation-bar.png) #### Administrator users (admins) All admin users have access to the usage rights settings of a menu item. Here, you may set menu items to be either viewable for all users, or only viewable by users who created the menu item as well as the viewers who have been assigned the relevant roles. For more information, see [Usage Rights](#usage-rights). In addition to the two ways to access the **Manage My Views** page to manage menu items that are available to regular users, admins can also manage menu items through the **Views** tab under the **Administration** menu item. On the **Manage My Views**, page admins can **only** see the list of menu items created by themselves or that are accessible to all users. On the page accessible through **Administration** > **Views**, admins can view, edit, or delete the menu items created by themselves **as well as** other users. Visiting menu item through administration: ![Visiting menu item through administration](@site/static/img/support/data-and-reporting--views-list.png) ## Creating menu items To create a menu item: 1. Hover over the navigation bar until the **Settings** icon is revealed and select it. 2. Next to the **Parent Menu** dropdown, select the **Add** icon to add a new menu item. 3. In the **Creating A New Menu Item** dialog, enter all the necessary information. For more information on the fields, see [Fields for menu items](#fields-for-menu-items) below. 4. Select **Save Menu Item**. ![Creating A New Menu Item Dialog](@site/static/img/support/managing-the-mambu-ui--creating-a-new-menu-item.png) :::note If there are more menu items than can fit in the navigation bar, a **>>** icon will be shown where the remaining menus are nested. ![Nested Menu Items](@site/static/img/support/managing-the-mambu-ui--main-navigation-menu.png) ::: ## Fields for menu items |Field | Description | | --- | --- | | Name | The name can be a maximum of 32 characters. If you use a non-English display language, you can enter the name of the view in your language. | | Type | The menu item type will determine which custom views you create as part of a menu item and some of the permissions you need in order to view the menu item. See [Menu item types and permissions](#menu-item-types-and-permissions) above for more details. | | Include Collections Item (only for loan and deposit transaction) | Loan and deposit transaction items allow including the repayments/deposits collections item. You can add or remove the collections item for any transactions item by toggling the **Include Collections Item** checkbox when editing the menu item. | ### Usage Rights Only admins may access the **Usage Rights** settings of a menu item. For more information, see [User types and menu items](#user-types-and-menu-items). If you select the **All Users** checkbox, then all roles will be selected and any user with the appropriate permissions assigned to them either directly or through a role will be able to view the menu item. For more information on the different permissions necessary for the different custom view types, see [Menu item types and permissions](/docs/menu-items#menu-item-types-and-permissions). If you do not select the **All User** checkbox, then users will need to be assigned a role with appropriate permissions to view the menu item. Users will not have access to the menu item if they have the permissions directly assigned to them. ## Editing menu items To edit a menu item: 1. Hover over the navigation bar until the **Settings** icon is revealed and select it. 2. Using the **Parent Menu** dropdown, select the menu item you would like to edit. 3. Next to the **Parent Menu** dropdown, select the **Edit** icon . 4. Edit the name as desired and select **Confirm**. ![Manage my views screen, highlighting the edit button for the parent menu and the Actions - Edit button for editing the views](@site/static/img/support/edit-views-in-different-languages.png) ## Rearranging menu items You can rearrange the order of menu items in the navigation bar. To rearrange menu items: 1. Hover over the navigation bar until the **Settings** icon is revealed and select it. 2. Next to the **Parent Menu** dropdown, select the **Custom View** icon . 3. Rearrange the menu items into your preferred order. 4. Select **Save Changes**. ## Deleting and disabling menu items To delete or disable a menu item: 1. Hover over the navigation bar until the **Settings** icon is revealed and select it. 2. Using the **Parent Menu** dropdown, select the menu item you would like to delete or disable. 3. Next to the **Parent Menu** dropdown, select the **Edit** icon . 4. Select either **Delete** or **Disable**. * Deleting the menu item will delete all the custom views that belong to it. * Disabling the menu item will remove the menu item from the navigation bar, until it’s enabled again. 5. Select **Confirm**. --- # MySQL 8.0 Update URL: https://docs.mambu.com/docs/mysql-8-update/ :::warning You may [update Jasper reports](#updating-jasper-reports) while your tenant is still on MySQL 5.7. However, you must only implement the [MySQL updates](#mysql-updates) if the Mambu team has informed you that your tenant has been upgraded to MySQL 8.0. ::: ## MySQL Updates Mambu has migrated from using MySQL 5.7 to MySQL 8.0. In order to avoid experiencing issues with your existing Jasper Reports, you must update your MySQL version. For more information about upgrading your MySQL version, see [MySQL 8.0 - Upgrading MySQL](https://dev.mysql.com/doc/refman/8.0/en/upgrading.html) on the MySQL website. We advise that you check that you're using an updated version of the connector. To download the latest version of the connector, go to [MySQL Community Downloads](https://dev.mysql.com/downloads/connector/j/) on the MySQL website. Moreover, you may need to redo the steps to create a connection between Jaspersoft Studio and your MySQL server. For more information, see [Data Adapter](/docs/data-adapter). ## Updating Jasper reports To prepare for the MySQL version update from 5.7 to 8.0, you must update your Jasper reports. You may do this while you're still using MySQL 5.7. For more information on how to test your updates, see [Testing Jasper report updates](#testing-jasper-report-updates). Below is a list of changes to consider: * `GROUPS` and `ROWS` are now keywords and cannot be used as aliases anymore. For a complete list of keywords, see [Keywords and Reserved Words](https://dev.mysql.com/doc/mysqld-version-reference/en/keywords.html) on the MySQL website. We recommend you apply this change as soon as possible and [test your Jasper report updates](#testing-jasper-report-updates). * The `Group by [ASC|DESC]` statement is no longer supported, queries should be refactored to use the `GROUP BY ORDER BY [ASC|DESC]` statement instead. For more information, see [SQL Incompatible Changes](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#:~:text=Incompatible%20change:%20As%20of%20MySQL%208.0.13,MySQL%208.0.13%20or%20higher%20replica%20servers.) on the MySQL website. * In MySQL 5.7 when using the `CAST(“string” as DATETIME)` function, the timezone offset was ignored while in MySQL 8.0 the timezone offset is taken into account. For more information, see [Support for Date-Time Types in Connector/J 8.0](https://dev.mysql.com/blog-archive/support-for-date-time-types-in-connector-j-8-0/) on the MySQL website. * If your `ORDER BY` clause sorts the results based on a column or combination of columns that don't guarantee uniqueness, rows with the same values in the specified columns may appear in a different relative order between MySQL 5.7 and MySQL 8.0. ### Testing Jasper report updates If you're updating your Jasper reports in preparation for the MySQL 8.0 update and you want to test that all the queries work properly then you may clone your database and migrate the cloned database to MySQL 8.0. This will then allow you to test all your queries on the cloned data. --- # Native Fields URL: https://docs.mambu.com/docs/native-fields/ Fields are values associated with a Mambu entity such as a client, group, or loan account. For example, the client entity includes several fields by default for storing information about each client, such as ID, email address, and creation date. *Native fields* are fields Mambu provides by default. As a general rule, you are not able to edit native fields. If you want to create specific fields for your organization then you must use custom field definitions. For more information, see [Custom Fields](/docs/custom-fields). The exception to this rule is a set of native fields that are associated with the client entity. For more information, see [Client native fields](/docs/managing-clients#client-native-fields). ## Native fields in the Mambu UI Native fields are visible throughout the Mambu UI. If the field is outlined in green, then it is a required field. ## Native fields when using Mambu API v1 and v2 Native fields are also present in the JSON objects that you use to work with Mambu API v1 and API v2. Native fields always come before custom field values in a JSON object. Custom field values are always nested inside custom field sets. To distinguish a native field from a custom field value, you must look at the property name in the JSON object. If the property name starts with an underscore `_`, it is a custom field set and the values nested within it are custom field values - otherwise a property in the JSON object is a native field. For more information, see our [API Reference](/api/pages/api-v2/responses). ## Managing native fields To change the display language of all the native fields in the Mambu UI, you may edit your language settings. For more information, see [Language Settings](/docs/language-settings). :::note Custom field definitions and a specific set of client native fields are not translated when the Mambu display language changes. You must edit them by going to **Administration** > **Fields**. For more information, see [Client native fields](/docs/managing-clients#client-native-fields) and [Custom Fields](/docs/custom-fields). ::: --- # Navigating in the Mambu UI URL: https://docs.mambu.com/docs/navigating-in-mambu/ When you first log in to the Mambu UI, you will land on a customizable dashboard composed of different widgets. For more information, see [Dashboard](/docs/dashboard). To navigate through the Mambu UI, you can use: * [the top bar](/docs/navigating-in-mambu#top-bar) * [navigation bar](/docs/navigating-in-mambu#navigation-bar) * [links](/docs/navigating-in-mambu#links) :::warning The information you are able to view while you navigate through Mambu depends on your access settings. For more information, see [Understanding Users, Roles, and Permissions](/docs/understanding-users-roles-and-permissions). ::: The list of supported browsers for the Mambu UI is defined here: [Supported browsers](/docs/mambu-ui-management-overview/#supported-browsers). ## Top bar ![Top bar of Mambu](@site/static/img/support/getting-started--top-navigation-bar.png) ### Organization name The name of your organization is the first item you see on the top left-hand corner of the top bar. To define it, go to **Administration** > **General Setup** > **Organization Details** > **Institution Name**. ![Organization name that will be customized for each tenant](@site/static/img/support/getting-started--mambu-logo-header.png) ### Branch filter If you have permission to access more than one branch, you will have access to the branch filter. Select a branch to display any branch-specific information. For more information on branches, see [Branches and Centres](/docs/branches-and-centres). ![Branch dropdown, where all defined branches of the organization can be found](@site/static/img/support/getting-started--branch-filter-dropdown.png) ### View menu The **View** menu allows you to create a temporary custom view using a quick lookup. Custom views are a tool to generate reports on the fly and to easily retrieve filtered lists of information. For more information, see [Custom Views](/docs/custom-views). ![The View menu and the list of entities](@site/static/img/support/getting-started--view-menu-dropdown.png) ### Create menu ![Create button and list of entities](@site/static/img/support/getting-started--create-menu.png) The **Create** menu gives you access to creation forms. The default options are **Client**, **Group**, **Loan Account**, **Deposit Account**, and **User**. Note that you must have the appropriate relevant permissions to view these options. When you create additional client and group types, those will also be included as options in the list. For more information, see [Client Types](/docs/client-types) and [Group Types](/docs/group-types). ### Search box The search box allows you to search for clients, groups, users, branches, and centres either by their name or ID. You may also search for clients by entering the first characters of the ID of one of their identification documents. You can also use the search box to find shortcuts to create new clients, loans, and savings accounts. To run a search, start typing the name or number associated with the entity or shortcut you're looking for, and you will see an auto-complete list of matching results. To use the search box either select it or use the shortcut Alt-Space. For more information on shortcuts available in the search box, see [Search box shortcuts](/docs/mambu-search#keyboard-navigation). ### Tasks You will see a small gray or green box to the right of the search box - this is the tasks icon. If you have no open tasks assigned, the square will be grey and contain the number 0. Otherwise, the square is green and shows the number of open tasks you have assigned. You can view the tasks due, add new tasks, and assign them to other users. It also allows you to view a list of all your tasks. For more information, see [Communicating with other users](/docs/notifications-overview). ![Task area, where the tasks of the user that is logged in can be found](@site/static/img/support/getting-started--tasks-due.png) ### User settings Select your name to view a dropdown list of options. ![User Settings navigation with View your profile, Edit your profile, My Views and Logout options](@site/static/img/support/getting-started--user-profile-dropdown-menu.png) #### View Your Profile Select **View Your Profile** to navigate to your profile page. This option is is only accessible if you have any of the following permissions: * **View User Details** (`VIEW_USER_DETAILS`) * **Create Users** (`CREATE_USER`) * **Edit Users** (`EDIT_USER`) * **Delete Users** (`DELETE_USER`) #### Edit Your Profile Select **Edit Your Profile** to open the **Edit User** dialog. This option is only accessible if you have any of the following permissions: * **View User Details** (`VIEW_USER_DETAILS`) * **Create Users** (`CREATE_USER`) * **Edit Users** (`EDIT_USER`) #### My Views Select **My Views** to navigate to the **Manage My Views** page, where you can manage and create menu items and custom views. For more information, see [Menu Items](/docs/menu-items) and [Custom Views](/docs/custom-views). #### Logout Select this option to log out of Mambu. ### Help ![Help navigation](@site/static/img/support/getting-started--help-menu.png) **Help** is a quick access point for support resources. **Hide Help** removes contextual tooltips that are available throughout the Mambu application. **Customer Service Portal** is a self-service portal, for more information, see [Customer Service Portal](/docs/customer-service-portal) **Go To Help Docs** goes to our `support.mambu.com` site through which you may access our support documentation. **Web Form for support cases** is an online contact form. For more information, see [Web form for support cases](/docs/mambu-support#web-form-for-support-cases). ## Navigation bar The navigation bar displays menu items. There are two categories of menu items, *menu items with views* and *menu items without views*. The menu items without views are **Dashboard**, **Products**, **Reporting**, **Accounting**, and **Administration**, these are predefined and all users have access to them. Menu items with views have custom views attached to them. There are predefined menu items with views and you can also create additional menu items with views. For more information on creating and customizing menu items, see [Menu Items](/docs/menu-items) and for more information about creating and managing custom views, see [Custom Views](/docs/custom-views). The menu items with views that you are able to view will depend on your permissions. For more information on the necessary permissions for each menu item and custom view type, see [Menu item types and permissions](/docs/menu-items#menu-item-types-and-permissions). ![Navigation bar with menu items](@site/static/img/support/getting-started--navigation-bar-with-client-status-dropdown.png) ## Links The Mambu UI includes many links you can use to directly access user profiles, client profiles, loan accounts, and savings accounts, or to perform some operations such as entering repayments or editing client profiles. You can easily identify links in Mambu by their blue color. ![Mambu links can ease the way of navigating through the app](@site/static/img/support/getting-started--loan-accounts-list.png) --- # Non-Scheduled Fee Allocation URL: https://docs.mambu.com/docs/non-scheduled-fee-allocation/ Non-scheduled fee allocation offers enhanced flexibility for managing manual fees on loan accounts. This functionality allows you to apply fees to an account and track them in a distinct Fee balance without automatically adding them to the next scheduled installment payment. ## Set up non-scheduled fee allocation To enable non-scheduled fee allocation, you must configure a new fee type during product setup. 1. Navigate to **Product Setup** to access the relevant loan product in your Mambu environment. 2. Within the product configuration, add a new fee. The type should be Manual. 3. When defining how the fee is collected, select **No Allocation**. This ensures the fee is placed directly into a separate fee balance and does not impact the regular repayment schedule. ![no allocation](/img/support/no-allocation.png) 4. Note that you cannot choose to capitalize non-scheduled fees at application. ![capitalize non scheduled fees](/img/support/capitalize-non-scheduled-fees.png) Once a manual fee is applied with No Allocation, it will be handled as follows: * Each application of a non-scheduled fee is logged in the account's transaction history. The corresponding transaction details will include specific information related to the non-allocated fee. * The non-scheduled fees will contribute to separate *Non-Scheduled Fee Balance* and *Non-Scheduled Fee Paid* balances visible directly on the loan account details page. These balances are distinct from any amounts tied to the repayment schedule * Non-scheduled fees operate independently of your regular repayment schedule. This means they won't ever show as "due" and won't be part of your Fees Due balance. However, keep in mind that these amounts will still contribute to the total balance of your account. | Balances after fee application | Balances after fee repayment | | --- | --- | | ![balances after fee application](/img/support/balances-after-fee-application.png) | ![balances after fee repayment](/img/support/balances-after-fee-repayment.png) | **Total balance of the account** ![balance of the account](/img/support/balance-of-the-account.png) * Repayment for the non-scheduled fee is exclusively handled through the Custom Repayments feature. This allows for flexible collection outside of the regular installment cycle. * To collect a non-allocated fee, select **Custom repayments** and choose **Non Scheduled Fees** for the Repayment Item. ![repayment item non scheduled fees](/img/support/repayment-item-non-scheduled-fees.png) ## Fees maintained outside the schedule Flexible fee application, or *fees maintained outside the schedule*, allows you to apply fees to loan accounts without a mandatory allocation to the repayment schedule. This provides greater flexibility for both lenders and borrowers. ### Features * Fees can now be designated as 'non-scheduled' during application. * Non-scheduled fees do not accrue interest. * The repayment of these fees is not automatically enforced through a specific scheduled installment. ### How it works * When applying a fee (via UI or API), choose the new option to make it 'non-scheduled'. * The fee will increase the total outstanding balance. * Importantly, it will not automatically change the borrower's regular scheduled installment amount. * As a result, the fee adds to the total outstanding balance but does not accrue interest. It also won't automatically change the borrower's scheduled installment payment, allowing the lender to define a separate collection process. #### Schedule allocation During the fee application process, users have an option called the Schedule Allocation Method, where they can specify whether the fee should be allocated to the schedule or applied without schedule allocation (No allocation). Non-scheduled fees will increase the outstanding balance but won't modify the installment amounts on the existing repayment schedule. Lenders can define processes for how these fees are collected. --- # Automated email notifications URL: https://docs.mambu.com/docs/notifications-channels-email-automated-email-notifications/ Automated email notifications allow you to send emails when certain events occur and only when configured conditions are met. Before sending emails to clients, groups, or credit officers, create an email notification template, ensure recipients are subscribed, and configure your email settings. See [Email setup](/docs/email-setup). Permissions required: - Create templates: Create Templates (`CREATE_COMMUNICATION_TEMPLATES`) and View Administration Details. - Edit/activate/deactivate templates: Edit Templates (`EDIT_COMMUNICATION_TEMPLATES`) and View Administration Details. - View templates: any of Edit Templates, Create Templates, or View Administration Details. ## Create an automated email template 1. Go to Administration > Email > Templates. 2. Select Add Notification. 3. Enter all the necessary information (see fields below). 4. Select Save Changes. Once created, templates are listed with a state and a status: - State: In Use (at least one notification sent) or Not In Use - Status: Active (can be used) or Inactive (deactivated) ## Fields for automated email templates ### Name A unique name, up to 255 characters. Leading and trailing spaces are trimmed automatically. ### Subscription option settings Choose whether recipients are Opt-out (auto-subscribed) or Opt-in (manually subscribed). - Opt-out: On first save, recipients are automatically subscribed in the background. They can later unsubscribe. - Opt-in: Recipients are not subscribed by default and must be added manually. ### Target Which entity is monitored: Clients or Groups. The target determines recipient options, placeholders, and available event triggers. Note: Automated email templates do not include account activity events (for example, account transactions). Those events are not available for the email channel. ### Recipient Recipient options depend on the chosen target and event. Examples: - Client target: send it to the client or to the assigned credit officer. - Group target: send it to the credit officer or to group members with a specific group role. ### Event trigger Select the event that triggers the notification. Options depend on the target and the email channel. See [Event triggers](/docs/event-triggers). ### Conditions Define additional conditions (field, operator, value). Choose Match All or Match Any to control how multiple conditions are evaluated. ### Contents Define the email subject and body. You can use placeholders. See [Placeholders](/docs/placeholders) and [Content editors](/docs/content-editors). - Subject: up to 255 characters. We recommend keeping subjects concise (around 50 characters) for better previews; this is guidance, not an enforced limit. - Body: supports rich text and HTML when creating templates. ## Subscribe or unsubscribe a recipient 1. Open the recipient profile (for example, a client or group). 2. Select **More > Set Notifications**. 3. In **Notification Requests**, select or deselect the relevant notifications. :::note - The dialog lists notifications relevant to the recipient type. - Notifications are listed by event trigger name and channel (SMS, email, or webhook). ::: ## Dispatch behavior Email notifications are dispatched when their events occur and conditions match while the template is Active. There is no Mambu-enforced working-hours window for email delivery. If timing matters to your recipients, consider including timestamps in your template content. ## Manage templates You can activate, deactivate, and edit templates under Administration > Email > Templates. Editing and activation changes require the Edit Templates permission (plus View Administration Details). ## Prerequisites and troubleshooting - Ensure the Email channel is enabled and configured for your organization. If the configuration is missing or invalid, sends will fail. - If expected emails are not sent, check: template Status (Active), subscriptions for recipients, event conditions, and email configuration. --- # Email setup URL: https://docs.mambu.com/docs/notifications-channels-email-email-setup/ This page explains how to configure email so Mambu can send **manual and automated notifications**, as well as **system emails** (such as password resets and user invitations). - With a **custom SMTP server**, emails are sent from your own domain using the credentials you provide. - If no custom SMTP is configured, system emails continue to be sent from a **Mambu-managed sender**. The Email channel for notifications may be disabled in the UI when no custom SMTP is selected. :::warning Once you configure a custom email server, it will also be used for system messages such as password reset emails and user invitations. After changing settings, always verify that these flows still work as expected. ::: ## Prerequisites and permissions - **Navigation:** `Administration > Email > Settings` - **To view settings:** Users with administration visibility or template permissions can view the configuration (for example, *View Administration Details*, *Create Templates*, or *Edit Templates*). - **To change and save settings:** Admin permission is required. - After any change, verify end-to-end by sending a **test email** and checking a **password reset** or **invitation** flow. ## Configure your email server in Mambu To set up an email server in Mambu: 1. On the main menu, go to **Administration > Email > Settings**. The **Settings** tab is only visible to users with the required permissions. 2. Choose the email provider option: - **Custom SMTP** – use your own SMTP server and credentials. - **Mambu-managed sender** – leave Custom SMTP disabled. 3. If you select **Custom SMTP**, fill in the fields described below and select **Save Changes**. 4. Optionally, use **Send Test Email** to validate connectivity before saving. The test uses the values currently in the form and does **not** persist them. We strongly recommend always testing after setup and making any changes by sending yourself a test email and validating key flows such as password reset. ## Form fields to set up an email server | Field | Description | |---------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **From Name** | The display name reported as the sender's name in the email. Often your organization name, such as `Mid City Bank`. | | **From Email** | The email address reported as the sender's email in the email, such as `info@midcity.bank`. Used as the `From:` address when sending via your SMTP. | | **Reply-to email** | The reply address email. Often the same as the **From Email**. Replies from recipients are sent here. | | **SMTP Host** | The DNS address of the email server. For example: `smtp.example.com`. | | **SMTP Port** | The port used to communicate with the host. Common values are `465` or `587`, depending on the provider and encryption method. | | **Transport Encryption Method** | The encryption method used to secure the SMTP connection. Supported: **SSL/TLS** (implicit TLS, usually port 465) and **STARTTLS** (explicit TLS, usually port 587). | | **Username** | The username part of the credentials to use the SMTP host. Often the full email address. | | **Password** | The password part of the credentials to use the SMTP host. Stored encrypted in Mambu. | Notes: - When **Custom SMTP** is selected, Mambu attempts to send via your SMTP first and may fall back to a Mambu-managed no-reply sender if the primary attempt fails. - If **Custom SMTP** is not selected, system emails continue to be sent from a Mambu-managed sender. The Email channel for notifications may be disabled if no valid configuration is present. :::tip After configuring SMTP, send yourself a test email and also trigger a password reset or user invitation to validate both notification and system emails. ::: ## Send Test Email Use **Send Test Email** to try sending a message with the current form values **without saving** the configuration. ### What the test checks - Resolves the SMTP host and attempts to connect using the selected encryption method. - Tries to authenticate with the provided username and password. - Attempts to submit a test email for delivery. ### What the test does *not* guarantee - Final delivery to the recipient’s inbox. Spam filtering, DMARC/DKIM alignment, and downstream provider issues are outside the scope of this test. ### Common causes of test failures - Invalid hostname, wrong port, or encryption mismatch (**SSL/TLS** vs **STARTTLS**). - Wrong credentials or missing app-specific passwords. - Firewall or allowlisting rules blocking Mambu egress IPs from reaching your SMTP on the selected port. ## Examples for common email service providers If you already use a trusted email service provider such as Google Workspace/Gmail or Amazon SES, you can connect it via SMTP. For more advanced email workflows (marketing journeys, complex templates, etc.), consider using [Webhooks](/docs/webhook-notifications) to trigger sending email templates through your existing service. ### Google Workspace / Gmail SMTP The Google Workspace platform or Gmail can be used as an email service provider. Example configuration: | Field | Description | |---------------------------------|------------------------------------------------------------------------------------------------------------| | **From Name** | Any string. Google may override this value with the default value from the account. | | **From Email** | Gmail or Google Workspace address. Google may override this value with the default value from the account. | | **Reply-to email** | Gmail or Google Workspace address. Often the same as **From Email**. | | **SMTP Host** | `smtp.gmail.com` | | **SMTP Port** | `465` (SSL/TLS) or `587` (STARTTLS) | | **Transport Encryption Method** | `SSL/TLS` or `STARTTLS`, depending on the chosen port. | | **Username** | Full Gmail or Google Workspace user, such as `mambu@gmail.com` or `hello@mambu.com`. | | **Password** | Application-specific password or SMTP relay credentials, depending on your Google security settings. | > Check Google’s documentation for the latest requirements on app passwords, 2-step verification, and SMTP relay. ### Amazon Simple Email Service (SES) Amazon SES can be used as an email service provider. You must have an AWS account and SES configured for your domain. | Field | Description | |---------------------------------|---------------------------------------------------------------------------------------------------------------------| | **From Name** | Any string, usually the name of your organization. | | **From Email** | Full email address to display in the `From:` field. Must be verified in SES depending on your configuration. | | **Reply-to email** | Full email address used when replying to the email. This can be the same as **From Email**. | | **SMTP Host** | Regional SES SMTP endpoint, for example `email-smtp.eu-west-1.amazonaws.com`. Use the endpoint for your SES region. | | **SMTP Port** | Typically `465` (SSL/TLS) or `587` (STARTTLS). | | **Transport Encryption Method** | `SSL/TLS` or `STARTTLS`, matching the chosen port. | | **Username** | The username from your SES SMTP credentials. | | **Password** | The password from your SES SMTP credentials. | Ensure your DNS and domain authentication (SPF, DKIM, DMARC) are correctly configured with your provider to improve deliverability and reduce the risk of messages being flagged as spam. ## IP address ranges Emails being sent through your SMTP server from Mambu will originate from a fixed set of IP addresses per Mambu region. If your SMTP server or firewall requires allowlisting, you may need to allow these IP addresses. - Any updates to infrastructure will be announced on our Status Page. - If you need to know the current sender IP addresses for your dedicated environment or region, please contact **Mambu Support**. ## Troubleshooting - **The Send Email options don’t appear in the UI:** - Ensure the Email channel is enabled in **Administration > Email > Settings**. - Verify your user role has the necessary permissions to send notifications. - **Test email fails to send:** - Double-check SMTP host, port, and encryption method. - Verify username/password or app password requirements with your provider. - Confirm your firewall allows Mambu IPs to reach your SMTP on the selected port. - **System emails not received after changes:** - Trigger a password reset or user invitation to test. - Check spam/junk folders and domain authentication settings (SPF/DKIM/DMARC). - If issues persist, review your SMTP logs and contact your email provider or Mambu Support. If none of the above helps, see this [page](/docs/troubleshooting-email-sms-setup) --- # Automated SMS notifications URL: https://docs.mambu.com/docs/notifications-channels-sms-automated-sms-notifications/ Automated SMS notifications allow you to send SMS messages when certain events occur and only when configured conditions are met. To send SMS to individual clients, groups, or credit officers, first create the SMS template and make sure recipients are subscribed. An SMS gateway must be configured. See [SMS setup](/docs/sms-setup). Permissions required: - Create templates: Create Templates (`CREATE_COMMUNICATION_TEMPLATES`) and View Administration Details. - Edit/activate/deactivate templates: Edit Templates (`EDIT_COMMUNICATION_TEMPLATES`) and View Administration Details. - View templates: any of Edit Templates, Create Templates, or View Administration Details. ## Create an automated SMS template 1. Go to **Administration > SMS > Templates**. 2. Select **Add Notification**. 3. Enter all the necessary information (see fields below). 4. Select **Save Changes**. Templates list a state and a status: - **State**: *In Use* (at least one notification sent) or *Not In Use*. - **Status**: *Active* (can be used) or *Inactive* (deactivated). ## Fields for automated SMS templates ### Name A unique name, up to 255 characters. Leading and trailing spaces are trimmed automatically. ### Subscription option settings Choose **Opt-out** (auto-subscribed) or **Opt-in** (manually subscribed). - **Opt-out**: On first save, recipients are automatically subscribed in the background. They can later unsubscribe. - **Opt-in**: Recipients are not subscribed by default and must be added manually. ### Target **Clients** or **Groups**. The target determines recipient options, placeholders, and the set of available event triggers for the SMS channel. ### Recipient Options depend on the chosen target. Examples: - For **Clients**: send to the client or to the assigned credit officer. - For **Groups**: send to the credit officer or to group members with a specific group role. ### Event trigger Select the event that triggers the notification. Available events depend on the selected target and the SMS channel. See [Event triggers](/docs/event-triggers). ### Conditions Add conditions (field, operator, value). Choose **Match All** or **Match Any** to control how multiple conditions are evaluated. ### Contents Enter the SMS text. You can use placeholders. See [Placeholders](/docs/placeholders). Notes about length and billing: - SMS providers segment long messages automatically; longer content may be delivered as multiple segments and billed accordingly. - Mambu enforces a technical maximum message length. Very long messages will be rejected before sending. Keep messages concise for better deliverability and cost control. ## Subscribe or unsubscribe a recipient 1. Open the recipient profile (for example, a client or group). 2. Select **More > Set Notifications**. 3. In **Notification Requests**, select or deselect the relevant notifications. **Notes** - The dialog lists notifications relevant to the recipient type. - Notifications are listed by event trigger name and channel (SMS, email, webhook). ## Dispatch behavior SMS notifications are dispatched when their events occur and conditions match while the template is **Active**. There is no Mambu-enforced working-hours window for SMS delivery. Actual delivery timing also depends on your SMS provider. ## Manage templates You can activate, deactivate, and edit templates under **Administration > SMS > Templates**. Editing and activation changes require the Edit Templates permission (plus View Administration Details). --- # SMS setup URL: https://docs.mambu.com/docs/notifications-channels-sms-sms-setup/ You can set up an SMS gateway so Mambu can send manual and automated SMS notifications to clients, groups, or credit officers. Supported providers: - Twilio - Infobip - None (disabled) If you need to integrate a different SMS gateway, please contact Mambu Support. Permissions: - **View settings**: Users with administration visibility or template permissions (for example, View Administration Details, Create Templates, or Edit Templates) can view the SMS settings. - **Save settings**: Admin permission is required to change and save SMS settings. ## Create an SMS gateway account Create an account with your chosen SMS provider and collect the credentials they require (for example, Account SID and Auth Token for Twilio; base URL, username, and password for Infobip). ## Configure the SMS gateway in Mambu 1. Go to **Administration > SMS > Settings**. 2. In **SMS Gateway**, select your provider: **None**, **Twilio**, or **Infobip**. 3. Enter the required fields for the selected provider (see below). 4. Select **Save Changes**. Notes: - Selecting **None** disables SMS for your organization. Manual and automated SMS will not be sent, and send options may be hidden in the UI. - Password is required on the first setup. On later edits, leaving the password blank keeps the existing password. ## Provider fields ### Infobip | Name | Description | Required | | -------------- | --------------------------------------------------------------------------- | -------- | | Base URL | Your Infobip API base URL, for example `xxxxx.api.infobip.com`. | Yes | | Account Username | Your Infobip account username or API user, as provided by Infobip. | Yes | | Account Password | Your Infobip account password or API key (per your Infobip setup). | Yes | | Phone Number | Sender phone number configured with Infobip (From number). | Yes | ### Twilio | Name | Description | Required | | -------------- | -------------------------------------------------------- | -------------------------------------------- | | Account Username | Your Twilio **Account SID** (used as username). | Yes | | Account Password | Your Twilio **Auth Token** (used as password). | Yes (on first setup; leave blank to keep existing) | | Phone Number | Your Twilio From phone number (E.164 format recommended). | Yes | ## Manage SMS templates You can manage automated SMS templates under **Administration > SMS > Templates**. Templates determine triggers, recipients, and message content. SMS sending requires that the SMS gateway be enabled and correctly configured. ## Test and troubleshooting - **Test send**: From the SMS Settings page, you can send a test SMS after selecting a provider and entering valid settings. This validates connectivity and credentials by attempting to send a message; it does not guarantee final delivery (provider routing, filtering, or handset issues may still affect delivery). - **Common issues**: - Invalid credentials (wrong username/token/password) or base URL (Infobip) cause sends to fail. - **None** selected as a provider prevents sending. - Network/firewall blocks between Mambu and your SMS provider can prevent connections. - Missing or invalid sender number with your provider can cause messages to be rejected. If sends fail, verify your provider credentials, base URL (Infobip), sender number, and any required allowlisting with your provider. Contact Mambu Support if you need help diagnosing configuration issues. If none of the above helps, see this [page](/docs/troubleshooting-email-sms-setup) --- # Streaming API URL: https://docs.mambu.com/docs/notifications-channels-streaming-streaming-api/ The Streaming API is a system-to-system communication channel that uses a pull-based strategy to stream large volumes of event data out of Mambu. You use **event streaming notification templates** to define what to publish and when. Your systems then consume those events via the Streaming API. If you have multiple client applications that need to consume the same events, prefer the Streaming API over webhooks. Webhooks are push-based and optimized for point-to-point delivery. For a comparison, see [Webhook notifications](/docs/webhook-notifications). :::note To use the Streaming API, you must have API consumers enabled and configured. See [API Consumers](/docs/api-consumers) in the User Guide and [Streaming API Authentication](/api/pages/streaming/authentication) in the API Reference. ::: ## Create and manage event streaming notification templates Event streaming templates define which events are produced and what payload is delivered through the Streaming API. To create an event streaming notification template: 1. Go to **Administration > Events Streaming > Templates**. 2. Select **Add Notification**. 3. Enter the necessary information (see fields below). 4. Select **Save Changes**. Templates are listed with: - **State** – *In Use* (at least one notification sent) or *Not In Use*. - **Status** – *Active* (can be used) or *Inactive* (deactivated). Only templates with **Status = Active** can produce events. ### Permissions To manage Streaming templates: - **Create / edit templates:** requires the **Manage Events Streaming** permission. - **View templates:** users with administration visibility (for example, **View Administration Details**) or **Manage Events Streaming** can view the Events Streaming templates. ## Template fields ### Name - Must be unique. - Leading and trailing spaces are automatically trimmed on save. - Maximum length: **255 characters**. ### Subscription option Choose how recipients are subscribed: - **Opt-out (auto-subscribed):** on first save, relevant recipients are automatically subscribed in the background. They can later unsubscribe. - **Opt-in (manually subscribed):** recipients are not subscribed by default. You must subscribe to them explicitly. Streaming templates use the same subscription model as other notification channels, and subscriptions are managed via **Notification Requests** on the recipient profile. ### Target The target determines what the event relates to and which events are available. Supported targets include, for example: - **Client** - **Group** - **Background process** (for example, End of Day) - **Data access** - **Payment order** (when the Payments capability is enabled) - **Accounting** (journal entries) Notes: - The availability of targets and events depends on enabled capabilities and tenant feature toggles. - Not all events are available for all targets. ### Event trigger Choose the event that will trigger the notification. Available events depend on: - The selected **target**, and - Enabled capabilities and feature toggles for your tenant. Compared to email and SMS, event streaming may expose additional event categories when they are enabled. For an overview of event types, see [Event triggers](/docs/event-triggers). ### Conditions Optionally, add conditions to control when the template triggers: - Each condition is defined by **field**, **operator**, and **value**. - You can choose: - **Match All** – all conditions must be true (AND logic), or - **Match Any** – at least one condition must be true (OR logic). ### Topic Each template has a **topic** that identifies where its events are published for the Streaming API. - The topic name is **generated by the system** based on your environment and the selected event. - The topic is shown in the template form; you do not create or manage it separately. - This topic name is the **logical identifier** used by Streaming API clients when creating subscriptions. Internal infrastructure and physical topic details are managed by Mambu and are intentionally abstracted from customer configuration. ### Contents (payload) The template body defines the **payload** that will be sent to your consumers when the event is published. You can: - Structure the payload (for example, as JSON). - Use **placeholders** to inject values from the triggering context (such as client, account, or payment order data). The Streaming API delivers your payload together with metadata such as event identifiers and timestamps. For more details on placeholders, see [Placeholders](/docs/placeholders). ## Subscriptions and delivery There are two levels of subscription: 1. **Template subscriptions** (Opt-in / Opt-out). 2. **Streaming API subscriptions** (for your client applications). ### Template subscriptions (Notification Requests) Template subscriptions control **whether events are produced** for a given recipient. - Streaming templates follow the same subscription model as other channels. - Recipients must be subscribed for events to be generated for them: - **Opt-in:** recipients are only included if they are explicitly subscribed. - **Opt-out:** recipients are auto-subscribed the first time; they can later unsubscribe. - You can subscribe or unsubscribe recipients via **More > Set Notifications** on their profile. ### Streaming API subscriptions (client side) Your client applications use the Streaming API to subscribe and read events from the topics exposed by your templates. A typical Streaming API workflow: 1. **Create a subscription** - Use the Streaming API to create a subscription to one or more streams/topics. - The subscription defines what you will read. 2. **Open an event stream** - Call the Streaming API endpoint that returns a continuous stream of events for the subscription. - Keep this connection open while processing events. 3. **Process events and commit cursors** - As you process events, **commit the cursor** to record the position you have read up to. - If you reconnect later, you can resume from the committed cursor. 4. **Delete the subscription** - When you no longer need the events, delete the subscription to stop producing data for that consumer. Refer to the API Reference for details on resources such as **subscriptions**, **events**, **streams**, and **cursor commits**. ### Delivery behavior (high-level) - **Delivery:** At-least-once. Your consumers should be idempotent and able to handle occasional duplicate events. - **Ordering:** Events are ordered for a given stream/partition within a subscription. Do not assume global ordering across different topics or subscriptions. - **Retention:** Events are stored for a limited retention window. If a subscription is idle for longer than that window, older events may no longer be available. ## Authentication and access Using the Streaming API requires: - An **API Consumer** configured in your tenant. - An **API key** associated with that API Consumer. Use the API key to authenticate your Streaming API requests, following the guidance in the **Streaming API → Authentication** section of the API Reference. ## Troubleshooting and tips - **No events are received** - Check that the template **Status** is *Active*. - Verify that the relevant events are actually occurring in your tenant. - Confirm that recipients are subscribed (Opt-in) or were auto-subscribed (Opt-out). - Ensure your Streaming API subscription is created against the correct topic and is in an active state. - **Unexpected duplicates** - Design your consumers to be **idempotent** (for example, by tracking event IDs) to handle at-least-once delivery. - **Authorization errors** - Verify that the correct API Consumer and API key are used. - Check that your API Consumer is allowed to access the Streaming API. Operational details such as underlying broker technology, partitions, and internal metrics are managed by Mambu and are intentionally not exposed in this documentation. --- # Webhook best practices URL: https://docs.mambu.com/docs/notifications-channels-webhooks-best-practices/ This page outlines practical recommendations to avoid common pitfalls and keep webhook integrations reliable at scale. The guidance reflects how the **Notifications** service actually dispatches webhooks. ## Template configuration - **Prefer specific triggers over broad ones** - Very broad events (for example, “account activity” style events) can generate high volumes of webhook calls. - Retries for transient failures may amplify traffic bursts. - For high-volume use cases, consider: - Narrowing conditions. - Using separate templates and/or endpoints to isolate the load. - **Use HTTPS endpoints only** - Webhook destinations must use `https`. Non-HTTPS URLs are rejected before dispatch. - Avoid private IPs or internal-only hosts that cannot be reached from Mambu’s infrastructure. - **Validate destinations and headers** - Use valid, production URLs—not placeholder or test values. - Avoid putting secrets in URLs (for example, query parameters). Put credentials or tokens into headers instead. - Do not rely on redirects: `3xx` responses are **not** treated as success. Use the final URL directly. - Custom headers defined on the template are forwarded to your endpoint (except for some reserved internal headers that are stripped for security). - **Deactivate templates you no longer need** - Deactivating a template stops **new** notifications from being produced upstream. - Messages already queued for delivery may still be dispatched by the Notifications service, so expect a short tail of in-flight requests. - **Multiple templates to the same URL** - If several templates post to the same endpoint, size and tune that endpoint for the combined throughput and potential retry bursts. - Consider separating high-volume and low-volume integrations by URL. ## Endpoint design - **Respond quickly with a 2xx status** - Only HTTP **2xx** responses are treated as success. - `3xx`, `4xx`, `5xx`, timeouts, and network/TLS errors are treated as failures. - Process the webhook asynchronously on your side (for example, enqueue to a job queue) and return 2xx as soon as you accept the payload. - Requests are sent with a timeout; heavy synchronous work increases the chance of timeouts and repeated delivery attempts. For more details, see [Troubleshoot delayed notifications](/docs/troubleshooting-delayed-notifications). - **Idempotency and deduplication** - Webhook requests include `x-notifications-idempotency-key`. - Automatic retries of the same delivery use the **same** idempotency key. - Manual “resend” actions generate a **new** idempotency key. - Use this header to: - Detect duplicate deliveries. - Make handlers idempotent (for example, ignore a second request with a key that has already been processed successfully). - **Design for at-least-once delivery** - Because of retries in case of transient failures, delivery is **at-least-once**. - Your receiver must tolerate duplicates: - Use `x-notifications-idempotency-key` and/or identifiers in the payload to implement safe deduplication. - Avoid non-idempotent side effects (for example, double-charging or double-posting). - **Request method and payload** - The HTTP method and body are defined by the notification template/message. - Ensure your endpoint: - Supports the configured HTTP method. - Validates and safely processes the payload format you expect (for example, JSON). - **Security and authentication** - Require HTTPS. - Use header-based authentication (for example, API keys, HMAC signatures, or OAuth tokens) rather than credentials in URLs. - Rotate credentials regularly and update template headers accordingly. - Validate and sanitize incoming payloads before further processing. - **Avoid redirects and heavy synchronous logic** - Do not rely on redirect chains; `3xx` responses are not treated as success. - Keep synchronous logic small and fail-fast; push heavy work to background jobs. ## Monitoring and alerting - **Use status codes as signals** - **2xx** – Success. No retry. - **4xx** – Client errors (typically non-retryable). - Often indicates misconfiguration, missing/invalid credentials, or authorization issues. - Fix the problem quickly to restore delivery. - **5xx**, timeouts, and network/TLS errors – Treated as transient. - These are retried with backoff and contribute to protection mechanisms (circuit breaker). - **Track latency and timeouts** - Monitor response times for your webhook endpoints. - Sustained increases in latency lead to timeouts and retries. - Alert on: - Rising average or P95/P99 latency. - Increases in timeout rates. - **Instrument your receiver logs** Log enough information to understand what happened without storing unnecessary sensitive data. For each request, log, for example: - Timestamp. - Endpoint/path and HTTP method. - HTTP status code. - The `x-notifications-idempotency-key` value. - High-level processing result (accepted / rejected / failed). - A correlation ID or your own trace ID if you add one via custom headers. Avoid logging full payloads if they may contain personal or sensitive data; consider structured, redacted logging. - **Watch for failure streaks** - Spikes in non-2xx responses (especially 5xx) and sustained failure streaks usually indicate: - Receiver outages or dependency failures. - Misconfigurations (for 4xx). - These patterns also influence retry behavior and may contribute to circuit-breaker protection, temporarily reducing or pausing deliveries to protect your systems. ## Failure handling, retries, and protection - **Retries** - Certain failures (for example, 5xx, timeouts, and network errors) are retried according to internal policies with backoff. - This means you may see repeated attempts for the same webhook until either: - It succeeds with a 2xx, or - Retry limits are reached / protection mechanisms apply. - **Circuit breaker** - When repeated failures occur for a specific destination (for example, persistent 5xx or timeouts), a protection mechanism may temporarily pause or slow deliveries for that template and tenant. - This helps: - Prevent overwhelming an unstable endpoint. - Protect the overall system. - Once the destination recovers and failures cease, deliveries resume automatically, according to the circuit breaker’s rules. - **What this means for you** - Keep your endpoint healthy and fast. - Use clear 2xx/4xx/5xx responses to signal the real state. - Fix persistent 4xx errors quickly. - Scale receiver capacity or apply graceful degradation during incidents. ## Security recommendations - Use HTTPS everywhere for webhook endpoints. - Prefer short-lived tokens or signed headers rather than long-lived static secrets. - Restrict access to your endpoints using: - Network controls (IP allowlists, if appropriate). - Application-level authentication and authorization. - Validate payloads strictly and apply input validation to avoid injection or deserialization issues. ## Troubleshooting tips - **No events are received** - Check that: - The relevant webhook template is **Active**. - The triggering business event actually occurs. - The destination URL is correct and reachable from the public internet. - Verify that your endpoint is returning 2xx and not silently failing with 4xx/5xx. - **Lots of 4xx responses** - Likely misconfiguration: - Wrong URL or path. - Missing or invalid authentication. - Authorization rules block the request. - Update configuration and redeploy. Consider returning 2xx if you accept the event and handle business-level errors asynchronously. - **Lots of 5xx, timeouts, or connection errors** - Indicates that your endpoint or its dependencies are unhealthy or overloaded. - Scale horizontally, add caching, or temporarily reduce downstream work. - Expect the Notifications service to retry with backoff and, in persistent cases, to apply circuit-breaker protection. - **Duplicates seen in logs or processing** - Use `x-notifications-idempotency-key` and/or your own business identifiers to avoid processing the same event twice. - Confirm your handlers are idempotent (safe to call multiple times with the same key). --- See also: - [Circuit breaker](/docs/webhooks-circuit-breaker) - [Troubleshooting](/docs/troubleshooting-webhooks) --- # Circuit breaker URL: https://docs.mambu.com/docs/notifications-channels-webhooks-circuit-breaker/ The circuit breaker protects both Mambu and your systems from repeatedly calling slow or failing webhook endpoints. When a destination keeps timing out or returning errors, the circuit breaker can **temporarily pause delivery** to that destination, then probe it again, and resume when it has recovered. This page describes the behavior from the **Notifications** service point of view, which is responsible for HTTP dispatch, timeouts, retries, and the circuit breaker. ## What the circuit breaker does - Monitors webhook delivery outcomes on a per-destination basis (per tenant and template). - Counts failures such as: - Non-2xx HTTP responses - Request timeouts - Network/TLS/connect errors - When failures exceed configured thresholds, it **opens** the circuit for that destination and **temporarily pauses** delivery. - After a cool-down period, it **probes** the destination again with a limited number of trial requests. - If those trial requests succeed, normal delivery resumes; if failures continue, the circuit re-opens. Exact numeric thresholds and timings (timeouts, failure ratios, delays) are **configuration-driven** and may differ across environments. They are not fixed to “500 ms”, “5 out of 10”, or “5 seconds”. ## How it works (states and behavior) At a high level, the circuit breaker for webhooks behaves as follows: - **Closed (normal operation)** - All webhook deliveries are attempted. - A delivery is considered **successful** only if your endpoint returns an HTTP **2xx** status. - Non-2xx responses, timeouts, and network/TLS errors are treated as **failures**. - The HTTP client applies a **per-request timeout** that is configured by Mambu (values may differ for initial attempts vs. retry attempts). - **Opening the circuit** - Notifications track recent executions per destination. - When the **failure rate** or **number of failures** in a recent window crosses configured thresholds, the breaker **opens** for that destination. - While **Open**, webhook deliveries to that destination are **not attempted**; they are short-circuited by the breaker. - **Open (cool-down / pause)** - The circuit remains Open for a **configured cool-down period**. - During this period, new deliveries to that destination are blocked by the breaker and treated as failures from the retry policy’s point of view (no HTTP call is made). - **Half-open (probe)** - After the cool-down, the breaker moves to **Half-open** and allows a **limited number of trial requests** through. - If enough of these trial calls succeed (2xx within the normal timeout), the breaker transitions back to **Closed**. - If failures continue, the breaker returns to **Open** for another cool-down period. The overall goal is to **reduce pressure on unstable endpoints**, while still allowing them to recover and rejoin normal traffic once they start responding successfully again. ## Interaction with retries Webhook delivery uses two main phases: 1. **Initial (fast-lane) attempt** - A new notification is dispatched once with a per-request timeout. - If it succeeds (HTTP 2xx), the message is marked as sent. - If it fails in a way considered retryable (for example, timeout or transient network/TLS error), the message may be moved to a **slow lane** for retries. 2. **Slow-lane retries (under retry policy + circuit breaker)** - On the slow lane, retries are executed under a **retry policy** (with backoff) and, when enabled, a **circuit breaker**. - These policies are combined, so the **circuit breaker does influence retries**: - If the breaker is **Closed**, retries will attempt HTTP calls according to the retry policy. - If the breaker is **Open**, attempts are **short-circuited** and no HTTP call is made until the cool-down expires. - In **Half-open**, only a limited number of trial attempts are allowed; their outcome determines whether the breaker closes again or returns to Open. - Retries are still **at-least-once**: under transient failures, you may see **duplicate deliveries** for the same logical event. Because of this, your endpoint should always be prepared for: - **At-least-once delivery** (duplicates are possible). - Bursts of traffic when a previously failing endpoint recovers and traffic resumes. - Periods with **no traffic** after repeated failures, while the breaker is Open. For details on how failed notifications are retried and surfaced in the UI, see [Managing notifications](/docs/managing-notifications#automatic-retry-mechanism-for-failed-communications). ## Recommendations To work well with the retry policy and circuit breaker: - **Acknowledge quickly with 2xx** - Return an HTTP **2xx** status as soon as you accept the event. - Process the payload **asynchronously** on your side (for example, queue it internally) instead of doing heavy work in the synchronous response. - Avoid redirects (`3xx`) and long-running synchronous processing, which increase timeouts and failure counts, potentially causing [dispatch delays](/docs/troubleshooting-delayed-notifications) for other notifications. - **Design for at-least-once delivery** - Make your handlers **idempotent**. - Use the `x-notifications-idempotency-key` header to detect and safely ignore duplicate deliveries when present. - If you accept an event but encounter a downstream error, consider returning `2xx` and handling the error asynchronously, instead of returning `5xx` on the webhook call. - **Monitor failures and latency** - Track: - 2xx vs. non-2xx response rates (especially 4xx and 5xx) - Timeouts and request latency - Trends around incident times (spikes in errors followed by quiet periods) - Persistent non-2xx responses and timeouts **increase failure counts** and may **open the circuit** for your destination. - **React quickly to 4xx errors** - 4xx often indicates misconfiguration (wrong URL, invalid credentials, authorization failures). - Fix these quickly to restore delivery; otherwise, failures will persist and may keep the breaker from closing. - **Capacity and rate limiting** - Size your infrastructure to handle: - Normal traffic - Additional **retry traffic** during incidents - A potential burst when a destination recovers and the circuit closes - Apply your own rate limits and backpressure mechanisms where appropriate. For more guidance on endpoint design and observability, see [Webhook best practices](/docs/webhooks-best-practices) and [Troubleshooting](/docs/troubleshooting-webhooks). --- # Create webhook templates URL: https://docs.mambu.com/docs/notifications-channels-webhooks-defining-a-new-webhook/ To create or edit webhook templates, you need the following permissions: - Create templates: Create Templates (`CREATE_COMMUNICATION_TEMPLATES`) and View Administration Details. - Edit / activate / deactivate templates: Edit Templates (`EDIT_COMMUNICATION_TEMPLATES`) and View Administration Details. - View templates: any of Create Templates, Edit Templates, or View Administration Details. ## Create a webhook 1. Go to Administration > Webhooks > Templates. 2. Select **Add Notification**. 3. Enter the required information (see **Fields** below). 4. Select **Save Changes**. Templates list a state and a status: - **State**: In Use (at least one notification sent) or Not In Use. - **Status**: Active (can be used) or Inactive (deactivated). ## Fields ### Webhook name A human-readable unique name, up to 255 characters. Leading and trailing spaces are trimmed automatically. ### Subscription option Choose whether recipients are Opt out (auto-subscribed) or Opt-in (manually subscribed). - **Opt-out**: On first save, recipients are automatically subscribed in the background. They can later unsubscribe. - **Opt-in**: Recipients are not subscribed by default and must be added manually. ### Target Select what the notification relates to. Available targets include: - Client - Group - Background process (for example, End of Day) - Data access - Payment order (when Payments is enabled) - Accounting (journal entries) - Administrative (for example, Holiday Sync) The target determines which events are available and which placeholders you can use. ### Event trigger Choose the event that triggers the webhook. Available events depend on the selected target, enabled features, and the Webhooks channel. For a full list and details, see [Event triggers](/docs/event-triggers). ### Conditions Optionally restrict when the webhook is sent by adding conditions (field, operator, value). Choose: - **Match All** – all conditions must be true (AND) - **Match Any** – at least one condition must be true (OR) ### Webhook URL The destination endpoint for the request. - Must be a valid `http://` or `https://` URL; quotes are not allowed in the URL. - Certain placeholders are not allowed in the URL. - Placeholders can be used in the path and query string where appropriate. - For security and deliverability, use HTTPS. Depending on your environment, non-HTTPS or blacklisted destinations may be rejected at send time. ### Request type The HTTP method used for the request. Supported: - `POST` - `PUT` - `PATCH` ### Authorization Choose one of: - **No Authorization** - **Basic Authorization** (username and password) For token or API key authentication, use a custom header (see below). ### Content type Format of the request body: - Plain text (`text/plain`) - JSON (`application/json`) - XML (`application/xml`) If you select JSON or XML, ensure the payload is validly formatted. ### Custom request headers Static headers to include with every request. - Placeholders are **not** supported in headers. - Avoid reserved headers; some headers may be ignored by the platform (for example, `x-consumer-username`). ### Webhook contents The request payload sent to your endpoint. - You can include placeholders to inject values from the triggering context. - If you use JSON or XML, validate the structure before saving to avoid send-time failures. See [Placeholders](/docs/placeholders) for more details on available fields. ## Manage subscriptions 1. Open the recipient profile (for example, a client or group). 2. Select **More > Set Notifications**. 3. In **Notification Requests**, select or deselect the relevant notifications. Notes: - The list is grouped by event trigger and channel (SMS, email, webhook). - If multiple webhook templates exist for the same event trigger, a single checkbox controls subscription to all of them. ## Test your webhook configuration If you do not control the receiver logs, you can use tools such as RequestBin or Webhook Tester to inspect incoming requests from Mambu and verify: - URL and HTTP method - Headers - Payload shape and content ## Sender IP addresses Webhook requests originate from Mambu infrastructure. Source IP addresses vary by region and environment. If you need to allowlist IPs in your firewall, contact Mambu Support for the current list for your environment. --- # Webhooks Overview URL: https://docs.mambu.com/docs/notifications-channels-webhooks-overview/ Webhooks are system-to-system communication tools that use a push-based strategy to send HTTP callbacks for events happening in the Mambu application. For example, you can set up a webhook to notify one of your applications that a loan has been disbursed. When the event occurs, Mambu sends an HTTP request (typically `POST`) to your endpoint with a payload that can include details such as the loan account ID, client information, and amount. Your application can: - Process the request directly, or - Call back to Mambu to retrieve additional information or trigger further actions (for example, creating a task or sending an email), or - Enrich the data and forward it to another partner service. For more information on setting up webhooks, see [Create webhook templates](/docs/webhooks-defining-a-new-webhook). :::note The Streaming API is another system-to-system communication tool, but it uses a pull-based strategy and is better suited for use cases where multiple client applications must consume large volumes of data from Mambu. For more information, see [Streaming API](/docs/streaming-api) in our User Guide and [Streaming API](/api/pages/streaming/streaming-index) in our API Reference. ::: ## Benefits of using webhooks ### Audit The communication history records every notification sent out. - Each webhook notification is stored with its destination, status, timestamps, and the payload as it was rendered at send-out time. - When you manually re-send a failed webhook, the stored payload for that notification is sent again (it is not re-computed from the current template). This makes it easier to diagnose issues and, when needed, re-send exactly what was originally produced. ### Assured delivery Webhook delivery is backed by a retry mechanism that uses an exponential backoff policy. - If a webhook cannot be delivered (for example, due to timeouts, network errors, or non-2xx responses), the system may retry delivery according to a configured backoff policy. - Only HTTP `2xx` responses are considered successful. Non-`2xx` responses, timeouts, and connection errors are recorded as failures and may be retried depending on configuration. If automatic retries are exhausted or not applicable, no further automatic attempts are made. You can manually re-send failed webhook notifications via the UI or via API where available. For more information about Mambu APIs in general, --- # Troubleshoot webhooks URL: https://docs.mambu.com/docs/notifications-channels-webhooks-troubleshooting/ Use the Communications log to investigate failed webhook notifications and identify the root cause. ## Inspect failures in the Communications log 1. In the Mambu UI, open the Communications tab. 2. For a more detailed view: - Select Edit Columns. - Enable Include timestamps. - Add Creation Timestamp, Failure Reason, and Failure Details. 3. Locate the failed webhook notification, open the details, and review the payload and response status. 4. Apply filters (for example, status = Failed, time range) to narrow results. Prefer small time ranges to avoid heavy queries. ## Common failure reasons - Destination is unreachable (404 Not Found): The webhook URL is incorrect or the endpoint is down. - Unauthorized (401 Unauthorized): The API key or authentication method is incorrect. - Timeout: The destination server took too long to respond. See [Troubleshoot delayed notifications](/docs/troubleshooting-delayed-notifications) for more on how timeouts affect the queue. - Payload too large or malformed: The receiver rejected the message. - Blacklisted URL: Sending to restricted addresses is blocked. ## Resend options - Manual resend from the Communications log for individual items. - Programmatic resend via API. See [Managing notifications](/docs/managing-notifications#resending-failed-messages-via-the-api). ## Improve reliability - Follow [Webhook best practices](/docs/webhooks-best-practices). - Understand the [circuit breaker](/docs/webhooks-circuit-breaker) behavior for slow endpoints. --- # Webhook notifications URL: https://docs.mambu.com/docs/notifications-channels-webhooks-webhook-notifications/ Webhooks are a system-to-system communication channel that uses a push-based strategy to send HTTP callbacks for events happening in Mambu. For example, you can set up a webhook to notify one of your applications that a loan has been disbursed. Mambu will make a request to your application with a payload including information such as the loan account ID, client information, and amount. Your application may act directly on the request or call back to Mambu for more data or to trigger additional actions. See also: [Create webhook templates](/docs/webhooks-defining-a-new-webhook) and [Streaming API](/docs/streaming-api). ## Benefits ### Audit The communication history records every notification sent. Each record stores the destination, timestamps, status, failure details (if any), and the exact payload rendered at sent time. If a notification fails, you can resend that original payload snapshot. ### Assured delivery Delivery is backed by an automatic retry mechanism that uses an exponential backoff policy. Only HTTP 2xx responses are considered successful; non-2xx responses, timeouts, and connection errors are treated as failures and may be retried according to platform policy. If the configured threshold is reached with no success, automatic retries stop. You can manually resend failed communications via the UI or API (where available). For more information, see [Managing notifications](/docs/managing-notifications). ### Flexibility - Use a URL template for the destination. The URL must be HTTP or HTTPS. Avoid quotes and disallowed placeholders in the URL. Prefer HTTPS. - Create payload templates in plain text, `application/json`, or `application/xml` and use placeholders. See [Placeholders](/docs/placeholders). - Supported HTTP methods: `POST`, `PUT`, and `PATCH`. - Configure custom request headers. Headers are static (no placeholder expansion). The platform may ignore some reserved headers. ## Idempotency Webhook requests include an `x-notifications-idempotency-key` header when this feature is enabled. Design receivers to process events idempotently and deduplicate based on this key. Retries of the same notification reuse the same key; manual resends use a new key. ## Security - Use HTTPS/TLS for all communications. - Basic authentication is supported. If you use token-based authentication, pass tokens via custom request headers. ## Sender IP addresses Webhook requests originate from Mambu infrastructure. If you need to allowlist source IP addresses in your firewall, contact Mambu Support for the current list for your environment and region. ## Webhooks vs. Streaming API Webhooks push events to a single destination and are suitable for point-to-point integrations. The [Streaming API](/docs/streaming-api) is pull-based and better when multiple consumers need to read high-volume event streams. --- # Event triggers URL: https://docs.mambu.com/docs/notifications-event-triggers/ When setting up automated email, SMS, webhook, or event streaming notifications, you select the event that triggers the notification. Available events depend on the selected target and on the capabilities enabled for your environment. Some events are not available for all channels (for example, certain Cards or account authorisation hold events are available for webhooks and event streaming). This page lists events that can trigger automated notifications. Events used only by manual templates are not included here. Each row below lists the UI label and the API event name (in parentheses). Use the API name when configuring integrations. | Event | Description | |-----------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------| | Account in Arrears (`ACCOUNT_IN_ARREARS`) | An account changed its status to In Arrears (subject to arrears tolerance). | | End of Day processing completed (`END_OF_DAY_PROCESSING_COMPLETED`) | Background job completed updating accounts. | | Account Authorisation Hold Created (`ACCOUNT_AUTHORISATION_HOLD_CREATED`) | An authorisation hold has been created directly on an account. | | Account Authorisation Hold Reversed (`ACCOUNT_AUTHORISATION_HOLD_REVERSED`) | An authorisation hold has been reversed or cancelled on an account. | | Account Authorisation Hold Settled (`ACCOUNT_AUTHORISATION_HOLD_SETTLED`) | An authorisation hold has been settled on an account. | | Cards Authorisation Hold Created (`CARDS_AUTHORISATION_HOLD_CREATED`) | A new authorisation hold was created via the Cards API. | | Cards Authorisation Hold Created in Bulk (`CARDS_AUTHORISATION_HOLD_IN_BULK_CREATED`) | Authorisation holds were created in bulk via the Cards API. | | Cards Authorisation Hold Amount Increased (`CARDS_AUTHORISATION_HOLD_AMOUNT_INCREASED`) | An authorisation hold amount increased via the Cards API. | | Cards Authorisation Hold Amount Decreased (`CARDS_AUTHORISATION_HOLD_AMOUNT_DECREASED`) | An authorisation hold amount decreased via the Cards API. | | Cards Authorisation Hold Expired (`CARDS_AUTHORISATION_HOLD_EXPIRED`) | An authorisation hold expired after its configured period. | | Cards Authorisation Hold Reversed (`CARDS_AUTHORISATION_HOLD_REVERSED`) | An authorisation hold was reversed via the Cards API. | | Cards Authorisation Hold Settled (`CARDS_AUTHORISATION_HOLD_SETTLED`) | An authorisation hold was settled during related card transaction processing. | | Card Deposit Reversal (`CARD_DEPOSIT_REVERSAL`) | A card deposit transaction was reversed. | | Card Withdrawal Reversal (`CARD_WITHDRAWAL_REVERSAL`) | A card withdrawal transaction was reversed. | | Change Interest Rate (`INTEREST_RATE_CHANGED`) |

    The interest rate was changed at the account level.

    Note that this event only applies to Loans.

    | | Client Activity (`CLIENT_ACTIVITY`) | Non-transactional changes on a client record. | | Client Approved (`CLIENT_APPROVED`) | Client status changed to Approved. | | Client Created (`CLIENT_CREATED`) | A new client was created. | | Client Rejected (`CLIENT_REJECTED`) | Client status changed to Rejected. | | Collection Order Activity (`COLLECTION_ORDER_ACTIVITY`) | A collection (direct debit) progressed to the next stage. | | Credit Arrangement Created (`CREDIT_ARRANGEMENT_CREATED`) | A credit arrangement was created. | | Credit Arrangement Edited (`CREDIT_ARRANGEMENT_EDITED`) | A credit arrangement was edited. | | Credit Arrangement Approved (`CREDIT_ARRANGEMENT_APPROVED`) | A credit arrangement was approved. | | Credit Arrangement Rejected (`CREDIT_ARRANGEMENT_REJECTED`) | A credit arrangement was rejected. | | Credit Arrangement Withdrawn (`CREDIT_ARRANGEMENT_WITHDRAWN`) | A credit arrangement was withdrawn. | | Credit Arrangement Closed (`CREDIT_ARRANGEMENT_CLOSED`) | A credit arrangement was closed. | | Credit Arrangement Deleted (`CREDIT_ARRANGEMENT_DELETED`) | A credit arrangement was deleted. | | Credit Arrangement Account Added (`CREDIT_ARRANGEMENT_ACCOUNT_ADDED`) | An account was added to a credit arrangement. | | Credit Arrangement Account Removed (`CREDIT_ARRANGEMENT_ACCOUNT_REMOVED`) | An account was removed from a credit arrangement. | | Data Access State Changed (`DATA_ACCESS_STATE_CHANGED`) | Database access mode changed (read/write vs read-only). | | Deposit (`SAVINGS_DEPOSIT`) | A deposit transaction was posted on a savings account. | | Deposit (Adjustment) (`SAVINGS_DEPOSIT_REVERSAL`) | A savings deposit was adjusted. | | Deposit Account Created (`SAVINGS_CREATED`) | A savings account was created. | | Deposit Account Approval (`SAVINGS_APPROVAL`) | A savings account was approved. | | Deposit Account Activated (`SAVINGS_ACCOUNT_ACTIVATED`) | A savings account was activated. | | Deposit Account Activity (`SAVINGS_ACCOUNT_ACTIVITY`) | Non-transactional changes on a savings account. | | Deposit Account Rejection (`SAVINGS_ACCOUNT_REJECTION`) | A savings account was rejected in the approval process. | | Deposit Account Closure (`SAVINGS_ACCOUNT_CLOSURE`) | A savings account in Active or Matured state was closed. | | Savings Deposit Reapplied (`REAPPLIED_SAVINGS_DEPOSIT`) | A previously reversed savings deposit was reapplied. | | Savings Withdrawal Reapplied (`REAPPLIED_SAVINGS_WITHDRAWAL`) | A previously reversed savings withdrawal was reapplied. | | Deposit Interest Applied (`DEPOSIT_INTEREST_APPLIED`) | Interest was posted to a savings account. | | Deposit Interest Applied (Adjustment) (`DEPOSIT_INTEREST_APPLIED_ADJUSTMENT`) | A deposit interest application was adjusted. | | Deposit/Withdrawal Edited (`SAVINGS_TRANSACTION_EDITED`) | A savings deposit or withdrawal transaction was edited (availability depends on configuration). | | Group Activity (`GROUP_ACTIVITY`) | Non-transactional changes on a group. | | Group Created (`GROUP_CREATED`) | A new group was created. | | Holiday Synchronization Completed (`HOLIDAY_SYNC_COMPLETED`) | A holiday update was completed (Administrative target). | | Loan Account Created (`LOAN_CREATED`) | A loan account was created. | | Loan Account Approval (`LOAN_APPROVAL`) | A loan account was approved. | | Loan Account Activity (`LOAN_ACCOUNT_ACTIVITY`) | Non-transactional changes on a loan account. | | Loan Account Rejection (`LOAN_ACCOUNT_REJECTION`) | A loan account was rejected in the application process. | | Loan Account Rescheduled (`LOAN_ACCOUNT_RESCHEDULED`) | A loan account was rescheduled into a new account. | | Loan Account Refinanced (`LOAN_ACCOUNT_REFINANCED`) | A loan account was refinanced into a new account. | | Loan Account Closed (Repaid) (`LOAN_ACCOUNT_CLOSURE`) | A loan account was closed after being fully repaid. | | Loan Anticipated Disbursement (`LOAN_ANTICIPATED_DISBURSEMENT`) | Reminder before anticipated disbursement. | | Loan Disbursement (`LOAN_DISBURSEMENT`) | A disbursement transaction was posted on a loan account. | | Loan Disbursement (Adjusted) (`LOAN_DISBURSEMENT_REVERSAL`) | A disbursement transaction was adjusted. | | Loan Repayment (`LOAN_REPAYMENT`) | A repayment transaction was posted on a loan account. | | Loan Repayment (Adjustment) (`LOAN_REPAYMENT_REVERSAL`) | A repayment transaction was adjusted. | | Loan Fee Applied (`FEE_APPLIED`) | A fee applied transaction was posted. | | Loan Fee Charged (`FEE_CHARGED`) | A fee charged (for example, a disbursement fee) was posted. | | Loan Fee Adjusted (`FEE_ADJUSTED`) | A fee applied transaction was adjusted. | | Loan Penalty Applied (`PENALTY_APPLIED`) | A penalty applied transaction was posted. | | Loan Penalty Adjustment (`PENALTY_ADJUSTMENT`) | A penalty applied transaction was adjusted. | | Loan Write Off (`LOAN_ACCOUNT_WRITE_OFF`) | A loan was closed with a write-off transaction. | | Fees Due Reduced (`FEES_DUE_REDUCED`) | A fee due reduce transaction was posted. | | Fee Reduction Adjustment (`FEE_REDUCTION_ADJUSTMENT`) | A fee due reduce transaction was adjusted. | | Payment Order Activity (`PAYMENT_ORDER_ACTIVITY`) | A payment order progressed to the next stage (Payment Order target). | | Repayment Reminder (`REPAYMENT_REMINDER`) | A repayment is due in X days (requires a non-negative trigger days value). | | Withdrawal (`SAVINGS_WITHDRAWAL`) | A withdrawal transaction was posted on a savings account. | | Withdrawal (Adjustment) (`SAVINGS_WITHDRAWAL_REVERSAL`) | A savings withdrawal was adjusted. | | Portal Activated (`PORTAL_ACTIVATED`) | Customer Portal was activated for a client (requires Portal and a communications channel). | | Portal Password Reset (`PORTAL_PASSWORD_RESET`) | A Customer Portal password reset was requested (requires Portal and a communications channel). | | Journal Entry Added (`JOURNAL_ENTRY_ADDED`) | A journal entry was added (Accounting target). | | Journal Entry Adjusted (`JOURNAL_ENTRY_ADJUSTED`) | A journal entry was adjusted (Accounting target). | :::note - Event availability depends on the selected target and on enabled features. Some event categories are not available for certain channels (for example, email templates exclude some account activity, card, and authorization hold events). - Cards events require the Cards capability. The availability of Account Authorisation Hold and deposit-interest-related events depends on your enabled capabilities and environment configuration. Savings transaction edited availability also depends on your configuration. - Use the API event name (in parentheses) when integrating with APIs. ::: :::tip For a full list of dynamic fields you can use in these notifications, see [Notification placeholders](/docs/notifications-placeholders). ::: --- # Managing notifications URL: https://docs.mambu.com/docs/notifications-managing-notifications/ Mambu persists notifications (email, SMS, and webhooks) for auditing and troubleshooting. You can use the communication log to search, inspect, and export entries. [Streaming API](/docs/streaming-api) events are handled by a dedicated pipeline and are not managed through the same resend flow. To view the communication log with a list of notifications for your tenant, you must have access to a menu item of type Communications. For more information, see [Menu items](/docs/menu-items) and [Custom views](/docs/custom-views). ## Managing the communication log The communication log allows you to: - Apply filters (for example, by channel, state, date range, or template). - Customize displayed columns. For more information, see [Customizing columns](/docs/customizing-columns). - Export the current view to a file for analysis. - Save custom views for common filters. For more information, see [Custom views](/docs/custom-views). ## Notification information Each notification shows default information such as the current state, the sender (when available), creation and send timestamps, and failure details if applicable. ### Notification states The service uses the following states: * **Pending / processing** * `SENDING` * `WAITING` * **Terminal (success)** * `SENT` :::note Only `SENT` states represent successful delivery. ::: * **Terminal (failure)** * `FAILED` :::note `FAILED` states represent terminal failures. ::: ### Sent by Automated notifications typically show the system as a sender. User-initiated actions, where applicable, may show the username. Exact fields can vary by channel and UI context. ### Message contents For each entry, you can open the details to view the payload, destination, and any error information captured during dispatch. For emails, the subject is displayed in the details. Sensitive data may be redacted, and very long error messages may be truncated in storage. ## Exporting the log Use the Export action to download the current list. The exported file includes the visible columns and relevant fields for the selected entries. Depending on channel and configuration, huge payloads and error messages may be truncated in exports. ## Viewing client, group, or user communication logs To view notifications for a specific client, group, or user: 1. Open the client/group/user details page. 2. Select the **Communications** tab. ## Resending failed messages You can resend failed notifications from the UI or API (where supported). Resending creates a new log entry; the original remains for audit. - The resent message uses the stored rendered content from the original attempt (it does not re-render the template). - For webhooks, the resend will include a fresh `x-notifications-idempotency-key` header value. Design your endpoint to be idempotent and to treat this header as a deduplication hint. ### Resending failed messages via the Mambu UI To resend a failed message in the UI: - Open the message details by selecting the **Failed** state and choose **Resend**, or - Select the **more** link from the Message column and choose **Resend**. ### Resending failed messages via the API To resend failed webhook messages via API v2, send a `POST` to the `/communications/messages:resend` endpoint. For more information, see the resend endpoint in the API Reference. Example flow: 1. Find failed webhook messages by sending a `POST` to `/api/communications/messages:search` with a body that filters by state `FAILED` and type `WEBHOOK`. 2. Use the returned IDs in a `POST` to `/api/communications/messages:resend`. ## Automatic retry mechanism for failed communications Mambu applies a configurable retry policy for transient failures on email, SMS, and webhooks. - **Policy shape** Retries use an exponential backoff policy up to a configured limit. Exact retry counts, backoff intervals, and per-attempt timeouts are configured by Mambu and may change over time. - **Timeouts** The initial attempt uses a different (typically shorter) timeout than the following retry attempts (slow lane). - **Success criteria (webhooks)** Only HTTP `2xx` responses are considered success. Non-`2xx` responses, timeouts, and common network/TLS errors are treated as failures. - **Retryable conditions (examples)** - Transport exceptions such as connection issues, timeouts, and TLS/SSL handshake errors. - Channel-specific transient exceptions (for example, email or SMS provider transient errors). - HTTP status codes that are configured as retryable. The default set includes: - `401 Unauthorized` - `408 Request Timeout` - `429 Too Many Requests` - `500 Internal Server Error` - `502 Bad Gateway` - `503 Service Unavailable` - `504 Gateway Timeout` - **Non-retryable conditions** HTTP status codes outside the configured retryable set (for example `400`, `403`, `404`) are treated as permanent failures and are not retried automatically. ### Streaming API events Streaming delivery and cursor commits are handled by a dedicated pipeline with their own retry policies. Streaming is not retried or resent through the communication log and resend API described on this page. See also: - [Webhook best practices](/docs/webhooks-best-practices) - [Circuit breaker](/docs/webhooks-circuit-breaker) - [Troubleshooting](/docs/troubleshooting-webhooks) --- # Notifications overview URL: https://docs.mambu.com/docs/notifications-overview/ Mambu supports multiple ways to notify people or systems about important events: - [Email setup](/docs/email-setup) and [SMS setup](/docs/sms-setup) are used to communicate with people. - Mambu does not track whether or when end users view messages. - [Webhooks](/docs/webhook-notifications) and the [Streaming API](/docs/streaming-api) are used for system-to-system communication. - If you already use third-party messaging platforms, you can integrate using webhooks or the Streaming API - The Communication log in Mambu shows email, SMS, and webhook deliveries, including states, timestamps, and errors. Streaming is delivered via a separate pipeline and does not share the same resend/log flow. Notifications can be generated automatically (from business events) or initiated manually (for example, resending a failed delivery where supported). Most production traffic is event-driven. Below is an overview of the relevant documentation concerning the possible notification channels in Mambu: * [Event triggers](/docs/event-triggers): understand which events you can use to generate notifications. * [Managing notifications](/docs/managing-notifications): operate and diagnose notification delivery. * Email: [Email setup](/docs/email-setup), [Automated email notifications](/docs/automated-email-notifications) * SMS: [SMS setup](/docs/sms-setup), [Automated SMS notifications](/docs/automated-sms-notifications) * Webhooks: [Webhook notifications](/docs/webhook-notifications) * Streaming: [Streaming API](/docs/streaming-api) --- # Notification placeholders URL: https://docs.mambu.com/docs/notifications-placeholders/ Placeholders allow you to dynamically inject data into your notification templates (Email, SMS) and Webhook payloads. When a notification is triggered, Mambu replaces the placeholder with the actual value from the system. The example values on this page are illustrative only. The exact value returned by a placeholder depends on your data, configuration, product setup, and the event context. To verify the exact output for your use case, test the notification in your environment. * **Availability**: Placeholder availability depends on the selected event trigger and target. Not all placeholders are available for every event. * **Context**: Some placeholder meanings or values may depend on your product configuration, the event context, or the recipient type. * **Empty Values**: If a field has no value in Mambu (for example, an optional custom field that hasn't been filled), the placeholder will resolve to an empty string. For a full list of events that can trigger these notifications, see [Event triggers](/docs/event-triggers). ## Syntax Rules | Type | Syntax | Example | | :------------------------ | :--------------------------- | :------------------------------ | | **Standard Placeholders** | `` | ``, `` | | **Custom Fields** | `` | `` | | **Grouped Custom Fields** | `` | `` | ## Placeholder Reference ### Common, Identity, and Actor | Placeholder | Description | Expected values / Examples | Important notes | | :----------------------------- | :----------------------------------------------------------------------------- | :------------------------------------------------------------- | :--------------------------------------------------------------- | | `` | Full name of the client associated with the event. | Alex Morgan Taylor | | | `` | Human-readable ID of the client. | CL-1001 | | | `` | First name(s) of the client. | Alex | | | `` | Middle name(s) of the client. | Morgan | | | `` | Last name of the client. | Taylor | | | `` | Date of birth of the client. | 1988-12-09 | | | `` | Name of the group associated with the event. | Community Group A | | | `` | Human-readable ID of the group. | GRP-3001 | | | `` | The name of the Mambu user or staff member who typically triggered the action. | Integration User | For API-triggered actions, this may reflect the API user record. | | `` | The login or username of the Mambu user. | integration.user | Not the same as`USER_ID_NUMBER`. | | `` | The identification number associated with the user profile. | 1001 | | | `` | Typically the full name of the notification recipient. | Alex Morgan Taylor | The value varies depending on the recipient context. | | `` | First name(s) of the recipient. | Alex | | | `` | Middle name(s) of the recipient. | Morgan | | | `` | Last name of the recipient. | Taylor | | | `` | Human-readable ID of the recipient. | RC-2001 | | | `` | Mobile phone number of the recipient. | +44 7700 900000 | Can be empty if not provided. | | `` | Email address of the recipient. | alex.taylor@example.com | Can be empty if not provided. | | `` | Address line 1 of the recipient. | Example Street 10 | | | `` | Address line 2 of the recipient. | | | | `` | City of the recipient. | Berlin | | | `` | Region or state of the recipient. | | | | `` | Postal code of the recipient. | 2380 | | | `` | Country of the recipient. | | | | `` | Name of the branch associated with the account or client. | Main Branch | | | `` | Physical address of the branch. | 123 Mambu Way, Berlin | | | `` | Human-readable ID of the centre. | C-55 | | | `` | The day of the week for centre meetings. | Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday | | | `` | Current system date. | 2026-04-03 | | ### Account and Product | Placeholder | Description | Expected values / Examples | Important notes | | :------------------------ | :------------------------------------------------- | :------------------------------------------------------------ | :----------------------------------------------------------------------------------------------------------------- | | `` | Human-readable ID of the loan or savings account. | PDLB573 | | | `` | Name of the account. | Dynamic Loan Account | | | `` | Current state of the account. | `ACTIVE`, `PENDING APPROVAL`, `APPROVED`, `CLOSED`, `MATURED` | | | `` | Name of the product the account belongs to. | Dynamic Term Loan | | | `` | External ID of the account or entity. | EXT-5544 | | | `` | External reference ID associated with the account. | REF-9900 | | | `` | System encoded key of the related record. | 8a8f01ab23cd | The referenced entity depends on the event context (for example, account, transaction, or another related record). | | `` | The symbol of the currency. | €, $, £ | | | `` | The ISO code of the currency. | EUR, USD, GBP | | | `` | The symbol of the account currency. | €, $, £ | | | `` | The ISO code of the account currency. | EUR, USD, GBP | | ### Transaction and Balances | Placeholder | Description | Expected values / Examples | Important notes | | :------------------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------- | :-------------------------------------------------------------------- | | `` | Human-readable ID of the transaction. | TXN-10030 | | | `` | The amount of the transaction that triggered the event. | 900.00 | | | `` | Date and time when the transaction was created in Mambu. | 2026-03-17 11:11:49 | Not the same as`VALUE_DATE`, which is the effective date. | | `` | Type of the transaction. | `DEPOSIT`, `WITHDRAWAL`, `REPAYMENT`, `FEE`, `PENALTY_APPLIED` | | | `` | The method used for the transaction. | `Cash`, `Check`, `Bank Transfer` | Values depend on your transaction method configuration. | | `` | Comment or notes added to the transaction. | Monthly repayment | | | `` | The symbol of the transaction currency. | €, $, £ | | | `` | The ISO code of the transaction currency. | EUR, USD, GBP | | | `` | External reference ID of the transaction. | TX-EXT-1122 | | | `` | The total balance of the account after the transaction. | 900.00 | | | `` | The balance available on the account after the transaction. | 24.00 | Availability and calculation may depend on product and configuration. | | `` | The balance at the time the account was opened. | 0.00 | | | `` | The current principal balance of the account. | 1100.00 | | | `` | Total outstanding fees on the account. | 25.00 | | | `` | The tax amount applied to the transaction. | 5.50 | | | `` | The tax percentage applied. | 10.00 | | | `` | The credit amount of the transaction. | 100.00 | May be empty if the transaction is not of a credit type. | | `` | The debit amount of the transaction. | 50.00 | May be empty if the transaction is not of a debit type. | | `` | The original amount before adjustments or taxes. | 100.00 | | | `` | The date when the transaction becomes effective for interest. | 2026-03-17 12:11:49 | Preferred over`ENTRY_DATE`. | | `` | Deprecated placeholder for the effective transaction date. | 2026-03-17 12:11:49 | Use`VALUE_DATE` instead. | | `` | The date the transaction was booked in the ledger. | 2026-03-27 14:42:40 | | | `` | Indicates whether the transaction is an internal transfer. | Typically`Yes` or `No` | Exact representation can vary by notification context. | | `` | ID of a linked transaction (e.g., for reversals). | 1024 | | | `` | Date of the linked transaction. | 2026-03-16 | | ### Loan and Repayment | Placeholder | Description | Expected values / Examples | Important notes | | :----------------------------------- | :---------------------------------------------------------------------- | :------------------------------------------ | :--------------------------------------------------------------------------------------------------------- | | `` | The total amount of the loan. | 1111.00 | | | `` | Total number of installments for the loan. | 12 | | | `` | The interest rate of the loan account. | 5.5 | | | `` | The new interest rate after a rate change event. | 6.0 | | | `` | The date the loan was disbursed. | 2026-01-01 | | | `` | Scheduled date for loan disbursement. | 2026-01-10 | | | `` | Scheduled amount for loan disbursement. | 1111.00 | | | `` | Disbursement account or channel account used by the transaction. | Savings-123 | Depending on setup, this may refer to a linked account or another configured disbursement account/channel. | | `` | Typically the total remaining balance for the specific installment. | 50.68 | Usually includes principal, interest, fees, and penalties. | | `` | Typically the remaining principal balance for the specific installment. | 50.00 | | | `` | Typically the remaining interest balance for the specific installment. | 0.68 | | | `` | Typically the due date of the relevant installment. | 2026-05-05 | | | `` | Formatted repayment schedule or installment breakdown. | Installment list with due dates and amounts | Output depends on the notification rendering context. | | `` | The date the first installment is due. | 2026-02-01 | | | `` | Expected date when the account reaches maturity or completion. | 2027-01-01 | Typically relevant for products/accounts that have a maturity concept. | | `` | Principal portion of a transaction or installment. | 100.00 | | | `` | Interest portion of a transaction or installment. | 15.00 | | | `` | Fee portion of a transaction or installment. | 5.00 | | | `` | The type of fee. | `Disbursement`, `Late Repayment` | | | `` | The name of the fee. | `Processing Fee` | | | `` | Penalty portion of a transaction or installment. | 0.73 | | | `` | Principal amount currently due. | 0.00 | | | `` | Interest amount currently due. | 0.00 | | | `` | Fee amount currently due. | 0.00 | | | `` | Penalty amount currently due. | 0.00 | | | `` | Total amount currently due (Principal + Interest + Fees + Penalties). | 122.00 | | | `` | Total interest accrued on the account. | 45.50 | | | `` | Total penalties accrued on the account. | 10.00 | | | `` | Interest accrued during the transaction period. | 1.50 | | | `` | The amount available to be redrawn. | 0.00 | For revolving loan products. | | `` | The expected principal amount for a redraw. | 0.00 | | | `` | Amount paid in advance. | 0.00 | | | `` | Amount currently in arrears. | -12.85 | | | `` | Commission expected for the organization. | 10.00 | | | `` | Interest expected for funders. | 5.00 | | ### Savings and Overdraft | Placeholder | Description | Expected values / Examples | Important notes | | :--------------------------------------------------- | :------------------------------------------------------- | :------------------------- | :-------------- | | `` | Interest rate applied to overdrafts. | 12.0 | | | `` | Index rate used for overdraft interest calculation. | 2.5 | | | `` | Current amount due for an overdraft. | 150.00 | | | `` | Amount due for a technical overdraft. | 50.00 | | | `` | Negative interest accrued on the transaction. | 0.50 | | | `` | Overdraft interest accrued on the transaction. | 1.20 | | | `` | Technical overdraft interest accrued on the transaction. | 0.80 | | ### ID Documents | Placeholder | Description | Expected values / Examples | Important notes | | :-------------------------------- | :----------------------------------------------------- | :-------------------------------------------- | :-------------- | | `` | Typically the type of the identification document. | `Passport`, `National ID`, `Driver's License` | | | `` | Typically the identification number from the document. | SITE-1-105 | | | `` | Typically the authority that issued the document. | U.S. Department of State | | | `` | Typically the date the document expires. | 2029-07-11 | | ### Line of Credit, Authorization Hold, and Card | Placeholder | Description | Expected values / Examples | Important notes | | :------------------------------- | :----------------------------------------- | :------------------------------------------ | :----------------------------------------------------- | | `` | Human-readable ID of the line of credit. | LC-9988 | | | `` | The total approved credit limit. | 10000.00 | | | `` | The currently available credit. | 8500.00 | | | `` | The amount of credit already used. | 1500.00 | | | `` | The start date of the line of credit. | 2024-01-01 | | | `` | The expiration date of the line of credit. | 2025-01-01 | | | `` | The date the line of credit was approved. | 2023-12-15 | | | `` | The current state of the line of credit. | `Active`, `Closed`, `Expired` | | | `` | Notes or comments on the line of credit. | Standard terms apply | | | `` | External ID of the authorisation hold. | HOLD-5544 | | | `` | The state of the authorisation hold. | `Pending`, `Settled`, `Reversed`, `Expired` | | | `` | The amount held. | 100.00 | | | `` | The source of the authorisation hold. | `POS Terminal`, `E-commerce` | | | `` | The token representing the card used. | tkn_887766 | For security, Mambu never stores the full card number. | ### Journal Entry These placeholders are used with **Accounting** target events (for example, `JOURNAL_ENTRY_ADDED`). | Placeholder | Description | Expected values / Examples | Important notes | | :--------------------------------------- | :---------------------------------------------- | :------------------------- | :-------------- | | `` | Human-readable ID of the journal entry. | 44332 | | | `` | Date the entry was booked. | 2024-04-03 | | | `` | Date the entry was created in Mambu. | 2024-04-03 | | | `` | ID of the transaction that generated the entry. | 1025 | | | `` | ID of the General Ledger account. | 1001-001 | | | `` | The amount of the journal entry. | 150.00 | | | `` | Indicates if the entry is a Debit or Credit. | `DEBIT`, `CREDIT` | | | `` | Symbol of the entry currency. | $, €, £ | | | `` | ISO code of the entry currency. | USD, EUR, GBP | | | `` | Encoded key of the related account. | 8a818e897 | | | `` | Encoded key of the journal entry. | 8a818e898 | | | `` | Encoded key of the assigned branch. | 8a818e899 | | | `` | Notes associated with the journal entry. | End of day adjustment | | | `` | Encoded key of the related product. | 8a818e890 | | | `` | Type of the related product. | `LOAN`, `SAVINGS` | | | `` | Encoded key of the user who created the entry. | 8a818e891 | | ### Payment Order Activity Placeholders Some placeholder names are reused across payment-related notification families. The exact meaning and data source depend on the event context (for example, payment order activity, collection order activity, payment details, end-of-day, or data access). | Placeholder | Description | Expected values / Examples | Important notes | | :----------------------------------- | :-------------------------------------------------- | :--------------------------------- | :---------------------------------- | | `` | Current status of the order. | `COMPLETED`, `PENDING`, `REJECTED` | | | `` | ID of the transaction associated with the order. | txn-00423 | | | `` | Human-readable ID of the payment order. | order-51484 | | | `` | ID of the reversal transaction if applicable. | storno-32498 | | | `` | Code explaining why a transaction was rejected. | TJC125 | | | `` | Unique identification for the instruction. | instr-86492 | | | `` | End-to-end identification for the payment. | e2e-32424 | | | `` | Identification of the message containing the order. | msg-00957 | | | `` | The ultimate party that owes the money. | Alex Taylor | | | `` | Service level used for the payment (e.g., SEPA). | `SEPA` | | | `` | Name of the debtor. | Alex Taylor | | | `` | Name of the creditor. | Jordan Lee | | | `` | The ultimate party to whom the money is owed. | Jordan Lee | | | `` | ISO purpose code for the payment. | `SALA` | | | `` | Date requested for payment execution. | 2026-03-19 | | | `` | Time requested for payment execution. | 09:00:00 | | | `` | Identification of the instructed transaction. | TXN-9988 | | | `` | Date when the payment is settled. | 2026-03-19 | | | `` | Date when value is credited/debited. | 2026-03-19 | | | `` | Direction of the payment. | `INCOMING`, `OUTGOING` | | | `` | Product associated with the payment. | SEPA_CT | | | `` | IBAN of the debtor's account. | DE123... | | | `` | Identification of the debtor's account. | 987654321 | | | `` | Mambu ID of the debtor's account. | SAV-123 | | | `` | Account scheme for the debtor. | `IBAN` | | | `` | Currency of the debtor's account. | EUR | | | `` | BIC of the debtor's financial institution. | BANKDEHH | | | `` | Street address of the debtor. | Mambu St 1 | | | `` | Building number of the debtor. | 10 | | | `` | City of the debtor. | Berlin | | | `` | Postal code of the debtor. | 10115 | | | `` | ISO country code of the debtor. | `DE` | | | `` | Address line 1 of the debtor. | | | | `` | Address line 2 of the debtor. | | | | `` | IBAN of the creditor's account. | DE456... | | | `` | Identification of the creditor's account. | 123456789 | | | `` | Mambu ID of the creditor's account. | SAV-456 | | | `` | Account scheme for the creditor. | `IBAN` | | | `` | Currency of the creditor's account. | EUR | | | `` | BIC of the creditor's financial institution. | BANKDEBB | | | `` | Street address of the creditor. | Finance Ave 5 | | | `` | Building number of the creditor. | 20 | | | `` | City of the creditor. | Berlin | | | `` | Postal code of the creditor. | 10117 | | | `` | ISO country code of the creditor. | `DE` | | | `` | Address line 1 of the creditor. | | | | `` | Address line 2 of the creditor. | | | | `` | Currency of the instructed amount. | EUR | | | `` | The numeric amount instructed. | 150.00 | | | `` | Unstructured remittance information. | Payment for Invoice 123 | | | `` | Remittance reference number. | REF-123 | | | `` | Type of the remittance reference. | `SCOR` | | | `` | Issuer of the remittance reference. | Example Issuer | | | `` | Human-readable description of any errors. | Insufficient funds | | | `` | Technical error details. | (List of errors) | Typically used in webhook payloads. | ### Collection Order Activity Placeholders | Placeholder | Description | Expected values / Examples | Important notes | | :----------------------------------------- | :-------------------------------------------------- | :--------------------------------- | :---------------------------------- | | `` | Current status of the order. | `COMPLETED`, `PENDING`, `REJECTED` | | | `` | ID of the transaction associated with the order. | txn-00116 | | | `` | ID of the reversal transaction if applicable. | storno-51524 | | | `` | Human-readable ID of the collection order. | order-55724 | | | `` | Code explaining why a transaction was rejected. | TJC127 | | | `` | Unique identification for the instruction. | instr-12129 | | | `` | End-to-end identification for the payment. | e2e-12579 | | | `` | Identification of the message containing the order. | msg-00295 | | | `` | The ultimate party that owes the money. | Alex Taylor | | | `` | Name of the debtor. | Alex Taylor | | | `` | Name of the creditor. | Jordan Lee | | | `` | The ultimate party to whom the money is owed. | Jordan Lee | | | `` | Service level used for the payment (e.g., SEPA). | `SEPA` | | | `` | ISO purpose code for the payment. | `SALA` | | | `` | Date requested for payment execution. | 2026-03-19 | | | `` | Time requested for payment execution. | 09:00:00 | | | `` | Identification of the instructed transaction. | TXN-9988 | | | `` | Date when the payment is settled. | 2026-03-19 | | | `` | Date when value is credited/debited. | 2026-03-19 | | | `` | Direction of the payment. | `INCOMING`, `OUTGOING` | | | `` | Product associated with the payment. | SEPA_CT | | | `` | IBAN of the debtor's account. | DE123... | | | `` | Identification of the debtor's account. | 987654321 | | | `` | Mambu ID of the debtor's account. | SAV-123 | | | `` | Account scheme for the debtor. | `IBAN` | | | `` | Currency of the debtor's account. | EUR | | | `` | BIC of the debtor's financial institution. | BANKDEHH | | | `` | Street address of the debtor. | Mambu St 1 | | | `` | Building number of the debtor. | 10 | | | `` | City of the debtor. | Berlin | | | `` | Postal code of the debtor. | 10115 | | | `` | ISO country code of the debtor. | `DE` | | | `` | Address line 1 of the debtor. | | | | `` | Address line 2 of the debtor. | | | | `` | IBAN of the creditor's account. | DE456... | | | `` | Identification of the creditor's account. | 123456789 | | | `` | Mambu ID of the creditor's account. | SAV-456 | | | `` | Account scheme for the creditor. | `IBAN` | | | `` | Currency of the creditor's account. | EUR | | | `` | BIC of the creditor's financial institution. | BANKDEBB | | | `` | Street address of the creditor. | Finance Ave 5 | | | `` | Building number of the creditor. | 20 | | | `` | City of the creditor. | Berlin | | | `` | Postal code of the creditor. | 10117 | | | `` | ISO country code of the creditor. | `DE` | | | `` | Address line 1 of the creditor. | | | | `` | Address line 2 of the creditor. | | | | `` | Currency of the instructed amount. | EUR | | | `` | The numeric amount instructed. | 150.00 | | | `` | Unstructured remittance information. | Payment for Invoice 123 | | | `` | Remittance reference number. | REF-123 | | | `` | Type of the remittance reference. | `SCOR` | | | `` | Issuer of the remittance reference. | Example Issuer | | | `` | Identification of the direct debit mandate. | MAN-7788 | | | `` | Date the mandate was signed. | 2023-12-01 | | | `` | Sequence type of the collection. | `FRST`, `RCUR`, `FNAL`, `OOFF` | | | `` | Private identification of the creditor scheme. | ID-9988 | | | `` | Human-readable description of any errors. | Insufficient funds | | | `` | Technical error details. | (List of errors) | Typically used in webhook payloads. | | `` | Number of times the order has been retried. | 2 | | | `` | Date until which retries will be attempted. | 2026-03-25 | | ### Payment Details Placeholders Some placeholder names in this section are also used in payment order and collection order activity events. The exact meaning depends on the selected event family and notification context. | Placeholder | Description | Expected values / Examples | Important notes | | :----------------------------------------------------- | :--------------------------------------------------- | :------------------------- | :-------------- | | `` | Unique identification for the instruction. | instr-86492 | | | `` | End-to-end identification for the payment. | e2e-32424 | | | `` | Unique identification of the transaction. | txn-00423 | | | `` | Service level code for the payment. | `SEPA` | | | `` | Name of the debtor. | Alex Taylor | | | `` | BIC of the debtor agent. | BANKDEHH | | | `` | Currency of the debtor's account. | EUR | | | `` | IBAN of the debtor's account. | DE123... | | | `` | Alternative identification for the debtor account. | ACC-7766 | | | `` | Scheme for the alternative identification. | `Proprietary` | | | `` | Name of the creditor. | Jordan Lee | | | `` | BIC of the creditor agent. | BANKDEBB | | | `` | Currency of the creditor's account. | EUR | | | `` | IBAN of the creditor's account. | DE456... | | | `` | Alternative identification for the creditor account. | ACC-5544 | | | `` | Scheme for the alternative identification. | `Proprietary` | | | `` | Unstructured remittance information. | Payment for Invoice | | | `` | Structured remittance reference. | REF-9900 | | | `` | Issuer of the structured reference. | Example Issuer | | | `` | Type of the structured reference. | `SCOR` | | ### Administrative These placeholders are used with **Administrative** target events (for example, `HOLIDAY_SYNC_COMPLETED`). | Placeholder | Description | Expected values / Examples | Important notes | | :---------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------- | :--------------------------------------- | | `` | The unique ID assigned to the background task. | | | | `` | The final result of the holiday update. Indicates whether the installment rescheduling triggered by the holiday update finished. | `SUCCESS`, `FAILED` | | | `` | A human-readable description of the error that caused the sync to fail. | | Empty when `` is `SUCCESS`. | | `` | A machine-readable JSON array containing the encoded keys of the specific accounts that failed to update. Useful for automated retries. | `["encodedKey1", "encodedKey2"]` | Empty when `` is `SUCCESS`. | ### Activity, End of Day, and Data Access Some placeholder names are reused across technical event families. Their meaning depends on the event context (for example, End of Day processing vs. Data Access state changes). | Placeholder | Description | Expected values / Examples | Important notes | | :-------------------- | :--------------------------------------------- | :-------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- | | `` | The type of activity that triggered the event. | `CLIENT_CREATED`, `LOAN_CREATED`, `SAVINGS_DEPOSIT` | | | `` | The start date of the period or process. | 2026-03-01 | | | `` | The end date of the period or process. | 2026-03-31 | | | `` | End of Day process state. | `RUNNING`, `COMPLETED`, `FAILED` | For End of Day events, this reflects the End of Day execution state. | | `` | Data access mode state. | `READ_WRITE`, `READ_ONLY` | For Data Access events, this reflects database access mode changes. | | `` | Current system date and time. | 2026-04-03 16:52 | | | `` | URL for password reset or portal activation. | `https://...` | | | `` | System encoded key of the related record. | 8a8f01ab23cd | The referenced entity depends on the event context; commonly used in End of Day and other technical event families where available. | ## Custom Fields You can use placeholders for your own custom fields. ### Standard Custom Fields To include a standard custom field, use the syntax: `` Where `FIELD_ID` is the unique ID of the custom field (not the label). ### Grouped Custom Fields To include a field that is part of a grouped custom field set, use the syntax: `` * **ENTITY**: The Mambu entity the field belongs to (`CLIENT`, `GROUP`, `LOAN`, `SAVINGS`, or `USER`). * **FIELD_ID**: The unique ID of the custom field. * **INDEX**: The position of the value in the grouped set (starting from `1`). **Example**: `` :::note Placeholder availability depends on the selected event and notification context. Always verify that the data you want to include is available for the event trigger you are using. ::: --- # Troubleshoot delayed notification dispatch URL: https://docs.mambu.com/docs/notifications-troubleshooting-delayed-notifications/ This page explains why notifications may sometimes be dispatched with a delay, depending on the notification channel (webhooks, email, or SMS). ## Overview Mambu’s notification system is designed to handle high volumes of messages. To maintain stability and ensure reliable delivery, notifications are placed in a processing queue before being dispatched. While most notifications are sent almost immediately, delays can happen for different reasons depending on the channel. ## Webhooks: delays due to retries or high volume Webhook dispatch is available 24/7. However, several factors can lead to a temporary backlog in the queue: ### High notification volume During periods of exceptionally high notification volume—for example, when a very large number of events are triggered in a very short time—a temporary backlog can form. Notifications will wait longer in the queue before being picked up for dispatch. ### Impact of slow or unresponsive endpoints If a significant portion of recipient endpoints are slow, unavailable, timing out, or returning retryable non-2XX responses, the system will retry delivery automatically. * **Automated Retries**: The system attempts delivery up to four times in total (one initial attempt and three retries). * **Increasing Delays**: These retries are scheduled with increasing delays between attempts to allow the destination time to recover. * **Capacity Consumption**: While the system manages these automated retries, a portion of the available processing capacity is dedicated to those attempts. As a result, other notifications in the queue may wait longer before they are picked up for dispatch. :::info During periods of exceptionally high notification volume, if a significant portion of recipient endpoints are slow or unresponsive, the system’s automated retry logic may temporarily consume available processing capacity, leading to a longer wait time for other messages in the queue. This is most visible during significant traffic bursts. ::: ## Email and SMS: daily dispatch window To ensure predictable delivery timing, Email and SMS notifications are dispatched daily during a window of **09:00 to 18:00**, based on your organization’s configured timezone. This dispatch window applies only to Email and SMS; webhooks are not subject to this restriction and continue to be dispatched immediately 24/7. * **Outside the window**: If Email or SMS notifications are generated outside this window, they are held in a queue and picked up for dispatch once the next 09:00 to 18:00 window opens. * **Resumption delay**: If a large volume of notifications accumulates while the window is closed, they are processed in batches when dispatching resumes. This may result in a short additional delay before all messages are sent. ## What you should check on your side If you experience delays, we recommend investigating your infrastructure and observability data. ### Implement a queue-based intake pattern To ensure the fastest possible delivery, your webhook receiver should return an HTTP **2xx** response as quickly as possible. We recommend the following pattern: 1. Receive the HTTP call. 2. Persist or store the event quickly on your side (for example, in a database or message queue). 3. Return a success status (200 or 202) immediately. 4. Process the payload asynchronously afterward in a separate worker flow. ### Maintain operational visibility Observability is essential for understanding your integration's performance. You should have full visibility into: * **Endpoint Latency**: Monitor average and tail (P95/P99) response times. * **Success and Error Rates**: Track spikes in non-2xx responses or timeouts. * **Incoming Load**: Understand the volume of notifications your systems are receiving. ### Investigate network and endpoint behavior If some notifications arrive successfully while others using the same network path appear to be "missing" or delayed: * **Review the full request path**: Investigate your load balancers, proxies, firewalls, and WAF logs. * **Correlate timestamps**: Compare Mambu's Communications log timestamps with your own application and infrastructure logs. * **Evaluate endpoint responsiveness**: If requests using the same network route succeed intermittently, we recommend reviewing your infrastructure logs to identify any transient endpoint responsiveness or local network issues. ## When to contact Support If you have verified your endpoint performance and logs but still cannot identify the cause of persistent delays: 1. Collect the following evidence: - **Channel** (Email, SMS, Webhook). - **Notification IDs** from the Communications log. - **Timestamps** of the affected notifications. - **Relevant logs or metrics** from your side showing endpoint responsiveness. 2. Open a case with Mambu Support and provide the gathered details to help the team correlate your findings with system telemetry. --- **See also:** * [Troubleshoot failed notifications](/docs/troubleshooting-failed-notifications/) * [Webhook best practices](/docs/webhooks-best-practices) * [Circuit breaker](/docs/webhooks-circuit-breaker) --- # Troubleshoot Email and SMS Failures URL: https://docs.mambu.com/docs/notifications-troubleshooting-email-and-sms-setup/ When you configure email or SMS in Mambu Administration, you usually send a test message to confirm that the setup works. Sometimes this test fails without a clear message in the UI. This page explains: - A common external cause (for example, Gmail app passwords). - How to use the **Communications** view in Mambu to see the exact reason why the test email or SMS failed. This page applies to: - **Email** configuration tests (SMTP / email provider setup). - **SMS** configuration tests (SMS provider / gateway setup). It focuses on failures that occur when you press the **Test configuration** button in Mambu Administration and: - No test message arrives at the inbox/phone, and - The message appears as **Failed** in the Communication log. ## Step 1 – Check common provider requirements (Gmail app passwords) Many email providers have additional security requirements. A frequent example is Gmail or Google Workspace accounts. For Google accounts: - If 2-Step Verification is enabled on the account, regular passwords often cannot be used directly by external apps like Mambu. - In this case, Google requires an App password – a 16-digit code created specifically for the external app. - The app password is used instead of your normal account password in the Mambu Email configuration. For detailed instructions, see your email provider’s documentation. For Gmail, you can search for “Gmail app passwords” or refer to Google’s help page, for example: `https://support.google.com/mail/answer/185833?hl=en` If your provider requires app passwords or special SMTP settings, and they are not configured correctly in Mambu, the test message will fail with an authentication or connection error. The next section shows how to see that error inside Mambu. ## Step 2 – Make sure the Communications view is available To inspect the technical error for a failed setup test, you must access the **Communications** view. If you already see a **Communications** item in the top navigation bar, you can skip to the next step. ### 2.1 Add a new Communications view (if missing) 1. Go to **Administration > Views**. 2. Click the green **+** button to create a new view. ![notifications-troubleshooting-setup-communications-add-view-01](/img/support/notifications-troubleshooting-setup-communications-add-view-01.png) 3. In the dialog: - Set **Type** to **Communications**. - Give it a meaningful name, for example `LightWeightCommunication`. ![notifications-troubleshooting-setup-communications-add-view-02](/img/support/notifications-troubleshooting-setup-communications-add-view-02.png) 4. Assign the appropriate **permissions / roles** so that the users who need to troubleshoot notifications can access this view. 5. Save the changes. After saving, the new **Communications** view (for example, **LightWeightCommunication**) appears in the top horizontal navigation bar of the Mambu UI. ## Step 3 – Filter for the test email or SMS notification Now you can locate the test notification generated by your configuration test. 1. Click the **LightWeightCommunication** (or the name you chose) view in the top navigation bar. ![notifications-troubleshooting-setup-communications-open-view-01](/img/support/notifications-troubleshooting-setup-communications-open-view-01.png) 2. At the top of the page, open the filter dropdown labeled **No filter** and choose **Custom filter…**. ![notifications-troubleshooting-setup-communications-custom-filter-01](/img/support/notifications-troubleshooting-setup-communications-custom-filter-01.png) 3. In the filter dialog: - Set **Type** to **Email** or **SMS**, depending on which configuration you tested. - Set **State** to **Failed**. - Restrict the **Creation date** (or similar date field) to **Today** (or the date and time window when you pressed the test button). ![notifications-troubleshooting-setup-communications-custom-filter-02](/img/support/notifications-troubleshooting-setup-communications-custom-filter-02.png) 4. Click **Apply**. The dialog closes and the view refreshes to show only the notifications that match your filter. The failed test notification from your email/SMS configuration test should now be visible in the list. ## Step 4 – Add Failure Reason and Failure Details columns To understand *why* the setup failed, you need to see the diagnostic fields. 1. Click the green **Edit columns** button. ![notifications-troubleshooting-setup-communications-edit-columns-01](/img/support/notifications-troubleshooting-setup-communications-edit-columns-01.png) 2. In the dialog: - Enable **Include timestamps**. - Add the following columns (search by name if needed): - **Failure Reason** - **Failure Details** ![notifications-troubleshooting-setup-communications-edit-columns-02](/img/support/notifications-troubleshooting-setup-communications-edit-columns-02.png) 3. Click **Apply changes**. The dialog closes and the grid refreshes. The list is typically sorted so that the **most recent** notification (including your latest test) appears at the top. Locate the most recent failed notification that matches the time you pressed the **test configuration** button. ## Step 5 – Interpret the error for email and SMS setup Now use the **Failure Reason** and **Failure Details** to understand what went wrong with your setup. Typical patterns: ### 5.1 Authentication and credential issues Common examples: - **Failure Reason**: something like `INVALID_SMTP_CREDENTIALS`, `INVALID_SMS_GATEWAY_CREDENTIALS`, or a provider-specific credential error. - **Failure Details**: may mention “authentication failed”, “invalid username or password”, “invalid token”, or a provider error code. What to check: - SMTP or SMS provider username, password, token, or API key. - For Gmail / Google Workspace: - Confirm whether 2-step verification is enabled. - If yes, ensure you are using a valid app password for Mambu, not your normal account password. - Verify that the server host, port, and encryption settings (TLS/SSL) match the provider’s documentation. ### 5.2 Channel or service disabled Examples: - **Failure Reason**: `EMAIL_SERVICE_NOT_ENABLED`, `SMS_SERVICE_NOT_ENABLED`, or similar. - **Failure Details**: message indicating the channel is disabled. What to check: - In **Administration > Notifications > Email / SMS**, verify that: - The channel is **Enabled**. - Any required provider credentials are configured. - If you cannot access this area, contact an internal administrator with the necessary permissions. ### 5.3 Recipient / destination issues Even for a configuration test, Mambu needs a valid destination: - **Failure Reason**: `UNDEFINED_DESTINATION`, `MISSING_EMAIL_RECIPIENT`, `MISSING_SMS_RECIPIENT`, or a provider error indicating invalid address/number. - What to check: - The **Test recipient email** is valid and properly formatted. - The **Test phone number** is present and uses the correct international format (for example, `+`). - The test “To” address/number used in the configuration matches the expected field. ### 5.4 Provider and network errors Sometimes the configuration is correct, but the provider or network is having issues: - **Failure Reason**: generic provider error or `MESSAGING_EXCEPTION` / `SMS_GATEWAY_ERROR`. - **Failure Details**: contains an error code or message from the email/SMS provider (for example, throttling, blocked sender ID, invalid region). What to do: - Check the provider’s **status page** or dashboard for reported incidents. - Use the error code/message from **Failure Details** in the provider’s documentation. - Try again later or contact the provider’s support if the error persists. ## Next steps If you still cannot resolve why the email or SMS configuration test fails: 1. Capture: - A screenshot of the **Email / SMS configuration** page in Mambu (with sensitive data masked). - A screenshot or export of the **failed notification** row from the Communications view, including **Failure Reason** and **Failure Details**. 2. Note: - The **tenant name** / environment. - The approximate **timestamp** when you pressed the test button. 3. Open a support case with Mambu for the Notifications team and include the above details. This information allows the support team to correlate your configuration with internal logs and identify the root cause of the failed setup. --- # Troubleshoot Failed Notification Sending URL: https://docs.mambu.com/docs/notifications-troubleshooting-failed-notifications/ This page helps you understand why a notification failed after it was created. Use this guide when you can see a notification in the communication log, but its status is Failed. ## Scope This page applies to email, SMS, and webhooks that appear in the communication log. It focuses on notifications that were created but could not be delivered to the recipient or provider. :::note Event Streaming uses a separate delivery pipeline and is not managed through the same communication log or resend flow. ::: ## Find failed notifications To investigate failures, you must first locate the specific notification in the **Communications** tab (either at tenant level or on a specific client/account/group). 1. In the Mambu UI, open the **Communications** tab. ![notifications-troubleshooting-not-triggered-client-failed_notification-01](/img/support/notifications-troubleshooting-not-triggered-client-failed_notification-01.png) 2. To see the technical details of the failure, customize your view: 1. Click on **Edit Columns**. 2. Check the **Include timestamps** checkbox. 3. Add the following columns: - **Creation Timestamp** - **Failure Reason** – high-level error category. - **Failure Details** – short technical snippet (for example, HTTP status, provider error message, or exception text). ![notifications-troubleshooting-not-triggered-client-failed_notification-02](/img/support/notifications-troubleshooting-not-triggered-client-failed_notification-02.png) 3. Locate the failed notification: 1. Find the row where **State** is `Failed`. 2. Click on it to open the full content. 3. Review the **payload**, **destination**, and **Failure Details** to understand what went wrong. ![notifications-troubleshooting-not-triggered-client-failed_notification-03](/img/support/notifications-troubleshooting-not-triggered-client-failed_notification-03.png) 4. If there are many notifications, apply filters to narrow down the search: 1. Click the filter icon in the **Communications** tab. ![notifications-troubleshooting-not-triggered-client-failed_notification-04](/img/support/notifications-troubleshooting-not-triggered-client-failed_notification-04.png) 2. Create a filter based on criteria such as: - **State = Failed** - **Channel** (Email, SMS, Webhook) - **Creation Timestamp** range - **Template** or **Type** ![notifications-troubleshooting-not-triggered-client-failed_notification-05](/img/support/notifications-troubleshooting-not-triggered-client-failed_notification-05.png) 3. Set small time ranges – for example, one hour at a time – on tenants with a high volume of notifications to avoid heavy queries. Move through results in small time chunks until you locate the notification. ## How to use Failure Reason and Failure Details For every failed notification, Mambu stores: - **Failure Reason** – a short, categorized error code (for example, `INVALID_HTTP_RESPONSE`, `BLACKLISTED_URL`, `UNDEFINED_DESTINATION`). - **Failure Details** – a short text describing the technical cause (for example, `HTTP 404 Not Found`, provider error message, or exception snippet). Very long messages may be truncated. Together, these two fields tell you whether the problem is: - **Transient**: a network/provider issue, often retried automatically. - **Permanent**: a configuration, credentials, or data issue, requiring fixing settings or data. ## Investigate failures by channel Mambu uses the same concepts across channels, but the typical failures differ per channel: * [Webhook failures](#webhook-failures) * [Email failures](#email-failures) * [SMS failures](#sms-failures) ### Webhook failures Only HTTP 2xx responses are considered successful. Anything else results in a failure with a mapped Failure Reason. Below are common webhook-related reasons and what to do next: | Failure Reason | What it means (high level) | Recommended action | | :-------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **INVALID_HTTP_RESPONSE** | The destination endpoint returned a non-2xx HTTP status (for example`400`, `401`, `404`, `500`). The status code and (truncated) response body are stored in **Failure Details**. | Open the notification details and check**Failure Details** for the exact status code and response body. Fix the underlying issue on your endpoint (for example, incorrect URL, missing or invalid data, server error). | | **HTTP_ERROR_WHILE_SENDING** | A network-level or transport error occurred while sending the request (for example, DNS issue, connection refused, TLS handshake problem, timeout). | Verify that your endpoint is reachable from the public internet, responds within the configured timeout, and has a valid TLS certificate. Check your own logs for matching incoming attempts or failed connections. | | **BLACKLISTED_URL** | Mambu blocked the request because the URL is on a restricted/blacklisted range (for example, internal or private IPs, loopback). | Use a public, allow-listed URL (for example, through an API gateway or reverse proxy). If you need to call internal services, place an authorized endpoint in front of them. | | **INVALID_HTTP_PROTOCOL** | The URL uses a protocol that is not allowed by your environment (for example,`http://` instead of `https://`). | Update the webhook URL to use`https://`. If you believe `http://` should be supported for your environment, contact Mambu Support to discuss options. | | **MAX_MESSAGE_SIZE_LIMIT_EXCEEDED** | The serialized webhook payload is larger than the configured maximum message size. | Simplify the template payload (remove unnecessary fields or very large custom data) or adjust upstream logic so the payload size is smaller. | | **WEBHOOK_NOTIFICATIONS_DISABLED** or similar | The Webhook channel is globally disabled in Mambu settings. | Go to**Administration → Notifications → Webhooks** (or equivalent configuration) and ensure the channel is enabled. If you do not manage this configuration, contact your internal administrator. | | **UNDEFINED_DESTINATION** | No valid URL could be determined for the notification. | Check the template configuration to ensure the**Webhook URL** is populated and that any placeholders resolve to a valid URL. | :::tip For webhooks, always cross-check your own endpoint logs around the Creation Timestamp of the failed notification to see if the request reached your system and how it was handled. ::: ### Email failures Email notifications depend on a working SMTP configuration and valid recipient addresses. Common failure reasons: | Failure Reason | What it means | Recommended action | | :------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **EMAIL_SERVICE_NOT_ENABLED** (or equivalent) | The email channel is disabled at organization level. | Check**Administration → Notifications / Email Settings** and make sure email sending is enabled. | | **INVALID_SMTP_CREDENTIALS** (or similar) | Mambu could not authenticate with your email provider (wrong username/password, token, or host). | Verify SMTP host, port, username, password, and security settings in**Administration → Email Settings**. | | **MESSAGING_EXCEPTION** / provider error | A transient error happened between Mambu and the email provider (for example, provider outage, temporary rejection). | Review**Failure Details** for the provider message. If it looks transient, try resending later. If it persists, check your provider’s status page or contact their support. | | **UNDEFINED_DESTINATION** / **MISSING_EMAIL_RECIPIENT** (exact naming may vary) | No valid email address is available for the recipient. | Open the client/group/user profile and ensure**Email Address** is present, valid, and not blocked by your provider. | | **INVALID_EMAIL_ADDRESS** (if exposed) | The email address format is invalid or rejected by the provider. | Correct the recipient’s email field to use a valid format (for example,`name@example.com`). | :::note Automated retries typically apply to transient provider/network errors (for example, `MESSAGING_EXCEPTION`). Permanent issues like invalid credentials or missing recipients require configuration or data fixes. ::: ### SMS failures SMS notifications depend on a configured SMS provider (for example, Twilio) and valid mobile numbers. Common failure reasons: | Failure Reason | What it means | Recommended action | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **SMS_SERVICE_NOT_ENABLED** (or equivalent) | The SMS channel is disabled at organization level. | Check**Administration → Notifications / SMS Settings** and ensure SMS sending is enabled. | | **INVALID_SMS_GATEWAY_CREDENTIALS** / provider auth error | Mambu cannot authenticate with your SMS provider (invalid API key/SID/token). | Verify credentials and configuration in**Administration → SMS Settings**. | | **SMS_GATEWAY_ERROR** / provider error | The SMS provider rejected the message (for example, forbidden destination, unsupported country, throttling). | Inspect**Failure Details** for the provider’s error code and message. Use your provider’s documentation to interpret it and adjust sender ID, routing, or limits. | | **UNDEFINED_DESTINATION** / **MISSING_SMS_RECIPIENT** | No valid mobile number was found for the recipient. | On the client/group profile, ensure**Mobile Phone 1** is filled in and uses the correct international format (for example, `+`). | | **INVALID_PHONE_NUMBER** (if exposed) | The number format is invalid according to the SMS provider. | Correct the stored phone number to use a valid international format. | :::tip If SMS failures are widespread and recent, first check whether provider credentials or configuration were changed around the same time. ::: ## Transient vs. permanent failures and retries Mambu uses a retry policy to automatically re-attempt delivery for many transient errors. While implementation details (such as timeout values or retry counts) are configuration-driven and may change, you can think in terms of: - **Usually retried (transient):** - Delivery delays due to queueing or processing capacity (see [Troubleshoot delayed notifications](/docs/troubleshooting-delayed-notifications)). - Network / transport errors (`HTTP_ERROR_WHILE_SENDING`). - Provider temporary errors (for email/SMS). - Some non-2xx HTTP responses that indicate rate limiting or temporary unavailability (for example, `429`, `5xx`), depending on configuration. - **Not retried (permanent until fixed):** - Misconfiguration in Mambu (the channel is disabled, invalid credentials). - Invalid or missing destination (`UNDEFINED_DESTINATION`, missing email or mobile). - Business or authorization errors from your endpoint (for example, `401`, `403`, `404` plus provider-specific “invalid address” or “forbidden” messages). - Security-related blocks such as `BLACKLISTED_URL` or invalid protocol. If a notification remains in a Failed state after retries, the underlying cause must be addressed before further attempts will succeed. ## Next steps If you still cannot identify or fix the issue after following the steps above: 1. Collect the following information: - **Channel** (Email, SMS, Webhook). - **Template name / ID** (if applicable). - **Notification ID** (encoded key) from the communication log. - **Recipient ID** (client/account/group ID). - **Creation Timestamp** and **Failure Reason / Failure Details** from the log. 2. Export or screenshot the relevant row from the **Communications** tab. 3. Open a case with Mambu Support for the Notifications team and include all the above details. This context helps the team quickly correlate your tenant logs with internal telemetry and identify the root cause. --- # Troubleshoot Failed Notification Triggers URL: https://docs.mambu.com/docs/notifications-troubleshooting-notifications-not-generated/ This page helps you understand why a notification was not generated at all; for example, when you expected an email, SMS, webhook, or streaming event, but no entry appears in the communication log or downstream system. ## Scope This page applies to all notification channels and focuses on cases where no notification record was created: - [Email](/docs/email-setup) - [SMS](/docs/sms-setup) - [Webhooks](/docs/webhooks-overview) - [Event streaming](/docs/streaming-api) :::note If a notification was created but failed to be delivered, see [Troubleshoot failed notifications](/docs/troubleshooting-failed-notifications/). ::: There is no single rule of thumb for “no notification generated” issues. Notification creation depends on: - Template configuration - Subscriptions - Channel settings - Feature toggles - Entity data at the time of the event To identify the root cause, refer to the scenario below: * [Target, event, and filters do not match the action](#target-event-and-filters-do-not-match-the-action) * [Opt-out subscriptions are still processing in the background](#opt-out-subscriptions-are-still-processing-in-the-background) * [The entity is unsubscribed or the template/channel is disabled](#the-entity-is-unsubscribed-or-the-templatechannel-is-disabled) * [Additional checks for email and SMS](#additional-checks-for-email-and-sms) * [Advanced scenarios (less common but possible)](#advanced-scenarios-less-common-but-possible) ## Target, event, and filters do not match the action A notification is only created when the system finds an **Active** template where **all** the following match: 1. **Target** The template’s target (for example, Client, Group, Loan account, Deposit account, Payment order, Accounting) must match the entity involved in the event. 2. **Event trigger** The template’s event (for example, *Loan Repayment*, *Loan Fee Applied*, *Deposit*, *Client Created*) must match the actual event that occurred. 3. **Conditions (filters)** If the template has additional conditions (field / operator / value), they are evaluated at the moment of the event. If they evaluate to `false`, no notification is created. If any of these do **not** match, the system simply skips message creation. In that case: - No `NotificationMessage` is created. - Nothing appears in the Communications log. - The template may remain in a **Not in use** state because it never successfully triggered. ![notifications-troubleshooting-not-triggered-webhook-create_webhook-01](/img/support/notifications-troubleshooting-not-triggered-webhook-create_webhook-01.png) **How to check this** 1. Open the template and verify: - **Target** matches the type of entity you tested on. - **Event** matches the action you performed. - **Conditions** match the entity’s actual data at the time the event fired (for example, product, status, balance, branch). 2. On the entity (client, account, group, etc.), review the latest activity to confirm that: - The event you expected really occurred. - Relevant fields had the values required by the template conditions. ![notifications-troubleshooting-not-triggered-client-viewing_account-01](/img/support/notifications-troubleshooting-not-triggered-client-viewing_account-01.png) If the event or field values do not match the template configuration, no notification will be generated. ## Opt-out subscriptions are still processing in the background For templates that use the **Opt-out** subscription option, Mambu automatically subscribes existing eligible entities in the background. - For small tenants, this completes quickly. - For large tenants (tens or hundreds of thousands of entities), this may take longer and is handled by background tasks. Until the background subscription job processes a specific client/account/group: - That entity is not yet subscribed, and - No notification will be generated for that entity, even if the template configuration is otherwise correct. When you first save such a template, the UI shows a progress indicator for the subscription job: ![notifications-troubleshooting-not-triggered-webhook-create_template-02](/img/support/notifications-troubleshooting-not-triggered-webhook-create_template-02.png) **How to check this** - If you just created or changed an Opt-out template, wait for the background process to finish. - For large tenants: - Try again after some time. - Check a few different clients/accounts to see whether notifications are gradually starting to appear. - If you suspect the process is stuck, gather the template ID and tenant details and contact Mambu Support. ## The entity is unsubscribed or the template/channel is disabled This candidate covers scenarios where notifications used to be generated and suddenly stopped for some entities or completely. ### The client or account is unsubscribed Even if the template is active and correctly configured, no notification is created if the specific entity is not subscribed. 1. Open the Client or Account where you expected the notification: ![notifications-troubleshooting-not-triggered-client-subscription-01](/img/support/notifications-troubleshooting-not-triggered-client-subscription-01.png) 2. Select **More > Set Notifications**: ![notifications-troubleshooting-not-triggered-client-subscription-02](/img/support/notifications-troubleshooting-not-triggered-client-subscription-02.png) 3. In the pop-up, look for the row that matches: - The **event** (for example, *Loan Repayment*, *Deposit*, *Client Approved*), and - The **channel** (Email, SMS, Webhook). If the checkbox is unchecked, the entity is unsubscribed and no notification will be generated for that event/channel. ![notifications-troubleshooting-not-triggered-client-subscription-03](/img/support/notifications-troubleshooting-not-triggered-client-subscription-03.png) **Recommendation** - Check the relevant checkbox to subscribe the entity to that notification, then **Save changes**. - Keep in mind: - Subscription / unsubscription operations are currently not shown in the **Latest activity** column. - If you suspect an unintended subscription change, use your internal audit processes and, if needed, contact Mambu Support with template ID, entity ID, and time window. ### The template is inactive If the entity is correctly subscribed but the template itself is *Inactive, no notification will be generated. To verify: 1. Go to **Administration**. 2. Open the relevant channel area: - **Email > Templates** - **SMS > Templates** - **Webhooks > Templates** - **Streaming** (for event streaming templates) 3. Search for your template by name. ![notifications-troubleshooting-not-triggered-client-subscription-04](/img/support/notifications-troubleshooting-not-triggered-client-subscription-04.png) 4. Check the **Status** or **State** column: - **Active**: template can generate notifications (if all other conditions are met). - **Inactive**: template will not generate any notifications. ![notifications-troubleshooting-not-triggered-client-subscription-05](/img/support/notifications-troubleshooting-not-triggered-client-subscription-05.png) **Recommendation** - If the template should still be in use, activate it via the **Actions** menu. - Internally confirm who deactivated it and why, to avoid surprises later. ### The channel is disabled at the organization level Even if: - The template is Active, and - The entity is correctly subscribed, notifications will not be generated if the corresponding channel is disabled in global settings. Examples (exact labels may vary by environment): - **Email**: email sending disabled or no provider configured. - **SMS**: The SMS channel disabled or provider credentials are missing. - **Webhooks/Streaming**: specific feature toggles for streaming or webhooks not enabled. If the channel is globally disabled, the logic may skip message creation for that channel. **Recommendation** - Ask your Mambu admin to verify: - Email settings for your environment. - SMS configuration and enablement. - Webhook / Streaming feature toggles where applicable. - If you recently changed any global settings, test after re-enabling the channel. ## Additional checks for email and SMS For **Email** and **SMS**, a common reason for “no notification created” is a missing or invalid destination. 1. Open the client or account where you expected the SMS or email: ![notifications-troubleshooting-not-triggered-client-missing_email-01](/img/support/notifications-troubleshooting-not-triggered-client-missing_email-01.png) 2. Verify that the relevant contact fields are correctly populated, for example: - For email: - The **Email Address** is populated with a valid email address. - For SMS: - **Mobile Phone 1** is populated with a valid phone number (this is typically the field used for SMS dispatch). ![notifications-troubleshooting-not-triggered-client-missing_email-02](/img/support/notifications-troubleshooting-not-triggered-client-missing_email-02.png) If these fields are empty or invalid, notification creation is skipped for that entity, even if the template configuration is otherwise correct. If you see two fields with the same name, one is usually a custom field and the other is a native field. Make sure you write the information into the correct field. Even with similar names, our system will generate a notification only if the native field contains the information. :::tip Make sure your onboarding and data-quality processes keep **Email** and **Mobile Phone 1** populated for all customers that should receive notifications. ::: ## Advanced scenarios (less common but possible) If none of the above candidates explain the behavior, consider these more advanced cases: - **Feature toggles**: Feature toggles protect some events and channels (for example, specific authorization hold events, streaming, or advanced dispatch flows). If a toggle is turned off, notifications for those events will not be generated. - **Target mismatch for group vs members**: Certain targets (for example, Groups) send notifications only to the group entity, not to each member—unless explicitly modeled that way in your setup. - **Entity life cycle**: For some actions, the entity might be transitioned or deleted as part of the operation. In such cases, notifications may be skipped or routed differently depending on your configuration. - **Template still “Not in use”**: A template marked as “Not in use” simply means it has never actually produced a notification yet. This is a symptom rather than a cause, but it confirms that no event/template/condition combination has matched so far. If you suspect any of these, capturing precise details (template ID, entity ID, event type, and timestamp) will help Support validate behavior against logs. ## Next steps If you have gone through these candidates and still do not see notifications being created: 1. Collect the following information: - Template name and ID. - Channel (Email, SMS, Webhook, Streaming). - Tenant and environment (for example, sandbox vs. production). - Entity IDs (client ID, account ID, group ID, etc.). - The exact time window when you triggered the event. - A short description of the action you performed in Mambu (for example, “posted a repayment of X on loan Y”). 2. Check internally whether: - Anyone changed template configuration, subscriptions, or global channel settings. - Any related feature toggles were recently enabled/disabled. 3. Submit a ticket to Mambu Support and mention that it is for the Notifications team, including all the above details. This will significantly speed up the investigation and help us determine whether the notification was skipped due to configuration, subscriptions, data, or a platform issue. --- # Using Okta as your Identity Provider (IdP) URL: https://docs.mambu.com/docs/okta-as-idp/ ## Setting up federated authentication with Okta If you are using Okta, you can find Mambu as an approved app within Okta. For easy setup, please [go to the Okta integration network](https://www.okta.com/resources/find-your-apps/?keywords=Mambu) and search for Mambu. To manually setup federated authentication with Okta, please follow the step-by-step guide below. ### Setup in Okta 1. Sign in to [Okta](https://developer.okta.com/) with an admin account and navigate to **Applications** > **Add Application** > **Create App Integration**. 2. Create a new SAML 2.0 application. ![create saml 2 app](@site/static/img/support/users-and-access-control--create-a-new-app-integration.png) 3. Go to **General Settings** and enter an **App name** for the Okta SAML 2.0 application. ![create saml integration](@site/static/img/support/users-and-access-control--create-saml-integration-general-settings.png) 4. In the **Configure SAML** tab select **Show Advanced Settings**. When configuring the IdP please be sure to correctly configure Mambu Service Provider (SP) URL’s: For Login: `https://TENANT_NAME.mambu.com/saml/login` or `https://TENANT_NAME.env.mambu.com/saml/login` For Logout: `https://TENANT_NAME.mambu.com/saml/logout` or `https://TENANT_NAME.env.mambu.com/saml/logout` ![6 SAML settings](@site/static/img/support/6%20SAML%20settings.png) 5. **Map SAML Attributes** ( used for displaying the first and last name of the user and the username) ![Map SAML attributes](@site/static/img/support/users-and-access-control--saml-attribute-statements-configuration.png) 6. Enter the **Group Attribute Statements** for Mambu-Okta Role Mapping ![group attribute statements](@site/static/img/support/users-and-access-control--group-attribute-statements-configuration.png) 7. In the **Feedback** tab, select the **This is an internal app that we have created** option and then select **Finish**. ![Feedback tab](@site/static/img/support/users-and-access-control--saml-integration-feedback.png) 8. You will be redirected to the **Sign On** tab where SAML configuration settings can be accessed any time, by selecting **View SAML Setup Instructions**. ![SAML configuration](@site/static/img/support/users-and-access-control--okta-saml-2-0-configuration.png) :::note Make sure you have at least one user created and migrated into your IdP and that that user is assigned to the SAML app. ::: ### Setup in Mambu 1. In Mambu, on the main menu, go to **Administration** > **Access** > **Federated Authentication** and select the **Enable Sign Sign-On** check box with the **Manual Settings** option selected as well. Enter the **Name** you would like to use for your IdP. 2. Enter the **Single Sign-On Endpoint**, use the Identity Provider Single Sign-On URL: from the IdP page "View Setup Instructions" 3. Enter the **Certificate Fingerprint** with the value of the following command: `openssl x509 -noout -fingerprint -sha256 -inform pem -in ` > Remember to use the correct certificate name / path! 4. For the **Issuer ID**, type the Identity Provider Issuer from OKTA IdP 5. The **ACS URL** is optional. If filled, it is mapped with the value from the field *Destination URL* from the IdP page, "View Setup Instructions". ![7 FA in mambu](@site/static/img/support/7%20FA%20in%20mambu.png) 6. Select "Test SSO Connection" and enter the username and password of your OKTA account. The connection should be succesful and the next step is to select **Save Changes**. If you have any issues during the setup, please open a new topic on [Mambu Community](https://community.mambu.com) or contact our support team. ![Test connection Okta](@site/static/img/support/Test%20connection%20Okta.png) ### Add and assign users and respective roles 1. Sign in as an admin and go to **Directory** > **People**, and select **Add Person**. ![Add user](@site/static/img/support/Add%20user.png) 2. Add values for the required fields: **First name**, **Last name,** **Username**, and **Primary email**. 3. If the user already exists in Mambu, then the username and email fields should have the same value that exists in Mambu for that user. Please take into consideration that the username and email should be unique. 4. In order to assign the Mambu SAML App to a user, from the user profile select the **Assign Applications** tab. Then select an application and select **Assign**. ![assign mambu saml app to user](@site/static/img/support/assign%20mambu%20saml%20app%20to%20user.png) ### Add and assign Mambu Roles through Okta 1. Sign in as an admin, go to **Directory** > **Groups**, and select **Add Group**. Add a name and a description. 2. Make sure the group name from Okta is an exact match with the role name in Mambu so that users will inherit the Mambu role immediately after Okta Group assignment. 3. Select the group name and select **Add Members**. Search for the user that should be assigned to that role/group. :::note Every time a user signs in, we look through the list of groups the user belongs to in Okta, and try to find any exact match with a Mambu role setup on your instance. Please make sure every user has only one Mambu role/group assigned to them. ::: ![Add user to group](@site/static/img/support/Add%20user%20to%20group.png) ### Map group-based roles in Okta By default, Okta sends a role name of "Everyone" to the SAML configuration. To prevent this, you will need to create a mapping in Okta of group-based roles, which will ensure that it sends the correct roles to the SAML configuration. For assistance, refer to this page: [Enable group-based role mapping in Okta](https://help.okta.com/en-us/content/topics/deploymentguides/aws/aws-enable-role-based.htm). ### Assign branch IDs through Okta For each of your users, you must also define the branch they are assigned to in Okta. For more information, see [Managing Users under Federated Authentication - Branch assignment](/docs/managing-sso-provisioned-users#branch-assignment). The following are the main steps to perform branch assignment using Okta as your IdP: 1. Use the following instructions to create a custom attribute in your profile named "BranchID": [Add custom user attributes](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-add-custom-user-attributes.htm). 2. Use the following attributes: 1. Attribute length: Less than 100 2. User permission: Read-Write 3. Source priority: Inherit from profile source 3. If you want to all the users for a specific application to be assigned the same branch ID, then you may set the value of the `BranchID` attribute at the group level. For more information, see [Add custom attributes to a default Okta group profile](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-add-custom-group-attributes.htm). --- # Set up federated authentication with OneLogin URL: https://docs.mambu.com/docs/onelogin-as-idp/ Federated Authentication (FA) enables organizations to manage the identities and the credentials of the users in a centralized way using identity providers (IdPs) such as OneLogin. To set up FA with OneLogin: 1. Sign in to OneLogin with an admin account and go to **Apps**. 2. Create a new application by selecting **ADD APP**. 3. Enter **SAML Test Connector (IdP)** in the **Search** box and then select **SAML Test Connector (IdP)**. ![SAML Test Connector (IdP)](@site/static/img/support/Screen%20Shot%202018-10-05%20at%202.59.44%20PM.png) 4. Go to the **Info** tab and enter a **Display Name** for the application. ![Info tab with application name and icons](@site/static/img/support/Screen%20Shot%202018-10-05%20at%203.14.20%20PM.png) 5. Go to the **Configuration** tab and enter the required information. * **Audience**, **Recipient** and **ACS (Consumer) URL** should all be the URL that points to the login endpoint of Mambu (for example `https://TENANT_NAME.mambu.com/saml/login`). * **Single Logout URL** should be the URL that points to the logout endpoint of Mambu (such as `https://TENANT_NAME.mambu.com/saml/logout`). ![Configuration tab with details filled in](@site/static/img/support/Screen%20Shot%202018-10-05%20at%203.17.01%20PM.png) 6. Go to the **Parameters** tab and select **Add parameter**. * Enter the **Email**, **First Name**, and **Last Name**. For **NameID** (previously Email) use **Email**. ![](@site/static/img/support/saml-test-connector.png) :::info Be sure to select the **Include in SAML assertion** check box for all the parameters. ::: ![role id new field](@site/static/img/support/new-field-role-id-one-login.png) 7. Go to the **SSO** tab, and the values will be prepopulated. Select **Save**. These values will be copied and pasted into the **Federated Authentication** tab in Mambu. ![](@site/static/img/support/sso-one-login.png) :::info Make sure you have at least one user created/migrated into your IdP and that user is assigned to the SAML app you created. ::: In Mambu: 1. On the main menu, go to **Administration** > **Access** > **Federated Authentication** and select the **Enable Sign Sign-On** check box with the **Manual Settings** option selected as well. 2. Enter the **Name** you would like to use for your IdP. 3. Enter the **Single Sign-On Endpoint**, this will be the **SAML 2.0 Endpoint (HTTP)** from the **SSO** tab in OneLogin. 4. On the **SSO tab**, get the certificate from One Login: select **View Details** under X.509 Certificate and then select **Download**. ![Standard Strength Certificate in OneLogin](@site/static/img/support/standard-strength-certificate.png) 5. Fill in the Certificate Fingerprint with the value of the following command (do not forget to use the correct certificate name / path): ```shell openssl x509 -noout -fingerprint -sha256 -inform pem -in [certificate-file.crt] ``` 6. On the **SSO** tab, in the **Issuer ID** box, enter the Issuer URL from OneLogin. The field **ACS URL** is optional, and can be empty. If filled is mapped with the value from the field - ACS (Consumer) URL from Configuration panel. ![Enable Single Sign-On using OneLogin](@site/static/img/support/acs-url-one-login.png) 7. Select **Test SSO Connection** and enter the username and password of your OneLogin account. ![test sso connection](@site/static/img/support/successful-setup-one-login.png) 8. If the setup was successful, select **Save Changes**. ## Add and assign users To add a new user: 1. Sign in as an admin and go to **Users**, then select **NEW USER**. 2. Add values for the required fields: First Name, Last Name, and so on. If the user already exists then, for **Username** and **Email**, enter the same values that exist in Mambu. Please take into consideration that the username and email should be unique. 3. Select **SAVE USER**. 4. From the user's profile, go to the **Applications** tab, then select the plus icon, select an application, and select **Continue** > **Save**. 5. Optional: To change a user's password, go to **MORE ACTIONS** > select **Change Password** > enter a password > select **Update**. 6. Go to the Mambu login page and sign in via IdP. If you are a new user then the **Welcome** page should be displayed; otherwise, you should be redirected to the Dashboard. ## Add and assign roles To add a new role: 1. Sign in as an admin and go to **Users** > **Roles**, then select **NEW ROLE**. ![create a new role in one login](@site/static/img/support/add-new-role-one-login.png) 2. Select the role name and go to the **Users** tab. 3. Enter the username in the **Check existing or add new users to this role** section and select **CHECK** > select **Add To Role**. :::warning The role id from the IdP should be the same as the role name (not the role id) from Mambu. ::: --- # Organization Contact Details and Time Zone URL: https://docs.mambu.com/docs/organization-contact-currency-and-timezone/ You can edit all the information related to your organization's contact information and general settings. ## Managing organization details using Mambu UI To add or edit the organization's contact information and time zone: 1. On the main menu, go to **Administration** > **General Setup** > **Organization Details**. 2. Enter all the necessary information. See below for more information on the fields. 3. Select **Save Changes**. ![Organization settings, like name, address, currency, time zone and date format](@site/static/img/support/organization-contact-details.png) ## Fields in Organization Details Fields shown with a green outline are required. They are also indicated below. ### Institution Name (required) Enter the name of your institution which will be displayed in left corner of the top bar. ### Contact Details Enter the contact details of your institution: * Street Address Line 1 * City * State/Province/Region * Zip Postal Code * Country * Mobile Phone * Email ### Currency The base currency of the organization. For more information, see [Currencies](/docs/currencies). ### Time Zone Define the organization's local time zone. Note that your organization's time zone controls when various automated processes occur, such as End-of-Day processing and automated notifications. For more information, see [End-of-Day Processing and Cron Jobs](/docs/automatic-end-of-day-actions) and [Automating Notifications](/docs/automated-email-notifications) for more information. ### Local Date Format (required) The pattern that determines the date format to be used for Mambu dates. All dates displayed in the Mambu UI will use the format defined here. For more information on how to enter your format specification, see [Date and time formatting](/docs/organization-contact-currency-and-timezone#date-and-time-formatting). ### Local Date/Time Format (required) The pattern that defines the date and time format to be used for Mambu timestamps. All dates and times displayed in the Mambu UI will use the format defined here. For more information on how to enter your format specification, see [Date and time formatting](/docs/organization-contact-currency-and-timezone#date-and-time-formatting). ### Decimal Mark Define whether to use a period `.` or a comma `,` as a decimal mark. ## Date and time formatting The following characters that are accepted when defining the date and date/time formats. | Symbol | Meaning | Presentation | Example | | --- | --- | --- | --- | | y | year | Number | 2009 | | M | month in year | Text/Number | July/07 | | d | day in month | Number | 10 | | h | hour in am/pm (1-12) | Number | 12 | | H | hour in day (0-23) | Number | 0 | | m | minute in hour | Number | 30 | | s | second in minute | Number | 55 | | S | millisecond | Number | 978 | | w | week in year | Number | 27 | | W | week in month | Number | 2 | | k | hour in day (1-24) | Number | 24 | | K | hour in am/pm (0-11) | Number | 0 | | ' | escape for text | Delimiter | (none) | | ' | single quote | Literal | ' | ### Time format specification examples | Pattern | Example output | | --- | --- | | dd.MM.yy | 30.06.09 | | yyyy.MM.dd hh:mm:ss | 2009.06.30 08:29:36 | | H:mm | 8:29 | | H:mm:ss:SSS | 8:28:36:249 | | dd.M.yyyy | 26 October 2020 | --- # Overdraft Products URL: https://docs.mambu.com/docs/overdraft-products/ With the *Current accounts*-type deposit product, you have the option to allow overdrafts. If you select this option, the accounts created under this product will allow for withdrawals beyond zero, meaning the balance can be negative up to a certain limit provided on creation of the account. When the account goes negative, interest starts being accrued on the account and will be charged regularly according to the settings provided for the product being used. *** ## Overdraft Setup When [setting up a deposit product](/docs/setting-up-new-deposit-products), in the **Overdraft Conditions** section of the **Creating a New Deposit Product** form, select the **Allow Overdrafts** checkbox. ![The overdraft conditions section of the Creating a new deposit product form with allow overdrafts checkbox selected](@site/static/img/support/allow-overdrafts.png) When creating a product with an overdraft facility, please consider the following two sections: ### Interest Rate This section refers, for the most part, to the application of positive (credit) interest on current account products. However, the **When is the Interest Paid Into the Account?** setting defines how frequently both positive (credit) interest and negative (debit) overdraft interest will be applied. If no interest application frequency is selected here, overdraft interest will not be applied to the account, only accrued, and will have to be applied manually. If you don't want to pay positive (credit) interest on overdraft accounts, you will still need to enable interest by checking the **Interest paid into account?** box but can enter '0' in the fields for default, maximum and minumum interest rate. With this setup, any accounts created under this product will not pay any interest to your clients and only negative interest will be charged in case the account balance goes below 0 (as per the be settings defined in the **Overdraft Conditions** section). ### Overdraft Conditions If the option to **Allow Overdrafts** is enabled for the product, the following settings become available: #### Interest Rate Source Two sources of interest rates are supported for Deposit Products allowing overdrafts: * **Fixed Interest Rate**: Remains fixed for the entire term of the loan. * **Index Interest Rate**: A floating interest rate, also known as a variable rate. It is calculated as a sum of a reference (benchmark) index interest rate and a specified spread (margin). As a result, the index interest rate will change together with changes in the reference (benchmark) index interest rate. If the **Index Interest Rate** option is chosen, additional fields will become available: * **Index source**: Here you can choose the source of your index rate from a predefined drop down list. * **Interest Spread constraints**: To define constraints of spread that will be added to the reference index rate (default, minimum and maximum) when creating a new account under this product. * **Interest Rate Review Frequency**: How often should the overdraft interest rate be updated (reviewed). You can find more details and examples of overdraft interest rate calculations in [Overdraft Interest Calculation](/docs/interest-calculation-methods-in-deposit-accounts#overdraft-interest-calculation). :::warning Negative index rate Mambu does not support negative interest rate from overdrafts. Thefore if index interest rate source has a negative sign, please make sure that after adding a spread, interest rate sign is positive : `Index rate + Interest spread > 0`. If you need to use negative interest rate on overdraft, please contact your Customer Success Manager. ::: ### Max Overdraft Limit Maximum Overdraft Limit is a maximum negative balance that the current account can reach. No withdrawals will be possible beyond this limit. When creating new accounts under this product, users will be able to arrange an overdraft with their clients for any amount up to the maximum amount given here. :::note The limit for the overdraft defined here refers only to principal. So this is the limit a client can withdraw, but the account's balance can go below this limit in case there are any fees or interest posted. ::: ### Balance used for calculation of interest You can select to use either the minimum daily balance or the balance following any End of Day processes to calculate interest to be applied. ### Days In Year You can choose from four different day count methods for interest calculation on overdrafts: * **Actual/365 Fixed (365 days)** is the method that calculates the interest daily by counting the actual number of days in the calendar and uses a fixed 365 year length. * **Actual 360** is the method that calculates interest daily by counting the number of days in the calendar, but uses a fixed 360 year length. * **Actual/Actual ISDA** is the method that calculates the interest daily by counting the number of days in the calendar and also considers leap year. * **30E/360 (360 days)** counts the days from the calendar, but also introduces some changes on the months with 31 and 28 days. *** ## Accounts managed under Credit Arrangements (Lines of Credit) In this section you can decide if accounts created for this product can be managed in a line of credit or not. Under **Accounts Managed under Credit Arrangements (Line of Credit)** setup, you will find the following options: 1. **Optional (default)**: Accounts created on this product can be managed in a line of credit, but it’s not required to have them under lines of credit 2. **Required**: The account can’t be approved if it is not associated with a line of credit 3. **No**: Accounts for this product are not allowed to be managed in lines of credit You can read more in our article about [Managing Credit Arrangements](/docs/managing-credit-arrangements). ![Overdraft Conditions section with many options to choose from.](@site/static/img/support/deposits--overdraft-conditions.png) *** ## Technical Overdraft Technical overdrafts allow funds to be withdrawn from an account beyond the agreed overdraft limit. Technical overdrafts for deposits can be enabled on the product level and will apply for all accounts created under that product. More information on technical overdrafts is available in [this article](/docs/technical-overdraft). :::note If technical overdrafts are enabled for a deposit product, they can only be disabled if no accounts have been created under that product. ::: ### Technical Overdraft Interest Rate If an interest rate is set for authorized overdrafts on a deposit account, then the same interest rate would be applied to any technical overdraft. ![Allow Overdraft and Allow Technical Overdraft options checked under Overdraft Conditions section](@site/static/img/support/deposits--overdraft-conditions-3.png) Conversely, if no interest rate is set for authorized overdrafts on the deposit account, then Mambu would not apply any interest on technical overdrafts. ![Allow Technical Overdrafts option checked under Overdraft Conditions section.](@site/static/img/support/deposits--overdraft-conditions-5.png) ### Technical Overdraft Accounting The accounting rules for technical overdrafts are carried forward from the applied accounting methodology ('Cash' or 'Accrual') on the products with authorized overdrafts. If an accounting methodology was selected with appropriate General Ledger (GL) accounts for authorized overdrafts, then the same accounting rules would apply to technical overdrafts. ![Accounting Rules section with Cash Methodology selected.](@site/static/img/support/deposits--accounting-rules-configuration.png) :::note If authorized overdrafts were disabled for a deposit product whilst allowing for technical overdrafts, then the accounting methodologies ('Cash' or 'Accrual' would nevertheless require the definition of appropriate GL accounts for overdrafts.) ::: ![Accounting Rules section with Accrual Methodology selected.](@site/static/img/support/deposits--accounting-rules.png) :::warning There will not be separate Journal Entries for interest earned from Technical Overdrafts. Entries added for overdraft interest will represent the total amount from both authorized and technical overdrafts. ::: You can read more in our article about [Accounting Setup](/docs/accounting-setup). --- # Interest Rate Change Threshold Overpayment URL: https://docs.mambu.com/docs/overpayment-and-interest-rate-change-threshold/ ## Overview The PMT Adjustment Threshold manages overpayments and interest rate changes in relation to upcoming instalments. If an overpayment or interest rate change occurs within a predefined number of days (X days) before an installment date, the recalculation of the next installment will be deferred. The adjustment will be applied to the subsequent instalment (n+1), preventing last-minute changes to the upcoming payment. ![pmt adjustment threshold](@site/static/img/support/pmt-adjustment-threshold.png) ## Feature Description The PMT Adjustment Threshold uses a configurable threshold period. Changes occurring within this period will not impact the next scheduled installment. Adjustments made outside this threshold will result in an update to the next installment, providing sufficient time to notify customers of the changes. This functionality enhances the customer experience by providing adequate notice of installment changes due to overpayments or interest rate modifications. If the threshold feature is not configured, the system will follow the existing process, recalculating and updating the current installment as necessary. ## Key Considerations * No user interface (UI) changes are associated with this functionality. * The feature leverages the PMT Threshold functionality and adheres to the existing overpayment calculation rules. * It is automatically enabled if the PMT Threshold feature is activated at the product or account level. * This functionality ensures greater transparency and predictability in loan repayment schedules while minimizing unexpected adjustments for customers. --- # Pacs.008 URL: https://docs.mambu.com/docs/pacs008/ The table below provides more details about the structure and content of Pacs.008 messages. *** ## Pacs.008 reference table
    # SEPA MULT MESSAGE ELEMENT SEPA CORE REQUIREMENTS
    Document
    • **XML Tag** : Document
    • **Type** : Document
    1..1 FITo FICustomerCredit TransferV02
    • **ISO Name** : FIToFICustomerCreditTransferV02
    • **ISO Definition** : The FI2FICustomerCredit Transfermessage is sent by the debtor's agent to the creditor's agent, directly or through other agents and/or a payment clearing and settlement system. It is used to move funds from a debtor's account to a creditor.
    • **XML Tag** : FIToFICstmrCdtTrf
    • **Type** : FIToFICustomerCreditTransferV02
    1 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • **ISO Name** : Group Header
    • **ISO Definition** : Set of characteristics shared by all individual transactions included in the message.
    • **XML Tag** : GrpHdr
    • **Type** : GroupHeader33
    1.1 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Message Identification
    • **ISO Name** : Message Identification
    • **ISO Definition** : Point to point reference, as assigned by the instructing party, and sent to the next party in the chain to unambiguously identify the message.
    • **Usage** : The instructing party has to make sure that MessageIdentification is unique per instructed party for a pre-agreed period.
    • **XML Tag** : MsgId
    • **Type** : Max35Text
    • **ISO Length** : 1 .. 35
    • **SEPA Length** : 1 .. 35
    1.2 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Creation Date Time
    • **ISO Name** : Creation Date Time
    • **ISO Definition** : Date and time at which the message was created.
    • **XML Tag** : CreDtTm
    • **Type** : ISODateTime
    1.4 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Number Of Transactions
    • **SEPA Usage Rule**(s) : The number of transactions is limited to one.
    • **ISO Name** : Number Of Transactions
    • **ISO Definition** : Number of individual transactions contained in the message.
    • **XML Tag** : NbOfTxs
    • **Type** : Max15NumericText
    • **Pattern** : [0-9]
    1.6 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Total InterbankSettlementAmount
    • **SEPA Usage Rule**(s) : Mandatory - Only ‘EUR’ is allowed.
    • Amount must be 0.01 or up to the maxiumum amount per instruction that can be processed under the Scheme as defined in EPC document EPC023-16 “Maximum Amount for Instructions”.
    • **SEPA Format Rule**(s) : The fractional part has a maximum of two digits.
    • **ISO Name** : Total InterbankSettlementAmount
    • **ISO Definition** : Total amount of money moved between the instructing agentand the instructed agent.
    • **XML Tag** : TtlIntrBkSttlmAmt
    • **Type** : ActiveCurrencyAndAmount
    • **SEPA FractDigits** : 2 TotalDigits : 18
    • SEPA Inclusive 0.01 ..
    1.7 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++InterbankSettlement Date
    • **SEPA Rulebook** : AT-42 TheSettlement Dateof the SCT Transaction.
    • **SEPA Usage Rule**(s) : Mandatory
    • **ISO Name** Interbank :Settlement Date
    • **ISO Definition** : Date on which the amount of money ceases to be available to the agent that owes it and when the amount of money becomes available to the agent to which it is due.
    • **XML Tag** : IntrBkSttlmDt
    • **Type** : ISODate
    1.8 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++SettlementInformation
    • **ISO Name** :SettlementInformation
    • **ISO Definition** : Specifies the details on how the settlement of the transaction(s) between the instructing agentand the instructed agent is completed.
    • **XML Tag** : SttlmInf
    • **Type** : SettlementInformation13
    1.9 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++SettlementInformation
    • +++SettlementMethod
    • **SEPA Usage Rule**(s) : Only CLRG, INGA and INDA are allowed.
    • **ISO Name** :SettlementMethod
    • **ISO Definition** : Method used to settle the (batch of) payment instructions.
    • **XML Tag** : SttlmMtd
    • **Type** : SettlementMethod1Code
    • **SEPA Code Restrictions** :
    • CLRG - ClearingSystem -Settlement is done through a payment clearing system.
    • INDA - InstructedAgent -Settlement is done by the agent instructed to execute a payment instruction.
    • INGA - InstructingAgent -Settlement is done by the agent instructing and forwarding the payment to the next party in the payment chain.
    1.1 0..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++SettlementInformation
    • +++SettlementAccount
    • **SEPA Usage Rule**(s) : Only ‘Identification’ is allowed.
    • **ISO Name** :SettlementAccount
    • **ISO Definition** : A specific purpose account used to post debit and credit entries as a result of the transaction.
    • **XML Tag** : SttlmAcct
    • **Type** : CashAccount16
    1.11 0..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++SettlementInformation
    • +++Clearing System
    • **ISO Name** :Clearing System
    • **ISO Definition** : Specification of a pre-agreed offering between clearing agents or the channel through which the payment instruction is processed.
    • **XML Tag** : ClrSys
    • **Type** : ClearingSystemIdentification3Choice
    1.18 0..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Payment Type Information
    • **SEPA Usage Rule**(s) : Mandatory
    • **ISO Name** : Payment Type Information
    • **ISO Definition** : Set of elements used to further specify the type of transaction.
    • **XML Tag** : PmtTpInf
    • **Type** : PaymentTypeInformation21
    1.21 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Payment Type Information
    • +++Service Level
    • **SEPA Usage Rule**(s) : Mandatory
    • **ISO Name** : Service Level
    • **ISO Definition** : Agreement under which or rules under which the transaction should be processed.
    • **XML Tag** : SvcLvl
    • **Type** : ServiceLevel8Choice
    1..1 **XML Tag** xs:choice
    1.22 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Payment Type Information
    • +++Service Level
    • ++++Code
    • **SEPA Rulebook** : AT-40 The identification code of the SCT Scheme.
    • **SEPA Usage Rule**(s) : Only ‘SEPA’ is allowed.
    • **ISO Name** : Code
    • **ISO Definition** : Specifies a pre-agreed service or level of service between the parties, as published in an external service level code list.
    • **XML Tag** : Cd
    • **Type** : ExternalServiceLevel1Code
    • **ISO Length** : 1 .. 4
    • **SEPA Length** : 1 .. 4
    • **SEPA Code Restrictions**
    • SEPA - SingleEuroPaymentsArea - Payment must be executed following the Single Euro Payments Area scheme.
    1.24 1..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Payment Type Information
    • +++Local Instrument
    • ++++Code
    • **SEPA Rulebook** : AT-40 The identification code of the SCT Scheme
    • **SEPA Usage Rule**(s) : Only ‘SCT’ is allowed.
    • **ISO Name** : Code
    • **ISO Definition** : Specifies the local instrument, as published in an external local instrument code list.
    • **XML Tag** : Cd
    • **Type** : ExternalLocalInstrument1Code
    • **ISO Length** : 1 .. 35
    • **SEPA Length** : 1 .. 35
    1.25 0..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++Payment Type Information
    • +++Category Purpose
    • **SEPA Rulebook** : AT-45 Category purpose of the the SCT Instruction.
    • **SEPA Usage Rule**(s) : Depending on the agreement between the Originator and the Originator Bank, ‘Category Purpose’ may be forwarded to the Beneficiary Bank.
    • **ISO Name** : Category Purpose
    • **ISO Definition** : Specifies the high level purpose of the instruction based on a set of pre-defined categories.
    • **Usage** : This is used by the initiating party to provide information concerning the processing of the payment. It is likely to trigger special processing by any of the agents involved in the payment chain.
    • **XML Tag** : CtgyPurp
    • **Type** : CategoryPurpose1Choice
    1.26 0..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++InstructingAgent
    • **SEPA Usage Rule**(s) : Only BIC is allowed
    • **ISO Name** : InstructingAgent
    • **ISO Definition** :Agent that instructs the next party in the chain to carry out the (set of) instruction(s).
    • **XML Tag** : InstgAgt
    • **Type** : BranchAndFinancialInstitutionIdentification4
    1.27 0..1
    • FITo FICustomerCredit TransferV02
    • +Group Header
    • ++InstructedAgent
    • **SEPA Usage Rule**(s) : Only BIC is allowed.
    • **ISO Name** : InstructedAgent
    • **ISO Definition** :Agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s).
    • **XML Tag** : InstdAgt
    • **Type** : BranchAndFinancialInstitutionIdentification4
    2 1..n
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • **SEPA Usage Rule**(s) : Only one occurence is allowed.
    • **ISO Name** :Credit TransferTransaction Information
    • **ISO Definition** : Set of elements providing information specific to the individualcredit transfer(s).
    • **XML Tag** : CdtTrfTxInf
    • **Type** : CreditTransferTransactionInformation11
    2.1 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Payment Identification
    • **ISO Name** : Payment Identification
    • **ISO Definition** : Set of elements used to reference a payment instruction.
    • **XML Tag** : PmtId
    • **Type** : PaymentIdentification3
    2.2 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Payment Identification
    • +++Instruction Identification
    • **ISO Name** : Instruction Identification
    • **ISO Definition** : Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction.
    • **Usage** : The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction.
    • **XML Tag** : InstrId
    • **Type** : Max35Text
    • **ISO Length** 1 .. 35
    • **SEPA Length** 1 .. 35
    2.3 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Payment Identification
    • +++End To End Identification
    • **SEPA Rulebook** : AT-41 Originator’s Reference to the SCT Inst Transaction.
    • **SEPA Usage Rule**(s) : Acustomerreference that must be passed on in the end-to-end chain. In the event that no reference was given, ‘NOTPROVIDED’ must be used.
    • **ISO Name** : End To End Identification
    • **ISO Definition** : Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end
    • chain.
    • **Usage** : The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction.
    • **Usage** : In case there are technical limitations to pass on multiple references, the end-to-end
    • identification must be passed on throughout the entire end-to-end chain.
    • **XML Tag** : EndToEndId
    • **Type** : Max35Text
    • **ISO Length** : 1 .. 35
    • **SEPA Length** : 1 .. 35
    2.4 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Payment Identification
    • +++Transaction Identification
    • **SEPA Rulebook** : AT-43 The Originator Bank’s reference number of the SCT Inst Transaction message.
    • **SEPA Usage Rule**(s) : Must contain a reference that is meaningful to the Originator’s Bank and is unique over time.
    • **ISO Name** : Transaction Identification
    • **ISO Definition** : Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain.
    • **Usage** : The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level.
    • **Usage** : The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period.
    • **XML Tag** : TxId
    • **Type** : Max35Text
    • **ISO Length** : 1 .. 35
    • **SEPA Length** : 1 .. 35
    2.6 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++InterbankSettlementAmount
    • **SEPA Rulebook** : AT-04 The amount of the SCT in Euro.
    • **SEPA Usage Rule**(s) : Only ‘EUR’ is allowed.
    • Amount must be 0.01 or up to the maximum amount per instruction that can be processed under the Scheme as defined in document EPC023-16 “Maximum Amount for Instructions under the Rulebook”.
    • **SEPA Format Rule**(s) : The fractional part has a maximum of two digits.
    • **ISO Name** : InterbankSettlementAmount
    • **ISO Definition** : Amount of money moved between the instructing agentand the instructed agent.
    • **XML Tag** : IntrBkSttlmAmt
    • **Type** : ActiveCurrencyAndAmount
    • **SEPA FractDigits** : 2 TotalDigits : 18
    • SEPA Inclusive 0.01 ..
    2.1 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Acceptance Date Time
    • **SEPA Rulebook** : AT-50 Timestamp of the SCT Transaction.
    • **SEPA Usage Rule**(s) : Mandatory - The Timestamp must be unambiguous and at least include seconds.
    • **ISO Name** : Acceptance Date Time
    • **ISO Definition** : Point in time when the payment order from the initiating party meets the processing conditions of the account servicing agent. This means that the account servicing agent has received the payment order and has applied checks such as authorisation, availability of funds.
    • **XML Tag** : AccptncDtTm
    • **Type** : ISODateTime
    2.14 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Charge Bearer
    • **SEPA Usage Rule**(s) : Only ‘SLEV’ is allowed.
    • **ISO Name** : Charge Bearer
    • **ISO Definition** : Specifies which party/parties will bear the charges associated with the processing of the payment transaction.
    • **XML Tag** : ChrgBr
    • **Type** : ChargeBearerType1Code
    • **SEPA Code Restrictions**
    • SLEV - FollowingServiceLevel - Charges are to be applied following the rules agreed in the service level and/or scheme.
    2.24 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Debtor
    • **ISO Name** : Ultimate Debtor
    • **ISO Definition** : Ultimate party that owes an amount of money to the (ultimate) creditor.
    • **XML Tag** : UltmtDbtr
    • **Type** : PartyIdentification32
    2.25 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Debtor
    • +++Name
    • **SEPA Rulebook** : AT-08 Name of the Originator Reference Party.
    • **SEPA Usage Rule**(s) : ‘Name’ is limited to 70 characters in length.
    • **ISO Name** : Name
    • **ISO Definition** : Name by which a party is known and which is usually used to identify that party.
    • **XML Tag** : Nm
    • **Type** : Max140Text
    • **ISO Length** 1 .. 140
    • **SEPA Length** 1 .. 70
    2.27 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Debtor
    • +++Identification
    • **SEPA Rulebook** : AT-09 Identification code of the Originator Reference Party.
    • **ISO Name** : Identification
    • **ISO Definition** : Unique and unambiguous identification of a party.
    • **XML Tag** : Id
    • **Type** : Party6Choice
    1..1 **XML Tag** xs:choice
    2.28 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Debtor
    • +++Identification
    • ++++Organization Identification
    • **SEPA Usage Rule**(s) : Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Organization Identification
    • **ISO Definition** : Unique and unambiguous way to identify an organization.
    • **XML Tag** : OrgId
    • **Type** : OrganizationIdentification4
    2.29 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Debtor
    • +++Identification
    • ++++Private Identification
    • **SEPA Usage Rule**(s) Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Private Identification
    • **ISO Definition** : Unique and unambiguous identification of a person, eg, passport.
    • **XML Tag** : PrvtId
    • **Type** : PersonIdentification5
    2.33 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • **ISO Name** : Debtor
    • **ISO Definition** : Party that owes an amount of money to the (ultimate) creditor.
    • **XML Tag** : Dbtr
    • **Type** : PartyIdentification32
    2.34 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Name
    • **SEPA Rulebook** : AT-02 Name of the Originator.
    • **SEPA Usage Rule**(s) : Mandatory - ‘Name’ is limited to 70 characters in length.
    • **ISO Name** : Name
    • **ISO Definition** : Name by which a party is known and which is usually used to identify that party.
    • **XML Tag** : Nm
    • **Type** : Max140Text
    • **ISO Length** : 1 .. 140
    • **SEPA Length** : 1 .. 70
    2.35 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Postal Address
    • **SEPA Rulebook** : AT-03 Address of the Originator (only mandatory when the Originator Bank or the Beneficiary Bank is located in a non-EEA SEPA country or territory).
    • **ISO Name** : Postal Address
    • **ISO Definition** : Information that locates and identifies a specific address, as defined by postal services.
    • **XML Tag** : PstlAdr
    • **Type** : PostalAddress6
    2.44 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Postal Address
    • ++++Country
    • **ISO Name** : Country
    • **ISO Definition** : Nation with its own government.
    • **XML Tag** : Ctry
    • **Type** : CountryCode
    • **Pattern** : [A-Z]
    2.45 0..2
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Postal Address
    • ++++Address Line
    • **SEPA Usage Rule**(s) : Only two occurrences are allowed.
    • **ISO Name** : Address Line
    • **ISO Definition** : Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
    • **XML Tag** : AdrLine
    • **Type** : Max70Text
    • **ISO Length** : 1 .. 70
    • **SEPA Length** : 1 .. 70
    2.46 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Identification
    • **SEPA Rulebook** : AT-10 Originator’s Identification Code.
    • **ISO Name** : Identification
    • **ISO Definition** : Unique and unambiguous identification of a party.
    • **XML Tag** : Id
    • **Type** : Party6Choice
    1..1 **XML Tag** xs:choice
    2.47 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Identification
    • ++++Organization Identification
    • **SEPA Usage Rule**(s) : Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Organization Identification
    • **ISO Definition** : Unique and unambiguous way to identify an organization.
    • **XML Tag** : OrgId
    • **Type** : OrganizationIdentification4
    2.48 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor
    • +++Identification
    • ++++Private Identification
    • **SEPA Usage Rule**(s) : Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Private Identification
    • **ISO Definition** : Unique and unambiguous identification of a person, eg, passport.
    • **XML Tag** : PrvtId
    • **Type** : PersonIdentification5
    2.51 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Debtor Account
    • **SEPA Rulebook** : AT-01 The IBAN of the account of the Originator.
    • **SEPA Usage Rule**(s) : Mandatory - Only IBAN is allowed.
    • **ISO Name** : Debtor Account
    • **ISO Definition** : Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction.
    • **XML Tag** : DbtrAcct
    • **Type** : CashAccount16
    2.52 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++DebtorAgent
    • **SEPA Rulebook** : AT-06 BIC of the Originator Bank.
    • **SEPA Usage Rule**(s) : Only BIC is allowed.
    • **ISO Name** : DebtorAgent
    • **ISO Definition** : Financial institution servicing an account for the debtor.
    • **XML Tag** : DbtrAgt
    • **Type** : BranchAndFinancialInstitutionIdentification4
    2.54 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++CreditorAgent
    • **SEPA Rulebook** : AT-23 The BIC of the Beneficiary Bank.
    • **SEPA Usage Rule**(s) : Only BIC is allowed.
    • **ISO Name** : CreditorAgent
    • **ISO Definition** : Financial institution servicing an account for the creditor.
    • **XML Tag** : CdtrAgt
    • **Type** : BranchAndFinancialInstitutionIdentification4
    2.56 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • **ISO Name** : Creditor
    • **ISO Definition** : Party to which an amount of money is due.
    • **XML Tag** : Cdtr
    • **Type** : PartyIdentification32
    2.57 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Name
    • **SEPA Rulebook** : AT-21 Name of the Beneficiary.
    • **SEPA Usage Rule**(s) : Mandatory - ‘Name’ is limited to 70 characters in length.
    • **ISO Name** : Name
    • **ISO Definition** : Name by which a party is known and which is usually used to identify that party.
    • **XML Tag** : Nm
    • **Type** : Max140Text
    • **ISO Length** : 1 .. 140
    • **SEPA Length** : 1 .. 70
    2.58 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Postal Address
    • **SEPA Rulebook** : AT-22 Address of the Beneficiary.
    • **ISO Name** : Postal Address
    • **ISO Definition** : Information that locates and identifies a specific address, as defined by postal services.
    • **XML Tag** : PstlAdr
    • **Type** : PostalAddress6
    2.67 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Postal Address
    • ++++Country
    • **ISO Name** : Country
    • **ISO Definition** : Nation with its own government.
    • **XML Tag** : Ctry
    • **Type** : CountryCode
    • **Pattern** : [A-Z]
    2.68 0..2
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Postal Address
    • ++++Address Line
    • **SEPA Usage Rule**(s) : Only two occurrences are allowed.
    • **ISO Name** : Address Line
    • **ISO Definition** : Information that locates and identifies a specific address, as defined by postal services, presented in free format text.
    • **XML Tag** : AdrLine
    • **Type** : Max70Text
    • **ISO Length** : 1 .. 70
    • **SEPA Length** : 1 .. 70
    2.69 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Identification
    • **SEPA Rulebook** : AT-24 Beneficiary Identification Code.
    • **ISO Name** : Identification
    • **ISO Definition** : Unique and unambiguous identification of a party.
    • **XML Tag** : Id
    • **Type** : Party6Choice
    1..1 **XML Tag** xs:choice
    2.7 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Identification
    • ++++Organization Identification
    • **SEPA Usage Rule**(s) : Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Organization Identification
    • **ISO Definition** : Unique and unambiguous way to identify an organization.
    • **XML Tag** : OrgId
    • **Type** : OrganizationIdentification4
    2.71 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor
    • +++Identification
    • ++++Private Identification
    • **SEPA Usage Rule**(s) : Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Private Identification
    • **ISO Definition** : Unique and unambiguous identification of a person, eg, passport.
    • **XML Tag** : PrvtId
    • **Type** : PersonIdentification5
    2.74 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Creditor Account
    • **SEPA Rulebook** : AT-20 The IBAN of the account of the Beneficiary.
    • **SEPA Usage Rule**(s) : Mandatory - Only IBAN is allowed.
    • **ISO Name** : Creditor Account
    • **ISO Definition** : Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction.
    • **XML Tag** : CdtrAcct
    • **Type** : CashAccount16
    2.75 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Creditor
    • **ISO Name** : Ultimate Creditor
    • **ISO Definition** : Ultimate party to which an amount of money is due.
    • **XML Tag** : UltmtCdtr
    • **Type** : PartyIdentification32
    2.76 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Creditor
    • +++Name
    • **SEPA Rulebook** : AT-28 Name of the Beneficiary Reference Party.
    • **SEPA Usage Rule**(s) : ‘Name’ is limited to 70 characters in length.
    • **ISO Name** : Name
    • **ISO Definition** : Name by which a party is known and which is usually used to identify that party.
    • **XML Tag** : Nm
    • **Type** : Max140Text
    • **ISO Length** : 1 .. 140
    • **SEPA Length** : 1 .. 70
    2.78 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Creditor
    • +++Identification
    • **SEPA Rulebook** : AT-29 Identification code of the Beneficiary Reference Party.
    • **ISO Name** : Identification
    • **ISO Definition** : Unique and unambiguous identification of a party.
    • **XML Tag** : Id
    • **Type** : Party6Choice
    1..1 **XML Tag** xs:choice
    2.79 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Creditor
    • +++Identification
    • ++++Organization Identification
    • **SEPA Usage Rule**(s) : Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Organization Identification
    • **ISO Definition** : Unique and unambiguous way to identify an organization.
    • **XML Tag** : OrgId
    • **Type** : OrganizationIdentification4
    2.8 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Ultimate Creditor
    • +++Identification
    • ++++Private Identification
    • **SEPA Usage Rule**(s) : Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed.
    • **ISO Name** : Private Identification
    • **ISO Definition** : Unique and unambiguous identification of a person, eg, passport.
    • **XML Tag** : PrvtId
    • **Type** : PersonIdentification5
    2.85 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Purpose
    • **SEPA Rulebook** : AT-44 The purpose of the SCT Instruction.
    • **ISO Name** : Purpose
    • **ISO Definition** : Underlying reason for the payment transaction.
    • **Usage** : Purpose is used by the end-customers, that is initiating party, (ultimate) debtor, (ultimate) creditor to provide information concerning the nature of the payment. Purpose is a content element, which is not used for processing by any of the agents involved in the payment chain.
    • **XML Tag** : Purp
    • **Type** : Purpose2Choice
    1..1 **XML Tag** xs:choice
    2.86 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Purpose
    • +++Code
    • **ISO Name** : Code
    • **ISO Definition** : Underlying reason for the payment transaction, as published in an external purpose code list.
    • **XML Tag** : Cd
    • **Type** : ExternalPurpose1Code
    • **ISO Length** : 1 .. 4
    • **SEPA Length** : 1 .. 4
    2.9 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • **SEPA Rulebook** : AT-05 Remittance Information.
    • **SEPA Usage Rule**(s) : Either ‘Structured’ or ‘Unstructured’ may be present.
    • **ISO Name** : Remittance Information
    • **ISO Definition** : Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, such as commercial invoices in an accounts' receivable system.
    • **XML Tag** : RmtInf
    • **Type** : RemittanceInformation5
    2.91 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Unstructured
    • **SEPA Usage Rule**(s) : ‘Unstructured’ may carry structured remittance information, as agreed between the Originator and the Beneficiary. Only one occurrence of ‘Unstructured’ is allowed.
    • **ISO Name** : Unstructured
    • **ISO Definition** : Information supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts' receivable system, in an unstructured form.
    • **XML Tag** : Ustrd
    • **Type** : Max140Text
    • **ISO Length** : 1 .. 140
    • **SEPA Length** : 1 .. 140
    2.92 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • **SEPA Usage Rule**(s) : Only one occurrence of ‘Structured’ is allowed.
    • **SEPA Format Rule**(s) : ‘Structured’ can be used, provided the tags and the data within the ‘Structured’ element do not exceed 140 characters in length.
    • **ISO Name** : Structured
    • **ISO Definition** : Information supplied to enable the matching/reconciliation of an entry with the items that the payment is intended to settle, such as commercial invoices in an accounts' receivable system, in a structured form.
    • **XML Tag** : Strd
    • **Type** : StructuredRemittanceInformation7
    2.95 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • ++++Creditor Reference Information
    • **SEPA Usage Rule**(s) : When present, the Creditor Bank is not obliged to validate the reference information. When used both ‘Type’ and ‘Reference’ must be present.
    • **ISO Name** : Creditor Reference Information
    • **ISO Definition** : Reference information provided by the creditor to allow the identification of the underlying documents.
    • **XML Tag** : CdtrRefInf
    • **Type** : CreditorReferenceInformation2
    2.96 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • ++++Creditor Reference Information
    • +++++Type
    • **ISO Name** : Type
    • **ISO Definition** : Specifies the type of creditor reference.
    • **XML Tag** : Tp
    • **Type** : CreditorReferenceType2
    2.97 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • ++++Creditor Reference Information
    • +++++Type
    • ++++++Code Or Proprietary
    • **ISO Name** : Code Or Proprietary
    • **ISO Definition** : Coded or proprietary format creditor reference type.
    • **XML Tag** : CdOrPrtry
    • **Type** : CreditorReferenceType1Choice
    1..1 **XML Tag** xs:choice
    2.98 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • ++++Creditor Reference Information
    • +++++Type
    • ++++++Code Or Proprietary
    • +++++++Code
    • **SEPA Usage Rule**(s) : Only ‘SCOR’ is allowed.
    • **ISO Name** : Code
    • **ISO Definition** : Type of creditor reference, in a coded form.
    • **XML Tag** : Cd
    • **Type** : DocumentType3Code
    • **SEPA Code Restrictions** : SCOR (StructuredCommunicationReference) - Document is a structured communication reference provided by the creditor to identify the referred transaction.
    2.1 0..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • ++++Creditor Reference Information
    • +++++Type
    • ++++++Issuer
    • **ISO Name** : Issuer
    • **ISO Definition** : Entity that assigns the credit reference type.
    • **XML Tag** : Issr
    • **Type** : Max35Text
    • **ISO Length** : 1 .. 35
    • **SEPA Length** : 1 .. 35
    2.101 1..1
    • FITo FICustomerCredit TransferV02
    • +Credit TransferTransaction Information
    • ++Remittance Information
    • +++Structured
    • ++++Creditor Reference Information
    • +++++Reference
    • **SEPA Usage Rule**(s) : If a Creditor Reference contains a check digit, the receiving bank is not required to validate this. If the receiving bank validates the check digit and if this validation fails, the bank may continue its processing and send the transaction to the next party in the chain.
    • RF Creditor Reference may be used (ISO 11649).
    • **ISO Name** : Reference
    • **ISO Definition** : Unique reference, as assigned by the creditor, to unambiguously refer to the payment transaction.
    • **Usage** : If available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the amount of money. If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor's reference or payment remittance identification should be quoted in the end-to-end transaction identification.
    • **XML Tag** : Ref
    • **Type** : Max35Text
    • **ISO Length** : 1 .. 35
    • **SEPA Length** : 1 .. 35
    --- # Paginated Report URL: https://docs.mambu.com/docs/paginated-report/ ## Business case Extract loan transactions along with their type where the number of results are expected to exceed 10.000 rows (Mambu batch limit). ## Technical concepts Usage of pagination. Data is extracted in batches of 10.000 results. :::note In the sample, the highest transaction ID exceeds 10.000. This is because some of the IDs aren't consecutive. The number of Excel results is 10,000 as expected. ::: ## Sources * [jrxml template report](https://s3.amazonaws.com/mambu-notifications/Resources/TenThousandLoanTransactions.jrxml) * [resulting report](https://s3.amazonaws.com/mambu-notifications/Resources/TenThousandLoanTransactions.xlsx) ## Preview [![developer--paginated-loan-transactions-report-preview.png](@site/static/img/support/developer--paginated-loan-transactions-report-preview.png)](https://s3.amazonaws.com/mambu-notifications/Resources/paginated_loan_transactions.png) *** --- # Paying Off a Loan URL: https://docs.mambu.com/docs/paying-off-a-loan/ When you *pay off* a loan, you make a prepayment that covers the whole amount due as of a given date, when the client wants to fully pay their loan earlier than initially agreed and thus close their loan account. It is also sometimes called "early settlement" or "early closure" of a loan account. To pay off a loan, you need to have the **Pay Off Loan Accounts** (`PAY_OFF_LOAN`) permission. If you want to waive or reduce some of the interest or fees that are due, then the **Apply Loan Adjustments** (`APPLY_LOAN_ADJUSTMENTS`) permission will be required in addition to the **Pay Off Loan Accounts** permission. To pay off a loan, on the right-hand side of the account overview page, select **Close** > **Pay Off**. ![Pay Off Loan pop-up with Principal Balance, Interest Balance, Penalty Balance, Pay Off Account, Channel, Repayment , Value date and Notes fields](@site/static/img/support/Pay%20Off%20Loan%20pop-up%20with%20Principal%20Balance,%20Interest%20Balance,%20Penalty%20Balance,%20Pay%20Off%20Account,%20Channel,%20Repayment%20,%20Value%20date%20and%20Notes%20fields.png) If you don't waive any of the amounts due, when paying off a loan, there will be a repayment transaction logged for the remaining balances (principal + interest + fees + penalty, if applicable). :::note A payoff action cannot currently be fully undone, the account can be reopened and the repayment transaction can be manually reverted, but the interest, fees and penalty reductions would remain in place. ::: When paying off a loan, the sequence of events happening in the back-end is the following: * Any future interest (not yet due or pre-paid) will be ignored or not considered due and will not be included in the amount to be paid to close the account * A repayment transaction is logged for the total amount paid * The account is automatically closed (with all obligations met) :::note When paying off a dynamic loan, the interest balance and penalties balance also contains the accrued interest and penalties. So when closing the account, Mambu will apply the interest and penalties until the current date unless the user subtracts the accrued amounts from the balance. ::: ## Preview payoff for a future date To preview the balances of a loan in case of a payoff on a future date: 1. Open the loan account. 2. On the right-hand side of the screen, select **Close** > **Pay Off**. 3. In the **Pay Off Loan** dialog, select the **Future date** option in the **Value Date (Entry Date)** field. 4. The payoff amount for the date you selected will be displayed. ![Payoff value date options - Now or future date](@site/static/img/support/Payoff%20value%20date%20options%20-%20Now%20or%20future%20date.png) To preview all the balances of the loan on a particular day, select the future date from the calendar. The system will automatically calculate the balance for that day. The balances are calculated as per below example: * **Principal balance**: USD9000 * **Interest balance**: USD90.07 = USD82.85 (today interest balance) + USD7.22 (future interest for X days, starting from tomorrow) * **Fee balance**: USD280 = USD280 (today fee balance) + USD0 (future fees during X days, starting from tomorrow) * **Penalty balance**: USD472.73 = USD354.55 (today penalty balance) + USD118.18 (future penalty during X days, starting from tomorrow) * **Total payoff balance**: USD9842.80 = USD9000 + USD90.07 + USD280 + USD472.73 ![Preview pay off for a future value date where date is selected from the calendar](@site/static/img/support/Preview%20pay%20off%20for%20a%20future%20value%20date%20where%20date%20is%20selected%20from%20the%20calendar.png) :::note This option is only to **preview** the balances for future dates and not to perform the actual payoff for a future date. ::: --- # Payments Introduction URL: https://docs.mambu.com/docs/payment-gateway-introduction/ The Mambu Payment Gateway (MPG) provides a user interface that facilitates one-time and recurring transactions using the Single Euro Payments Area (SEPA) scheme. For more information, see [Mambu Payment Gateway](/docs/mambu-payment-gateway). The Mambu Payments Gateway API allows you to make, receive, reject, and refund standards-based payments. For more information, see our [Mambu Payments Gateway API Reference](https://api.mambu.com/payments-api/#welcome). The MPG is tightly connected to Mambu's core banking features. Payments are routed to the correct Mambu accounts, payer and payee details are automatically inserted into SEPA messages when possible, and general ledger accounts are kept up to date both for payments and, if using Anti-Money Laundering (AML), for movements of funds into suspense accounts. ![payments gateway UI showing pending transactions](@site/static/img/support/payments%20gateway%20UI%20showing%20pending%20transactions.png) The core functionality of the MPG can be extended to support additional AML and suspense account flows, such as using a pre-built Mambu Connector running on the Mambu Process Orchestrator and a supported partner such as ComplyAdvantage. Using the MPG, customers can quickly gain access to the entire market of more than 27 countries in the Eurozone. ## Supported flows The Mambu Payment Gateway has been built according to the guidelines set out in the 2021 SEPA Credit Transfer and 2021 SEPA Direct Debit Core rulebooks and handles the following flows and messages: ### Credit Transfer Pacs.008.001.02 - Incoming/Outgoing payment Camt.056.001.01 - Incoming/Outgoing Recall request Pacs.004.001.02 - Incoming/Outgoing Authorize recall request Camt.029.001.03 - Incoming/Outgoing Deny recall request Pacs.002.001.03 - Incoming rejection/Outgoing positive status report ### Credit Transfer Inquiries Camt.027.001.06 - Claim Non-Receipt Pacs.028.001.01 - Status update on Recall of SCT Pacs.028.001.01 - Status update on Inquiry for existing camt.087 or camt.027 Camt.087.001.05 - Claim value-date correction Pacs.004.001.02 - Positive response for Request for Status Update on Recall Camt.029.001.08 - Sepa Inquiries response - Only negative confirmation at the moment for camt.087 ### Direct Debit Pacs.003.001.02 - Incoming/Outgoing collection Pacs.007.001.02 - Incoming/Outgoing Reverse collection (sent by Creditor to Debtor) Pacs.004.001.02 - Incoming/Outgoing Refund collection (sent by Debtor to Creditor) Pacs.002.001.03 - Incoming CSM rejection ## General prerequisites Before using Mambu Payment Gateway, you must have the following: - SEPA registration - A system to manage mandates for direct debit payments - Access to an automated clearing house - The ability to generate and register IBANs for accounts ## Mambu Core Banking prerequisites :::note Our [Getting Started](/docs/payments-settings) article walks through configuring the items listed below. ::: In Mambu Core Banking, you will need: - An [API Consumer](/docs/api-consumers) and [API Key](/docs/api-consumers#api-keys) - A Mambu user account with [API Access rights](/docs/creating-new-users#access-rights) - [Transaction Channels](/docs/transaction-channels) that follow the pattern `----`. For more information, see [Create the payment transaction channels](/docs/payments-settings#3-create-the-payment-transaction-channels). - If using AML functionality, you will need accounts set up to hold [suspended payments](/docs/aml-suspense-accounting) while checks are being processed. - Mambu accounts should be mapped to an IBAN using the appropriate External Account Representation (EAR) endpoint. For more information, see [External Account Representation - createMappings](https://api.mambu.com/payments-api//#external-account-representation-createmapping) in our Mambu Payments Gateway API Reference. --- # System Properties URL: https://docs.mambu.com/docs/payment-gateway-system-properties/ The Mambu Payment Gateway (MPG) has multiple configuration options to address your needs. All these options are available in the **System Properties** page, under the **Configuration** section of the MPG side menu. In the following article, we will describe what each configuration option does, as well as provide some examples. The system properties page is split into sub-sections, each with a group of related properties. Some of the configuration options in this article are marked as **Deprecated**. These have no effect regardless of the value and are scheduled for removal or change. ## Basic configuration This section contains the minimum set of information required for MPG to function correctly. It allows you to specify the Bank Identifier Code (BIC) of your bank and the automated clearing house (ACH) as well as the ACH system. ![basic-configuration](@site/static/img/support/basic-configuration.png) The table lists the available fields in the basic configuration section and you may select the field title for more information. | Field | Description | Required | | --- | --- | --- | | [Bank BIC](#bank-identifier-code) | The identifier of your bank. | Yes | | [ACH BIC](#ach-bic) | The identifier of the automated clearing house (ACH) used to process payments. | Yes | | [ACH System](#ach-system) | The channel through which the payment instruction is processed. Maximum of six characters. | Yes | | AML BIC Sender | Deprecated field. | No | | AML BIC Receiver | Deprecated field. | No | Below is more information about each field. ### Bank Identifier Code This is the BIC of your bank or financial institution. When first setting your basic configuration, you must provide the **Bank BIC** and local bank codes to the Mambu team so that they can finish setting up the payments system. By default, all newly created schedulers will be running using this BIC. This value will be populated under `InstgAgt>FinInstnId>BIC` in the group header of the generated outgoing messages, and incoming schedulers will pick up incoming messages, which have the same `InstdAgt>FinInstnId>BIC` value as the current BIC. In this example, outgoing schedulers will be generating Single Euro Payments Area (SEPA) messages with `TESTBICA` as the value for `GrpHdr>InstgAgt>FinInstnId>BIC`, and incoming schedulers will be picking up incoming SEPA messages, which have `TESTBICA` as the value for `GrpHdr>InstdAgt>FinInstnId>BIC` . The Mambu Payment Gateway also offers support for multiple BICs. For more information, see [Schedulers](/docs/schedulers-and-holidays#schedulers). :::warning If you plan to change the **Bank BIC** value, contact us through [Mambu Support](/docs/mambu-support). We will make sure that the value is correctly configured inside Mambu dependent systems. ::: ### ACH BIC This is the BIC code of your Automated Clearing House (ACH), also sometimes referred to as Clearing and Settlement Mechanism (CSM). It is populated under the `InstdAgt>FinInstnId>BIC` in the generated message header. In this example, outgoing schedulers will be generating SEPA messages with `GrpHdr>InstdAgt>FinInstnId>BIC`, with the value `TESTBICB`. ### ACH System This is the proprietary code of the clearing system type. It is populated under `ClrSys>Prtry` in the generated message header. In this example, Outgoing Schedulers will be generating SEPA messages with `ST2` as the value of `GrpHdr>SttlmInf>ClrSys>Prtry`. ## Extra System Properties The extra system properties section allows you to configure parameters related to security. ![Extra system properties](@site/static/img/support/payments--extra-system-properties.png) ### Password Expiration Days This is the password expiration for user accounts in days. After which the user will be prompted to change their password. In this example, if a user has not updated their password in the past year, they will be redirected to the password change page upon logging in. ### Failed login attempts This is the number of failed login attempts allowed for user accounts before their account gets disabled and needs to be re-enabled by an administrator. In this example, if a user fails to login five or more times consecutively, their account will be automatically disabled. An MPG user with administrator permissions is then able to re-enable the account. ### Number of password history to keep This is the number of previous passwords a user is forbidden to re-use when changing their password. In this example, the MPG users cannot use any of the previous five passwords when configuring a new one. ### Password Minimum Length If a value is provided here, users will not be able to set passwords that do not meet this minimum length. The default minimum length of passwords is eight characters. In the example, users would need to use 13 or more characters in their passwords. ### Test code - Deprecated ### Outgoing transactions limit This is the limit of transactions which will be included inside Outgoing SEPA Credit Transfer (CT) pacs.008 and Anti-Money Laundering (AML) pacs.008 messages. In this example, if there are 20 pending outgoing transactions, two pacs.008 messages with 10 transactions each will be generated and sent to the configured callout. ## Callout Configuration The callout configuration allows you to specify the settings for the system where your payment messages will be sent. ![callout-configuration\(2\)](@site/static/img/support/callout-configuration%282%29.png) :::warning We strongly recommend that you implement a deduplication or idempotency mechanism on the service which is receiving the outgoing messages. Networks can be unstable and it is possible that the same payment message can be sent multiple times. ::: ### Target URL Callout URL to which payment messages should be sent. It must support `POST` and `PUT` requests with an `application/xml` body. ### HTTP Method HTTP method to be used when calling the callout URL. `POST` or `PUT` are currently supported. ### Content Type Content type to be used when calling the callout URL. Only `application/xml` is supported. ### Authorization type Authorization type to be used when calling the callout URL. `No authorization` and `Basic authorization` are currently supported. When selecting `Basic authorization`, you must also specify the username and password. #### Retry policy The retry policy for all Mambu Payment Gateway callouts (for example, for SEPA and AML) is as follows. When a callout fails - with a responce of 4xx, 5xx, or timed out - an alarm is raised in the MPG alerts section containing the following information: * Failure reason * Number of retries executed so far The callout will be automatically sent out again on the next outgoing scheduler run, as per your configuration. For example, if your outgoing scheduler is configured to run twice a day and it fails the first time, then the callout will be retried only once on that day, and twice every following day, until it succeeds. :::note Due to the importance of these callouts, the number of retries is unlimited. The retries will continue until the callout is acknowledged by the designated target. ::: ## Incoming Direct Debit Configuration ![payments--incoming-direct-debit-configuration.png](@site/static/img/support/payments--incoming-direct-debit-configuration.png) ### Maximum allowed days to retry When receiving an incoming SEPA Direct Debit (DD) instruction which initially fails (for example insufficient amount), the debtor bank can retry the debit transaction for a specific number of days before sending back a return instruction. This option specifies the maximum number of days to retry failed debit transactions before returning the DD transaction. In this example, the Mambu Payment Gateway will retry the debit transaction for four days, according to the Incoming SEPA DD Retry Scheduler configuration, before sending an outgoing return instruction on the fifth day. ## AML Configuration If AML is enabled, the Mambu Payment Gateway will send the incoming credit instruction to your AML service for a compliance check. The check should be performed in the external system and the results should be delivered via API. It is possible to configure multiple AML statuses that can be reflected in the screen to show the current state of the transaction. ![aml-configuration\(2\)](@site/static/img/support/aml-configuration%282%29.png) ### AML Credit Transfer Incoming Enabled If enabled, Incoming SEPA Credit Transfers will be sent to the AML Callout URL for AML verification before being credited to the client account. If disabled, Incoming SEPA Credit Transfers will be immediately credited to the client account. ### AML Credit Transfer Outgoing Enabled If enabled, Outgoing SEPA Credit Transfers will be sent to the AML Callout URL for AML verification after the amount has been debited from the client account, but before the actual SEPA pacs.008 message has been sent to the Callout URL. If disabled, Outgoing SEPA Credit Transfers will be sent to the Callout URL without passing through the AML checks. ### AML Direct Debit Incoming Enabled If enabled, Incoming SEPA Direct Debits will be sent to the AML Callout URL for AML verification before being debited from the client account. If disabled, Incoming SEPA Direct Debits will be immediately debited from the client account. ### AML Direct Debit Outgoing Enabled If enabled, Outgoing SEPA Direct Debits will be sent to the AML Callout URL for AML verification before the actual SEPA pacs.003 message has been sent to the Callout URL. If disabled, Outgoing SEPA Direct Debits will be sent to the Callout URL without passing through the AML checks. ### AML Incoming Message Split Enabled When incoming SEPA Credit Transfers or Direct Debits are received and Incoming AML is enabled, the file is sent to the configured AML callout as a whole. In cases where the system targeted by the AML callout does not support handling of very large files, the Mambu Payment Gateway is now able to split the Incoming instruction into multiple smaller instructions before sending each of them to the AML callout. If the flag is set, you will be able to input the AML Incoming Message Transaction Batch Limit. When a value larger than zero is configured, for each incoming instruction which contains more than AML Incoming Message Transaction Batch Limit transactions, the MPG will split it up in batches which contain a maximum of AML Incoming Message Transaction Batch Limit transactions. All Group Header information will remain the same, except the Total Number of Transactions and Total Amount, which will reflect the actual information from the batch. In this example, incoming messages with more than 10 transactions will be split into multiple smaller instructions with at most 10 transactions each before being sent to the AML callout. ### Target URL AML Callout URL to which SEPA messages should be sent for AML verifications. ### HTTP Method HTTP method to be used when calling the Callout URL. `POST` or `PUT` are currently supported. ### Content Type Content type to be used when calling the Callout URL. `application/xml` and `application/json` are supported. Selecting one of them means that the AML Callout request will be of the specified type: XML or JSON. ### Authorization type Authorization type to be used when calling the Callout URL. `No authorization` and `Basic authorization` are currently supported. When selecting `Basic authorization`, you must also specify the Username and Password, as shown in the picture. ### AML Suspense Accounting IDs If AML Suspense Accounting Enabled is selected, AML Suspense Accounting flows will be executed when a transaction is AML Suspended. More information about this feature is available in the [AML & Suspense Accounting](/docs/aml-suspense-accounting) section. After enabling AML Suspense Accounting, a new section will be available giving the possibility to set a Suspense Account for each BIC. All suspended incoming or outgoing payments which were initiated with a specific BIC will be redirected to the Suspense Account assigned to it. ![suspense-account-configuration](@site/static/img/support/suspense-account-configuration.png) In this example, two separate BICs are configured in the MPG, and a Suspense Account ID is specified for each of them. ## Message processing configuration The message processing configuration settings control whether there is automatic processing and, in some cases, response generation for certain message types. If automatic processing is not enabled, the response messages will generally need to be manually sent using the Mambu Payment Gateway UI. ![Message processing configuration.png](@site/static/img/support/Message%20processing%20configuration.png) ### Automatically respond with negative response for failed recalls due to business reasons If this flag is enabled, when a camt.056 Recall instruction processing fails due to a business reason (for example, account locked or not enough balance), a negative response with reason code `AGNT` will be automatically published. If this flag is disabled, the negative response must be manually triggered via the SEPA CT Pending section under Authorization from the UI. This flag is enabled by default. ### Automatically process pacs.002.001.03 messages with RJCT group status If this flag is enabled, when an incoming pacs.002 rejection instruction is received with `RJCT` as group status, all transactions from the original pacs.008 instruction will be reverted. If this flag is disabled, transactions will no longer be automatically reverted, and instead the MPG will wait for some manual input to fix the original pacs.008 instruction and re-send it to the configured Callout. You can spot the Rejected transactions either in the MPG UI or the Instructions API, and then contact us to fix and reprocess the pacs.008 instruction. This flag is enabled by default. Please contact us through [Mambu Support](/docs/mambu-support). ### Generate positive pacs.002.001.03 messages for Credit Transfers When this setting is enabled the system will generate a positive payment status report (pacs.002.001.03 message) when all payments from an incoming SEPA credit transfer message have been settled. The group status (``) of the message will have the value `ACCP`. This is not a standard SEPA European Payments Council (EPC) message or business flow, thus the functionality can be enabled through this flag. This flag is enabled by default. ### Generate positive pacs.002.001.03 messages for Credit Transfers with service level TGT When this setting is enabled the system will generate a positive payment status report (pacs.002.001.03 message) when all payments from an incoming message where the TARGET2 settlement method was used, have been settled. The group status (``) of the message will have the value `ACCP`. This is not a standard SEPA EPC message or business flow, thus the functionality can be enabled through this flag. This flag is enabled by default. ### Generate UETR-compliant Transaction ID for outgoing Credit Transfers with service level TGT If payments with service level TGT are supported, enabling this property will allow generating the Transaction ID as an UUIDv4 without dashes, if not provided. The value of the Transaction ID is the actual outgoing Payment Order ID. ### Automatically process requests for Status Update on Recall If this flag is enabled, when a Request for Status Update for a Recall instruction is received (pacs.028.001.01), it will be automatically processed by the MPG and a negative response (camt.029.001.03) will be generated and sent out. If disabled, Status Update instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default. ### Automatically process requests for Status Update on SCT Inquiry If this flag is enabled, when a Request for Status Update for an SEPA Credit Transfer (SCT) Inquiry instruction is received (pacs.028.001.01), it will be automatically processed by the MPG and a negative response (camt.029.001.08) will be generated and sent out. If disabled, Status Update instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default. ### Automatically process Claims Non-Receipt If this flag is enabled, when a Claim of Non-Receipt (camt.027.001.06) for an SCT instruction is received, it will be automatically processed by the MPG and a negative response (camt.029.001.08) will be generated and sent out. If disabled, SCT Inquiry instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default. ### Automatically process Claims for Value Date Correction If this flag is enabled, when a Claim of Non-Receipt (camt.087.001.05) for a SCT instruction is received, it will be automatically processed by the MPG and a negative response (camt.029.001.08) will be generated and sent out. If disabled, SCT Inquiry instructions will wait for a manual trigger of the response, either through the MPG UI or API. This flag is enabled by default. ### Settle Incoming SEPA Instant Asynchronously With this flag enabled, the processing of an Incoming SEPA Instant payment will pause after the Positive Status Report Message (pacs.002.001.03) is sent to the relevant Clearing and Settlement Mechanism (CSM). The processing will continue and the settlement will take place after a `POST` request is made to the `api/v1/payments:settleInstantPayment` endpoint. For more information, see [settleInstantPayment](https://api.mambu.com/payments-api//#sepa-credit-transfers-settleinstantpayment) in our Mambu Payments Gateway API Reference. ## SMS Configuration The SMS configuration section is available to you if you want to use multi-factor authentication (MFA). For more information about enabling MFA for MPG users, see [User Management and Audit Trail - Multi-factor authentication](/docs/user-management-and-audit-trail#multi-factor-authentication-mfa) ![sms-configuration](@site/static/img/support/sms-configuration.png) ### SMS Gateway SMS system to be used for sending Multi-Factor Authentication (MFA) SMS messages. Currently `TWILIO` and `INFOBIP` are supported, or `NONE`. If one of the first two options are selected, you must input the following information as well. ### Account Username Username to be used for authentication with the SMS Gateway. ### Account Password Password to be used for authentication with the SMS Gateway. ### Phone Number Actual phone number from which the SMS messages will be sent. --- # Payment Holidays URL: https://docs.mambu.com/docs/payment-holidays/ Payment holidays allow banks to offer their customers a temporary break from payments, while interest still continues to accrue on the outstanding mortgage balance during this period. This means that, even if the term doesn't extend, the total amount the borrower owes will increase, leading to higher future payments. Lenders can choose whether a [Dynamic Mortgage](/docs/dynamic-mortgages) or [Interest-Only](/docs/equal-installment-interest-only-loans) loan can extend or keep its original term during the product configuration process in the **Repayment Schedule Editing** section of Repayment Scheduling. Here's how payment holidays without extending the term work for dynamic mortgages and interest-only loans: ## Dynamic mortgages Dynamic mortgages are often designed with built in flexibility, making them well-suited for payment holidays that don't extend the original loan term. ### Core functionality * **Zeroing of installment details**: For the payment holiday installments, the *total expected* will be set to 0. * **Principal recalculation**: Missed principal payments are implicitly deferred. The system ensures the schedule maintains the same number of instalments. * **PMT recalculation**: The payment (PMT) of the upcoming installments is recalculated to account for the deferral of principal and the eventual application of payment holiday interest. This new PMT maintains the original number of installments. The calculation uses the following parameters: * Interest rate (IR) * Number of remaining installments * Principal balance * **PMT formula**: PMT(Interest rate/12, remaining number of installments, −principal balance of payment holiday installment) * **Accrual of PH interest**: Interest for the payment holiday period continues to accrue. This accrued PH interest is logged in a dedicated **Payment Holidays Interest Accrued** balance. * **Manual application of payment holiday interest**: Unlike regular interest, interest from payment holiday installments is not applied automatically by a cron job. Instead, this interest must be manually applied by the lender after the payment holiday period has concluded. * This application can be done either in bulk on the first installment after the payment holiday period, or in smaller portions across multiple/all remaining installments of the schedule. * **Allocation of applied payment holiday interest**: Once the payment holiday interest is manually applied by the lender, it will be allocated to the interest balance, consistent with regular interest. ### How do payment holidays work in dynamic mortgages 1. The borrower applies for a payment holiday for a specified period (e.g., 1-3 months, varying by lender and product). 2. During the holiday, the borrower makes no payments. a. The affected installments are marked as *Grace*, and their expected principal, interest, and total due amounts are set to zero. 3. The system immediately recalculates the PMT for the remaining original number of installments, adjusting them to account for the deferred principal and the upcoming application of payment holiday interest. Lenders can view these new monthly payments right after the payment holiday installments are set up. 4. Interest continues to accrue on the principal balance in the background and is logged in the **Payment Holidays Interest Accrued Balance**. 5. After the payment holiday, the lender must manually apply the accrued payment holiday interest. This applied interest then increases the total due of subsequent instalments. ## Interest-only loans For interest-only loans, payment holidays without term extension also result in increased future payments due to continued interest accrual on the outstanding balance. ### Core functionality * **Automatic interest accrual**: The interest that accrues during the payment holiday (PH interest) is automatically calculated and applied on the due date(s) of the payment holiday installment(s). This process is typically handled by a scheduled system job (cron job). * **Balance allocation**: The accrued payment holiday interest is initially recorded in a dedicated Payment Holidays Interest Accrued Balance. Once applied, this accrued payment holiday interest is also moved to the interest balance, similar to regular interest. * **Capitalization of missed interest**: The interest that accrues during the payment holiday is added to the outstanding loan balance. * **No direct principal impact on schedule**: Since interest-only loans primarily involve paying interest, the direct capital repayment portion isn't 'missed' in the same way as a capital repayment loan. However, the capitalized interest from the holiday increases the overall amount the borrower needs to repay at the end of the term. * **Schedule recalculation**: When the payment holiday installments are added, the loan schedule is recalculated. To maintain the original loan term, the future monthly interest-only payments will increase to cover the capitalized interest from the holiday. * **Payment (PMT) recalculation formula**: PMT=PMT(IR/12, Number of remaining installments, closing balance after payment holiday, initial PB, 0) * The Payment (PMT) of the upcoming installments is recalculated using these parameters: * Interest rate (IR) * Number of remaining installments * Closing balance of the payment holiday installment. This reflects the balance including capitalised interest. * Initial principal balance (PB). This parameter is specifically used for interest-only loans. ### How do payment holidays work in interest-only loans 1. The borrower applies for a payment holiday for a specified period (e.g., 1-3 months, varying by lender and product). 2. During the holiday, no payments are made. Interest continues to accrue on the closing balance of each installment. 3. Interest accrues and is applied on each installment due date, and then capitalized (becoming part of the loan’s closing balance). 4. Lenders can view the new monthly payments immediately after the payment holiday installments are set up. ## GL accounting for payment holiday interest When payment holiday interest accrual is enabled in accounting, accruals are logged as separate accounting entries using two dedicated GL financial resources at the loan product level: `Payment Holiday Interest Receivable` and `Payment Holiday Interest Income`. ### Configuring dedicated GL rules To record payment holiday interest in a separate GL breakdown from regular interest, you must configure accounting rules for both `Payment Holiday Interest Receivable` and `Payment Holiday Interest Income` at the loan product level. This configuration must be done explicitly — the system does not create these rules automatically. ### Fallback behaviour If no GL accounting rules are configured for payment holiday interest, the system will accrue it under the standard interest receivable account instead of returning an error. This ensures EOD interest accrual jobs always complete successfully, regardless of whether dedicated rules are in place. ![Configuring for payment holiday interest](@site/static/img/support/loans--payment-holidays-accounting-for-payment-holiday-interest.png) Without dedicated `Payment Holiday Interest Receivable` and `Payment Holiday Interest Income` rules configured at the product level, payment holiday interest will be indistinguishable from regular interest in your accounting records. :::note GL accounting for payment holiday interest is available on demand. Please reach out to your Customer Success Manager or to [support@mambu.com](mailto:support@mambu.com) for additional information or guidance. ::: --- # Payment Methods for Declining Balance Equal Installments (DBEI) Loans URL: https://docs.mambu.com/docs/payment-methods-for-dbei-loans/ For both dynamic and fixed term loans you can choose a payment method based on a declining balance with the borrower paying the loan down in equal installments. This type of loan allows a few different payment methods, which will have an impact on the schedule. To select a payment method for the declining balance equal installments loans: 1. In the main dashboard, go to **Administration** > **Products** > **Loans**. 2. In the bottom-right corner, select **New Loan Product**. 3. In the **Creating a new loan product** form, go to the **Repayment Scheduling** section and, under **Payment Method**, choose one of the following methods, explained on this page. * **Standard Payments**, available for both **Fixed** and **Dynamic Term** loan products. * **Balloon Payments**, available for both **Fixed** and **Dynamic Term** loan products. * **Optimized Payments**, available for **Dynamic Term** loan products. * **Payment Plan**, available for **Fixed Term** loan products. 3. Aftering configuring the rest of the product, select **Save Product**. ![The repayment scheduling section of Creating a new loan product form with the following payment methods: standard payments, optimized payments, and baloon payments](@site/static/img/support/interest-calculation-methods-for-dbei-loans-1380x1284.png) ## Standard payments The *Standard Payment* method allows you to simply divide the total amount due (including interest) by the number of installments to be made to pay down the loan. If it is not possible to divide cleanly and [rounding has been enabled](/docs/setting-up-new-loan-products#rounding-of-repayment-schedules) for this product, the last payment may be slightly smaller or larger than the previous installments by a few cents. When rounding has not been enabled for the product and the principal cannot be cleanly divided, you will receive a warning, giving you the option of changing the amount or the number of installments to ensure the collection of the entire amount. ### Example In the following example, rounding has been enabled for the product and the last installment is slightly different than the rest of the installments. ![Declining balance equal installments loan fixed standard payments with rounding](@site/static/img/support/dbei_fixed_standard_with_rounding.png) In the following example, rounding has not been enabled for the product and the last installment is exactly the same as the rest of the installments. ![Declining balance equal installments loan fixed standard payments with no rounding warning](@site/static/img/support/dbei_fixed_standard_warning_no_rounding.png) ## Balloon Payments The *Balloon Payments* method allows you to offer borrowers a fixed repayment amount each month with the balance of the loan to be paid off in the final installment - which could be a lot bigger. These kinds of loans are typically targeted at businesses as a large final payment to settle the loan may be beyond the reach of an individual client. When you create a loan account based on this product you will be able to set the monthly payment amount and Mambu will calculate the schedule. For dynamic loans, the schedule, including the amount of the final payment will be recalculated based on any overpayments made by the borrower. ### Examples The following is an example showing balloon payment making interest-only payments and settling the whole loan with a large lump sum at the end. ![Balloon payments example](@site/static/img/support/dbei_fixed_balloon_schedule_interest_only.png) The following is an example showing balloon payment schedule paying down interest and some of the principal with the final payment being around half of what was initially lent to the client. ![Balloon payments example](@site/static/img/support/dbei_fixed_balloon_schedule_interest_and_principle.png) ## Payment Plan The *Payment Plan* method allows you to specify a periodic payment for a specific number of installments with rates being able to rise or fall with subsequent installments. ### Example For example, you can change the interest rate throughout the life of the loan. * You can reduce the interest rate by 1.5% each year. * You can have 10% interest rate for the first three months of the loan, and after this period decrease it to 8% and continue with this rate until the loan reaches maturity. When you create a loan account, you define your payment plan, as in the following example. ![Payment Plan account terms at Loan Account Creation](@site/static/img/support/loans--account-terms-configuration.png) The interest rate is computed based on the [Internal Rate of Return (IRR)](https://en.wikipedia.org/wiki/Internal_rate_of_return) formula. In the image below we have illustrated the schedule for the loan account defined in the example above. ![Payment Plan Schedule with two tiers](@site/static/img/support/loans--payment-plan-schedule.png) ## Optimised Payments The *Optimised Payments* method allows you to have a minimum deviation in the last installment when the first installment period is different from the rest of the repayment periods. The optimised payments method runs multiple iterations to find the best Periodic Payment (PMT) or total due and to generate the optimum schedule with minimum deviation and maintain it on the lower side. The deviation occurs due to the rounding of the repayment currency. The optimised payments method is applied when creating or activating a loan account and will be reapplied when any changes are made to the schedule due dates or the number of installments. ### Example In the following example with optimized payments, the last installment is only one cent smaller than the rest of the installments. Loan amount: USD1000 Interest rate: 100% Disbursement date: May 1, 2023 First repayment date: July 1, 2023 ![Optimised Payments calculation method](@site/static/img/support/optimized-payments-example-2330x530.png) :::note In this example, the first installment contains more interest because of the two-month period between the disbursement date and the first repayment date. ::: ## Equal installments for a longer first period across the loan schedule for simple interest In many regions, loan schedules commonly feature equal installments, with the first repayment typically due 2-3 months after disbursement. During this initial period, substantial interest can accrue, particularly with high interest rates, potentially causing the interest to exceed the total first installment due. To address this, a specific implementation is available for certain product configurations. If the calculated interest on an installment surpasses the total amount due, the excess interest will be carried forward to future installments. Mambu will cap the interest charged for that installment at the total amount due, meaning no principal will be collected. This process continues until the interest amount is less than the total due, at which point principal collection can begin. This feature applies to the following product configuration: * **Product Type**: Dynamic Term Loan * **Interest Calculation**: Declining Balance Equal Installments * **Calculate Interest using**: Principal Only * **Payment Method**: Optimized * **Pre-Payment Allocation**: On Upcoming Pending Installment Only * **Pre-Payment Recalculation**: Reduce Number of Installments * **Mark Principal as Paid When**: Principal Expected is Paid * **Overdue Payments**: Increase the Overdue Installments The **Equal Installments for longer 1st period** checkbox will appear in the **Repayment Scheduling** section of the Loan Product creation form when the above product configuration is used. ![Equal installments for longer first period](@site/static/img/support/equal-installments-for-longer-first-period.png) The toggle is activated when the calculated installment exceeds the total amount due. This can be reviewed during Loan Account configuration using the Preview Schedule. A **Carry forward interest split** checkbox has been added to display the amount of interest carried over to subsequent installments. The following examples show the difference between the two options: Without selecting the checkbox: ![Carry forward interest split un-selected](@site/static/img/support/carry-forward-interest-split.png) With the checkbox selected: ![Carry forward interest split selected](@site/static/img/support/carry-forward-interest-split-2.png) Selecting the **Carry forward interest split** checkbox will show the carried-forward interest amount in the **Schedule** tab. See the examples below. Without selecting the checkbox: ![Carry forward interest split un-selected](@site/static/img/support/carry-forward-interest-split-3.png) With the checkbox selected: ![Carry forward interest split selected](@site/static/img/support/carry-forward-interest-split-4.png) :::note This implementation is currently only supported on the product configuration mentioned above. Payment holidays cannot be defined when the **Equal Installments for longer 1st period** checkbox is enabled. ::: --- # Payment Modification Thresholds (PMT Thresholds) URL: https://docs.mambu.com/docs/payment-modification-thresholds/ To provide greater flexibility in managing loan payments, especially in response to interest rate changes, overpayments or fee capitalization actions, the Mambu system uses “thresholds”. These determine when upcoming payment amounts (PMT) are updated in the loan schedule. This ensures consistency with direct debit notifications and allows for immediate reflection of changes when appropriate. ## How it works A threshold is defined as a specific number of days prior to an installment's due date. When a relevant event (like an interest rate change, fee capitalisation or an overpayment) occurs, the system checks if the event date falls before or after this threshold for the upcoming installment. **Example of threshold calculation** Threshold = 15 days * `dueDate`=2024-05-20, * `directDebitDate`=2024-05-05, * `transactionDate`=2024-05-05, **after threshold** * If the transaction occurs in the exact day of the threshold it is considered as being posted after the threshold so the upcoming installment PMT is not recalculated. Threshold=15 days * `dueDate`=2024-05-20, * `directDebitDate`=2024-05-05, * `transactionDate`=2024-05-04, **before threshold** * **Event occurs before threshold**: If the event (e.g., interest rate change, overpayment) happens before the threshold date for the next scheduled installment, the PMT of the upcoming installment will be updated to reflect the change. * **Event occurs after threshold**: If the event happens after the threshold date for the next scheduled installment, the PMT of the upcoming +1 installment will be updated. The current or immediately upcoming installment's PMT will remain unchanged, preserving consistency with any already-sent direct debit notifications. :::note No matter how the PMT is updated, interest accrual of the loan account always changes immediately when a relevant transaction occurs. This means the interest will be calculated based on divisions, taking into account any event posted to your account, such as an interest rate change, an overpayment, or fee capitalisation. ::: This threshold can be set up at the product level, acting as a default setting for any new accounts created under that product. However, this default value can be changed when an individual account is being set up. ![pmt threshold method](/img/support/pmt-threshold-method.png) PMT adjustment threshold determines whether the total due of the current installment is adjusted after an interest rate change or an overpayment. If the time interval between the interest rate change and the due installment is greater than the specified threshold, the total due is recalculated to reflect the new interest rate. Otherwise, the total due remains unchanged. --- # Payment Order Flow URL: https://docs.mambu.com/docs/payment-order/ Payment order flows describe the stages that a payment order may go through and the payment status it may have after each stage. Mambu supports one payment order flow for outgoing payments and two payment order flows for incoming payments. For a list of the available payment statuses, see [Payment statuses](#payment-statuses). regarding incoming payments, in one payment order process, AML checks happen before the payment order is created. This is the current default process for all customers. In the other payment order process, AML checks happen after the payment order is created. If you want to enable this second payment order flow process, please contact us through [Mambu Support](/docs/mambu-support). :::note All Mambu customers will eventually transition from the current default payment order flow for incoming payments, where AML checks happen before payment order creation, to the new payment order flow, where AML checks happen after payment order creation. You will be notified well ahead of time before we deprecate the original payment order flow and enforce the transition for all customers. ::: The main difference between the two incoming payment order flow processes is that when AML checks happen before the payment order is created, you and your other payment systems are not notified of rejected incoming payments. However, when AML checks happen after payment order creation, you and your other payment systems will be notified about rejected incoming payments and you're able to manage the rejected incoming payments. Below we describe all of the available flows and you may visit the relevant section: * [Outgoing payment order flow](/docs/payment-order#outgoing-payment-order-flow) * [Incoming payment order flow with AML checks before payment order creation (default)](/docs/payment-order#incoming-payment-order-flow-with-aml-checks-before-payment-order-creation) * [Incoming payment order flow with AML checks after payment order creation (available upon request)](/docs/payment-order#incoming-payment-order-flow-with-aml-checks-after-payment-order-creation) You may also set up webhook or streaming API notifications in order to receive notifications when a payment order goes through a stage in a payment order flow and gets a different payment status. For more information, see [Payment events](#payment-events). ## Payment statuses The table below lists the available payment statuses that a payment order can be in. | Name | Status | Description | | --- | --- | --- | | Received | `RCVD` | Payment initiation has been received (input has been validated). | | Accepted technical validation | `ACTC` | Payment order has been accepted based on the requested execution time. | | Customer Profile Validation in Progress | `CPVP` | The previous technical validation was successful. The customer profile validation has started. | | Accepted settlement in process | `ACSP` | Payment order has been executed (the corresponding transaction, either debit or credit, has been posted in Mambu core). | | Accepted settlement completed | `ACSC` | Payment order completed (SEPA message has been sent to callout URL). | | Rejected | `RJCT` | Payment request has been rejected. | ## Outgoing payment order flow The processing of a payment order is done in four stages: initiate, accept, clear, and settle. AML checks happen during the settle stage. After a payment passes each of these stages, it receives a specific status. If at any of these stages, the payment is rejected, it will receive a rejected `RJCT` status. ![Outgoing Payment Order Flow Process](@site/static/img/support/outgoing_payment_order_flow_process%20%282%29%281%29.jpg) ### Initiate stage The payment order is initiated by the Payment Service User via the [Mambu Payments Gateway API](https://api.mambu.com/payments-api//#welcome). In this stage, there are several validations done on the SEPA debtor agent, SEPA creditor agent, and the currency. If the payment order does not pass all of these validations, it can get a rejected (`RJCT`) status. If the payment order does pass all of these validations, then it will get a received (`RCVD`) status. ### Accept stage The payment order is validated and enriched with additional data, such as a BIC code. If the execution date is the current date in the case of credit transfers, then the payment order gets an accepted technical validation (`ACTC`) status. Otherwise, it will get a rejected (`RJCT`) status. ### Clear stage In the clear stage, certain checks are carried out and if the payment order passes all the checks then the actual transaction on the deposit account is carried out and the payment gets an accepted settlement in process (`ACSP`) status. Next, it will move to the settlement stage. If the payment order does not pass all the checks, then the payment order gets a rejected (`RJCT`) status. This may happen for example, if: - The debtor has insufficient funds. - The account is blocked. - The account does not exist. - The IBAN is not linked to a deposit account in Mambu. :::note The routing can be determined in consideration of the following criteria: account number or IBAN of the creditor or debtor, bank account number or BIC of the creditor or debtor. ::: ### Settle stage In the settlement stage, outgoing payments go through AML checks. If everything goes well, we initiate the SEPA transaction (either pacs 008 or pacs 003) to the callout URL. The payment order is executed on the beneficiary side. In this case, the payment order will get an accepted settlement completed (`ACSC`) status. For more information, see [Settlement](#settlement). If there is an issue at this point, for example, the URL is not accessible, or the outgoing payment doesn't pass AML checks, then the payment gets a rejected (`RJCT`) status. ### Rejected If the payment is rejected in any stage of the payment order flow, it gets a rejected (`RJCT`) status. :::note A payment will also receive a rejected (`RJCT`) status if: * an incoming pacs.002 or pacs.004 message is received * an incoming camt.056 is authorised via pacs.004 ::: ## Incoming payment order flow with AML checks before payment order creation This is the default payment order flow process for incoming payments. A payment order is created only if the incoming payment passes AML checks and thereafter the processing of the payment order is done in four stages: initiate, accept, clear, and settle. After a payment passes each of these stages, it receives a specific status. If at any of these stages, the payment is rejected, it will receive a rejected `RJCT` status. ![Incoming payment order flow where AML checks happen before payment order creation diagram](@site/static/img/support/Payment%20state%20transitions%20%281%29%20%281%29%281%29.jpg) ### Initiate stage The payment order is initiated by the Payment Service User via the [Mambu Payments Gateway API](https://api.mambu.com/payments-api//#welcome). In this stage, there are several validations done on the SEPA debtor agent, SEPA creditor agent, and the currency. If the payment order does not pass all of these validations, it can get a rejected (`RJCT`) status. If the payment order does pass all of these validations, then it will get a received (`RCVD`) status. ### Accept stage The payment order is validated and enriched with additional data, such as a BIC code. If the execution date is the current date in the case of credit transfers, then the payment order gets an accepted technical validation (`ACTC`) status. Otherwise, it will get a rejected (`RJCT`) status. ### Clear stage In the clear stage, certain checks are carried out and if the payment order passes all the checks then the actual transaction on the deposit account is carried out and the payment gets an accepted settlement in process (`ACSP`) status. Next, it will move to the settlement stage. If the payment order does not pass all the checks, then the payment order gets a rejected (`RJCT`) status. This may happen for example, if: - The debtor has insufficient funds. - The account is blocked. - The account does not exist. - The IBAN is not linked to a deposit account in Mambu. :::note The routing can be determined in consideration of the following criteria: account number or IBAN of the creditor or debtor, bank account number or BIC of the creditor or debtor. ::: ### Settle stage In the settlement stage, we initiate the SEPA transaction (either pacs 008 or pacs 003) to the callout URL. If everything goes well, the payment order is executed on the beneficiary side. In this case, the payment order will get an accepted settlement completed (`ACSC`) status. For more information, see [Settlement](#settlement). If there is an issue at this point, for example, the URL is not accessible, then the payment gets a rejected (`RJCT`) status. ### Rejected If the payment is rejected in any stage of the payment order flow, it gets a rejected (`RJCT`) status. :::note A payment will also receive a rejected (`RJCT`) status if: * an incoming pacs.002 or pacs.004 message is received * an incoming camt.056 is authorised via pacs.004 ::: ## Incoming payment order flow with AML checks after payment order creation The processing of a payment order is done in five stages: initiate, accept, clear, AML check, and settle. After a payment passes each of these stages, it receives a specific status. If at any of these stages, the payment is rejected, it will receive a rejected `RJCT` status. This payment order flow process allows you to properly manage rejected incoming payment order flows. ![Incoming payment order flow with AML checks after payment order creation diagram](@site/static/img/support/incoming_payment_order_flow_aml_checks_after_payment_order_creation%20%281%29.jpg) ### Initiate stage The payment order is initiated by the Payment Service User via the [Mambu Payments Gateway API](https://api.mambu.com/payments-api//#welcome). In this stage, there are several validations done on the SEPA debtor agent, SEPA creditor agent, and the currency. If the payment order does not pass all of these validations, it can get a rejected (`RJCT`) status. If the payment order does pass all of these validations, then it will get a received (`RCVD`) status. ### Accept stage The payment order is validated and enriched with additional data, such as a BIC code. If the execution date is the current date in the case of credit transfers, then the payment order gets an accepted technical validation (`ACTC`) status. Otherwise, it will get a rejected (`RJCT`) status. ### Clear stage In the clear stage, certain checks are carried out and if the payment order passes all the checks then the payment gets a customer profile validation in progress (`CPVP`) status. If the payment order does not pass all the checks, then the payment order gets a rejected (`RJCT`) status. This may happen for example, if: - The debtor has insufficient funds. - The account is blocked. - The account does not exist. - The IBAN is not linked to a deposit account in Mambu. :::note The routing can be determined in consideration of the following criteria: account number or IBAN of the creditor or debtor, bank account number or BIC of the creditor or debtor. ::: ### AML check stage In the AML check stage, certain checks are carried out and if the payment order passes all the checks then the actual transaction on the deposit account is carried out and the payment gets an accepted settlement in process (`ACSP`) status. Next, it will move to the settlement stage. If the payment order does not pass all the checks, then the payment order gets a rejected (`RJCT`) status. ### Settle stage In the settlement stage, we initiate the SEPA transaction (either pacs 008 or pacs 003) to the callout URL. If everything goes well, the payment order is executed on the beneficiary side. In this case, the payment order will get an accepted settlement completed (`ACSC`) status. For more information, see [Settlement](#settlement). If there is an issue at this point, for example, the URL is not accessible, then the payment gets a rejected (`RJCT`) status. ### Rejected If the payment is rejected in any stage of the payment order flow, it gets a rejected (`RJCT`) status. :::note A payment will also receive a rejected (`RJCT`) status if: * an incoming pacs.002 or pacs.004 message is received * an incoming camt.056 is authorised via pacs.004 ::: ## Settlement In Mambu we deal with two different settlement flows, intrabank and interbank. ### Intrabank payment flow Intrabank payments occur when the originator and the beneficiary are in the same financial institution. In this case, a transfer transaction is made from the originator to the account of the beneficiary. The `paymentDetails` object of the transfer will include details of the payment request, including the end to end ID and scheme used, for example SEPA. In this case, the flow ends when the settlement is complete and the beneficiary account is credited or debited. The payment message doesn't reach the Mambu Payment Gateway UI because the Mambu Payment Gateway only handles interbank payments. ### Interbank payment flow Interbank payments occur when the originator and beneficiary are in different financial institutions. In this case, the Mambu Payment Gateway generates the files necessary for the specific payment based on the scheme being used. For example, in an outgoing SEPA payment, after Mambu receives the payment request and identifies that it is a SEPA credit transfer payment, Mambu will generate a pacs.008 message. For more information about pacs.008 messages, see [Pacs.008](/docs/pacs008). The Mambu Payment Gateway will create a deposit or withdrawal transaction against the customer account matching the IBAN contained in the payment message. The `paymentsDetails` object will contain information about the original request, including the payment scheme used and end to end ID. This flow ends once the payment message is sent to the automated clearing house (ACH) or the clearing and settlement mechanism (CSM) to proceed with the settle procedure. ## Payment events You can opt to receive webhook or streaming API notifications as a payment goes through each of the stages and statuses in the payment order flow. For more information on setting up Streaming API events, see [Streaming API](/docs/streaming-api) in our User Guide and the [Streaming API Reference](/api/pages/streaming/streaming-index). For more information about setting up webhook notifications, see [Defining a New Webhook](/docs/webhooks-defining-a-new-webhook). In order to create such events, when creating your notification template, you must select **Payment Order** as the event target and **Payment Order Activity** as the event trigger. :::note The **Payment Order Activity** event trigger relates only to credit transfer events. If you want to receive notifications about direct debits, you may select the **Collection Order Activity** event trigger. ::: :::note You will only have access to the payment-related event targets and [event triggers](/docs/event-triggers) if you have the Payments capability enabled. ::: ### Placeholders To define the content of your notification, you have access to payment-related placeholders. For more information about placeholders, see [Placeholders](/docs/placeholders). Below is a list of the placeholders available for payments: **Creditor** * Creditor Account Currency * Creditor Account IBAN * Creditor Account Id * Creditor Account Identification * Creditor Account Scheme * Creditor Address - Building Number * Creditor Address - City * Creditor Address - Country Code * Creditor Address - Line1 * Creditor Address - Line2 * Creditor Address - Postal Code * Creditor Address - Street * Creditor BICFI * Creditor Name **Debtor** * Debtor Account Currency * Debtor Account IBAN * Debtor Account Id * Debtor Account Identification * Debtor Account Scheme * Debtor Address - Building Number * Debtor Address - City * Debtor Address - Country Code * Debtor Address - Line1 * Debtor Address - Line2 * Debtor Address - Postal Code * Debtor Address - Street * Debtor BICFI * Debtor Name **Payment** * End To End Identification * Error Description * Errors * Instructed Amount * Instructed Amount Currency * Instructed Transaction ID * Instruction Identification * Message Identification * Purpose Code * Remittance Issuer * Remittance Reference * Remittance Reference Type * Remittance Unstructured * Requested Execution Date * Requested Execution Time * Settlement Date * Status * Transaction ID * Ultimate Creditor * Ultimate Debtor * Value Date --- # Payment Plan for Fixed Term Loans URL: https://docs.mambu.com/docs/payment-plan-for-fixed-term-loans/ There are cases in which organizations may want to offer loans with a defined *payment plan*, meaning that they would specify a periodic payment for a specific number of installments. When you choose **Payment Plan** as a method of payment in the **Repayment Scheduling** section of the [Creating a new loan product form](/docs/setting-up-new-loan-products#repayment-scheduling), you can change the interest rate throughout the life of the loan. For example: * You can reduce the interest rate by 1.5% each year. * You can have 10% interest rate for the first three months of the loan, and after this period decrease it to 8% and continue with this rate until the loan reaches maturity. * * * ## Product definition :::note The **Payment Plan** can be configured only for **Fixed Term Loans** with a **Declining Balance Equal Installments** interest calculation method. ::: ![Payment Plan option under Repayment Scheduling section](@site/static/img/support/loans--repayment-scheduling-configuration-5.png) *** ## Account definition In the below image we have illustrated the loan account definition with two payment amounts for a specific number of installments: * USD200 for the first 12 installments * USD80 for the 13th to the 15th installment The interest rate is computed based on the [Internal Rate of Return (IRR)](https://en.wikipedia.org/wiki/Internal_rate_of_return) formula. ![Payment Plan account terms at Loan Account Creation](@site/static/img/support/loans--account-terms-configuration.png) ### Account schedule In the below image we have illustrated the schedule for the Loan Account defined in the example above. ![Payment Plan Schedule with 2 tiers](@site/static/img/support/loans--payment-plan-schedule.png) --- # Paymentology Integration URL: https://docs.mambu.com/docs/paymentology-integration/ We partner with [Paymentology](https://www.paymentology.com) to provide card issuing and processing services. Paymentology is a card issuing platform providing an Open API. The Paymentology connector is for Mambu customers who want to offer debit cards to their clients. Using the Paymentology connector means you do not need to build out your own gateways or deal with messaging standards such as ISO 8583. Paymentolgy works globally and is integrated with the Visa, Mastercard, and MADA networks - allowing you or your clients to make the best choice of a card product. For more information about Paymentolgy see [Mambu Marketplace](https://mambu.com/partner/paymentology) or the [Paymentology website](https://www.paymentology.com/). The Mambu-Paymentology integration connects the Mambu banking platform and Paymentology payment card processing centre. The integration focuses on processing payment card authorization requests and clearing transactions as well as a list of various related messages, such as advices and reversals. Mambu is where the card account's available and ledger balance are maintained. ### Prerequisites Before working with cards, make sure you have your Mambu environment set up. There may be additional setup to be done in Paymentology if you intend to use their simulation workplace for the testing purposes. ### Architecture The Mambu-Paymentology integration is based on the Fast and Secure Transactions (FAST) message interface. Communication is done using two endpoints, to which Paymentology forwards payment card authorization and transaction messages, received from the network, and converted into the FAST v3 format. The received messages are mapped to the corresponding Mambu APIs, which are called in order to update the available and ledger balances of a Mambu payment card account. The first endpoint is dedicated to payment card authorization related messages, such as authorization requests, balances inquiries, various reversals, and advices. The full list of supported authorization messages is provided in [Authorizations endpoint](/docs/paymentology-integration#authorizations-endpoint). The second endpoint is dedicated to process debit and credit settlement transactions as well as transaction reversals. More details in [Transactions endpoint](/docs/paymentology-integration#transactions-endpoint). Currently the scope of the integration is limited to authorizations and card transactions coming from the Mastercard scheme. Accordingly the following cardholder transaction type codes are supported:
    Processing code Description Direction
    00 Purchase Debit
    01 Withdrawal Debit
    02 Debit Adjustment Debit
    09 Purchase with Cash Back Debit
    10 Account Funding Debit
    17 Cash Disbursement Debit
    18 Scrip issue Debit
    20 Purchase Return
    Refund    		 Credit
    21 Deposit Credit
    22 Credit Adjustment Credit
    23 Check Deposit Guarantee Credit
    24 Check Deposit Credit
    28 Payment Transaction Credit
    30 Balance inquiry None
    ### Authorizations endpoint The authorizations endpoint is dedicated to authorization processing. Authorization messages are checked for mandatory fields and processing codes are checked to ensure that they are supported. If the checks are passed, a corresponding Mambu API is called. The `200 OK` is returned with ISO8583 response fields, after receiving a response from Mambu. The response includes field `DE39 Response Code` with the defined ISO8583 response code, which is returned back to the Acquirer as a result of the authorization processing. If the checks are not passed, the `400 Bad Request` is returned along with the error reason. The following authorization messages are supported:
    Business case MTI DE3_1 Purpose
    Debit authorization request 0100 00, 01, 02, 09, 10, 17, 18 Create a debit hold if the available balance is sufficient.
    Credit authorization request 0100 20, 21, 22, 23, 24, 28 Create a credit hold.
    Incremental authorization request 0100 00, 01, 02, 09, 10, 17, 18 Increase a debit hold amount if the available balance is sufficient.
    Balance inquiry 0100 30 Get the ledger and the available balances of a card account.
    Debit authorization advice 0120 00, 01, 02, 09, 10, 17, 18 Create a debit hold without the available balance check.
    Credit authorization advice 0120 20, 21, 22, 23, 24, 28 Create a credit hold.
    Incremental authorization advice 0120 00, 01, 02, 09, 10, 17, 18 Increase a debit hold amount without the available balance check.
    Final authorization advice 0120 00, 01, 02, 09, 10, 17, 18 Change a debit hold amount.
    Declined authorization advice 0120 - Fully reverse a hold.
    Declined incremental authorization advice 0120 - Reverse the increase of a hold.
    Full authorization reversal 0400, 0420 - Fully reverse a hold
    Partial authorization reversal 0400, 0420 - Partially reverse a hold.
    Debit transaction request 0200 00, 01, 02, 09, 10, 17, 18 Create a debit transaction if the available balance is sufficient.
    Credit transaction request 0200 20, 21, 22, 23, 24, 28 Create a credit transaction.
    Debit transaction advice 0220 00, 01, 02, 09, 10, 17, 18 Create a debit transaction without the available balance check.
    Credit transaction advice 0220 20, 21, 22, 23, 24, 28 Create a credit transaction.
    Declined transaction advice 0220 - Fully reverse a transaction.
    Transaction reversal 0400, 0420 - Fully reverse a transaction.
    Declined request 0100, 0200 - Decline authorization or transaction request.
    ### Transactions endpoint The transactions endpoint is used to process settlement transactions. Each card transaction from the Mastercard file is converted to an API call by Paymentology. Transaction messages are checked for mandatory fields and processing codes are checked to ensure that they are supported. If the checks are passed, a corresponding Mambu API is called. The `200 OK` is returned in case a card transaction is successfully processed by Mambu. If the checks are not passed, the `400 Bad Request` is returned along with the error reason. The following transaction messages are supported:
    Business case MTI ISO_MSG.3 Purpose
    Debit transaction presentment 1240 00, 01, 02, 09, 10, 17, 18 Create a debit transaction without the available balance check.
    Credit transaction presentment 1240 20, 21, 22, 23, 24, 28 Create a credit transaction.
    Presentment reversal 1240 - Fully reverse a transaction.
    --- # Getting Started URL: https://docs.mambu.com/docs/payments-settings/ Before you can start using the Mambu Payments Gateway API and the Mambu Payment Gateway (MPG) the following steps are required. ## Mambu configuration Below are some configuration steps to set up in Mambu. ### 1. Create API consumer and key for Mambu Payments Gateway API All requests to the [Mambu Payments Gateway API](https://api.mambu.com/payments-api//#welcome) require an `ApiKey` header. To generate an API key, you must create an API consumer that has the **Manage Payments** (`MANAGE_PAYMENTS`) permission . For more information, see [API Consumers](/docs/api-consumers). ### 2. Create API consumer or API user for API v2 Next, you must create an API consumer or API user with appropriate details and permissions to perform withdrawal, deposit, and adjustment transactions using [API v2](/api/). You will need this to integrate payments with Mambu core to execute deposit operations. :::note We aim to transition to the use of API consumers as opposed to API users, therefore we recommend that you use an API consumer rather than an API user to access API v2. ::: #### Create an API consumer for API v2 If you decide to use an [API consumer](/docs/api-consumers) to access API v2 you must name it `payments_integration` and you must assign it all the relevant permissions. For more information, see [Assign permissions for the Mambu Payments Gateway API consumer or API user](#assign-permissions-for-the-mambu-payments-gateway-api-consumer-or-api-user). #### Create an API user for API v2 If you decide to create an API user for API v2, then upon creation you must provide the credentials (username and password) to the Mambu team so that they can be set up in the payments system. For more about creating users, see [Creating a User](/docs/creating-new-users). :::info You may not assign API access rights to a user upon creation, you must assign them when editing the user. For more information, see [API Consumers - Access Rights](/docs/creating-new-users#access-rights). ::: :::warning If you have assigned the user access rights using a predefined role, the Access Rights options will be greyed out. Make sure that `API` has been selected in the role configuration and that `Mambu` has not been selected, as this user account should not be used to interact with the Mambu UI. For more information, see [Creating a User - Permissions](/docs/creating-new-users#permissions). ::: ![Editing User dialog](@site/static/img/support/payments-api-user.png) #### Assign permissions for the Mambu Payments Gateway API consumer or API user An API consumer or user in Mambu may be assigned permissions either directly or through a role. We recommend assigning permissions through a role. This will allow you to apply the permissions to new API consumers or users, as well as to secure the transaction channel you will be using for SEPA payments against accidental use by other Mambu users. For more information, see [Roles](/docs/roles). If you choose to assign permissions through a role, create a role with the appropriate permissions assigned to it. :::warning Please be aware When creating your role, you must select **API** under **Access Rights**. ::: If you choose to assign permissions directly, you may do so while creating or editing the API consumer or user. For a list of permissions, see the table below. | Permission Set | Permission | Details | Required | |-----------------|-------------|------|---------| | Deposit Accounts | **View Deposit Account Details** | Needed for retrieving Mambu account and transaction details for accounts linked to a given IBAN, for example to update refunded payments with the details of the related Mambu transaction. | Yes | | Deposit Accounts | **Make Deposit** | Needed to create transactions in a Mambu account when a payment has been received for which the account holder is the creditor. | Yes | | Deposit Accounts | **Make Withdrawal** | Needed to create transactions in a Mambu account when a payment has been received or created for which the account holder is the debtor. | Yes | | Deposit Accounts | **Make Intra-clients Transfers** | Needed to process transactions where funds are being transferred between two accounts held by the same customer. | Yes | | Deposit Accounts | **Make Inter-clients Transfers** | Needed to process transactions where funds are being transferred between two accounts held by customers at the same financial institution. | Yes | | Deposit Accounts | **Apply Deposit Account Adjustments** | Needed to adjust transactions in the case of recalls or reversals. | Yes | | Deposit Accounts | **Backdate Deposit Transactions** | Needed to apply the correct value date when a payment is received and the settlement date is in the past. | Yes | | Deposit Accounts | **Bulk Deposit Corrections** | Needed to apply the correct date to transactions or reverse them in certain cases. | Yes | | Accounting | **Booking Date Deposits Journal Entries** | Needed to apply the correct dates to journal entries when payments are received and the settlement date is in the past. | Yes | | Deposit Accounts | **Make Early Withdrawals** | Mandatory if you use fixed deposit accounts and want to allow customers to make SEPA payments from such an account before the end of the maturity period. | No | | Holds | **Create Holds** | Needed to create authorisation holds in a Mambu account when an instant payment has been received for which the account holder is the creditor, or when an instant payment has been received or created for which the account holder is the debtor. Required permission for instant payment processing.| No | | Holds | **Edit Account Holds** | Needed to settle or revert authorisation holds in a Mambu account. Required permission for instant payment processing. | No | | Holds | **View Account Holds** | Needed for retrieving authorisation holds details. Required permission for instant payment processing. | No | ### 3. Create the payment transaction channels To initiate and receive incoming credit transfers, you must create a reserved transaction channel for each payment type, currency, and direction. Transaction channels should be created using the pattern `----`. For example, for incoming SEPA credit transfers, the transaction channel ID might be `FUBKDE71XXX-CT-SEPA-EUR-I`. | Component | Notes | |-------------|--------| |`BIC`| Your BIC. Please note that you must use the BIC11 format, so any BIC8 codes must be padded with three `X` characters, for example, for an eight character BIC of `NASSDE55`, you should use `NASSDE55XXX` when creating your transaction channels. | |`PAYMENT_TYPE`| Must be either `CT` for credit transfers or `DD` for direct debits. | |`SCHEME`| The payment scheme supported by this transaction channel must be:
    • SEPA for SEPA payments
    • SEPA_INST for SEPA instant payments
    • ISO20022 for generic ISO payments
    • SIC for payments via the Swiss Interbank Clearing system
    • EUROSIC for Swiss Interbank Clearing system payments in Euros
    • SWIFT_MT for SWIFT payments via the European Central Bank's real-time gross settlement system
    | |`CURRENCY_CODE`| The three-letter, ISO 4217 currency code. For SEPA payments, must be `EUR`.| |`DIRECTION`| `I` for incoming payments and `O` for outgoing.| :::warning Please be aware In the past, there was a different pattern for setting up transaction channels where the transaction channel ID for SEPA credit transfers was `_payments_sepa` and for direct debits it was `_direct_debit_sepa`. Old transactions will continue to be associated to these transaction channels. However, for new transactions you must switch to the new ID naming pattern. When switching over to the new ID naming pattern, we strongly recommend that you create entirely new transaction channels instead of renaming the existing `_payments_sepa` or `_direct_debit_sepa` transaction channels. ::: To create the payment transaction channel: 1. Go to **Mambu UI** > **Administration** > **Financial Setup** > **Transaction Channels** > **Add Channel**. 2. Enter a **Channel name**. 3. Enter the **Channel ID**. See the table above for details on how the pattern that the ID should follow. 4. Under **Usage Rights**, if you assigned permission directly to your Mambu API user in the previous step then select **All Users**. If you assigned permissions to your Mambu API user through a role then select the role you created in the previous step. 5. Select **Save Changes**. ![image.png](@site/static/img/support/payments-transaction-channels-naming-convention.png) ![image.png](@site/static/img/support/payments-transaction-channels-for-sepa.png) For more information about transaction channels, see [Transaction Channels](/docs/transaction-channels). ### 4. Create the suspense account When using Anti-Money Laundering (AML) flows, you will need an additional deposit product and account to be configured with specific general ledger (GL) accounts so that suspended amounts are tracked accurately in accounting. #### 4.1 Create the Suspense GL Account [Add a new Liability GL Account](/docs/creating-your-chart-of-accounts#adding-a-new-account) from: **Mambu UI** > **Accounting** > **Chart of Accounts** > **Add A New Account** ![Screenshot 2020-10-13 at 12.46.52](@site/static/img/support/payments--edit-gl-account-modal.png) #### 4.2 Create the Suspense Product Add a new active Current Account ([Deposit Product](/docs/setting-up-new-deposit-products)) from: **Mambu UI** > **Administration** > **Products** > **Deposits** > **New Deposit Product**. The product must have the following [Accounting Rules](/docs/linking-products-to-accounting): at least one account of type Asset, one Expense and one Income. For help on creating a chart of accounts you can check out how to [add Accounts to your Chart of Accounts](/docs/creating-your-chart-of-accounts). ![suspense_product_accounting](@site/static/img/support/suspense_product_accounting.png) #### 4.3 Create a Suspense Account [Create a Deposit Account](/docs/creating-a-deposit-account) with the product defined at step 2. #### 4.4 Optional: Map to IBAN If you need to initiate payments out of the suspense account, it will have to be mapped to an IBAN, using the [External Account Representation API](https://api.mambu.com/payments-api//#external-account-representation-createmapping). ## Mambu Payment Gateway Configuration ### 5. Register a user in Mambu Payment Gateway To register a user, use the registration form, at `https://gateway.TENANT_NAME.sandbox.mambu.com/user/registration/`. Your password must have at least eight characters and include at least one of the following: uppercase letter, lowercase letter, number, and a special character. For more information about additional password settings, see [Extra System Properties](/docs/payment-gateway-system-properties#extra-system-properties). Once registered, contact the Mambu team to confirm and grant the user you created administrator permissions. You will only need to do this once. Afterward, the newly created admin can add and approve other new users. For more information, see [User Administration and Audit Trail](/docs/user-management-and-audit-trail). ![image.png](@site/static/img/support/payments_register_account.png) Once your account has been created, you can proceed with the configuration of the Mambu Payment Gateway by accessing the **Configuration** menu. ### 6. Go through the system properties The configuration menu item contains the system properties configuration which consists of various configuration sections. You should go through each configuration section and enter the relevant information in the fields. The table provides a list of the configuration sections along with a description of each, select the section title for more information about the settings in each section. For more information, see [System Properties](/docs/payment-gateway-system-properties). | Configuration section | Description | | --- | --- | | [Basic Configuration](/docs/payment-gateway-system-properties#basic-configuration) | Specify the BIC of your bank and the automated clearing house (ACH) as well as the ACH system. | | [Callout Configuration](/docs/payment-gateway-system-properties#callout-configuration) | Specify the settings for the system where your payment messages will be sent. | | [Message Processing Configuration](/docs/payment-gateway-system-properties#message-processing-configuration) | Configure settings related to processing payment messages. | | [Extra System Properties](/docs/payment-gateway-system-properties#extra-system-properties) | Configure a number of parameters related to security. | | [Incoming Direct Debit configuration](/docs/payment-gateway-system-properties#incoming-direct-debit-configuration) | Specify the maximum number of days to retry failed debit transactions before returning the direct debit transaction. | | [AML Configuration](/docs/payment-gateway-system-properties#aml-configuration) | Configure settings related to your AML system. | | [SMS Configuration](/docs/payment-gateway-system-properties#sms-configuration) | Set up an SMS gateway for multi-factor authentication (MFA). | Along with the system properties configuration you must also set up your schedulers configuration. ### 7. Set incoming and outgoing schedulers configuration Payments are processed in bulk, according to a configurable schedule. In order to configure this schedule, go to **Mambu Payment Gateway UI** > **Configuration** > **Schedulers**. For more information, see [Schedulers](/docs/schedulers-and-holidays#schedulers). For each channel you use (SEPA Credit Transfers, SEPA Direct Debit, SEPA Direct Debit Business to Business etc.), you will need to set up at least two schedulers for: 1. Incoming (to receive payment information) and 2. Outgoing (to send payment information) To run a scheduler, select the button in the Start/Stop column. For some channels you will also need to create additional schedulers to process retries and returns. ![image.png](@site/static/img/support/image%2863%29.png) :::note Please note More than one outgoing or incoming scheduler can be configured for a given channel. However, you cannot create schedulers with overlapping schedules. ::: ### 8. Optional: Configure holidays It is possible to define holidays that will be used to enable or disable payments on certain dates, when the local clearing house is not operating. For more information, see [Holidays](/docs/schedulers-and-holidays#holidays). ![image.png](@site/static/img/support/image%2838%29.png) --- # Permissions URL: https://docs.mambu.com/docs/permissions/ A *permission* is the authorization given to users that enables them to view a type of information or to perform an action in Mambu. You can either assign individual permissions to users or you can group permissions by creating a role and then assigning that role to a user. By managing permissions, each user will only have access to the information that is relevant for their required activities in Mambu. For more information about assigning permissions to either users or roles see [Creating a User](/docs/creating-new-users) or [Roles](/docs/roles). :::note If users have [Audit Trail](/docs/audit-trail) enabled, Mambu will track all the activities performed by all types of users, regardless of what set of permissions they have. ::: ## Granular Administration Permissions In Mambu, a user with the type administrator has access to the Mambu Administration section. This user type has complete control over the Mambu app and can do all possible actions. However, you will often need to create multiple types of administrators, that have their access limited to some areas of the Mambu Administration section. For example, you might want to create Roles similar to these, for more granularity: * A *Financial Administrator*, in charge with setting the rates, currencies, and so on. * An *Access Administrator*, who manages users, roles, access preferences, and who can set up Federated Authentication. * A *Technical Setup Administrator*, who manages the setup of Event Streaming APIs, Data Imports and Exports, and so on. In order to enable you to create separate roles for the needs of your organization, our Administration permissions provide a high level of granularity. With granular permissions, you can create robust role-based access control rules and apply the principle of least privilege for your users, only giving permissions as absolutely needed for completing specific tasks. ## Standard Behavior for Granular Administrator Permissions The standard behaviour for granular permissions on the **Administration** section, applicable both on the UI and on the API endpoints is the following: * *Create, Read, Update, Delete* (CRUD) permissions on more complex entities. * *Manage* permission on simpler entities. To better understand how the CRUD permissions and the Manage permission standard is applied, let's pick the *Branches* entity and go through each permission. ### Create Entities The Create permission has implicit View permission mapped. This means that a user with the Create permission also has all the capabilities a user with only View permission has. Please note, this is an implicit View permission, which means it is not signaled in the Permission Tree of the given entity. This permission also gives you the capability to create a new entity of the given kind, both via the UI and API, provided that you also have API access. ### View Entity Details This permission is applicable to API 2.0 endpoints such as `getAll` and `getById` provided that you also have API access. For branches, these would be the following: `GET /branches` `GET /branches/` This permission is applicable on Mambu UI as follows: You can see all branches by navigating to **Administration** > **Organization** > **Branches**. You can't edit any fields or create a new branch if you only have View permissions. You can click on branch and/or ID as applicable, in order to see the details. ### Edit Entities The Edit permission has implicit View permission mapped. This means that a user with the Edit permission also has all the capabilities a user with only the View permission has. Please note, this is an implicit View permission, which means it is not signaled in the permission tree of the given entity. This permission also gives you the capability to Edit an entity of the given kind, both via the UI and API, provided you also have API access. Edit entity permissions contains access to actions like: * Activate/Deactivate Entity * Unlock Entity (applicable for Users) ### Delete Entities This permission has an implicit View permission. This means that with the Delete permission, you also have all the capabilities a user with only View permission has. Please note, this is an implicit View permission, which means it is not signaled in the permission tree of the given entity. The delete user action is available both for Administrator and other users that will be granted the “Delete Users” permission. ### Manage Entity The Manage entity permission is used with smaller entities that do not need a full CRUD operation set or to cover current lack on granularity with a minimum impact on backwards compatibility. This permission gives you access to fully manage the entity or feature, while enhancing granularity by not needing an Administrator user type to edit, delete or create new entities. ## Permission descriptions A list of permissions is available in the Mambu UI when you go to create or edit any users or roles. The list of available permissions visible under the **Permissions** section in the relevant dialogs, changes depending on whether you have **Mambu** and/or **API** options selected under **Access Rights**. :::note The default selections under **Access Rights** for users and roles differ. For users, the **Mambu** option is selected by default, when creating new users. The **API** option is only available when editing users, not when creating them. For roles, the **Mambu** and **API** are not selected by default, when creating new roles. ::: Below you can find a description of each of the permissions available in Mambu by category or set. These permissions function identically for Mambu user accounts and Mambu roles. Each permission includes the name used in the UI and the name used with the API (in parentheses). :::warning The name displayed in the UI and the name as it appears in the API or database exports can differ. For example, the name for the permission to view historical data in the UI is **View Historical Data**. The name of the same permission used with the API is `VIEW_INTELLIGENCE`. We recommend consulting the list below to retrieve the correct name. ::: ### General The General category contains the following permissions: * **Audit Transactions (AUDIT_TRANSACTIONS)**: allows you to filter and find transactions. With this permission enabled, you can view the **All Deposit Transactions** option under the **Deposit Transactions** menu item, the **All Loan Transactions** option under the **Loan Transactions** menu item, and the **Activities** menu item. You must also have at least View permissions on deposit or loan accounts. * **Create Index Rate (CREATE_INDEX_RATE)**: allows you to create index interest rates. * **View Comments (VIEW_COMMENTS)**: allows you to view any comments related to clients, users, branches, products, and accounts under the **Comments** tab which becomes visible. * **Create Comments (CREATE_COMMENTS)**: allows you to create new comments. * **Edit Comments (EDIT_COMMENTS)**: allows you to edit existing comments. * **Delete Comments (DELETE_COMMENTS)**: allows you to delete existing comments. * **Export to Excel (EXPORT_TO_EXCEL)**: allows you to export custom views data, and any report under **Reporting** or **Accounting**. Only visible if **Mambu** is selected under **Access Rights**. * **Download Backups (DOWNLOAD_BACKUPS)**: allows you to download backups. Only visible if API is selected under Access Rights. * **Import Data (IMPORT_DATA)**: allows you to import data. Only visible if API is selected under Access Rights. * **View Background Tasks (VIEW_BACKGROUND_TASKS)**: allows users to carry out actions that involve background tasks. Actions that require background tasks include managing deposit and loan accounts, updating general ledger (GL) account closures, and generating balance sheet report. ### Administration The Administration category contains the following permissions: * Custom Fields: * **View Custom Fields (VIEW_CUSTOM_FIELD)**: enables **Fields** tab under **Administration**. Allows access to view custom field definitions which have been set up for the tenant. **Please note**: this permission does not manage whether a user is able to view custom field values for any of the entities. * **Create Custom Fields (CREATE_CUSTOM_FIELD)**: allows you to create custom field sets and custom field definitions. See [Custom Fields](/docs/custom-fields). **Please note**: this permission does not manage whether a user is able to edit custom field values for any of the entities. * **Edit Custom Fields (EDIT_CUSTOM_FIELD)**: allows you to edit custom field sets and custom field definitions. **Please note**: this permission does not manage whether a user is able to edit custom field values for any of the entities. * **Delete Custom Fields (DELETE_CUSTOM_FIELD)**: allows you to delete custom field definitions. **Please note**: this permission does not manage whether a user is able to delete custom field values for any of the entities. * Branches: * **View Branch Details (VIEW_BRANCH_DETAILS)**: enables **Organization** tab under **Administration**. Allows access to Branch information when clicking the Branch name elsewhere in the system. * **Create Branches (CREATE_BRANCH)**: enables access to **Administration** > **Organization** > **Branches** > **Create Branch**. See [Creating Branches](/docs/branches-and-centres#branches). * **Edit Branches (EDIT_BRANCH)**: enables access to **Administration** > **Organization** > **Branches** > **Edit Branches**. Allows you also to activate, deactivate, and unlock branches. See [Editing a Branch](/docs/branches-and-centres#editing-a-branch). * Centres: * **View Centre Details (VIEW_CENTRE_DETAILS)**: enables **Organization** tab under **Administration**. Allows access to Centre information when clicking the Centre name elsewhere in the system. * **Create Centres (CREATE_CENTRE)**: enables access to **Administration** > **Organization** > **Centres** > **Create Centre**. See [Creating Centres](/docs/branches-and-centres#creating-a-centre). * **Edit Centres (EDIT_CENTRE)**: enables access to **Administration** > **Organization** > **Centres** > **Edit Centres**. Allows you to activate, deactivate, and unlock centres. * * **Delete Centres (DELETE_CENTRE)**: enables access to **Administration** > **Organization** > **Centres** > **Delete**. Allows you to delete centres. * Products: * **View Loan Product Details (VIEW_LOAN_PRODUCT_DETAILS)**: enables the **Products** tab and the **Loans** subtab. Allows you to view all the loan products created in Mambu. * **Create Loan Product (CREATE_LOAN_PRODUCT)**: allows a user to create loan products. * **Edit Loan Product (EDIT_LOAN_PRODUCT)**: allows a user to edit and copy loan products. * **Delete Loan Product (DELETE_LOAN_PRODUCT)**: allows a user to delete loan products. * **View Deposit Product Details (VIEW_SAVINGS_PRODUCT_DETAILS)**: enables the **Products** tab and the **Deposits** subtab. Allows you to view all the deposit products created in Mambu. * **Create Deposit Product (CREATE_SAVINGS_PRODUCT)**: allows a user to create a deposit product. * **Edit Deposit Product (EDIT_SAVINGS_PRODUCT)**: allows a user to edit and copy a deposit product. * **Delete Deposit Product (DELETE_SAVINGS_PRODUCT)**: allows a user to delete a deposit product. * **Create Product Documents (CREATE_PRODUCT_DOCUMENT_TEMPLATES)**: allows you to create document templates. See [Creating a Document](/docs/product-documents#creating-a-document). Note, this permission relates only to document templates, there is a separate permission set for documents attached to accounts and other entities. * **Edit Product Documents (EDIT_PRODUCT_DOCUMENT_TEMPLATES)**: allows you to edit document templates. See [Content Editors](/docs/content-editors). Note, this permission relates only to document templates, there is a separate permission set for documents attached to accounts and other entities. * **Delete Product Documents (DELETE_PRODUCT_DOCUMENT_TEMPLATES)**: allows you to delete document templates. Note, this permission relates only to document templates, there is a separate permission set for documents attached to accounts and other entities. * Transaction Channels: * **View Transaction Channels (VIEW_TRANSACTION_CHANNELS)**: allows you to view the list of transaction channels. * **Create Transaction Channels (CREATE_TRANSACTION_CHANNELS)**: allows you to create a new transaction channel. * **Edit Transaction Channels (EDIT_TRANSACTION_CHANNELS)**: allows you to modify transaction channels. * **Delete Transaction Channels (DELETE_TRANSACTION_CHANNELS)**: allows you to delete transaction channels. * Currencies (only visible if API is selected under Access Rights): * **View Exchange Rates (VIEW_EXCHANGE_RATES)**: allows you to view exchange rates. * **Create Exchange Rates (CREATE_EXCHANGE_RATE)**: allows you to create exchange rates. * **Manage Holidays (MANAGE_HOLIDAYS)**: allows you to view, edit, and add to the list of holidays from **Administration** > **General Setup** > **Holidays**. See [Holidays](/docs/holidays-and-non-working-days#holidays). * Manage Configuration As Code (only visible if **API** is selected under Access Rights) * **View Manage Configuration As Code (GET_MANAGE_CONFIGURATION_AS_CODE)**: allows a user to make `GET` requests using the configuration as code endpoints. For more information, see [Configuration as Code Overview](/docs/configuration-as-code-1/). * **Update Manage Configuration As Code (PUT_MANAGE_CONFIGURATION_AS_CODE)**: allows a user to make `PUT` requests using the configuration as code endpoints. For more information, see [Configuration as Code Overview](/docs/configuration-as-code-1/). * **Manage Eod Processing (MANAGE_EOD_PROCESSING)**: allows you to manage EOD Processing from **Administration** > **Financial Setup** > **EOD Processing**. Allows you to access the [Background Process](/api/api-v2/backgroundprocess/backgroundprocess) endpoint. * **Manage Risk Levels (MANAGE_RISK_LEVELS)**: enables **Risk Levels** tab under **Administration** > **Financial Setup**. See [Defining Risk Levels](/docs/defining-risk-levels). * **Manage Apps (MANAGE_APPS)**: enables the **Apps** tab under **Administration**. Allows you to access and manage Mambu apps. Only visible if **Mambu** is selected under **Access Rights**. * **Manage Authorization Holds Setup (MANAGE_AUTHORIZATION_HOLDS_SETUP)**: enables **Authorization Holds Setup** tab under **Administration** > **Financial Setup**. Allows you to access and setup authorization holds. * **Manage Index Rates (MANAGE_INDEX_RATES)**: enables **Rates** tab under **Administration** > **Financial Setup**. Allows you to access and manage rates. * **Manage Currencies (MANAGE_CURRENCIES)**: enables **Currencies** tab under **Administration** > **Financial Setup**. Allows you to manage currencies and currency-related rates, such as accounting rates or exchange rates. ### Access The Access category contains the following permissions: * Users: **Please Note**: For security reasons, we recommend tightly controlling which users have user management permissions. For more information, see [Limiting role and user management permission assignment](/docs/understanding-users-roles-and-permissions#limiting-role-and-user-management-permission-assignment). * **Create Users (CREATE_USER)**: allows you to create new users in the system. See [Creating User Accounts](/docs/creating-new-users). * **Edit Users (EDIT_USER)**: allows you to edit existing users. **Does not** allow you to change other users' passwords. * **View User Details (VIEW_USER_DETAILS)**: allows you to view the user profile of Mambu users within this menu, including your own. Your profile is also accessible when clicking your name in the top right corner, and then clicking **View Your Profile**. Other users’ profile is also accessible from **Activities** or **Transactions**. * **Delete Users (DELETE_USER)**: allows you to delete existing users. See [Deactivating, Reactivating and Deleting User Accounts](/docs/deactivating-reactivating-and-deleting-user-accounts#deleting-a-user). * Roles: **Please Note**: For security reasons, we recommend tightly controlling which users have role management permissions. For more information, see [Limiting role and user management permission assignment](/docs/understanding-users-roles-and-permissions#limiting-role-and-user-management-permission-assignment). * **Create Roles (CREATE_ROLE)**: allows you to create new roles in the system. See [Creating a new role](/docs/roles#creating-a-role). * **Edit Roles (EDIT_ROLE)**: allows you to edit existing roles. See [Editing a role](/docs/roles#editing-a-role). * **View Roles (VIEW_ROLE)**: allows you to view the existing roles. * **Delete Roles (DELETE_ROLE)**: allows you to delete existing roles. See [Deleting a role](/docs/roles#deleting-a-role). * Api Consumers and Keys * **View Api Consumers and Keys (VIEW_API_CONSUMERS_AND_KEYS)**: enables the **API Consumers** tab under **Administration**. See [API Consumers](/docs/api-consumers). * **Create Api Consumers and Keys (CREATE_API_CONSUMERS_AND_KEYS)**: allows you to create API consumers and keys. * **Edit Api Consumers and Keys (EDIT_API_CONSUMERS_AND_KEYS)**: allows you to edit API consumers and keys. * **Delete Api Consumers and Keys (DELETE_API_CONSUMERS_AND_KEYS)**: allows you to delete API consumers or API keys. See [API Consumers](/docs/api-consumers#deleting-api-consumers). * **Manage Federated Authentication (MANAGE_FEDERATED_AUTHENTICATION)** (only visible if **Mambu** is selected under **Access Rights**): enables you to manage users under Federated Authentication. See [Managing Users under Federated Authentication](/docs/managing-sso-provisioned-users). * **Manage Access Preferences (MANAGE_ACCESS_PREFERENCES)** (only visible if **Mambu** is selected under **Access Rights**): allows you to manage access preferences, such as Minimum password length or whether you want to lock users after failed logins. See [Access Preferences](/docs/access-preferences). * **Manage Two Factor Authentication (MANAGE_TWO_FACTOR_AUTHENTICATION)** (only visible if **Mambu** is selected under **Access Rights**): allows you to manage two-factor authentication for user preferences. For more information see [Two Factor Authentication](/docs/creating-new-users#two-factor-authentication). :::note Having any permission under the **Access** permissions category enables the **Access** tab under **Administration** and any relevant subtabs you have access to based on the permissions granted. ::: ### Communication The Communications category contains the following permissions: * **Create Templates (CREATE_COMMUNICATION_TEMPLATES)**: enables the **Templates**, **SMS**, **Email**, and **Webhooks** tabs under **Administration**. Allows you to view and create communication templates for tasks, SMS, emails and webhooks. * **Edit Templates (EDIT_COMMUNICATION_TEMPLATES)**: enables the **Templates**, **SMS**, **Email**, and **Webhooks** tabs under **Administration**. Allows you to view and create communication templates for tasks, SMS, emails and webhooks. * **Send Manual SMS (SEND_MANUAL_SMS)**: Allows you to send ad-hoc, manual SMS messages to clients. See [Manual SMS Notifications](/docs/manual-sms-notifications). * **Send Manual Email (SEND_MANUAL_EMAIL)**: Allows you to send ad-hoc, manual emails to clients. See [Manual Email Notifications](/docs/manual-email-notifications). * **View Communication History (VIEW_COMMUNICATION_HISTORY)**: allows you to view the history of all communications (via SMS, Email, Webhooks). See [View Communication History](/docs/managing-notifications). * **Resend Failed Messages (RESEND_FAILED_MESSAGES)**: allows you to resend the communication messages that didn’t go through. See [Resend Failed Notification Messages](/docs/managing-notifications#resending-failed-messages). ### Clients The Clients category contains the following permissions: * **View Client Details (VIEW_CLIENT_DETAILS)**: allows you to access the list of clients and the individual clients’ overview screen. * **Create Clients (CREATE_CLIENT)**: allows you to create new clients. See [Creating Individual Clients](/docs/create-an-individual-client). * **Edit Clients (EDIT_CLIENT)**: allows you to make changes to the client fields, some custom field values, and notifications settings. See [Editing a Client](/docs/managing-clients#editing-a-client). * **Delete Clients (DELETE_CLIENTS)**: allows you to delete clients, provided they don’t have open accounts, transactions, or activities. See [Deleting a Client](/docs/managing-clients#deleting-a-client). * **Approve Clients (APPROVE_CLIENT)**: allows you to change the status of a client from pending approval to approved. * **Reject Clients (REJECT_CLIENT)**: allows you to reject unapproved clients. * **Exit Clients (EXIT_CLIENT)**: allows you to change the status of a client to Exited. * **Anonymize Client Data (ANONYMIZE_CLIENT)**: allows a user to anonymize a client's data. Only available to be assigned to a role. * **Blacklist Clients (BLACKLIST_CLIENT)**: allows you to change the status of a client to Blacklisted. * **Undo Client State Changed (UNDO_CLIENT_STATE_CHANGED)**: allows you to undo approval or blacklisting of clients. * **Change Client Type (CHANGE_CLIENT_TYPE)**: allows you to change the type of the client, if different types of clients exist. * **Manage Client Association (MANAGE_CLIENT_ASSOCIATION)**: allows you to perform Branch/Centre/Credit Officer association actions when you create or edit clients. Allows you to perform single reassign or bulk reassign actions from Clients custom view. See [Assigning Clients to Credit Officers and Branches](/docs/creating-a-group#assigning-groups-to-branches-centres-and-credit-officers). * **Edit Client Id (EDIT_CLIENT_ID)**: allows you to manually change the system-generated random client or group ID. * **Edit Custom Field Values For Blacklisted Clients (EDIT_BLACKLISTED_CLIENT_CFV)**: allows you to edit custom field values for blacklisted clients. ### Groups The Groups category contains the following permissions: * **View Group Details (VIEW_GROUP_DETAILS)**: allows you to access the group or company overview tab and the list of all the existing groups or companies. * **Create Groups (CREATE_GROUP)**: allows you to create groups. See [Create a New Group](/docs/creating-a-group). * **Edit Groups (EDIT_GROUP)**: allows you to make changes to the group or company members, basic information and custom fields. * **Delete Groups (DELETE_GROUP)**: allows you to delete groups provided they don’t have open accounts, transactions, or activities. Only visible if **Mambu** is selected under **Access Rights**. * **Change Group Type (CHANGE_GROUP_TYPE)**: allows you to change the group type if different group types exist. * **Manage Group Association (MANAGE_GROUP_ASSOCIATION)**: allows you to perform Branch/Centre/Credit Officer association actions when you create or edit groups. Allows you to perform single reassign or bulk reassign actions from Groups custom view. See [Assign Groups to Credit Officers and Branches](/docs/creating-a-group#assigning-groups-to-branches-centres-and-credit-officers). * **Edit Group Id (EDIT_GROUP_ID)**: allows you to edit group IDs. ### Credit Arrangements The Credit Arrangements category contains the following permissions: * **View Credit Arrangement Details (VIEW_LINE_OF_CREDIT_DETAILS)**: allows you to access the Credit Arrangements overview and related tabs: Schedule, Transactions. See [Viewing a Credit Arrangement](/docs/managing-credit-arrangements#view-a-credit-arrangement). * **Create Credit Arrangements (CREATE_LINES_OF_CREDIT)**: allows you to create a new credit arrangement for a client. See [Creating a New Credit Arrangement and Exposure Limits](/docs/creating-a-new-credit-arrangement). * **Edit Credit Arrangements (EDIT_LINES_OF_CREDIT)**: allows you to edit an existing credit arrangement. See [Editing a Credit Arrangement](/docs/managing-credit-arrangements#edit-a-credit-arrangement). * **Approve Credit Arrangements (APPROVE_LINE_OF_CREDIT)**: allows you to approve credit arrangements that are in Pending Approval state. * **Undo Approve Credit Arrangements (UNDO_APPROVE_LINE_OF_CREDIT)**: allows you to undo approval of a credit arrangement. * **Withdraw Credit Arrangements (WITHDRAW_LINE_OF_CREDIT)**: allows you to withdraw a credit arrangement that hasn’t been approved yet. * **Undo Withdraw Credit Arrangements (UNDO_WITHDRAW_LINE_OF_CREDIT)**: allows you to undo the withdrawal of a credit arrangement. * **Reject Credit Arrangements (REJECT_LINE_OF_CREDIT)**: allows you to reject a credit arrangement that hasn’t been approved yet. * **Undo Reject Credit Arrangements (UNDO_REJECT_LINE_OF_CREDIT)**: allows you to undo the rejection of a credit arrangement. * **Add Accounts to Credit Arrangements (ADD_ACCOUNTS_TO_LINE_OF_CREDIT)**: allows you to add a new account to an existing credit arrangement. See [Adding Accounts to a Credit Arrangement](/docs/adding-accounts-to-a-credit-arrangement). * **Remove Accounts from Credit Arrangement (REMOTE_ACCOUNTS_FROM_LINE_OF_CREDIT)**: allows you to remove an account from a credit arrangement. See [Removing Accounts from a Credit Arrangement](/docs/removing-accounts-from-a-credit-arrangement). * **Close Credit Arrangements (CLOSE_LINES_OF_CREDIT)**: allows you to close an existing credit arrangement. See [Closing a Credit Arrangement](/docs/managing-credit-arrangements#close-a-credit-arrangement). * **Delete Credit Arrangements (DELETE_LINES_OF_CREDIT)**: allows you to delete a credit arrangement. See [Deleting a Credit Arrangement](/docs/managing-credit-arrangements#delete-a-credit-arrangement). ### Loan Accounts The Loan Accounts category contains the following permissions: * **View Loan Account Details (VIEW_LOAN_ACCOUNT_DETAILS)**: allows you to access the list of loan accounts and the accounts’ overview screen. * **Create Loan Accounts (CREATE_LOAN_ACCOUNT)**: allows you to create a new loan account. See [Creating a New Loan Account](/docs/creating-a-new-loan). * **Edit Loan Accounts (EDIT_LOAN_ACCOUNT)**: allows you to change existing loan accounts, rename and add some custom field definitions, and change account parameters for unapproved loans. See [Editing a Loan](/docs/editing-a-loan). * **Delete Loan Accounts (DELETE_LOAN_ACCOUNT)**: allows you to delete loan accounts, provided they don’t have transactions or activities. * **Enter Repayments (ENTER_REPAYMENT)**: allows you to enter payments. See [Processing Loan Repayments](/docs/processing-loan-repayments). * **Edit Repayment Schedule (EDIT_REPAYMENT_SCHEDULE)**: for fixed products that have this setting enabled at product level, it allows you to edit items on the loan schedule. See [Editing Repayment Schedule](/docs/editing-customizing-repayment-schedules). * **Approve Accounts (APPROVE_LOANS)**: allows you to approve loans that are in Pending Approval state. See [Approving a Loan Account](/docs/approving-a-loan). * **Request Loan Approval (REQUEST_LOAN_APPROVAL)**: submitting for approval loans that are in Partial Application state. * **Disburse Loans (DIBURSE_LOANS)**: allows you to disburse loans that are in Approved state. See [Disbursing a loan](/docs/disbursing-a-loan). * **Withdraw Loan Accounts (WITHDRAW_LOAN_ACCOUNTS)**: allows you to withdraw a loan account that hasn’t been disbursed yet. See [Withdrawing a Loan](/docs/withdrawing-a-loan). * **Undo Withdraw Loan Accounts (UNDO_WITHDRAW_LOAN_ACCOUNTS)**: allows you to undo a withdrawal of a loan account. See [Undoing a Loan Withdrawal](/docs/withdrawing-a-loan#undoing-a-loan-withdrawal). * **Set Loan Incomplete (SET_LOAN_INCOMPLETE)**: allows you to undo submitting a loan for approval by changing the account’s state from Pending Approval to Partial Application. Only visible if **Mambu** is selected under **Access Rights**. * **Reject Loan Accounts (REJECT_LOANS)**: allows you to reject loan accounts that are in Pending Approval or Partial Application state. See [Rejecting a Loan Account](/docs/rejecting-a-loan). * **Undo Reject Loan Accounts (UNDO_REJECT_LOANS)**: allows you to undo a rejection of a loan account. See [Undoing a Loan Rejection](/docs/rejecting-a-loan#undoing-a-loan-rejection). * **Close Repaid Loan Accounts (CLOSE_LOAN_ACCOUNTS)**: allows you to close accounts that have been fully repaid. See [Closing a Loan](/docs/closing-a-loan-with-all-obligations-met). * **Write Off Loan Accounts (WRITE_OFF_LOAN_ACCOUNTS)**: allows you to write off a loan account that has pending balance. See [Writing-off a Loan](/docs/writing-off-a-loan). * **Terminate Loan Accounts (TERMINATE_LOAN_ACCOUNTS)**: allows you to terminate loan accounts. See [Terminating a Loan](/docs/terminating-a-loan). Only visible if **Mambu** is selected under **Access Rights**. * **Pay Off Loan Accounts (PAY_OFF_LOAN)**: allows you to completely settle a loan account. See [Paying-off a Loan](/docs/paying-off-a-loan). * **Undo Close (UNDO_LOAN_ACCOUNT_CLOSURE)**: allows you to undo non-write off loan closures. * **Undo Write Off (REVERSE_LOAN_ACCOUNT_WRITE_OFF)**: allows you to undo the write off of a loan account. See [Undoing a Write-off](/docs/writing-off-a-loan#undoing-a-write-off). * **Refinance Loan Account (REFINANCE_LOAN_ACCOUNT)**: allows you to refinance a loan. See [Rescheduling and Refinancing Loans](/docs/rescheduling-and-refinancing-loans). * **Reschedule Loan Account (RESCHEDULE_LOAN_ACCOUNT)**: allows you to reschedule a loan. See [Rescheduling and Refinancing Loans](/docs/rescheduling-and-refinancing-loans). * **Apply Accrued Interest (APPLY_ACCRUED_LOAN_INTEREST)**: allows you to charge the interest accrued to date (if applicable). See [Interest Calculation Methods in Loans](/docs/interest-calculation-methods-in-loans). * **Apply Loan Account Fees (APPLY_LOAN_FEES)**: allows you to charge manual fees to the account. See [Applying and Reversing Fees and Penalties](/docs/applying-and-reversing-fees-and-penalties). * **Apply Loan Adjustments (APPLY_LOAN_ADJUSTMENTS)**: allows you to adjust financial transactions, meaning transactions that involve an amount. Furthermore, this permission is granted implicitly with the **Bulk Loan Corrections** permission, meaning if you have the **Bulk Loan Corrections** permission, then you will also have the **Apply Loan Adjustments** permission by default. * **Backdate Loan Transactions (BACKDATE_LOAN_TRANSACTIONS)**: allows you to post transactions with a past date. * **Set Settlement Accounts (LINK_ACCOUNTS)**: allows you to set a settlement deposit account for a loan account. * **Collect Securities (COLLECT_GUARANTIES)**: when a loan is written off, this permission allows collection of secured amounts from the Mambu savings account. See [Collecting Securities](/docs/writing-off-a-loan#collecting-securities). Only visible if **Mambu** is selected under **Access Rights**. * **View Securities Details (VIEW_SECURITIES_DETAILS)**: enables access to the Security tab for loan accounts. Allows you to view securities. * **Create Securities (CREATE_SECURITIES)**: enables access to the Security tab for loan accounts. Allows you to create securities. * **Edit Securities (EDIT_SECURITIES)**: enables access to the Security tab for loan accounts. Allows you to edit securities. * **Delete Securities (DELETE_SECURITIES)**: enables access to the Security tab for loan accounts. Allows you to remove securities. * **Lock Loan Accounts (LOCK_LOAN_ACCOUNTS)**: allows you to set an account to Locked status in which no automated transactions are posted to the account. See [Locking Loans](/docs/locking-loans). * **Post Transactions on Locked Accounts (POST_TRANSACTIONS_ON_LOCKED_LOAN_ACCOUNTS)**: allows you to post repayments and fees into locked accounts. * **Edit Loan Tranches (EDIT_LOAN_TRANCHES)**: allows you to modify the tranches of an existing loan account. * **Edit Penalty Rate (EDIT_PENALTY_RATE)**: allows you to change the penalty rate of an existing loan account. See [Loan Penalties Setup](/docs/loan-penalties-setup). * **Set Disbursement Conditions (SET_DISBURSEMENT_CONDITIONS)**: allows you to define disbursement conditions when entering a loan application and overriding them when disbursing the account. * **Edit Loan Transactions (EDIT_LOAN_TRANSACTIONS)**: allows you to edit custom field values on loan transactions that are already posted. * **Bulk Loan Corrections (BULK_LOAN_CORRECTIONS)**: allows you to backdate or reverse transactions on loan accounts. See [Adjusting Transactions in Bulk](/docs/adjusting-transactions#adjusting-transactions-in-bulk). * **Edit Interest Rate (EDIT_INTEREST_RATE)**: allows you to edit the interest rate on active loan accounts. See [Change Interest Rate](/docs/change-interest-rate). * **Edit Repayment Method Value (EDIT_REPAYMENT_METHOD_VALUE)**: allows you to change monthly payment due (or minimum monthly payment due) value shown in the schedule on Revolving loan accounts. See [Editing payment due in the schedule](/docs/revolving-credit-loans#repayment-schedule-editing) * **Edit Periodic Payment for Active Accounts (EDIT_PERIODIC_PAYMENT_FOR_ACTIVE_ACCOUNT)**: allows you to change periodic payments for active accounts. * **Edit Principal Payment for Active Revolving Credit (EDIT_PRINCIPAL_PAYMENT_ACTIVE_REVOLVING_CREDIT)**: edit principal payment amount on active Revolving Credit loan accounts. * **Perform Repayments with Custom Amounts Allocation (PERFORM_REPAYMENTS_WITH_CUSTOM_AMOUNTS_ALLOCATION)**: allows you to make repayments with a custom allocation of the repaid amount. See [Enter a Custom Repayment](/docs/processing-loan-repayments#enter-a-custom-repayment). * **Manage Loan Association (MANAGE_LOAN_ASSOCIATION)**: allows you to associate a loan account to a specific branch. See [Loan Association](/docs/creating-a-new-loan#association). * **Make Withdrawal Redraw (MAKE_WITHDRAWAL_REDRAW)**: allows you to withdraw from a redraw balance. See our [API Reference](/api/api-v2/loans_transactions/make-withdrawal). ### Deposit Accounts The Deposit Accounts category contains the following permissions: * **View Deposit Account Details (VIEW_SAVINGS_ACCOUNT_DETAILS)**: allows you to access the list of deposit accounts and the accounts’ overview screen. * **Create Deposit Accounts (CREATE_SAVINGS_ACCOUNT)**: allows you to create new deposit accounts. See [Creating a Deposit Account](/docs/creating-a-deposit-account). * **Edit Deposit Accounts (EDIT_SAVINGS_ACCOUNT)**: allows you to edit existing accounts. See [Editing Accounts](/docs/editing-accounts). * **Delete Deposit Accounts (DELETE_SAVINGS_ACCOUNT)**: allows you to delete a deposit account with no transactions. See [Deleting Accounts](/docs/deleting-accounts). * **Make Deposit (MAKE_DEPOSIT)**: allows you to post a deposit transaction. See [Enter a Deposit](/docs/deposits-withdrawals-and-transfers#entering-a-deposit). * **Make Withdrawal (MAKE_WITHDRAWAL)**: allows you to post a withdrawal transaction. See [Make Withdrawals](/docs/deposits-withdrawals-and-transfers#making-withdrawals). * **Make Early Withdrawals (MAKE_EARLY_WITHDRAWALS)**: allows you to make a withdrawal before the maturity date is reached. See [Early Withdrawals in Fixed Deposits](/docs/deposits-withdrawals-and-transfers#early-withdrawals-in-fixed-deposits). * **Approve Deposit Account (APPROVE_SAVINGS)**: allows you to approve deposit accounts that are in Pending Approval state. See [Approving a Deposit Account Application](/docs/deposit-accounts-life-cycle-and-states#approved). * **Activate Maturity (ACTIVATE_MATURITY)**: allows you to set a maturity date for fixed deposit account or savings plan, if applicable. See [Setting up a Maturity Period](/docs/setting-up-a-maturity-period). * **Close Deposit Accounts (CLOSE_SAVINGS_ACCOUNTS)**: allows you to close a deposit account with zero balance. It also allows you to write off overdraft accounts with overdraft balance. See [Closing Accounts](/docs/closing-accounts). * **Apply Deposit Account Fees (APPLY_SAVINGS_FEES)**: allows you to charge manual fees to deposit accounts. See [Applying Fees](/docs/managing-fees-in-deposit-accounts). * **Re-open Deposit Accounts (REOPEN_SAVINGS_ACCOUNT)**: allows you to reopen closed deposit accounts. See [Re-opening a Deposit Account](/docs/re-opening-a-deposit-account). * **Apply Deposit Account Adjustments (APPLY_SAVINGS_ADJUSTMENTS)**: allows you to reverse deposit accounts transactions and to undo approval. This is currently an API only feature. * **Lock Deposit Account (LOCK_SAVINGS_ACCOUNT)**: allows you to set an account to *Locked* status in which no automated transactions are posted to the account. See [Locking and Unlocking Accounts](/docs/locking-and-unlocking-deposit-accounts). * **Unlock Deposit Account (UNLOCK_SAVINGS_ACCOUNT)**: allows you to unlock a deposit account. See [Locking and Unlocking Accounts](/docs/locking-and-unlocking-deposit-accounts#unlock-accounts). * **Undo Write Off (REVERSE_SAVINGS_ACCOUNT_WRITE_OFF)**: allows you to undo the write off of a deposit account. Only visible if **Mambu** is selected under **Access Rights**. * **Backdate Deposit Transactions (BACKDATE_SAVINGS_TRANSACTIONS)**: allows you to post transactions with a date in the past. See [Backdating Deposits and Withdrawals](/docs/deposits-withdrawals-and-transfers#backdating-deposits-and-withdrawals). * **Make Intra-clients Transfers (MAKE_TRANSFER)**: allows you to post transfer transactions from a deposit account to another deposit or loan account belonging to the same client. See [Make Transfers](/docs/deposits-withdrawals-and-transfers#making-transfers). * **Make Inter-clients Transfers (MAKE_INTER_CLIENTS_TRANSFERS)**: allows you to post transfer transactions from a deposit account to deposit or loan accounts belonging to different clients. See [Make Transfers](/docs/deposits-withdrawals-and-transfers#making-transfers). * **Post Transactions on Dormant Accounts POST_TRANSACTIONS_ON_DORMANT_ACCOUNTS**: allows you to post transactions on accounts that are dormant, meaning they have been inactive for a number of days defined in the initial setup. * **Apply Accrued Interest (APPLY_ACCRUED_SAVINGS_INTEREST)**: allows you to charge the interest accrued to date. * **Edit Deposit Transactions (EDIT_SAVINGS_TRANSACTIONS)**: allows you to edit custom field values on deposit transactions that are already posted. * **Bulk Deposit Corrections (BULK_DEPOSIT_CORRECTIONS)**: allows you to backdate or reverse transactions on deposit accounts. * **Undo Maturity (UNDO_MATURITY)**: allows you to undo the maturity date for fixed deposit and savings plan accounts, if applicable. * **Block and Seize Funds (BLOCK_AND_SEIZE_FUNDS)**: allows you to block funds from deposit accounts. * **Withdraw Blocked Funds (WITHDRAW_BLOCKED_FUNDS)**: allows you to make transfers and withdrawals of blocked funds. Only available to be assigned to a role. * **Manage Deposit Association** (MANAGE_DEPOSIT_ASSOCIATION): allows you to use the transfer branch functionality for a deposit account. * **Manage Deposit Account Recipient** (MANAGE_DEPOSIT_ACCOUNT_RECIPIENT): allows you to use the transfer ownership functionality of a deposit account. * **Bypass Account Ownership Transfer View Restriction** (BYPASS_ACCOUNT_OWNERSHIP_TRANSFER_VIEW_RESTRICTION): allows the user — or, for API access, the API consumer — to maintain visibility of past ownerships and the previous owner's financial activity after an account has been transferred. Restricted by default. See [Transfer Account Ownership](/docs/transfer-account-ownership#post-transfer-restrictions). ### Cards The Cards category is only available for roles and contains the following permissions: * **Create Cards (CREATE_CARDS)**: allows you to create cards. * **View Cards (VIEW_CARDS)**: allows you to view cards. * **Delete Cards (DELETE_CARDS)**: allows you to delete cards. * **Reverse Card Transactions (REVERSE_CARD_WITHDRAWAL_TRANSACTION)**: allows you to reverse card transactions. * **View Card Account Balances (CARD_BALANCE_INQUIRY)**: allows you to view card account balances. ### Authorization Holds (via Card Token) * **Create Authorization Holds (CREATE_AUTHORIZATION_HOLDS)**: allows you to create authorization holds via card tokens using API v2. * **Edit Authorization Holds (UPDATE_AUTHORIZATION_HOLDS)**: allows you to edit authorization holds via card tokens using API v2. * **View Authorization Holds (VIEW_AUTHORIZATION_HOLDS)**: allows you to view authorization holds via card tokens using API v2. * **Create Card Transactions (CREATE_CARD_TRANSACTIONS)**: allows you to create card transactions via API v2. ### Holds (via Account Id) * **Create Holds (CREATE_HOLDS)**: allows you to create transaction holds on active deposit accounts. * **Edit Account Holds (EDIT_HOLDS)**: allows you to edit transaction holds on active deposit accounts. ### Documents The Documents category contains the following permissions: * **View Documents (VIEW_DOCUMENTS)**: allows you to view any attachment across Mambu. * **Create Documents (CREATE_DOCUMENTS)**: allows you to add and attach new files. See [Creating a Document](/docs/product-documents#creating-a-document). * **Edit Documents (EDIT_DOCUMENTS)**: allows you to edit attached files. * **Delete Documents (DELETE_DOCUMENTS)**: allows you to delete attached files. ### Tasks The Tasks category contains the following permissions: * **View Tasks (VIEW_TASK)**: allows you to view your current and past tasks. See [Finding and Completing Tasks](/docs/tasks#finding-and-completing-tasks). * **Create Tasks (CREATE_TASK)**: allows you to create new tasks for yourself or for other users. See [Tasks](/docs/tasks). * **Edit Tasks (EDIT_TASK)**: allows you to edit tasks. See [Editing and Deleting Tasks](/docs/tasks#editing-and-deleting-tasks). * **Delete Tasks (DELETE_TASK)**: allows you to delete accomplished tasks. See [Editing and Deleting Tasks](/docs/tasks#editing-and-deleting-tasks). ### Reporting The Reporting category contains the following permissions: * **View Historical Data (VIEW_INTELLIGENCE)**: allows you to view historical data. * **View Reports (VIEW_REPORTS)**: allows you to view dashboard indicators and reports under reporting. See [Accessing, Managing and Generating Reports](/docs/management-reports). Only visible if **Mambu** is selected under **Access Rights**. * **Create Reports (CREATE_REPORTS)**: allows you to add indicator reports. See [Create a New Indicator Report](/docs/management-reports#creating-an-indicator-report). Only visible if **Mambu** is selected under **Access Rights**. * **Edit Reports (EDIT_REPORTS)**: allows you to edit indicator reports. See [Edit Indicator Reports](/docs/management-reports#editing-indicator-reports). Only visible if **Mambu** is selected under **Access Rights**. * **Delete Reports (DELETE_REPORTS)**: allows you to delete indicator reports. See [Delete Indicator Reports](/docs/management-reports#deleting-indicator-reports). Only visible if **Mambu** is selected under **Access Rights**. ### Accounting The Accounting category contains the following permissions: * Accounting Rates * **View Accounting Rates (VIEW_ACCOUNTING_RATES)**: allows you to view accounting rates. * **Create Accounting Rates (CREATE_ACCOUNTING_RATES)**: allows you to create accounting rates via the UI or API. * **Manage Chart of Accounts (MANAGE_ACCOUNTS)**: allows you to create and edit General Ledger accounts. Only visible if **Mambu** is selected under **Access Rights**. * **Log Journal Entries (LOG_JOURNAL_ENTRIES)**: allows you to create and post journal entries. * **View Accounting Reports (VIEW_ACCOUNTING_REPORTS)**: allows you to view, generate, and print accounting reports. See [Accounting Reports](/docs/accounting-reports). * **Make Accounting Closures (MAKE_ACCOUNTING_CLOSURE)**: allows you to make periodical closures. See [Accounting Closures](/docs/accounting-closures). Only visible if **Mambu** is selected under **Access Rights**. * **Delete Accounting Closures (APPLY_ACCOUNTING_ADJUSTMENTS)**: allows you to edit or delete accounting closures. Only visible if **Mambu** is selected under **Access Rights**. * **Booking Date Loans Journal Entries (BOOKING_DATE_LOANS_GL)**: allows you to select the journal entry booking date of a given loan transaction. * **Booking Date Deposits Journal Entries (BOOKING_DATE_SAVINGS_GL)**: allows you to select the journal entry booking date of a given deposit transaction. * **Rectify Adjustment After Accounting Closures (RECTIFY_ADJUSTMENT)**: allows you to rectify and adjust a transaction after an account closure, by allowing a booking date input after the accounting closure. * **Manage Inter-branch Gl Account Rules (MANAGE_INTERBRANCH_GLACCOUNT_RULES)**: allows you to make changes to this section. For more details please check this [article](/docs/inter-branch-transfer-gl-account). ### Tellering The Tellering category is only visible if **Mambu** is selected under **Access Rights** and contains the following permissions: * **Open Till (OPEN_TILL)**: permission normally granted to a supervisor or vault teller. Allows opening a till for a regular teller. See [Opening a Till](/docs/managing-tills-tellering-widget#open-a-till). * **Close Till (CLOSE_TILL)**: permission normally granted to a supervisor or vault teller. Allows closing a till for a regular teller. See [Closing a Till](/docs/managing-tills-tellering-widget#close-a-till). * **Add Cash (ADD_CASH)**: allows you to post repayments or deposits. See [Processing Loan Repayments](/docs/processing-loan-repayments) and [Entering Deposits](/docs/deposits-withdrawals-and-transfers). * **Remove Cash (REMOVE_CASH)**: allows you to post disbursements or withdrawals. See [Disbursing a Loan](/docs/disbursing-a-loan) or [Making Withdrawals](/docs/processing-transactions-via-a-till-tellering-widget#post-transactions). * **Post Transaction without a Till (POST_TRANSACTIONS_WITHOUT_OPENED_TILL)**: allows you to post repayments, deposits, disbursements, and withdrawals without a till. ### Funds The Funds permission enables access to the Funding tab for Loans and Investment Deposit Accounts. It allows you to manage funding sources. * **View Funds Details (VIEW_INVESTOR_FUNDS_DETAILS)**: allows you to view all loans funded by an investor's account with the breakdown for each, indicating the original invested amounts, the remaining funds to be collected and the interest earned on that account. See [Funding Sources - P2P Lending](/docs/funding-sources-p2p-lending). * **Create Funds (CREATE_INVESTOR_FUNDS)**: allows you to create "Funding account"-type deposit products and the related funding deposit accounts for each investor. See [Funding Sources - P2P Lending](/docs/funding-sources-p2p-lending). * **Edit Funds (EDIT_INVESTOR_FUNDS)**: allows you to edit "Funding account"-type deposit products and the related funding deposit accounts for each investor. * **Delete Funds (DELETE_INVESTOR_FUNDS)**: allows you to delete "Funding account"-type deposit products and the related funding deposit accounts for each investor. * **Sell Loan Fraction (SELL_LOAN_FRACTION)**: allows you to sell loan fractions, allowing a loan funder to sell a portion of the loan (or fraction) to a different funder. See [Secondary Marketplace for Peer-to-Peer Loans - Selling a Loan Fraction Share](/docs/secondary-marketplace-for-p2p-loans#selling-a-loan-fraction-share). ### Events Streaming The Events Streaming category contains the following permissions: * **Manage Events Streaming (MANAGE_EVENTS_STREAMING)**: allows you to view and work with Events Streaming. For more information, see [Using the Streaming API](/docs/streaming-api). Only visible if **Mambu** is selected under **Access Rights**. ## Particular actions that depend on permission combinations There are certain actions that a user can perform in Mambu without having a specific permission in place for them, they depend upon other permissions or user types. * Only administrators can create Views which are available for other users. * Users can change their own password but only administrators can change other users' passwords. * Only the user who created a task can edit it. * In order to view loan and deposit accounts you will need the view client permission in addition to view permissions for the type of account you want to view. * To carry out transfer transactions, users need to also have the “Enter Repayments” or “Make Deposit” permission (if the transfer is meant to become a repayment in a loan account or a deposit in a savings account). * For rescheduling loans, users also need the “Create Loan” permission. * To revert a certain type of transaction, besides the "Apply Loan/Deposit product adjustments", the user requires the permission to post that type of transaction. For example, to revert a repayment, the user must have the "Enter Repayments" permission as well. * To change the Loan's Account branch, you need the "Manage Loan Association" permission, which is disabled by default. Without this permission, the branch box from the **Create Loan Account** form and the **Edit Loan Account** form will be read-only and you won’t be able to change the branch. --- # Placeholders URL: https://docs.mambu.com/docs/placeholders/ Placeholders allow you to pull in data about a specific client, group, loan account, deposit account, or transaction in an email, SMS, webhook, streaming API event notification or product document. You may use placeholders when creating: * [Automated SMS Notifications](/docs/automated-sms-notifications) * [Manual SMS Notifications](/docs/manual-sms-notifications) * [Automated Email Notifications](/docs/automated-email-notifications) * [Manual Email Notifications](/docs/manual-email-notifications) * [Product Documents](/docs/product-documents) * [Webhooks](/docs/webhooks-defining-a-new-webhook) * [Streaming API event notification](/docs/streaming-api) * [Tasks](/docs/tasks) The placeholders available when you are creating a specific notification template will depend on the other template details including information such as target, recipient, or event trigger. ## Adding a placeholder to a template or document To add a placeholder to a notification template or document: 1. Go to the template editor. 2. Select a field from the **Placeholder** dropdown menu. 3. Copy the placeholder text that is displayed when the field is selected, including the curly brackets. 4. Paste the placeholder text in the content editor, where it should be displayed. 5. Save your changes. For example, if the document requires to have the account ID then this field should be selected in the placeholder dropdown, and its placeholder `` copied and pasted in the document editor. Whenever the document is generated for an account, the account ID will be displayed where the placeholder was inserted. ## Product document placeholders ### Account placeholders You can select account placeholders using the **Account Placeholders** dropdown. They are available for account documents and include information about the account and the account holder, including custom field values. ### Transaction placeholders You can select transaction placeholders using the **Transaction Placeholders** dropdown. The dropdown is only displayed and available if the **Include transaction history** checkbox is selected. Transaction placeholders are available for transaction and account documents and they include transaction fields. They are available for transaction and account documents. ### Start Statement / End Statement Placeholders [Product Documents](/docs/product-documents) which have the **Include transaction history** checkbox selected (for example, an account statement) have two additional placeholders which define where the transaction history such as the list of transactions within a date range will be displayed. * **Start statement**: defines the start of the transaction history area in the document * **End statement**: defines the end of the transaction history area Any transaction history information that should be displayed in the document should be included between the start or end statement placeholders, no other placeholders should be included in between the start or end statement placeholders. You will only need to add one row of placeholders and the system will create as many rows as there are transactions between the date range given. Using the HTML editor you can make sure each element of the statement is properly formatted and aligned. For example, a template with this section: ### Statement HTML Code ```html

    MBU Bennett Bank. - Branch:
    Address: 1506  00502  Tel:

    Deposits Account Statement
    Printed on:

    Client Information:Account Information:

    Name:
    Contact Data: , , , Phone:
    Identification: ID Number: , ID Type:

    Product:
    Account ID:




    Transaction Date Transaction ID Transaction Type Debit Amount Credit Amount Balance 
    FORMAT FORMAT FORMAT






    ``` Will look like this in the rich text editor: ![Statement template for regular checking](@site/static/img/support/editing-statements-templates.png) And produce a statement looking like this: ![Example of account statement](@site/static/img/support/account-statement.png) :::warning Amount placeholders will represent the absolute numeric value upon document generation, that means there is no negative or positive symbol before an amount. However, you can use the transaction type placeholder - `` - to differentiate between deposits, withdrawals, transfers and other fees and charges. ::: ## Contracts and receipts for groups Some placeholders can be combined with numbers to retrieve information from each member of a group. Following the syntax `` where `X` means the group member number. For example, for the client name field, ` ; ; ` could be added, displaying the name of the first, second, and third client. Placeholders that can be used with the syntax above: * `` * `` * `` * `` * `` * `` * `` * `` * `` * `` The `INTEREST_TIER_RATE` placeholder can also be used with numbers using the following syntax: * Tier 1 Interest Rate: `` * Tier 2 Interest Rate: `` :::note The numbers added to the placeholder should start with "1" and go up to the maximum number of members in a group. ::: ## Formatting numbers In many jurisdictions, contracts and other documents need to specify amounts in numeric and written form. For example: the value GBP120.25 would also need to be written out as "one hundred and twenty pounds sterling and twenty five pence." Mambu can automatically convert numeric values into words in the following languages: English, Spanish, and Chinese. Placeholders are available for use in both document and notification templates. :::note The numeric placeholders will be converted to words in the language of the current user viewing the document. ::: ### Options After selecting a numeric placeholder, you will be able to select the number format type. In the table below, we use the number 1,250.25 and show the output for each number format type. These are the default number formats and they may not be edited. | Display Option | Output | | --- | --- | |Formatted Number|1,250.25| |Unformatted Number|1250.25| |Integer in Words|one thousand two hundred fifty| |Fractional in Words|twenty five| |Tenths in Words|two| |Hundredths in Words|five| ![Placeholder type that can be Formatted Number, Unformatted Number, Integer in Words, Fractional in Words, Tenths in Words, Hundredths in Words](@site/static/img/support/loans--loan-document-placeholder-configuration.png) ### Currency The currency symbol can be included as either its symbol or currency code. The placeholders for these are `` and `` respectively. If you need to include the currency as words in your templates - for example, United States dollars, pound sterling, or euros - this can be done by creating a custom field definition with the desired text - for example, `currency in words`. Then add it to your accounts and inclue it in templates using the specific placeholder - for example, ``. For more information, see [Custom Fields](/docs/custom-fields). :::note We recommend making this field a required selection box if you work in multiple currencies to avoid possible human error when adding this to accounts. ::: ## Formatting dates For any placeholders which provide a date or date and time you can alter the pattern used to reflect the legal and cultural expectations of your region using the letters `d` for day, `M` for month, `y` for year, `h` for hour, `m` for minute, and `s` for second. For clarity a few examples are given in the table: | Placeholder | Generated output | | --- | --- | | `FORMAT_DATE` | 29/02/2020 | | `FORMAT_DATE` | 02-29-20 | | `FORMAT_DATE` | 2020-02-29 02:54:03 | The date and time used will be in the local time as configured in **Administration** > **General Setup** > **Organization Details**. ## Language settings The client preferred language will determine the language of some placeholders that you include in your notification templates and product documents. The following placeholders will be translated automatically: * `GENDER` * `CENTRE_MEETING_DAY` * `TRANSACTION_TYPE` * `TRANSACTION_DATE` * `AUTH_HOLD_SOURCE` * `AUTH_HOLD_STATE` * `LINE_OF_CREDIT_STATE` * the value of any other custom field of `checkbox` type For more information about language settings and the client preferred language, see [Language Settings](/docs/language-settings). --- # Pool Accounting URL: https://docs.mambu.com/docs/pool-accounting/ To ensure full financial accuracy and enable proper reconciliation of your profit-sharing operations, our platform provides a complete accounting flow at the pool level. This guide details how to configure and use the pool-level accounting features for Suspense, Reserve, and Bank P&L accounts. This process creates a complete audit trail, accurately tracking funds from the total pool income through to their final allocation after a profit application run. Before you begin, ensure you have a comprehensive **Chart of Accounts** configured in **Administration** > **General Setup.** ## Configuring pool accounting To enable pool-level accounting, you must map the correct General Ledger (GL) accounts to your Profit Sharing Pool. 1. Navigate to **Profit sharing** > **Product**, select a **Product**, and navigate to **Actions**. 2. In the **Actions** screen, select **View settings**. 3. Navigate to **Create product settings** > **Profit sharing GL Accounts** section. 4. Choose a GL account from the drop-down list for each of the categories: **Profit suspense account**, **Reserve account**, **Bank P&L account**. * See below for definitions of these account types. * Save the product. :::note The Mudarib Share (the bank's equalization bar) is configured at the deposit product level, not at the pool level. You will not see GL account settings for the Mudarib Share on the pool configuration screen to prevent incorrect setups. ::: * **Suspense Account:** This is a temporary holding account. When profit is applied, the total distributable profit for customers, reserves, and the bank is moved here before being allocated to the final destination accounts. * **Reserve Account:** An account used to hold funds set aside after some procedure failure. After profit application of all accounts in the Pool, this GL account should be empty. **Bank P&L Account:** The final income account where the bank's share of the profit is recognized after all other allocations (customer profit, Mudarib share, reserves) have been made. ## How pool-level accounting works The accounting entries described below are automatically generated when an administrator runs the Apply Profit process for the pool. This process moves the funds from their source to their final destinations. The flow of funds follows two main stages: * **Stage 1:** Moving Total Distributable Profit to Suspense * First, the system transfers the total profit amount that needs to be distributed from the pool's source of funds (e.g., an Income account) into the temporary Suspense account. This journal entry consolidates the distributable profit, preparing it for allocation. * **Debit:** Source of Funds GL (e.g., Pool Income) * **Credit:** Suspense Account * **Stage 2:** Allocating Profit from the Suspense Account * Next, the system debits the Suspense account to allocate the funds to the various beneficiaries based on the profit distribution results. By the end of this process, the Suspense and Reserve Accounts balance for this transaction will be zero, and your financial reports will accurately reflect the final profit distribution. * **Debit:** Suspense Account (for the total amount) * **Credit:** Saving Controls (The total profit owed to all customers. This account is defined at the product level.) * **Credit:** Reserve Account (The amount allocated to reserves, if any.) * **Credit:** Bank P&L Account (The remaining profit belonging to the bank after customer shares and reserves are allocated.) --- # Posting Transactions with Custom Fields URL: https://docs.mambu.com/docs/posting-transactions-with-custom-fields/ There are two categories of transactions in Mambu: * Transactions made through transaction channels * Transactions made without using transaction channels For more information on what transaction channels are and which transactions are posted through them, see [Transaction Channels](/docs/transaction-channels). All transactions made through transaction channels can have custom field values assigned to them. For transactions made without using transaction channels, only transfers support having custom field values assigned to them. Custom fields are additional fields you can create to capture any additional information required for your business processes. For more information, see [Custom Fields](/docs/custom-fields). ## Managing custom field values ### Entering information in custom field definitions You may enter custom field values when posting transactions, provided you have the appropriate access rights for the custom field definitions. For more information, see [Custom Fields - Rights section](/docs/custom-fields#configuring-rights-for-roles). ![Disbursing a Loan using Bank Channel](@site/static/img/support/transactions-and-interest--disbursing-loan.png) ### Editing custom field values To edit custom field values, you must have the **Edit Loan Transactions** (`EDIT_LOAN_TRANSACTIONS`) and **Edit Deposit Transactions** (`EDIT_SAVINGS_TRANSACTIONS`) permissions. Mambu will log activities for any changes made on existing transactions. To edit custom field values on an account: 1. Open the account where you want to edit custom field values. 2. Go to the **Transactions** tab. 3. Select **View** on the transaction you want to edit. 4. Select **Edit** next to the custom field value you want to change. 5. Select **Check Mark** to save. ![Loan Transaction - Transaction Details](@site/static/img/support/transactions-and-interest--loan-transaction-details.png) ## Custom field definitions for transfers To make transfer custom field definitions, under **Administration** > **Fields**, select **Transaction by Type**. For more information, see [Custom Fields](/docs/custom-fields). When a transfer is made from a source account to a target account, two transactions will be logged, one in the source account and one in the target account. However, the transfer custom field values will only be available on the source account transaction. ## Transaction custom field definitions for custom views and filtering Transaction custom field definitions can also be included as columns or filter constraints in: * Transactions custom views * Deposits collections * Repayment collections For more information, see [Custom Views](/docs/custom-views). --- # Prepayment Recalculation Methods URL: https://docs.mambu.com/docs/prepayment-recalculation-methods/ When a client makes an early repayment on a loan using the dynamic method, you can choose whether to recalculate the repayment schedule or not. Mambu supports different recalculation options which you can choose from, based on your internal operations and the interest calculation method used. ## Declining Balance When [setting up a new loan product](/docs/setting-up-new-loan-products), if under **Interest Rate** you have chosen the **Declining Balance** interest calculation method, then in the **Repayment Collection** section of the form, select one of the following prepayment recalculation methods: * No recalculation * Reschedule remaining repayments * Recalculate the schedule, keep the same number of terms * Recalculate the schedule, keep the same principal amount ![The available prepayment recalculation methods](@site/static/img/support/prepayment-recalculation.png) The repayment recalculation method you choose when setting up a new loan product will be applied to all the accounts created under it. Based on the product setup, this is how the schedule would look like one month after disbursal and without any payments made: ![Schedule - Declining Balance (recalculation method)](@site/static/img/support/loans--loan-repayment-schedule-7.png) ### No recalculation When using this method, there are no changes in the original repayment schedule. The repayments will remain as if the USD600 were paid on the due date. ![Schedule - Declining Balance with No Recalculation](@site/static/img/support/loans--loan-repayment-schedule-5.png) In the example, both the repayments due in February and March are paid. Without any interest accrued after March 21, the remaining amount will be used to pay the principal of the third installment, the total amount of the principal, and a partial amount of the fourth installment. The remaining installments will still display the same amount as in the original schedule. ### Reschedule remaining repayments When using this method, the expected principal amounts of all the upcoming repayments is reduced equally by the prepaid amount. ![Schedule - Reschedule remaining repayments](@site/static/img/support/loans--loan-repayment-schedule-3.png) In the example, you can see that the first and second repayments are paid. The third installment's principal is also paid and, as there was no interest accrued, the installment is considered as totally paid. The remaining amount will still be used to pay part of the fourth installment's principal. The remaining repayments are recalculated. ### Recalculate the schedule, keep the same number of terms When using this method, where there is an overpayment, the next repayments will be recalculated based on the resulting principal balance. ![Schedule - recalculate schedule, keep the same number of terms](@site/static/img/support/loans--loan-repayment-schedule-table.png) If instead of an overpayment, there had been a partial pre-payment, the remaining schedule would not be recalculated. ### Recalculate the schedule, keep the same principal amount When using this method, where there is an overpayment, the next repayments will be recalculated based on the resulting principal balance and the repayment is allocated first on the due installments. When the due installments are paid, the number of installments is reduced by allocating the remaining amount on the pending installments at the bottom of the schedule and marking them as paid when the principal expected is covered. ![Schedule - Recalculate schedule, keep the same principle amount](@site/static/img/support/loans--loan-repayment-schedule.png) ## Declining Balance Equal Installments When [setting up a new loan product](/docs/setting-up-new-loan-products), if under **Interest Rate** you have chosen the **Declining Balance (Equal Installments)** interest calculation method, then in the **Repayment Collection** section of the form, select one of the following prepayment recalculation methods (**Pre-Payment Allocation**): * **On Next Installments** with **Mark Installment as Paid When**: * Full Due is Paid (on/after Due Date) * Principal Expected is Paid (before/on Due Date) * **On Upcoming Pending Installment Only** with **Pre-Payment Recalculation**: * Reduce Amount per Installment (RAI) * Reduce Number of Installments (RNI) The repayment recalculation method you choose when setting up a new loan product will be applied to all the accounts created under it. Next you can see how the schedules would look like for each of the methods, based on the interest calculation method used. Let's consider the following loan details for the examples: * Amount: USD1000 * Six installments * Principal Payment Interval: 1 * Interest Rate: 10% charged per year * Installments Frequency: Every Month * Disbursement Date: 21/01/2021 * Today's Date: 21/03/2021 * 360 days in year Under each recalculation method and each interest method you will see how the repayment schedule would look like for each method, assuming there is a repayment of USD600—knowing the due amount on the 21st of March is just the sum of the first two installments, therefore there will be a pre-payment of the remaining amount. Based on the same account setup, this is the original schedule for an account using the Declining Balance Equal Installments (DBEI) method. ![Schedule - DBEI - recalculation methods](@site/static/img/support/loans--loan-repayment-schedule-table-5.png) ### Prepayment allocation: On Upcoming Pending Installment Only You have two additional options for allocating prepayments only to the upcoming installment. #### Reduce Amount per Installment (RAI) This method allows for the amount per installment to be reduced when a prepayment is performed, therefore keeping the original number of installments. When making a prepayment, once the principal on the next due installment is covered, it will be marked as paid and the extra interest to be accrued will be recalculated in the next installment. This means that, on the due date, the client only needs to pay a portion of interest. ![Schedule - Reduce Amount per Instalment](@site/static/img/support/loans--loan-account-schedule.png) #### Reduce Number of Installments (RNI) This method allows for the number of installments on the account to be reduced when a prepayment is performed. When the prepayment is performed earlier than the expected due date and if the principal amount is covered, then the installment is marked as paid and the remaining un-accrued interest will be recalculated in the next installment. Using this method, the principal due can be reduced to zero. ![Schedule - Reduce Number of Instalments](@site/static/img/support/loans--loan-repayment-schedule-9.png) In the example, the USD600 prepayment is allocated fully on the current installment. In our case the first on the schedule. Since the expected principal was covered, the installment is marked as paid and the remaining interest is recalculated in the next installment. As the repayment amount was considerably higher than what was expected, the last two installments on the schedule are completely reduced. When entering a repayment greater than the total due, you can choose which prepayment recalculation method you want to use. It can be either **Reduce Amount per Installment** or **Reduce Number of Installments**. The impact on the schedule is visible only if you enter an overpayment, meaning, if the repayment is smaller or equal to the total due, there is no impact on the schedule regardless what prepayment recalculation you choose. ![Apply a Repayment dialog with choose prepayment recalculation checkbox selected and the two available options for prepayment recalculation: reduce number of installments and reduce amount per installment](@site/static/img/support/choose-prepayment-recalculation.png) :::warning If you have a product setup with **Reduce Number of Installments** and **Increase the Last Installment** as recalculation methods, you will not be able to choose between **Reduce Amount per Installment** and **Reduce Number of Installments**. ::: ### Prepayment allocation: On Next Installments You have two additional options for allocating prepayments on the next installments. #### Full Amount Due is Paid (on/after Due Date) When using this method, the prepayment is allocated to the principal on the current and next installments. However, the current installment will be marked as partially paid, as there remains interest to be accrued until the due date. This means on the due date, the client needs to pay the interest accrued until then. ![Schedule - Prepayment allocation on next installments](@site/static/img/support/loans--loan-repayment-schedule-with-prepayment-allocation.png) #### Principal Expected is Paid (before/on Due Date) When using this method, the prepayment will be allocated to the principal on the current and next installment. The current installment will be marked as paid and interest is recalculated in the next due installment. ![Schedule - Principal expected is paid (before/on due date)](@site/static/img/support/loans--loan-repayment-schedule-table-3.png) --- # Principal Overpayment URL: https://docs.mambu.com/docs/principal-overpayment/ **Principal overpayments** provide a distinct way to process non-scheduled overpayments, applying the funds directly to the outstanding principal balance. This can then impact your repayment schedule based on the chosen prepayment recalculation method, either by reducing the amount per installment or by reducing the number of installments. This functionality is supported for [dynamic mortgages](/docs/dynamic-mortgages). For [interest only loans](/docs/equal-installment-interest-only-loans), principal overpayments can be made by entering a Custom Repayment and specifically allocating it to the principal. ## How it works * **Dedicated overpayment option**: Use the **Make Principal Overpayment** button to allocate your payment for principal reduction under the rules of principal overpayment. * You can also use the API endpoint `POST /loans//principal-overpayment-transactions`. * **Separate transaction log**: Every overpayment in the principal balance will be logged as a distinct Principal Overpayment Entered transaction at the account level. * **Direct principal allocation**: Any funds you submit using this new overpayment method are allocated entirely to the loan’s outstanding principal balance. Importantly, interest is neither applied nor paid with this specific principal overpayment transaction. * **Immediate balance updates**: The overpayment instantly reduces your loan’s principal balance. This immediately updates how future interest is calculated, potentially lowering the total interest you’ll pay over time. * **Schedule recalculation**: Your loan schedule is then recalculated based on your chosen prepayment recalculation method: * **Reduce number of installments**: Shortens your loan term by reducing instalments from the end of the loan. * **Reduce amount per installment**: Recalculates the total amounts due for your remaining installments, making each payment smaller. * **Threshold consideration**: If your loan uses the "Reduce Amount per Instalment" method, the new payment amount (PMT) will be recalculated while also considering any thresholds set up at the account level. * **No installment allocation**: While the overpayment doesn't directly pay any specific instalment on your schedule, it does have a schedule representation. This is shown in a separate column purely for informational purposes, making it easier to reconcile the amounts. * **Early repayment charges**: Principal overpayments may be subject to early repayment charges. :::note In order to post a non-scheduled overpayment, the account must not have any late installments. If there are any late installments, these should first be paid before the non-schedule overpayment can be allocated to the account. ::: --- # Processing Loan Repayments URL: https://docs.mambu.com/docs/processing-loan-repayments/ You can process single, partial, custom or bulk repayments. These may be entered in the present or backdated. ## Enter a single repayment To enter a single repayment to a client or group's loan account: 1. Open the client's profile. 2. Select the appropriate loan account. 3. On the right-hand side of the screen, select **Enter Repayment**. 4. In the **Apply a Repayment** dialog, enter the amount, the entry date, the transaction channel (by using the **Channel** dropdown), and some notes about the repayment. If a repayment is due, the **Amount** field is automatically populated with the total due amount, which includes principal, interest, fees, and/or penalties due balances. 5. Select **Apply Repayment** - the repayment will be done based on the [allocation order](/docs/repayment-allocation-order) you set up when creating the loan product. ![The amount to be paid is populated automatically with the total due and you can see it in the Apply a repayment dialog](@site/static/img/support/apply-a-repayment-amount.png) :::warning Interest accrued (which is only a parameter at account level, not a balance) **will not** be paid or displayed in the total due balance if it's not applied. If interest accrued is applied, you'll be able to see an interest balance for it. ::: ## Backdate repayments By default, when entering a repayment the transaction date will be today. You can choose to backdate a repayment, but you need to make sure that there are no repayments already entered after this date. To backdate a repayment: 1. Open the client's profile in the Mambu UI. 2. Select the appropriate loan account. 3. On the right-hand side of the screen, select **Enter Repayment**. 4. In the **Apply a Repayment** dialog, enter the amount. 3. Under **Entry Date**, select **Backdate** and enter a date in the past. 4. Select **Apply Repayment**. ![Apply a repayment dialog with option to backdate](@site/static/img/support/backdate-a-repayment.png) :::note If there were any **Interest Applied** transactions logged after the date of the repayment, you also need to revert them before entering the repayment, so that the interest is calculated based on the new amounts. ::: ## Future-dated repayments Loan accounts using the Fixed Flat method do not depend on time for interest calculation and for that reason repayments can be entered with a future date, if necessary. To be able to accept postdated payments, you must specify this when [setting up new loan products](/docs/setting-up-new-loan-products), in the **Repayment Collection** section. ![Accept postdated repayments option in the Repayments Collection section of the loan product setup](@site/static/img/support/accept-postdated-payments.png) To enter a repayment in the future: 1. Open the client's profile in the Mambu UI. 2. Select the appropriate loan account. 3. On the right-hand side of the screen, select **Enter Repayment**. 4. In the **Apply a Repayment** dialog, enter the amount. 5. Under **Value Date (Entry Date)**, select **Postdate**. 6. Select **Apply repayment**. ![Apply a repayment dialog with the option to postdate](@site/static/img/support/apply-a-postdated-repayment.png) Mambu will apply the repayment according to the schedule, on the next pending installment or installments due dates. **Example** If we have a new loan, with no repayments entered, on which a USD300 payment is postdated. Mambu will split the USD300 according to the schedule and record the transactions on the installment due dates. ![Transactions tab - postdated payments transactions order](@site/static/img/support/loans--loan-account-transactions-3.png) ## Advance payments Advance payments allow borrowers to pay one or more future installments in full before their due dates, without triggering a recalculation of the repayment schedule. This is a common regulatory and market requirement in many countries. ### How it works An advance payment must cover the full total expected amount of the installment(s) it applies to — partial or excess payments are not accepted. Interest for the covered installments is recorded as pre-paid at the time of the advance payment. On each installment due date, the corresponding interest is then applied and marked as paid automatically. ### Product configuration Advance payments are supported for Dynamic Term Loans with the following configuration: * **Interest calculation method**: Declining Balance Equal Installments * **Interest calculated based on**: Principal only * **Payment method**: Optimized or Standard * **Pre-payment recalculation**: Reduce Number of Installments (RNI) or Reduce Amount per Installment (RAI) ### Key constraints * Advance payments cannot be applied if there is a late installment on the schedule. * Installments already paid via an advance payment cannot be edited or marked as a payment holiday. * Advance payments are not available on locked accounts. * Rescheduling and refinancing accounts with advance payments is supported. :::note Please note Advance payments are available on demand. Please reach out to your Customer Success Manager or to [support@mambu.com](mailto:support@mambu.com) for additional information or guidance. ::: ## Enter a custom repayment :::note In order to post a custom repayment, you need the **Perform Repayments With Custom Amounts Allocation** [permission](/docs/permissions). ::: At a Dynamic Term product level, in the **Repayments Collection** section, select **Allow Custom Repayment Allocation**. ![Repayment Collection section with Allow Custom Repayments Allocation option selected](@site/static/img/support/loans--repayment-collection-configuration-3.png) Once this option is enabled, you can allocate the repayment amount to principal, interest, fee name or fee type, or penalty balance. :::note When you allocate a repayment to fees via API 2.0, you can choose to which fee type or fee name you want to alocate it. When you allocate a repayment to fees via the UI, you can choose to which fee name you want to alocate it. ::: To enter a custom repayment in the UI: 1. Open the loan account. 2. On the right-hand side of the screen, select **Enter Repayment**. 3. In the **Apply a repayment** dialog, select the **Custom repayment** checkbox. 4. Allocate the repayment according to the client's preference. 5. Under **Entry Date**, select the date of the repayment. 6. Using the **Channel** dropdown, select the transaction channel used to enter the repayment. 7. Optional: Add any notes related to the repayment. 8. Select **Apply Repayment**. ![Option to enter a custom repayment in the Apply a repayment dialog](@site/static/img/support/apply-a-custom-repayment.png) Below you can find an example of how a custom repayment can be allocated according to the client's preference via API 2.0: * Principal balance: USD1000 * Fee balance: USD100 * Manual fees: USD30 * Upfront fees: USD70 * Interest balance: USD10 When we enter a repayment of USD200, we can choose to allocate the repayment amount towards Upfront Fee, Interest and Principal: ```json {"customPaymentAmountType":"UPFRONT_DISBURSEMENT_FEE", "amount":"70"}, {"customPaymentAmountType":"INTEREST", "amount":"10"}, {"customPaymentAmountType":"PRINCIPAL", "amount":"120"}, ``` After the repayment is posted, the remaining amounts will be: * Principal balance: USD880 * Fees balance: USD30 * Manual fees: USD30 * Upfront fees: USD0 * Interest balance: USD0 ## Enter a repayment from a deposit account A repayment can be entered from a deposit account directly to the loan account. 1. Open the deposit account. 2. Select **Transfer**. 3. In the **Make Transfer** dialog, under **To Client**, select the target loan account from the dropdown. 4. Enter the amount you wish to tranfer. 5. Optional: Add any notes related to the transfer. 6. Select **Make Transfer**. This can be done between different clients, so client A could make a repayment to client B. In order to reverse the transaction, the original transfer must be reversed from the deposit account and with it, both transactions will be reversed. ![Make Transfer window - transfer is made into another client account.](@site/static/img/support/loans--make-transfer-dialog.png) ## Bulk repayments collection You can generate loan repayments in bulk—for one or more accounts, for one date or a range of dates—and then you can print, export or process these payments. When a bulk repayment is processed, a process is sent to the database and it is marked as `Queued`. In the UI a progress bar with 0% is displayed to show that the process is set to begin. When a worker is available the process will move to an `In Progress` state in the database. In the UI, the progress bar will show the progress of the repayments. After the process is done, it will be marked as `Completed` in the database and the progress bar will disappear. :::note You cannot do two bulk payments at the same time. Any attempt to do this will result in a warning message: “Another process is in progress”. ::: ### Filtering repayments To filter the accounts or the repayments that you want to process or print, go to **Loan Transactions** > **Repayments Collection** in the main menu. Click on the dropdown menus to filter the repayments per branch, centre, credit officer, group, and dates. Then click on **Filter**. ### View repayments vs. View accounts If you select the **View Repayments** option, you will see all the repayments (installments) that are due within the selected dates. For example, you might see more than one repayment due for the same account if the range is two weeks and the account has weekly payments. The amount displayed in each row will be the repayment amount expected as per the schedule. The **Date Paid** and **Amount Paid** fields will be populated with default values from the repayment schedules of those accounts, assuming that the client paid the exact amount due on the due date. When selecting the **View Accounts** option, you will see the total amount due for each account as of the specified date or a sum of all amounts due up to that date, if the client missed several installments. When selecting this view you can only select a single date, not a date range. ![Repayments collection screen](@site/static/img/support/repayments-collection.png) ### Posting a batch of repayments To enter the repayments, select the correspondent check boxes for each repayment or account, select **Post Repayments** in the new dialog, add the required details and then select **Post Repayments**. When posting the repayments you can specify the transaction channel to be used (by using the **Channel** dropdown) for all the repayments in the batch, along with any transaction details such as a check or receipt number and you can choose to backdate the transaction, if needed. All of these settings will be applied to all the payments in that batch. ![Dialog showing the total amount, the entry date and the channel used to post repayments in bulk](@site/static/img/support/post-repayments-in-bulk.png) :::note You can change each repayment's amount and dates individually, in the exceptional situations where they are different from what was defined in the repayment schedules, such as partial repayments or other situations in which the values change. If you change any of these values, you'll see that the row will change its color to orange, highlighting the repayments with different values from the original. ::: :::note If there are repayments that already have a transaction channel or date paid value filled in, they are not overriden with the ones from the **Post Repayments** dialog. ::: :::note The value in the **Post Repayments** button gets updated every time you add a new repayment, so that you can always see the total amount. ::: ### Customizing columns Just as in custom views, you can [customize](/docs/customizing-columns) which columns you want to see in the report. If you include any columns for transaction channel details, you can use them to enter a specific transaction channel info for each repayment. ### Printing repayment collection sheets The repayments collection tool can also be used to display and keep track of repayments due within a specific date. The list can then be printed and given to field staff who collect repayments directly from clients. To print a list of repayments due, use the filters to display the list you want to print on the right-hand side of the screen, and select **Print**. [![loans--repayments-collection-report.png](@site/static/img/support/loans--repayments-collection-report.png)](https://mambu2.document360.io/docs/https://s3.amazonaws.com/mambu-static/images/stories/repayments%20due.jpg) ## Partial repayments When a client does not pay the total amount due for a specific repayment, Mambu automatically sets a status of **Partially Paid** to that repayment. The amount paid will then be allocated according to the settings you defined in the [Lending Parameters](/docs/setting-up-new-loan-products). So, the order you determined in that section will define your organization's priority in terms of what needs to be paid first, principal, interest, fees, or penalties. ## Revert last repayment To revert the last repayment entered into an account: 1. Open the loan account. 2. Go to the **Transactions** tab. 3. Find the last repayment. 4. On the right-hand side of the row, select **Actions** > **Adjust**. 5. Enter the reason for the reversal. 6. Select **Reverse Repayment**. ![Actions button with Adjust option selected](@site/static/img/support/loans--loan-account-transactions.png) --- # Processing Transactions via a Till URL: https://docs.mambu.com/docs/processing-transactions-via-a-till-tellering-widget/ A teller can process the following transactions through the Tellering widget available from the Dashboard: * loan repayments * deposits on saving accounts * withdrawals from saving accounts :::warning For any other kind of client account transaction (such as disbursement, applying a fee, applying interest and so on Tellers should use the regular client account view.) ::: ## Post transactions To post a transaction through the Tellering widget: 1. On the main Dashboard, enter the client’s name, ID number or Document ID—the system will suggest a list of clients as you type in the field. 2. Select the destination account from the list of available client’s active accounts. 3. Select the type of transaction to be posted: * if you choose a loan account, then the **Transaction** field will automatically be set as a **Repayment**; * if you choose a deposit account, then the field will have a drop-down option to choose between a **Deposit** or a **Withdrawal**. 4. Enter the amount to be posted and click on **Post Transaction**. ![Posting a transaction from the Teller widget where Client, Account, Transaction type and amount fields are displayed](@site/static/img/support/tellers--post-cash-deposit-transaction.png) Once the transaction has been posted it will appear in the **Transaction Log** section and the **Expected Cash in Till** amount will be updated immediately with each transaction. You will also be prompted to print a receipt for the posted transaction. This option is available only if a receipt template has been created for the particular product and if the **Show Receipt** checkbox is selected. :::note Please note that for the time being all the transactions posted by a Teller user will go through the transaction channel that has been specified as “Default” under **Administration** > **Financial Setup** > **Transaction Channels**. ::: :::warning Transactions processed by a Teller outside of the Till (not through the Dashboard widget will still be reflected in the Transactions Log of the Till. This includes transactions posted via the Repayments and Deposit collections tools.) ::: ## Process inter-branch transactions All transactions posted by the Teller will be assigned to the Teller’s branch. However, Tellers can process transactions for clients in different branches, provided that they have access to that particular branch. To process a transaction for a client in a different branch, the Teller would have to make sure that the correct branch is selected using the branch filter drop-down menu located on the top-left section of the screen. The “Inter-Branch Transfer GL Account” will be used for such transactions. For example, if a Teller processes a deposit for a client from another branch, the accounting entries would be as follows: `Dr. Cash on Hand (Default transaction channel) (Branch A) Cr. Interbranch (Branch A) Dr. Interbranch (Branch B) Cr. Client Savings (Branch B)` --- # Product Documents URL: https://docs.mambu.com/docs/product-documents/ The product documents functionality for loan and deposit accounts lets users generate and print documents such as contracts, receipts, and statements based on a previously configured template. These templates can pull in information from the account, its transactions, and account holder data via placeholders. For more information, see [Placeholders](/docs/placeholders). Product document templates are also great for creating any kind of item which needs to be signed or witnessed, for example, loan agreements or even statements and confirmations of particular transactions. Any number of different templates can be created for each product. :::warning A product document template is only available for a specific product so if you would like to use the same template across multiple products, it will have to be created for each one. There is currently no way to automate this via the API. ::: ## Permissions for product documents In order to view, create, edit, and delete product documents, you must have the appropriate permissions: * **Create Product Documents** (`CREATE_PRODUCT_DOCUMENT_TEMPLATES`) * **Edit Product Documents** (`EDIT_PRODUCT_DOCUMENT_TEMPLATES`) * **Delete Product Documents** (`DELETE_PRODUCT_DOCUMENT_TEMPLATES`) ## Creating a document ![Documents view. All documents defined at product level will be found here.](@site/static/img/support/managing-your-organization--documents-tab.png) To create a new document: 1. On the main menu, go to **Administration** > **Products**. 2. Access the product for which you want to define the template. 3. Select the **Documents** tab. 4. Select **Add Document**. 5. Enter all the necessary information. 6. Select **Save Changes**. ### Fields for product documents Below are the fields you must fill in to create a product document. #### Name The name for the product document. Maximum of 255 characters. #### Availability You may make the document available for accounts or transactions. Documents available for accounts only have access to general account information, therefore they could be used for contracts or letters of intent. Whereas transaction documents relate to individual transactions, therefore they are perfect for things like receipts or confirmations. #### Content You edit the contents of the product document using a rich text editor and an HTML editor. For more information on how to use each editor to customize your product documents, see [Content Editors](/docs/content-editors). ![Document Editor view, from where the document templates can be edited as needed.](@site/static/img/support/managing-your-organization--edit-contract-document-template.png) ## Page breaks using the content editor Often when working with documents you will need to create multi-page documents. Using the HTML view, you can make inserts to add page breaks. For a minimal implementation with no other styling information necessary you could have something like this using ` ``` and then in your template you can add `` at the points at which you would like to break the page. For example: A template with the following HTML: ```html

    header for page 1

    some text on page 1

    header for page 2

    some text on page 2

    header for page 3

    some text for page 3 ``` Would result in the following when printing: If your CSS is complex you should import the stylesheet from a separate file hosted on a secure server. Your CSS should include a definition for a class for a page break like the following: ```html H1.PageBreak ``` The CSS must be placed on the very first lines of the document template. In the HTML view template you should add your import statement between ` PAGE 01 CONTENT

    PAGE 02 CONTENT

    PAGE 03 CONTENT ``` Where `PAGE 01 CONTENT` appears in the code, you should include the html code of the first page you want to print. In `PAGE 02` the second page, and in `PAGE 03` the third one. If you need to include more pages in the document, just add another line like this: ```html

    YOUR NEW PAGE CONTENT ``` You will not see these page breaks in the standard preview window, however, they will be reflected in the preview generated by the system print dialog. :::warning If the CSS is not showing in your template please check if you wrote `@import url();` correctly, that it is between opening and closing `` tags, and that the url points to the right file. ::: ## Generating Product Documents You can generate a document from the account page by selecting **Documents** and selecting the desired template from the drop-down menu. For any templates that include a statement section, you will also need to select a date range. ### Printing accounts documents from client profile ![Printing accounts documents from Clients' Profile](@site/static/img/support/managing-your-organization--client-profile-attachments.png) 1. Navigate to the account. 2. Select **Document** and select the document type to be printed. 3. Review the document and print. ### Printing transaction documents ![Printing loan accounts transactions from Transactions tab](@site/static/img/support/managing-your-organization--client-profile-transactions-tab.png) 1. Go to the account and select the **Transaction** tab. 2. Find the transaction for which the document will be printed. 3. Select **Actions** and the name of the document to be printed. 4. Review the document and print. A preview of the document will be visible for you to make sure everything is correct. Selecting **Print** will allow you to send the document to any printer or to save it as a PDF, which you can then attach to the account from the **Attachments** tab. :::warning Chrome or other browsers may add their own header and footer when you try to print, which will include the URL of the page as well as the current date and time, make sure you have disabled this in the options menu before printing a document for a client. ::: One a document has been signed, you can easily scan it and attach it to the account. For more information, see [Loan Account Attachments](/docs/loan-account-attachments). --- # Profit Application URL: https://docs.mambu.com/docs/profit-application/ Mambu uses an automated system to apply calculated, distributed and approved profits in profit sharing. Manual profit application is not supported currently, but it is under consideration. The automated application process follows these steps: 1. Profit is approved and the Proposal status becomes "Approved" 2. The profit application process is initiated by the system. 3. The system performs an automated check to verify your account details and account status. 4. Profit is applied using the transaction type "Profit applied". 5. Profit is applied using on account based on the schedule, at the end of the payment cycle of each account. 6. Profit is applied using a backdated transaction type "Profit applied", or the transaction is scheduled to the future. 7. If some proposal accounts will not be applied with the profit, the proposal status will become "Approved" and the proposal will be maintained in the list of "Closed" proposals. 8. Once all the proposal accounts have been applied with the profit, the proposal status will become "Applied". 9. Profit can be applied on the last day of payment cycle 23:59:59 or on the next day 00:00:00. These options are configurable in the product settings. --- # Profit Approval URL: https://docs.mambu.com/docs/profit-approval/ Mambu uses an automated system to approved the calculated and distributed profits, which provides transparency and speed. Manual approval is not supported currently, but it is under consideration.The automated approval process follows these steps: 1. Profit is calculated by the system on next day after the last day of the investment period. The result will be reflected in a proposal. 2. After the profit calculation distribution for each account is completed, the system puts the proposal into a status of "Pending Approval". 3. The approval process will be started right after the profit calculation and distribution for each account is completed. 4. Once the system confirms a proposal, the status will automatically change to "Approved". --- # Profit Calculation and Distribution URL: https://docs.mambu.com/docs/profit-calculation-and-distribution/ The profit sharing calculation methods were designed to be compliant with Shari'ah rules. The profit sharing calculation consists of three key stages: 1. Profit calculation 2. Profit approval (currently unavailable) 3. Profit distribution (currently unavailable) This page describes the first stage - profit calculation. The purpose of profit calculation in Islamic funding, beyond profit approval and distribution, includes determining the equivalent rate for the Pool profit. This equivalent rate is essential in defining the proportions of profit attributable to specific accounts or investment holders. By calculating the rate, Islamic financial institutions can allocate the profit fairly between different accounts based on their contributions to the Pool, while ensuring compliance with Shariah principles. This process helps maintain transparency and fairness, ensuring that each participant receives their rightful share of the profit in accordance with the risk-sharing structure of Islamic finance. ## Profit calculation formula Currently we support **Equivalent rate** for the Pool calculation: ***Formula*** * _Equivalent rate for the Pool_ = (Profit amount for the Pool * Days in a year) / (Average balance for the Pool * Days in a month) * _Profit amount for the Pool_ = Income for the Pool - Expenses for the Pool * _Average balance for the Pool_ = Average balance for the Account 1 + Average balance for the Account 2 + Average balance for the Account 3 + Average balance for the Account 4 + Average balance for the Account 5 + etc. ## Data input We use data input for profit calculation for specific investment periods. 1. _Utilisation of income from GL accounts_: Income recorded in specific GL accounts will be taken into consideration during each investment period. This will ensure that all relevant income is accurately captured for profit allocation. 2. _Inclusion of expenses_: any expenses tracked in the associated GL accounts will also be factored into the overall profit calculation, ensuring a comprehensive understanding of net profit. 3. _Average balances of accounts_: average account balances will be calculated over the investment period and will be used to distribute income proportionately. This will take into account different balance measures such as Average Daily Balance, Minimum Daily Balance, and End of Day Balance. For more information, refer to [Interest Calculation Methods in Deposit Accounts](/docs/interest-calculation-methods-in-deposit-accounts#what-account-balance-is-used-for-calculations). ## Process flow The profit calculation process can be triggered manually. If this action is performed during the investment period, the system will return indicative profit calculations. However, if the user needs to calculate the equivalent rate for a Pool with a completed period, they must ensure that the End-of-Day (EOD) process has been finalised. ## Income allocation methods This section describes how the available income allocation methods are calculated. * **Average Balance (default)**: This method calculates profit allocation based on the average balance of accounts over a specified period, typically a month. * **Example**: * Income amount: 200.000 * Pool 1 average balance: 30.000 * Pool 2 average percentage: 70.000 Pool 1 will receive 30% of the income (60.000), and Pool 2 will receive 70% of the income (140.000). * **Number of accounts**: With this method, profit allocation is determined by the total number of accounts participating in the profit calculation period. * **Example**: * Income amount: 200.000 * Pool 1 has 1M accounts * Pool 2 has 9M accounts Pool 1 will receive 10% of the income (20.000), and Pool 2 will receive 90% of the income (180.000). * **Percentage**: This method allocates profit based on the percentage of each pool’s defined share relative to the total income. Pools with higher defined percentages receive a proportionately higher share of the profit. * **Example**: * Income amount: 200.000 * Pool 1 is allocated 20% of the income * Pool 2 is allocated 80% of the income Pool 1 will receive 20% of the income (40.000), and Pool 2 will receive 80% of the income (160.000). --- # Profit Calculation URL: https://docs.mambu.com/docs/profit-calculation/ Profit calculations run in the backend, and [Proposals](/docs/running-proposals) present the results of the calculations with detailed information. Proposals run across all active pools available for the defined period, and give a breakdown of the profit parameters for each pool that falls within the calculation period. This is used to approve and apply the profits among the relevant accounts. This section breaks down how profit is calculated for a pool. The calculations are performed for each monthly profit calculation cycle. ![proposal calculation](/img/support/proposal-left-sidebar.png) ## Calculating the Pool's equivalent rate **1. Distributed income**: The sum of all income generated from the assets in the investment pool for the profit calculation cycle. ### How Distributed Income is Calculated The calculation method depends on whether **Asset/Liability Check** is enabled at Pool level. #### When Asset/Liability Check is DISABLED (default) ``` Formula Distributed Income = Σ Total Income from all Financing Income categories linked to the Pool ``` * Only Financing Income categories contribute to distributable profit. * Other Productive Asset Income is excluded. #### When Asset/Liability Check is ENABLED The system compares the Pool's Aggregated Account Balance (total deposit liabilities) against the Total Asset per Pool (sum of income-generating asset GL balances) and applies one of two calculation methods: **Case A — Liabilities ≤ Financing Assets** When total deposits are less than or equal to financing assets: ``` Formula Distributed Income = Total Financing Income × (Aggregated Account Balance ÷ Financing Asset) ``` The pool only distributes the proportion of financing income that corresponds to customer funding. The remaining income (funded by bank equity) belongs to the bank. **Case B — Liabilities > Financing Assets** When total deposits exceed financing assets: ``` Formula Distributed Income = (Total Financing Income + Total Other Productive Asset Income) × MIN(1, Aggregated Account Balance ÷ (Financing Asset + Other Productive Asset)) ``` Other Productive Asset income (Sukuk, investments, interbank placements) is included to fund the customer deposits that financing assets alone cannot cover. ### Concrete Example: X Bank Islamic — April 2026 **Pool Configuration:** * Asset/Liability Check: ENABLED * Currency: AED * Days in Year / Month: 360 / 30 **Income Sources:** | Income Category | Type | Total Income (Cycle) | Asset GL Balance (Avg) | | --- | --- | --- | --- | | Sukuk & Investments | Other Productive Asset Income | AED 266.25 | AED 71,000 | | Financing Income (Murabaha) | Financing Income | AED 0 | AED 0 | **Pool Composition:** | Component | Amount | | --- | --- | | Shareholders' Equity | AED 21,000 | | Mudaraba Deposits (customer liabilities) | AED 50,000 | | Total Pool (Aggregated Account Balance) | AED 71,000 | **Calculation:** 1. Determine which case applies: * Aggregated Account Balance = AED 71,000 * Financing Asset = AED 0 * Other Productive Asset = AED 71,000 * Since Liabilities (71,000) > Financing Assets (0) → Case B applies 2. Apply Case B formula: ``` Distributed Income = (0 + 266.25) × MIN(1, 71,000 ÷ (0 + 71,000)) = 266.25 × MIN(1, 1.0) = 266.25 × 1.0 = AED 266.25 ``` **Key Observations:** * Without A/L Check enabled, the Sukuk income (AED 266.25) would not be distributed because it's classified as "Other Productive Asset Income". * With A/L Check enabled, all income is distributed because the pool's assets (71,000) exactly match the liabilities (71,000). * If deposits were 80,000 but assets remained 71,000, the ratio would be 71,000 / 80,000 = 0.8875, and only 88.75% of income would be distributed (the remaining 11.25% would be reserved as the pool is underfunded). * Negative balances are rounded to 0. * Asset balance calculation: Day x = ending balance of Asset GL; Cycle = average of daily balances. **2. Distributed expenses**: The sum of all direct expenses incurred in managing the investment pool for the profit calculation cycle. ### How Distributed Expenses are Calculated Expense categories linked to the Pool are aggregated and allocated based on the configured allocation method. Unlike income, expenses are not affected by the Asset/Liability Check setting — all linked expenses are always included in the calculation. ``` Formula Distributed Expenses = Σ Total Expenses from all Expense categories linked to the Pool ``` #### Allocation Methods When multiple Pools share the same expense category, expenses are distributed proportionally using one of three methods: | Allocation Method | Formula | Use Case | | --- | --- | --- | | **Number of Accounts** | Pool's Expense Share = Total Expense × (Accounts in Pool ÷ Total Accounts across all Pools) | Fair distribution when all accounts have similar impact on expenses | | **Average Balance** | Pool's Expense Share = Total Expense × (Pool Agg Balance ÷ Total Agg Balance across all Pools) | Proportional to deposit size — larger pools bear more expense | | **Fixed %** | Pool's Expense Share = Total Expense × Pool's Defined % | Manual allocation control (all pools must sum to 100%) | ### Possible types of Expenses Expense categories typically include: 1. **Operational Expenses** * Management fees * Administrative costs * Transaction processing fees * Regulatory compliance costs 2. **Pool-Specific Deductions** (workaround until Deductions feature is developed) * Wakala fee (recommended as expense category per AAOIFI SS 46) * Pool base reductions: * Fixed assets offset * CB cash reserve offset * Cash in hand offset * Staff financing offset * Qard Hasan debit balances offset * Prepaid expenses offset * Investment in restricted funds offset 3. **Provisions** * Provisions for doubtful debts * Investment loss reserves :::note Some Islamic banks prefer revenue sharing instead of profit sharing and may choose not to configure expense categories. In such cases, the entire income amount becomes the distributable profit without any expense deductions. ::: ### Concrete Example: X Bank Islamic — April 2026 **Expense Categories Configured:** | Expense Category | GL Account | Amount (Cycle) | Pool Association | Allocation Method | | --- | --- | --- | --- | --- | | Management Fees | E500001 | AED 0 | AED Pool | Average Balance | | CB Cash Reserve Offset | E500010 | AED 0 | AED Pool | Fixed % (100%) | | Cash in Hand Offset | E500011 | AED 0 | AED Pool | Fixed % (100%) | **Calculation:** ``` Distributed Expenses = 0 + 0 + 0 = AED 0 ``` In the April 2026 cycle, no expenses were recorded, meaning the full income (AED 266.25) becomes the distributable profit. If expenses were recorded (hypothetical scenario), assume: * Management Fees = AED 20 * CB Cash Reserve Offset = AED 14 (calculated outside Mambu, posted manually) * Cash in Hand Offset = AED 15 (calculated outside Mambu, posted manually) ``` Distributed Expenses = 20 + 14 + 15 = AED 49 Distributable Profit = Distributed Income - Distributed Expenses = 266.25 - 49 = AED 217.25 ``` **3. Distributable profit amount**: The gross profit available for distribution to customers and the bank for the profit calculation cycle, before any deductions or Nisbah split (if applicable). ``` Formula Distributable Profit amount = Distributed Income - Distributed Expenses ``` This represents the net profit generated by the Pool during the cycle, after accounting for all income sources and operational expenses, but before applying: * PER (Profit Equalisation Reserve) deductions * Nisbah split (Bank Share % / Customer Share %) * IRR (Investment Risk Reserve) deductions * WPI (Wakil's Performance Incentive) deductions * Mudarib Share for Cap/Floor adjustments ### Key Observations * Distributable Profit Amount is calculated at Pool level — it applies to all products and accounts linked to that Pool. * Asset/Liability Check affects Distributed Income — it determines which income types are included (Financing only vs. Financing + Other Productive Asset). * Expenses are always deducted — regardless of A/L Check setting. * Deductions (PER, IRR, WPI) are applied after this gross profit is calculated. * Each currency Pool is independent — AED profit does not mix with USD profit. * This amount drives the Pool Equivalent Rate — the base rate from which all product and account rates are derived. **4. Aggregated account balance**: The sum of the average eligible balances from all accounts participating in the pool during the profit calculation cycle. It represents the total customer deposit balances that participate in profit sharing for a given Pool during a specific profit calculation cycle. It serves as: * The denominator in the Pool Equivalent Rate calculation. * The liability side in Asset/Liability Check comparisons. * The base for proportional profit allocation across products and accounts. ### Calculation Method ``` Formula Aggregated Account Balance (Pool) = Σ Aggregated Account Balance (per account) for all accounts in products linked to the Pool ``` Where each account's Aggregated Account Balance is calculated as: ``` Formula Account Aggregated Balance = Average of [Account Daily Balance] from Cycle Start Date to Cycle End Date ``` The Account Daily Balance type is configured at Pool level and can be: | Balance Type | Definition | When to Use | | --- | --- | --- | | End of Day Balance | The last balance the account has at the end of each day | Most common — reflects actual closing position | | Average Daily Balance | Average balance the account has during the day (across all intraday transactions) | When intraday activity is significant | | Minimum Daily Balance | Lowest balance the account has during the day | Conservative approach — ensures profit only on guaranteed minimum funds | :::warning Important exception When **Asset/Liability Check is enabled**, the system always uses **End of Day Balance** for the A/L comparison, regardless of the Pool's configured balance type setting. This override ensures consistency between asset and liability measurements. ::: **Eligibility Rules** An account's balance is included in the Aggregated Account Balance calculation if: * Account is linked to a product that is linked to the Pool. * Account status is `ACTIVE`, `ACTIVE_IN_ARREARS`, `LOCKED`, or `DORMANT`. * Account has a positive balance during the cycle (negative balances are rounded to 0). * Account's product category is Shari'ah-based (e.g. Shari'ah-based Consumer Deposits). Accounts are excluded if: * Account status is `PENDING_APPROVAL`, `APPROVED` (not yet activated), or `CLOSED`. * Account balance is negative (technical overdraft) — rounded to 0 before aggregation. :::note The **Minimum Eligible Balance** parameter at product / pool level is used to determine profit *payment* eligibility, but it does NOT affect whether an account's balance is included in the Aggregated Account Balance calculation for Pool Equivalent Rate purposes. Even accounts below the minimum eligible threshold contribute their balance to the pool aggregate. ::: **5. Equivalent rate %**: The annualized profit rate for the investment pool. This rate serves as a benchmark for distributing profit distribution to each account. Also known as: Pool Equivalent Rate, Pool Return Rate, Pool Profit Rate. ``` Formula Equivalent Rate % = (Distributable Profit * Days in Year) / (Aggregated Account Balance * Days in Cycle) * 100 ``` ### Purpose and Use The Equivalent Rate % is the single most important output of the pool-level calculation because: * **Benchmark for all products** — every product's profit rate is derived from this rate via weightage adjustment. * **Annualized for comparability** — allows comparison across cycles of different lengths (e.g. 28-day February vs. 31-day March). * **Performance indicator** — measures the investment pool's actual return for the period. * **Regulatory reporting** — often required for Sharia compliance reporting and central bank submissions. * **Customer communication** — forms the basis for the rates disclosed to customers. **Calculate Pool Equivalent Rate (X Bank Islamic — April 2026):** ``` Pool Equivalent Rate = (Distributed Income ÷ Aggregated Account Balance) × (Days in Year ÷ Days in Month) = (266.25 ÷ 71,000) × (360 ÷ 30) = 0.00375 × 12 = 0.045 = 4.50% per annum ``` **6. Mudarib share account balance**: The balance of the Mudarib share general ledger account on the first day of the cycle, used for profit adjustments. **7. Reserve account balance**: The balance of the reserve general ledger account on the first day of the cycle. ## Calculating total accrued profit amount The total accrued profit amount is the sum of the accrued profit amounts calculated for all individual products and accounts within the pool during the profit calculation cycle. 1. **Total bank share amount**: The bank's total share of the accrued profit. It is derived by calculating the allocated portion from each account in the pool for the profit calculation cycle. 2. **Total Mudarib amount**: The total value of all profit adjustments made across all accounts. It is derived by calculating the difference between the initial profit amount and the final profit amount, after adjustments, for every account in the pool for the profit calculation cycle. ## Calculating total final profit amount The total final profit amount is the sum of the final profit amounts calculated for all individual products and accounts within the pool during the profit payment cycles. 1. **Total bank share amount**: The bank's final, total share of the profit after all adjustments have been applied across all accounts in the pool for the profit payment cycles. 2. **Total Mudarib amount**: The total value of all profit adjustments made across all accounts. It is derived by calculating the difference between the initial profit amount and the final profit amount, after adjustments, for every account in the pool for the profit payment cycles. ## Product profit calculation result 1. **Product**: The name of the product and the number of accounts in a product. 2. **Profit rate**: The percentage of a portion of the Pool profit amount for a product. 3. **End of calculation cycle**: The profit calculation result for the profit calculation cycle (not full payments cycles). * **Aggregated account balance**: The average of eligible account balances during the profit calculation cycle period. * **Total bank share amount**: The bank's final, total share of the profit after all adjustments have been applied across all accounts in the pool for the profit payment cycles. * **Total accrued profit amount** * **Total Mudarib amount** 5. **End of payment cycles**: Profit calculation result for profit payment cycles. Payment cycle depends on account activation date. Payment cycle might be not equal to profit calculation cycle, when Product/Account has *profit calculation frequency = Monthly* and account activation date is any date except the first day of the month. * **Aggregated account balance**: The average of eligible account balances during profit calculation cycle period * **Total bank share amount**: The total profit earned by the bank from a customer account for the profit calculation cycle for profit calculation period * **Total final profit amount**: The total profit earned by the account for the profit calculation cycle before profit adjustment * **Total Mudarib amount**: The total value of all profit adjustments made across all accounts in the product. It is calculated by taking the difference between the final profit amount after adjustments and the initial profit amount before adjustments for every account in the product, for the duration of the profit payment cycles. ## Account profit calculation result 1. **Account ID**: The ID of the account in the system. 2. **State**: The Real deposit account state. 3. **Profit rate rule**: The value defined at the Product level. 4. **Profit rate from rule**: The value defined at the Product level. 5. **Capped rate**: The value defined at the Product level. 6. **Minimum eligible balance**: The value defined at the Product level. 7. **End of calculation cycle**: The profit calculation result for the profit calculation cycle (not full payments cycles). * **Number of days**: The number of the days in the period from the start of the payment cycle until the end of the calculation cycle. * **Profit calculation cycle end date**: The end date of the calculation cycle period. * **Eligible account balance**: The average of eligible account balances during the profit calculation cycle period. * **Customer share percentage**: The value defined at Product level. This parameter is fixed on the last day of the profit calculation cycle and will never be recalculated. * **Customer profit rate**: The profit rate applicable to the customer account. ``` Formula Customer profit rate = Pool's Equivalent Rate * Customer share percentage ``` * **Customer share amount**: The total profit earned by the account for the profit calculation cycle before profit adjustment. ``` Formula Customer share amount = (Customer profit rate * Eligible account balance * Days in Cycle) / (Distributable Profit × Days in Year) ``` * **Bank share amount**: The total profit earned by the bank from a customer account for the profit calculation cycle for the profit calculation period. ``` Formula Bank share amount = (Account pool's last equivalent rate * Number of days in the profit calculation cycle * Account's aggregated account balance for the profit calculation cycle period) / (Days in year - Customer share amount) ``` * * **Customer profit rate after adjustments**: The account's profit rate after comparison of calculated profit rate by the system vs the profit rate rule defined at product level. * **Accrued profit amount**: The total profit earned by the account for the profit calculation cycle before profit adjustment. ``` Formula Accrued profit amount = (Customer profit rate after adjustments * Eligible account balance * Days in Cycle) / (Distributable Profit × Days in Year) ``` * **Mudarib share amount**: The total profit earned by the account for the profit calculation cycle before profit adjustment. ``` Formula Mudarib share amount = Final profit amount - Customer share amount ``` 8. **End of payment cycles**: The profit calculation result for profit payment cycles. Payment cycle depends on account activation date. Payment cycle might be not equal to profit calculation cycle, when the Product or Account has the profit calculation frequency of *Monthly* and the account activation date is any date except the first day of the month. * **Number of days**: The number of the days in the payment cycle period. * **Profit payment cycle end date**: The end date of the payment cycle period. * **Eligible account balance**: The average of eligible account balances for the profit payment cycle period. * **Customer share percentage**: The value defined at the product level. If the product uses a tiered system, this percentage can change if the customer's eligible account balance moves into a different tier. The percentage is finalized on the last day of the profit payment cycle. This ensures that any significant balance changes occurring after the profit calculation cycle are accounted for before payment. Once this percentage is finalized for a payment period, it will not be changed or recalculated for that period. * **Customer profit rate**: The profit rate applicable to the customer account. If the product uses a tiered system, this percentage can change if the customer's eligible account balance moves into a different tier. The percentage is finalized on the last day of the profit payment cycle. This ensures that any significant balance changes occurring after the profit calculation cycle are accounted for before payment. Once this percentage is finalized for a payment period, it will not be changed or recalculated for that period. ``` Formula Customer profit rate = Pool's Equivalent Rate * Customer share percentage ``` * **Customer share amount**: The total profit earned by the account for the profit calculation cycle before profit adjustment. If the product uses a tiered system, this amount can change if the customer's eligible account balance moves into a different tier. The amount is finalized on the last day of the profit payment cycle. This ensures that any significant balance changes occurring after the profit calculation cycle are accounted for before payment. Once this amount is finalized for a payment period, it will not be changed or recalculated for that period. ``` Formula Customer share amount = (Customer profit rate * Eligible account balance * Days in Cycle) / (Distributable Profit × Days in Year) ``` * **Bank share amount**: The total profit earned by the bank from a customer account for the profit payment cycle. ``` Formula Bank share amount = (Account pool's last equivalent rate * Number of days in the profit payment cycle * Account's aggregated account balance for the profit payment cycle period) / (Days in year - Customer share amount) ``` * **Customer profit rate after adjustments**: The account's profit rate after comparison of calculated profit rate by the system vs profit rate rule defined at product level. * **Final profit amount**: The total profit earned by the account for the profit calculation cycle before profit adjustment. ``` Formula Accrued profit amount = (Customer profit rate after adjustments * Eligible account balance * Days in Cycle) / (Distributable Profit × Days in Year) ``` * **Mudarib share amount**: A negative value indicates that the profit paid to the customer is lower than the calculated amount; hence the difference will be stored under the Pool’s **Mudarib Share Account balance**. A positive value indicates that the profit paid to customer is higher than the calculated amount, hence the difference will need to be taken from the Pool’s **Mudarib Share Account balance**. ``` Formula Mudarib share amount = Final profit amount - Customer share amount ```` * **Withholding tax amount**: The tax amount applicable for an account. ``` Formula Withholding tax amount = Final profit amount * Withholding tax rate ``` --- # Profit Sharing Accounting Principles URL: https://docs.mambu.com/docs/profit-sharing-accounting-principles/ Our platform's standard accounting methodologies are fully applicable to Shari'ah-compliant deposit products. This guide outlines the specific configurations required to set up daily accruals and manage the accounting rules for these products. Before proceeding, we recommend you familiarise yourself with our core accounting concepts. Please review the following documentation: * [Before using the account module](/docs/accounting-setup) * [Enabling accounting for deposits ](/docs/accounting-setup#enabling-accounting-for-loans-and-deposits) * [Creating your Chart of Accounts](/docs/creating-your-chart-of-accounts) * [Journal entries ](/docs/journal-entries) * [Accounting reports](/docs/accounting-reports) * [Accounting closure](/docs/accounting-closures) * [Fees accounting](/docs/fees-accounting) * [Inter-branch transfer GL account](/docs/inter-branch-transfer-gl-account) * [Booking date vs value date](/docs/booking-date-vs-value-date) * [Accounting methodologies](/docs/cash-vs-accruals-accounting) * [Cash-based accounting](/docs/cash-vs-accruals-accounting#cash-based-accounting) * [Accrual-based accounting](/docs/cash-vs-accruals-accounting#accrual-based-accounting) :::note Currently, accounting for Islamic banking products is only supported in your organization's base currency. Multi-currency accounting is not available for these products. ::: ## Configuring accounting rules The following steps explain how to enable and configure either Cash or Accrual accounting for a Shari'ah-compliant deposit product: 1. Navigate to **Administration** > **Products** > **Deposits** and click **New Deposit Product**. 2. In the **Creating a New Deposit Product** screen at **Administration** > **Products** > **Deposit**, select **Product category** and **Profit Sharing: Yes**. * Navigate to **Accounting Rules** and choose **Methodology**. ![Configuring accounting rules](/img/support/configuring-accounting-rules.png) ## Cash accounting setup With the cash-based method, revenue and expenses are recognized only when money is actually received or paid out. 1. Navigate to **Administration** > **Products** > **Deposits** and click **New Deposit Product**. 2. In the **Creating a New Deposit Product** screen at **Administration** > **Products** > **Deposit**, select **Product category** and **Profit Sharing: Yes**. 3. Navigate to **Accounting Rules** and choose **Methodology: Cash** 4. Select GL accounts from the drop-down list for **Profit Expenses** and **Mudarib Share** along with **Transaction Source**, **Savings Control**, and **Fee Income**. 5. Save the product. ![Cash accounting setup](/img/support/cash-accounting-setup.png) ## Accruals accounting setup With the accrual method, revenue and expenses are recognized when they are earned or incurred, regardless of when the cash is exchanged. 1. Navigate to **Administration** > **Products** > **Deposits** and click **New Deposit Product**. 2. In the **Creating a New Deposit Product** screen at **Administration** > **Products** > **Deposit**, select **Product category** and **Profit Sharing: Yes**. 3. Navigate **Accounting Rules** and choose **Methodology: Accrual**. 4. Select GL accounts from the drop-down list for **Profit Expenses** and **Mudarib Share** along with **Transaction Source**, **Savings Control**, and **Fee Income**. 5. Next to **Profit Accrued Method**, select **Daily** or **Monthly** from the drop-down. 6. Save the product. ![Accruals accounting setup](/img/support/accruals-accounting-setup.png) ## Daily profit accruals configuration These settings are only applicable if you have selected the Accrual methodology with a Daily profit accrued method. ### Setting Initial Profit Rate [ER] The Initial Profit Rate (ER) is used to calculate the daily profit accrual amount before the final profit distribution is known. 1. Navigate to **Profit sharing** > **Pools** > and select a **Pool**. 2. In the **Creating a New Pool** screen, navigate to **Daily profit Accruals** and enter **Initial ER (Profit rate)** value. 3. Save the product. ![Setting initial profit rate](/img/support/setting-initial-profit-rate.png) ### Defining calculation and booking rules These settings control how the accrued amount is calculated and when the journal entries are posted. 1. Navigate to **Profit sharing** > **Product**, select a **Product**, and navigate to **Actions**. 2. In the **Actions** screen, select **View settings**. 3. Navigate to **Create product settings** and **Daily profit accruals** section. 4. Select the **Accrued profit amount calculation method** drop-down list and choose one of the following options: **Customer profit rate after adjustments**, **Customer profit rate**, **Customer profit rate with capped rate**. 5. Select the **Profit accrual point** drop-down list and choose one of the following options: **Next accrual date**, **Current accrual date**. 6. Save the product. ![Defining calculation and booking rules](/img/support/defining-calculation-booking-rules.png) #### Accrued profit amount calculation method This defines the formula used to calculate the daily accrued amount. Choose one of the following: * **Using Customer profit rate after adjustments** - the calculation uses the final daily profit rate after applying any predefined rules (minimum, maximum, or fixed rates). ``` Formula 1. Customer profit rate = Pool's Equivalent Rate * Customer share percentage. After comparison with min, max, fix predefined profit rate, the system gets Customer profit rate after adjustments 2. Accrued profit amount = (Customer profit rate after adjustments * Eligible account balance * Days in Cycle) / Days in Year) ``` * **Using Customer profit rate** - the calculation uses the customer's share of the pool's expected rate without applying min/max/fixed adjustments. ``` Formula 1. Customer profit rate = Pool's Equivalent Rate * Customer share percentage 2. Accrued profit amount = (Customer profit rate * Eligible account balance * Days in Cycle) / Days in Year) ``` * **Using Customer profit rate with capped rate** - the calculation uses the customer's profit rate but will not exceed the predefined maximum profit rate. ``` Formula 1. Customer profit rate = Pool's Equivalent Rate * Customer share percentage. After comparison with only predefined max profit rate , the system gets Customer profit rate after adjustments 2. Accrued profit amount= (Customer profit rate * Eligible account balance * Days in Cycle) / Days in Year) ``` #### Profit accrual point This defines the timing for booking the daily accrual journal entries. * Current accrual date - journal entries are posted at the end of the day (23:59:59 in your organization's timezone). * Next accrual date - journal entries for the previous day are posted at the beginning of the new day (00:00:00 in your organization's timezone). * Every time the profit accrued is booked, the previous day journal entries will be reversed and the new ones with the current profit accrued will be logged. #### Journal entry updating process Each day, the system automatically reverses the previous day's accrual entry and posts a new one with the updated total accrued amount. This ensures that the General Ledger always reflects the precise, up-to-date liability for profits payable. --- # Configurations URL: https://docs.mambu.com/docs/profit-sharing-configurations/ Shari'ah-based deposits differ from conventional deposits in their profit calculation methodology. Instead of relying on a predefined interest rate, Shari'ah-based deposits calculate returns based on specified criteria which are defined under pool, product/account, cash flow configurations. The profit is determined and distributed based on Product / Account Shari'ah attributes at the end of this period. Shari'ah attributes can currently be configured at the product level, but not at the account level. ## Configuration process Before starting the profit sharing configurations, the **[Chart of Accounts](/docs/creating-your-chart-of-accounts)** must be prepared. This is required because GL accounts need to be linked to Cash Flow (Income & Expenses) and Pool accounting (if needed). The system automatically validates the configuration. It is necessary to follow this sequence: + Configure **Pool** with status of "Inactive" + Configure **Pool settings** + Configure **Income** & **Income settings** + Configure **Expense** & **Expense settings** + In **Product Settings**, add the Shari'ah attributes and link them to the **Pool**. + Go to the **Pool** and change its status to "Active" After the **Pool** is made "Active," the system automatically runs validations. If these validations pass, the action is completed. :::note **For testing:** All GL accounts and Customer accounts must have balances. You will need to create transactions and [manual journal entries](/docs/journal-entries) to ensure this. ::: ## Add Shari'ah attributes to Shari'ah-based deposit products Once a Shari'ah-based deposit product with the profit sharing calculation method is created from the **Administration** section, users can configure the product's Shari'ah attributes under the **Profit Sharing** tab. The **Products** section of the **Profit Sharing** tab lists the Shari'ah-based products. ![products profit sharing](@site/static/img/support/products-profit-sharing.png) You can: * Select **Actions** > **View settings** to view or configure the product settings. See below for more information. You can create multiple settings for Shari'ah-based product by clicking **Create product settings**. ![create product settings](@site/static/img/support/create-product-settings.png) * Select the product settings **Actions** > **Edit** to change the product settings. Currently all changes will be applicable for the next profit calculation cycle defined under the **Pool settings**. For product settings with the same pool association and different effective dates, the profit calculation will take the setting with the latest effective date. * Select the product settings **Actions** > **View** to view the product settings. * Select the product settings **Actions** > **Copy** to make a copy of the product settings. * Select **Actions** > **View accounts** to see all the accounts that are linked to that product. The product settings screen shows all the settings for that specific product. Click the **Create product settings** button to add settings to the product. You can configure the following parameters: | Parameter | Description | Required | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | Effective date | The date when the change should be implemented. | Yes | | Product payment frequency | Monthly and Every Calendar Month (at the end of every month) | Yes | | Profit application point | Payment cycle end date (23:59:59) and Next payment cycle start date (00:00:00) | Yes | | Minimum eligible balance | This option allows to add the minimum account balance of account to be eligible and include an account into profit calculation | Yes | | **Profit rate** | The account calculated profit rate will be compared with the Profit rate value in this rule and will adjust the account profit rate accordingly | | | Use fixed rate | This rule will define fixed profit rate value | Yes | | Use fixed rate as minimum rate | This rule will define minimum value of profit rate | Yes | | Use calculated rate | This rule will always use the profit rate value, calculated by the system | Yes | | Profit rate | This value will be defined for Use fixed rate and Use fixed rate as minimum rate profit rules | Yes | | Capped rate | Maximum profit rate applicable for Use fixed rate as minimum rate and Use calculated rate profit rate rules | Yes | | **Customer share** | Nisbah attribute | | | Fixed customer share | This option will use the same % of customer share for all amount of account balance | Yes | | Tiered customer share | This option will use different % of customer share based on the amount of account balance | Yes | | **Withholding tax** | This part of the process can be enabled and disabled. After enabling it -the**Withholding tax source** should be added. How to create **Withholding tax source** can be found [here](/docs/customizing-index-rates#creating-a-new-index-rate) | Yes | | **Pool association** | The pools that are associated with the product. A product can only be associated with one pool for a given period | Yes | ## Configure pools Pools contain the income and expense categories, profit calculation period that are used to define the profit calculation period and additional parameters for profit calculation. 1. In the **Configuration** > **Pools** section of the **Profit Sharing** tab, click **Create pool**. 2. Add a Name and a Description, and indicate if the pool is active. 3. Click **Save** to create the pool. 4. To configure the additional parameters, next to the pool name click **Actions** > **View settings**. 5. Click **Create pool settings**. You can configure the following parameters: | Parameter | Description | Required | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | | Effective date | The date when the change should be implemented | Yes | | Name | The name of the investment pool. Include at least 3 or more characters, symbols cannot be used. | Yes | | Status | Whether the investment pool is currently active or inactive. | Yes | | Description | Document additional details or context related to the pool. | No | | Calculation frequency | Profit calculation will be performed once per month, in accordance with the calculation frequency unit. | Default value | | Calculation frequency unit | Profit calculation will be performed once per month, in accordance with the calculation frequency. | Default value | | Profit calculation balance type |

    The options are:

    • End of Day Balance
    • Average Balance
    • Minimum Balance

    This parameter will be used when calculating the aggregated account balance over the profit calculation cycle and profit payment cycle period.

    | Default value | | Days in year | Profit calculation will be performed using Actual/365 days per year. | Default value | | Profit calculation start date | Identify the beginning date for the current profit sharing cycle. This date should be the same as the effective date or set in the future. | Yes | | Customer share loss | At the moment, the loss cannot be shared— the only available option is "No." | Default value | | **Profit sharing GL Accounts** | These are general ledger accounts used to record and track the allocation and distribution of profits to eligible accounts | Optional | | Profit suspense amount | This GL account is a temporary holding account used to record all Income categories amounts that are yet to be allocated | Optional | | Reserve Accounts | These GL accounts represent profit amount that have been set aside due to some reasons | Optional | | Bank P&L account | This GL account, a records the bank customer % from each account in profit calculation process | Optional | | Mudarib share account | This GL account is used to record the difference (amount) between customer share amount and final profit amount (adjusted customer share amount) | Optional | In addition to creating pools, you can: * Edit the existing pool and pool settings with the same effective date by selecting **Actions** > **Edit**. The profit calculation process will take the setting with the latest effective date. * View the existing pool settings by selecting **Actions** > **View**. * Copy the existing pool settings by selecting **Actions** > **Copy**. * Deactivate the existing pool by selecting **Actions** > **Edit** > **Inactive**. ## Configure incomes **Standard:** Revenue generated from Sharia-compliant financing and investment activities (e.g. Murabaha, Wakala, Ijarah, Sukuk). Only income from permissible sources is eligible for distribution to customers. **Business:** Income categories linked to the Pool define which revenue streams contribute to the distributable profit. Each income category specifies an Income Source type, which determines how the income participates in profit distribution: * **Financing Income** — income from the bank's financing products (Murabaha, Ijarah, Tawarruq, etc.) funded by customer deposits. Always involved in the distributable profit calculation, regardless of A/L check setting. * **Other Productive Asset Income** — income from the bank's non-financing productive assets (Sukuk, investment portfolios, interbank placements) funded by customer deposits. Only involved in distribution when the Asset/Liability Check is enabled at Pool level. Each Income Category is also linked to an Asset GL account (1:1) which is used as the asset balance source when A/L check is enabled at Pool level. Income covers the different income categories from the investments. For example, within a real estate investment pool you may have income categories for rental property income and another for business property income. Income categories are linked to specific deposit accounts, and associated with a defined number of pools. * In the **Configuration** > **Incomes** section of the **Profit Sharing** tab, click **Create income category**. You can configure the following parameters: | Parameter | Description | Required | | ----------- | ----------------------------------------------------------------------------------------------- | -------- | | Name | The name of the income category. Include at least 3 or more characters, symbols cannot be used. | Yes | | Description | Document additional details or context related to the income category. | No | Once an income category is created, it can have multiple different kinds of settings. For example, it can be derived from different sources, or be linked to different pools. To manage income settings for an income category: 1. Select **Actions** > **View settings**. This will show a list of the settings associated with the income. 2. In the income settings screen, click **Create income settings**. You can configure the following parameters: | Parameter | Description | Required | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | | Effective date | The date when the change should be implemented. | Yes | | Allocation method | Specifies the method employed for allocating income. Select one of the following options from the drop-down menu:
    • Average balance
    • Number of accounts
    • Percentage
    Will not have any impact if the pool:income relationship is 1:1. | Default value | | Income source | Default value:*Financing Income* | Yes | | GL account | The transaction amounts in this account will be included in the profit calculation. | Yes | | Asset GL Account | The asset GL account linked to this income category (1:1 relationship). Used as the asset balance source when Asset/Liability Check is enabled at Pool level. Asset balance per day = day-end GL balance. Asset balance per cycle = average of daily balances. | No | | Pool association | The pools that are associated with the Income category. Click**+** to add additional pools, and enter a value for each, depending on the allocation method. | Yes | In addition to creating income categories, you can: * Edit an income category by selecting **Actions** > **Edit**: * Name * Description In addition to creating Income settings, you can: * Edit income settings by selecting **Actions** > **Edit**. You can modify: * Allocation method * Income source type (Financing Income or Other Productive Asset Income) * Income GL accounts * Asset GL account (when Asset/Liability Check is enabled) * Pool associations :::note All changes must be completed before the profit calculation cycle starts. If you need to modify Income settings for a future cycle, create new income settings with an effective date and specify the required changes. The system will automatically apply the settings with the latest effective date for each cycle. ::: ## Configure expenses Expenses cover the different expense categories for the Pool. For example, within a real estate investment pool you may have income categories for rental property expenses and another for business property expenses. Expense categories are linked to specific deposit accounts, and associated with a defined number of pools. Expense categories are not required for all forms of profit sharing configuration. For example, some Islamic banks will prefer to use revenue sharing instead of profit, and will not need to use expenses for their calculation. * In the **Configuration** > **Expenses** section of the **Profit Sharing** tab, click **Create expense category**. You can configure the following parameters: | Parameter | Description | Required | | ----------- | ------------------------------------------------------------------------------------------------ | -------- | | Name | The name of the expense category. Include at least 3 or more characters, symbols cannot be used. | Yes | | Description | Document additional details or context related to the expense category. | No | Once an expense category is created, it can have multiple different kinds of settings. To manage settings for an expense category: 1. Select **Actions** > **View settings**. This will show a list of the settings associated with the income. 2. In the expense settings screen, click **Create expense settings**. You can configure the following parameters: | Parameter | Description | Required | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | | Effective date | The date when the change should be implemented. | Yes | | Allocation method | Specifies the method employed for allocating expenses. Select one of the following options from the drop-down menu:
    • Average balance
    • Number of accounts
    • Percentage
    Will not have any impact if the pool:expense relationship is 1:1. | Default value | | GL account | The transaction amounts in this account will be included in the profit calculation. | Yes | | Pool association | The pools that are associated with the expense category. Click**+** to add additional pools, and enter a value for each, depending on the allocation method. | Yes | In addition to creating expense categories, you can: * Edit an expense category by selecting **Actions** > **Edit**: * Name * Description In addition to creating Expense settings, you can: * Edit expense settings by selecting **Actions** > **Edit**. You can modify: * Allocation method * Expense GL accounts * Pool associations :::note All changes must be completed before the profit calculation cycle starts. If you need to modify Expense settings for a future cycle, create new expense settings with an effective date and specify the required changes. The system will automatically apply the settings with the latest effective date for each cycle. ::: ## Income and expense allocation methods This section describes how the available income and expense allocation methods are calculated. * **Average Balance (default)**: This method calculates profit allocation based on the average balance of accounts over a specified period (controlled through Pool settings); typically a month. * **Example**: * Income amount: 200.000 * Pool 1 average balance: 30.000 * Pool 2 average percentage: 70.000 Pool 1 will receive 30% of the income (60.000), and Pool 2 will receive 70% of the income (140.000). * **Number of accounts**: With this method, profit allocation is determined by the total number of active accounts participating in the profit calculation period. * **Example**: * Income amount: 200.000 * Pool 1 has 1M accounts * Pool 2 has 9M accounts Pool 1 will receive 10% of the income (20.000), and Pool 2 will receive 90% of the income (180.000). * **Percentage**: This method allocates profit based on the percentage of each pool’s defined share relative to the total income. Pools with higher defined percentages receive a proportionately higher share of the profit. * **Example**: * Income amount: 200.000 * Pool 1 is allocated 20% of the income * Pool 2 is allocated 80% of the income Pool 1 will receive 20% of the income (40.000), and Pool 2 will receive 80% of the income (160.000). ## Data input Profit calculation and distribution are carried out using profit sharing products, designated pools, income and expense configurations, and data recorded in the Income and Expense GL accounts. This process also incorporates transactions from the clients' accounts. 1. _Utilisation of income from GL accounts_: Income recorded in specific GL accounts will be taken into consideration during each investment period. This will ensure that all relevant income is accurately captured for profit allocation. 2. _Inclusion of expenses_: Any expenses tracked in the associated GL accounts will also be factored into the overall profit calculation, ensuring a comprehensive understanding of net profit. 3. _Average balances of accounts_: Average account balances will be calculated over the investment period and will be used to distribute income proportionately. This will take into account different balance measures such as Average Daily Balance, Minimum Daily Balance, and End of Day Balance. 4. _Backdating deposits and withdrawals_: The general rules of backdating transactions are explained here: [Backdating deposits and withdrawals](/docs/deposits-withdrawals-and-transfers#backdating-deposits-and-withdrawals). In Shari'ah-based Deposits: * Any backdated deposits or withdrawals will cause the system to rerun profit calculations for the pool, product, and account according to the new account balances in open Proposals. * Updated balances will be included in the average balance calculation in profit calculation for two purposes: profit calculation for pool, product, and accounts; and income allocation within the investment cycle. --- # Profit sharing introduction URL: https://docs.mambu.com/docs/profit-sharing-introduction/ Profit sharing in Mambu is an implementation of Islamic banking in the form of deposit products made up of Shari'ah law-based contracts. The principles of Islam, expressed by Shari'ah law, provide the foundation and the contracts built on these principles provide the structure for financial products. Mambu offers a foundation to support Islamic funding deposit-based contracts. ## Principles of Islamic banking The basic principles that all Shari'ah-compliant products adhere to are: * **Shari'ah-based**: Operating on Shari'ah principles, which prohibit the charging or payment of interest (riba) * **Prohibition of interest**: Charging, collecting, or paying interest within financial contracts is strictly prohibited. * **Asset-backed financing**: Transactions are real asset based. Due to existence of goods and services no expansion of money takes place and thus no inflation is created. * **Profit or loss sharing**: Financial contracts ensure the equitable sharing of profits or losses among participants. * **Avoidance of Haram transactions**: Transactions involving forbidden (haram) products are strictly forbidden. * **Transparency and ethical considerations**: Islamic banks often emphasise ethical and socially responsible investments. They ensure transparency and adherence to Shari'ah principles. * **Zakat and charity**: Islamic banks offer accounts and products that facilitate Zakat (Islamic almsgiving) payments. They may encourage charitable giving as part of their operations. * **Contractual framework**: specialised contracts, such as Mudarabah (profit-sharing), Murabaha (cost-plus-profit sale), Ijara (leasing), and more, which comply with Shari'ah principles are used. ## Profit sharing process There are three key stages: * Profit calculation - to get a final equivalent profit rate for the Pool. * Profit Approval (currently unavailable) * Profit distribution (currently unavailable) The diagram below outlines the key parameters involved in profit calculation: * **Income & expenses**: Represent the profit for the investment period and can be allocated across multiple Pools based on specific allocation methods. * **Pools**: Used to define the profit calculation frequency, the number of days in a month and year, and the type of balance used for calculating the average balance during the investment period. * **Product**: Manages the weighting of accounts within a Pool. The daily profits are applied, and the percentages are shared between the customer and the bank. ![profit sharing concepts](@site/static/img/support/profit-sharing-concepts.png) ## Cloud hosting providers Profit sharing tools can be used in core systems across different cloud platforms, such as GCP, AWS, and Azure. It is hosted in both shared and dedicated instances, including sandbox environments. ## Restrictions and security For optimal performance and security, it is recommended to use a dedicated environment. **Early Access Limitations:** Some restrictions may apply to features in early access. Please discuss your requirements with your Mambu Customer Success Manager. These limitations ensure efficient utilisation of early access features while maintaining system stability and security. Islamic Profit Sharing utilises High Availability setup that includes multiple availability zones for both compute and data services, ensuring Recovery Time Objective (RTO) of <5 minutes and Recovery Point Objective (RPO) of 0 minutes. Cross-region Disaster Recovery (DR) functionality is not currently available. ### User rights A user is anyone who accesses and uses Mambu via the UI or the API. Users are assigned permissions which determine the information they can access and the tasks they can perform. For more information about see [Understanding Users, Roles, and Permissions.](/docs/understanding-users-roles-and-permissions) For usage of Islamic profit sharing it is important to mark Profit sharing in all places where are you define access rights: **1. Create a New User** ![users-and-access-control--user-creation-form.png](@site/static/img/support/users-and-access-control--user-creation-form.png) **2. Create a Role** ![users-and-access-control--create-role-dialog.png](@site/static/img/support/users-and-access-control--create-role-dialog.png) **3. Create API Consumer** ## Getting help For help with Islamic Profit Sharing, please see the various channels available that you can use on the [Getting Support](/docs/mambu-support) page. The release notes for Islamic Profit Sharing can be found on our [Release Notes](https://community.mambu.com/c/release-notes) page. --- # Re-opening a Deposit Account URL: https://docs.mambu.com/docs/re-opening-a-deposit-account/ If a deposit account was closed by mistake or if a client who has been inactive for some time comes back to your organization and wants to use the same account, you can re-open it. To re-open a deposit account: 1. Open the client's profile. 2. Click on **Closed Accounts**. 3. Click on the deposit account that you want to re-open. 4. On the right hand side of the screen, click on **Re-Open Account**. 5. Add a comment about the reason for re-opening. 6. Click on **Change Status**. ![Re-Open Account option](@site/static/img/support/deposits--client-profile-closed-accounts.png) :::warning Only **Current** and **Savings** accounts can be re-opened. ::: *** --- # Redraw and Offset Settings URL: https://docs.mambu.com/docs/redraw-facility-and-offset-loans/ The Offset and Redraw capabilities are used for Dynamic Term loan products in Mambu. They automatically recalculate the interest due on the loan account in accordance with events that occur on the linked deposit account or the redraw balance. :::warning The Offset and Redraw capabilities are available for Dynamic Term loans with a few important constraints: * They are only available for loans with the **Declining Balance (Equal Installments)** interest calculation method. * The interest type must be **Simple Interest** calculated using **Principal and Interest**. ::: ## Offset As the name suggests, the *Offset* capability allows you to offset a non-principal balance against the outstanding principal of the loan for interest calculation purposes, thus reducing the interest calculated on an Dynamic Term loan account. With this capability enabled, clients can have their excess cash temporarily reduce the interest burden on their loan without committing it to repaying the loan. :::note You can link an offset account to a loan account even when the loan account is in **Partially Disbursed** state, after being refinanced. ::: With this capability, a deposit account is linked to the loan account, similar to a settlement account. The balance on the offset deposit account is offset against the outstanding principal of the loan for interest calculation purposes. When calculating interest for a Dynamic Term loan account with **Enable Offset** selected, Mambu will deduct the balance on the offset deposit account from the outstanding principal of the loan account before multiplying by the interest rate, instead of multiplying the interest rate directly by the outstanding principal balance of the loan. :::warning If the interest rate on the offset deposit account is positive, then the deposit account will accrue interest, irrespective of the offset linkage. ::: ## Redraw When using the *Redraw* capability of a Dynamic Term loan, borrowers can redraw or reborrow any principal that they had already repaid in excess of their scheduled installments. For the account-level transaction types and interest mechanics of Redraw, see [Redraw balance and transactions](/docs/redraw-for-loans). For example, a borrower's expected monthly principal payment is USD100. If they paid USD200 each month for a period of six months, they will have paid an extra USD600 in excess of their scheduled principal repayments. The redraw capability then allows the borrower to redraw USD600 at any time, if needed. In the meantime, the outstanding principal of the loan is reduced by USD600, which reduces the interest calculated. ## Product setup 1. When [setting up a new loan product](/docs/setting-up-new-loan-products), under **Product Type**, select **Dynamic Term Loan**. 2. Go to the **Interest Rate** section of the form. 3. Set the **Interest Calculation Method** to **Declining Balance (Equal Installments)**. 4. Under **Calculate Interest Using**, select **Principal and Interest**. 5. Ensure that the **Interest Type** is set to **Simple**. This uncovers a new section called **Redraw and Offset Settings**. 6. Select **Enable Redraw**, **Enable Offset**, or both. ![Redraw and Offset Settings](@site/static/img/support/redraw-and-offset.png) ## Loans with offset account linking When the **Enable Offset** checkbox is selected, the option to link to a deposit account is automatically enabled for this product type. You can select the type of deposit product you want your loan account to be linked to and how automatic repayments are to be processed. Mambu offsets 100% of the offset account's balance against the loan principal. :::warning A dynamic loan account with the offset capability cannot be disbursed unless a deposit account is linked to it. A "Missing linked offset account" validation message will appear when trying to perform the disbursement without a linked deposit account. ::: ### Interest Calculation For loans with the *Offset* capability, interest is accrued based on the following formula: `(Outstanding Principal Balance of the Loan + Interest Balance – Offset Account Balance) * Daily Interest Rate of the Loan %` where the following are used for the calculation: > End of day transaction balance on the offset deposit account End of day outstanding principal balance End of day interest balance In case the balance on the offset account is equal to or higher than the loan’s outstanding principal balance, no interest is charged on the loan. Accrued interest on the loan account will be recalculated when: * Transactions that impact its balance are performed on the offset deposit account, for example, deposits, withdrawals, transfers, fees or interest application. This also includes backdated transactions. * A repayment is made on the loan account including backdated repayments. * A repayment is reversed on the loan account. * Interest is applied multiple times during an installment. :::note At the moment, reversals on the offset deposit accounts are not supported. ::: ### Examples The examples below assume the following account setup: > Loan Amount: USD1,000 Interest Rate: 10% per year Installments: 5 (monthly) Disbursement date: 18th of May 2020 Deposit made into linked account: USD200 on 18th of May 2020 #### Loan account schedule at disbursement This is how the initial schedule of the loan account with zero balance on the offset account looks like: ![Schedule at disbursement with offset account balance](@site/static/img/support/Schedule%20at%20disbursement%20with%20offset%20account%20balance.png) The loan account’s interest accrued is automatically updated to reflect the change in interest caused by the change in balance on the offset account. ![Accrued interest at disbursement](@site/static/img/support/Accrued%20interest%20at%20disbursement.png) #### Accrued Interest with an offset account with USD200 balance Our next example uses the following values: > Oustaging Principal Balance = USD1000 Interest Balance = USD0 Offset Account Balance = USD200 Daily Interest rate = 10%/360 No of days = 30 The image below shows the interest accrued as of 18th of June 2020 (for the first installment, starting with 18th of May 2020), which is calculated as follows: `(Outstanding Principal Balance of the Loan + Interest Balance – Offset Account Balance) \* Daily Interest Rate of the Loan %` The accrued interest on the account overview is updated to reflect the change in the balance of the offset deposit account. ![Accrued interest with offset balance](@site/static/img/support/Accrued%20interest%20with%20offset%20balance.png) #### Loan account schedule after deposit to offset deposit account The interest calculated based on above formula is applied on the account and the schedule is updated accordingly. Please notice that only the first installment, where interest is applied, is affected by the offset balance, the other pending installments having interest expected calculated based on the expected principal. ![schedule after interest applied](@site/static/img/support/schedule%20after%20interest%20applied.png) ## Loans with redraw capability A *Redraw* capability is very similar to an offset account—one can imagine it as an offset account being part of the loan account. :::warning Mambu uses a validation that prevents an Automatic Redraw Repayment from being backdated behind an existing record. For example, if a Payment Made is posted on 12/02 at 15:00, the EOD process cannot trigger the Automatic Redraw Repayment for the 12/02 00:00 timestamp and will instead post it on 13/02 at 00:00. ::: ### Loan balances and repayments For loan accounts with the **Redraw** capability, Mambu maintains an outstanding **Principal Balance** and a **Redraw Balance**. When making a repayment, the client can choose to make the repayment on the redraw balance or the principal balance. When a repayment is made to the redraw balance, it will be recorded as such on the loan account and it is available for withdrawal. If the repayment is made towards the principal balance, it is not available for withdrawal and it will adjust the schedule in accordance with the **Reduce Number of Instalments** pre-payment recalculation setting. ![Pre-payment recalculation under Repayment Collection in the Creating a new loan product form](@site/static/img/support/pre-payment-recalculation-dbei.png) Whenever an installment is due, Mambu automatically takes any available redraw balance towards the scheduled repayment. Just like any other repayment transaction, these automatic repayment transactions can be reversed. ### Interest Calculation For loans with the **Redraw** capability, interest is calculated based on the following formula: `Daily Interest Rate of the Loan % * (Outstanding Principal Balance of the Loan + Interest Balance - Redraw Balance of the Loan)` where the following are used for the calculation: > End of day redraw balance of the loan End of day outstanding principal balance End of day interest balance In case the redraw balance is equal to the outstanding principal balance, no interest is charged on the loan. The redraw balance cannot be higher than the outstanding principal balance. Interest accrued on the loan account will be recalculated when: * Transactions that impact the redraw balance (repayments to or withdrawals from the redraw balance) are made. This includes backdated transactions. * A repayment is made to the loan account’s outstanding principal balance (including backdated repayments). * A repayment is reversed on the loan account. * Interest is applied multiple times during an installment. ### Examples The examples below assume the following account setup: > Loan Amount: USD1,000 Interest Rate: 10% per year Installments: 5 (monthly) Disbursement date: 18th of May 2020 #### Accrued interest with zero redraw balance Given the use case, the accrued interest on the Account Overview will be updated to reflect the change in the redraw balance of the loan. The image below shows the interest accrued in the first due date, 18th of June, when no payment was made in the redraw balance. ![Interest Accrued with no redraw balance](@site/static/img/support/Interest%20Accrued%20with%20no%20redraw%20balance.png) And below the schedule is displayed with no redraw balance: ![Schedule at disbursement without redraw balance](@site/static/img/support/Schedule%20at%20disbursement%20without%20redraw%20balance.png) #### Accrued interest with redraw balance Now, let's see what happens when a backdated payment transaction of USD205.03 (the total of the first installment due) is made in the redraw balance on the 1st of June. In this scenario, the interest accrued will be calculated on 2 intervals: * The first interval, from 18th of May until 1st of June, using only the principal balance (the formula takes into consideration the redraw balance and interest balance as well, but for this interval both balances are 0) * The second interval, from 1st of June until 18th of June, using (principal balance - redraw balance), since the redraw balance is > 0 (interest balance is still zero). So, the accrued interest has a new value of USD7.37. ![Accrued interest with redraw balance](@site/static/img/support/Accrued%20interest%20with%20redraw%20balance.png) After the interest is applied, the schedule is also modified: * The interest expected from the first installment will be updated with the new value (USD7.37). * The the total due amount will be decreased as well, since the interest is smaller. * The next installments will not be affected. ![Schedule with redraw balance](@site/static/img/support/Schedule%20with%20redraw%20balance.png) ### Accounting From an accounting perspective, Mambu considers the redraw balance as part of the outstanding principal balance. Therefore, repayments to the redraw balance will be booked against the relevant Loan Portfolio GL Account. When a repayment is made on the redraw balance of a loan account, Mambu creates the following journal entries: | Type | GL Account | | --- | --- | | Debit | Transaction Source | | Credit | Loan Portfolio | When Mambu automatically collects a repayment from the redraw balance, it creates the following journal entries: | Type | GL Account | | --- | --- | | Debit | Loan Portfolio | | Credit | Interest Receivable | This is because the redraw balance already sits in the Loan Portfolio GL account and interest is taken from the redraw balance. When the client wants to withdraw money from the redraw balance, the following journal entries are created: | Type | GL Account | | --- | --- | | Debit | Loan Portfolio | | Credit | Transaction Source | ### Loan pay off, write off, rescheduling, and restructuring When closing, meaning paying off, rescheduling, restructuring, or writing off a loan account with the **Redraw** capability, Mambu will use the redraw balance to reduce the outstanding principal balance. Consider an active loan account with USD1000 principal balance outstanding and a redraw balance of USD200. Whenever a loan closure is initiated, the resulting outstanding principal balance is USD800. Mambu will log **Redraw Repayment** transaction on the loan account for the redraw balance amount that was used to reduce the principal. ## Redraw and Offset on the same account The Redraw and Offset capabilities can be used simultaneously on the same account. To use both capabilities on the same loan account, follow the steps described under [Product setup](/docs/redraw-facility-and-offset-loans#product-setup) and select both **Enable Redraw** and **Enable Offset**. Any loan account created under a product with both options enabled must be linked to a deposit account that allows offset, meaning that when [creating a deposit product](/docs/setting-up-new-deposit-products), in the **[Internal Controls](/docs/setting-up-new-deposit-products#internal-controls)** section, you must select **Allow accounts to be used for Offset**. Settlement options will be by default **No Automated Transfers**. ### Interest calculation When using the Redraw and Offset capabilities on the same account, the interest will be calculated based on both the redraw and offset balances. The interest accrued is calculated based on the redraw and offset balances by default and updated at each cron job execution. However, on the schedule, the interest expected will be calculated based on the redraw and offset balances only when the interest is applied (on the due date). For loans with the **Redraw** and the **Offset** capability, interest is calculated based on the following formula: `Daily Interest Rate of the Loan % * (Outstanding Principal Balance of the Loan + Interest Balance - Redraw Balance of the Loan - Offset Account Balance)` ### Loan balances and repayments When both redraw and offset balances are enabled on the account, the installment will be automatically paid from the redraw balance, not from the offset balance, via **Redraw Repayment** transaction. --- # Redraw balance and transactions URL: https://docs.mambu.com/docs/redraw-for-dynamic-term-loans/ This page describes how the Redraw capability behaves at the **account level** — the balances Mambu tracks, the transaction types involved, and how interest is recalculated. For the product-level configuration that enables Redraw (and the related Offset capability), see [Redraw and Offset Settings](/docs/redraw-facility-and-offset-loans). For dynamic term or interest-only loan accounts configured with the Redraw capability, Mambu maintains two key balances: the *Outstanding Principal Balance* and the *Redraw Balance*. The Redraw Balance acts as a holding account for overpayments, allowing these funds to potentially reduce the interest accrued on the loan. Crucially, interest on your loan will be calculated not on the principal balance, but on the *Principal Balance minus the Redraw Balance*. This means that any funds held in your Redraw Balance effectively reduce the amount of principal on which interest is charged, leading to a financial benefit. ## Repayment options - redraw and principal balance When making a repayment, borrowers have the option to direct the funds towards either: * **Principal Balance**: Repayments made to the Principal Balance are not available for withdrawal. These payments directly reduce the outstanding principal and trigger an adjustment to the loan schedule, in accordance with the pre-payment recalculation method configured for the account (e.g., Reduce Amount per Installment or Reduce Number of Installments). * **Redraw Balance**: Repayments made to the Redraw Balance are recorded as 'Payment Made' transactions. Funds in the redraw balance are able to be withdrawn if the lender chooses to provide this option. They do not directly adjust the loan schedule but provide an interest benefit. ## Redraw transaction types * **Redraw Balance**: When you make an extra payment and direct it to your Redraw Balance, Mambu logs this as a 'Payment Made' transaction. These funds are then available for you to withdraw if needed. * **Redraw Repayment (automatic)**: On the installment due date, Mambu automatically utilizes funds from your Redraw Balance to cover the installment due. This is recorded as a 'Redraw Repayment' transaction. * **Redraw Withdrawal**: This allows borrowers to reborrow any funds they have already repaid in excess of their scheduled installments. For instance, if your monthly principal payment is £100 and you paid £200 for six months, you'd have an extra £600 in your Redraw Balance that you could withdraw. ## Key aspects of redraw * **Interest Calculation**: The interest accrued on your loan account is continually recalculated. * If Interest from Arrears is Decoupled, interest will always be recalculated after Payment Made or Redraw Withdrawal transactions based on the `Expected Principal Balance - Redraw Balance`. * If Interest from Arrears is not decoupled from the repayment schedule, interest will be calculated based on the `Outstanding Principal Balance + Interest Balance - Redraw Balance`. * If your Redraw Balance equals your Outstanding Principal Balance, no interest will be charged on the loan. * The Redraw Balance cannot exceed the Outstanding Principal Balance. * **Immediate interest impact**: A significant improvement with this feature is that the Interest Expected (the interest component of your upcoming installment) is now updated immediately after Payment Made (to Redraw Balance) and Redraw Withdrawal transactions. You no longer have to wait for the interest application event for this update to reflect. If the redraw balance impacts more than one installment, you'll see the interest recalculated across all of them. * **PMT Recomputation**: The Payment Amount (PMT) for future installments will not be recomputed after Payment Made or Redraw Withdrawal transactions. This is because the system anticipates that scheduled payments will be executed on time on their respective installment due dates from the Redraw Balance. * **Recalculation triggers**: Interest accrued/expected on the loan account will be recalculated whenever: * Transactions that impact the Redraw Balance (repayments to or withdrawals from the redraw balance) are made, including backdated transactions. * A repayment is made to the loan account’s outstanding principal balance (including backdated repayments). * A repayment is reversed on the loan account. * Interest is applied multiple times during an installment (only when Interest from Arrears is not decoupled). ## Examples of interest accrual with redraw In the following examples we will assume: * Loan Amount: £1,000 * Interest Rate: 10% per year * Installments: 5 (monthly) * Disbursement date: 18th of May 2020 ### Scenario 1: Accrued interest with zero redraw balance If no payment is made into the redraw balance, the interest for the first due date (18th of June) would be calculated solely on the principal balance. `1000*10%/365* 31 days = 8.49` ![accrued interest with zero redraw balance](/img/support/accrued-interest-with-zero-redraw-balance.png) ### Scenario 2: Accrued interest with a non-zero redraw balance Consider a backdated payment transaction of £205.03 (equal to the first installment amount due) made into the redraw balance on June 1st. In this case, the interest accrued will be calculated over two intervals: * **First Interval (May 18th - June 1st)**: Interest is calculated on the full principal balance (as both redraw and interest balances are zero for this period). * `1000*10%/365* 14 days = 3.84` * **Second Interval (June 1st - June 18th)**: Interest is calculated on `Principal Balance - Redraw Balance`, as the redraw balance is now greater than zero. * `(1000-205.03)*10%/365* 17 days = 3.70` As a result, the accrued interest will be reduced (e.g., to £7.54 in this example). After the *payment made* transaction, the expected interest for the first installment will update to this new lower value, but the Total due amount (PMT) will stay the same. Subsequent installments, if no further redraw activity occurs, will reflect the original schedule unless adjusted by other principal or redraw repayments. ![accrued interest with redraw balance](/img/support/accrued-interest-with-redraw-balance.png) ## Accounting implications of redraw From an accounting perspective, Mambu treats the Redraw Balance as part of the outstanding principal. * **Repayment to Redraw Balance**: When a repayment is made to the redraw balance, Mambu generates the following journal entries: * Debit: Transaction Source (e.g., Bank Account) * Credit: Loan Portfolio GL Account * **Automatic Redraw Repayment**: When Mambu automatically collects an installment from the redraw balance, the journal entries are: * Debit: Loan Portfolio * Credit: Interest Receivable (as interest is effectively paid from the principal held in the redraw balance) * **Redraw Withdrawal**: When a client withdraws money from the redraw balance, the journal entries are: * Debit: Loan Portfolio * Credit: Transaction Source (e.g., Bank Account) ## Loan closure, write-off, rescheduling, and restructuring When closing (paying off), rescheduling, restructuring, or writing off a loan account with the Redraw capability, Mambu automatically uses the existing Redraw Balance to reduce the outstanding principal balance. For example, if a loan has an outstanding principal balance of £1000 and a redraw balance of £200, initiating any form of loan closure will result in an effective outstanding principal balance of £800. Mambu will log a Redraw Repayment transaction for the amount of the redraw balance that was used to reduce the principal. --- # Reduced Payment Deviations for Equal Installment Loans URL: https://docs.mambu.com/docs/reduced-payment-deviations-for-equal-installment-loans/ :::note This method is currently available for Dynamic Term loans with the Declining Balance Equal Installments interest calculation method, and no taxes. ::: Loans with large differences in the number of days between payments have equal installments due, but the last installment is usually adjusted with the difference that comes from the irregular payment intervals. *** ## Optimized Payments The functionality is available by selecting **Optimized Payments** as a payment method in the **Repayments Schedule** section, when [setting up a new loan product](/docs/setting-up-new-loan-products). With **Optimized Payments**, you can redistribute the irregular installments surplus of interest over the remaining installments. To accomplish this, the schedule is created in three steps: 1. The standard schedule is calculated. 2. The difference between the installments is redistributed on the remaining installments. 3. The deviation per installment using the standard interpolation method is reduced. *** ### Example The following is an example with a comparison between the Standard Payments and the Optimized Payments methods. ![comparison between the Standard Payments and the Optimized Payments methods](@site/static/img/support/loans--loan-payment-schedule-comparison.png) The optimized payments steps are applied when creating or activating an account and when editing the schedule due dates or number of installments. --- # Rejecting a Deposit Account Application URL: https://docs.mambu.com/docs/rejecting-a-deposit-account-application/ When a deposit account is still *Pending Approval* and the application hasn't fulfilled your organization's requirements, for instance, you can choose to reject it. To reject a deposit account application: 1. Open the deposit account. 2. On the right hand side of the screen, click on **Close** > **Reject**. 3. Add a comment about the reason for rejection. 4. Click on **Change Status**. ![Close drop-down with Withdraw or Reject options.](@site/static/img/support/deposits--deposit-account-details-with-close-menu.png) --- # Rejecting a Loan URL: https://docs.mambu.com/docs/rejecting-a-loan/ Loan accounts that do not meet the criteria for offering a loan can be rejected, as long as the loan state is `Pending Approval` or `Partial Application`. To do so: 1. Open the account. 2. Select **Close** > **Reject**. 3. Add a note about the reason you are rejecting the loan (optional). 4. Select **Close**. ![Rejecting the Loan Account from Close drop-down menu](@site/static/img/support/loans--loan-account-details-with-action-menu.png) :::note When a loan account is rejected it will be displayed in the **Closed Accounts** tab for the client. A closed or rejected loan account cannot be further edited, except for its custom field values or name. All attachments and activities are kept for future reference. ::: ## Undoing a loan rejection When a Loan Account is rejected by mistake, it can be brought back to its previous status. To do so select **More** > **Undo Reject** and then add an optional note. Lastly, select **Change State**. --- # Removing accounts from a credit arrangement URL: https://docs.mambu.com/docs/removing-accounts-from-a-credit-arrangement/ Accounts that are not yet closed can be removed (unlinked) from credit arrangements as long as the product setup does not require the account to be linked to a credit arrangement. To remove an account from a credit arrangement: 1. Open the client's or the group's profile. 2. Select the credit arrangement from which you want to remove accounts. 3. On the right-hand side of the screen, select **More** > **Remove Account**. 4. Choose from the list of available loan accounts or deposit accounts allowing overdrafts. 5. Select **Remove Account**. ![Remove an account from a credit arrangement](@site/static/img/support/remove-account-from-credit-arrangement.png) :::note Removing an account from a credit arrangement will update the **Available Credit Amount Balances** and the **Approved Credit Amount** values. ::: --- # Repayment Allocation Order URL: https://docs.mambu.com/docs/repayment-allocation-order/ For cases of prepayments, partial repayments or fees and penalties payment, the allocation order defined at the product level will determine what will be paid first. Suppose you wanted the fees to be paid first, then penalties, interest, and finally principal. In this case **Fees** would be on top of the list and **Principal** on the bottom. ## Set the allocation order To set the order of the items to be paid: 1. When [setting up new loan products](/docs/setting-up-new-loan-products), go to the **Repayment Collection** section of the form. 2. Drag and drop items to arrange them according to the order in which you want them paid on partial or overpayments. ![Choose the order in which pricipal, interest, fees and penalties will be paid on partial or over-payments](@site/static/img/support/repayment-allocation-order.png) The allocation order you set here can later be changed either by editing the loan product or by [making a custom repayment](/docs/processing-loan-repayments#enter-a-custom-repayment) via the API. --- # Repayment collection URL: https://docs.mambu.com/docs/repayment-collection/ When you enter a repayment, the amount of that repayment goes to the balances, meaning principal, interest, fees, and penalties based on the allocation method you set up in the **Repayment Collection** section of the [Setting up new loan products](/docs/setting-up-new-loan-products) form. :::warning Interest accrued, which is only a parameter at account level, not a balance, **will not** be paid or displayed in the **Total Due** balance if it's not applied. If the interest accrued is applied, you'll be able to see an interest balance for it. ::: ## Payment allocation method Allows you to define how the repayments should be posted in the repayment schedule. ![payment-allocation-method](@site/static/img/support/payment-allocation-method.png) ### Horizontal payments When a repayment is entered for an account using **Horizontal Payments** it's the actual repayment schedule that will determine what should be paid first based on the due dates. The amount entered will always be used to pay each installment and only move to the next installment due, when the previous has been completely paid. Fees and penalties are always associated to specific repayments and become due when that repayment also is due. ### Vertical payments Accounts using **Vertical Payments** will be paid based on the account balances of principal, interest, fees and penalties, following the allocation order defined in the product. Payments are allocated based on the type of outstanding balance (interest, principal, etc) regardless of the repayment schedule. Fees and penalties are not tied to a specific date. As soon as they are applied they become due and can be paid at any point in time. :::note The Vertical Payments option is only available for the Dynamic schedule calculation method. ::: ### Examples For examples of each payment allocation method, see [Horizontal vs Vertical Payment Allocation.xlsx](https://s3.amazonaws.com/mambu-notifications/Resources/Horizontal+vs+Vertical+Payment+Allocation.xlsx). ## Prepayments acceptance Some organizations don't allow prepayments for certain products, such as those using Declining balance methodology. By default, Mambu will show the option to "Accept Pre-Payments". If you want to disallow prepayments for a specific product, **click on the menu** to select that option. ![Pre-Payments Acceptance for Loan Products](@site/static/img/support/pre-payments-acceptance.png) You have a set of additional options to configure for prepayments, depending if the product has Fixed or Dynamic schedule calculation. ## Accepting prepayments of interest Some organizations would like to allow their clients to pay in advance also the interest that is not due yet for upcoming installments. ![Accept Pre-Payment of Future Interest](@site/static/img/support/accept-pre-payments-postdated.png) * **Accept Interest Pre-Payments** (available for fixed and dynamic products, default selection). When you enter a prepayment, that is, a repayment transaction entered before or on the due date with an amount smaller than or equal to the total due, the interest accrued up to that moment will be applied and paid. The rest of the amount from that prepayment will be allocated to the principal. The prepayment will be entered in the current moment. This option is available for both fixed and dynamic product types. For dynamic accounts, the principal is reallocated based on [prepayment allocation methods](/docs/prepayment-recalculation-methods). * **Accept Postdated Payments** (available for fixed products only from the UI, not via the API). This will post the repayments in different future-dated transactions depending on the payment amount for the fixed accounts. With this option, you will be able to enter future repayment transactions. This option is available at account level only, in the **Repayment** dialog, if there is nothing due on the account. When a postdated payment is logged, a Repayment transaction and the Prepaid Interest applied will be logged with a future date: the due date of the prepaid installment. The installment will be marked as paid in the schedule, and when the end of day processing will run on that due date, the Interest Applied transaction will also be logged. :::warning Accounting-wise, when interest is prepaid, the amount of prepaid interest is credited to a deferred interest account, and when the due date finally arrives it will go to the usual interest income account. ::: ### Apply interest on prepayments On dynamic loan accounts, when a prepayment is made, it is usually desired to collect interest first. However, for this to happen, interest has to be applied before the prepayment. By default Mambu is set to do this automatically. If you don't want interest to be applied automatically, you can choose to apply it manually. When manual is selected, a prepayment will cause interest to be applied after the payment. ### Prepayments recalculation For dynamic loan accounts, you can define if and how the account recalculates the schedule when you make prepayments. For more information, see [Pre-payment Recalculation Methods](/docs/prepayment-recalculation-methods). ### When to mark an installment as paid A *prepayment* is a repayment made before the due date that fully or partially covers the principal. When making prepayments on dynamic loans, you can decide when you want to consider an installment as paid. To reveal this option, you must have the following product setup: * Product type: Dynamic Term loan * Interest calculation method: Declining Balance Equal Installments (DBEI) * Payments method: Standard Payments ![Repayment collection section of the Setting up a new loan form with the two options of When to mark installment as paid: when principal expected is paid or when the full due is paid](@site/static/img/support/mark-installment-as-paid-when-options.png) #### Principal expected is paid (before/on due date) If you select the principal expected is paid option, an installment is considered paid when the principal expected is paid. When you make a prepayment, Mambu applies and pays the interest accrued until that day. If the prepayment covers the interest applied on that day, plus the principal, the installment will be marked as **Paid**. #### Full due is paid (on/after due date) If you use the prepayment allocation on next installments, the full due is paid option is generally available. If you use the prepayment allocation on upcoming pending installment only, with the two available prepayment recalculation methods (reduce number of installments and reduce amount per installment), then the full due is paid option is an early access feature. If you select the full due is paid option, an installment is considered paid only when the full due amount, meaning the principal plus the interest due on the due date of that installment is paid. When you make a prepayment, Mambu applies and pays the interest accrued until that day. If the prepayment covers the interest applied on that day, plus the principal, the installment will still be marked as **Late**. The installment will be marked as **Paid** on or after the due date, when the interest due is fully paid. :::warning You can edit the **Mark installment as paid when** option at the product level and all the new accounts created using that product will have the new setting. The existing accounts will not be impacted. Therefore, we recommend you to check at the account level, under **Details**, which option was initially selected for your account. ::: ## Repayment Allocation Order For cases of prepayments, partial repayments or fees and penalties payment, the allocation order defined at the product level will determine what will be paid first. Suppose you wanted the principal to be paid first, then interest, fees and finally penalties. In this case Principal would be on top of the list and Penalties on the bottom. To set the order of the items to be paid: 1. When [setting up new loan products](/docs/setting-up-new-loan-products), go to the **Repayment Collection** > **Repayment Allocation Order**. 2. Drag and drop items to arrange them according to the order in which you want them paid on partial or overpayments. ![Repayment Collection section at Product Level with Repayment Allocation Order option.](@site/static/img/support/repayment-allocation-order.png) --- # Repayment due in 10 days URL: https://docs.mambu.com/docs/repayment-due-in-10-days/ ## Business case A 3rd party system must be notified about installments, which are due in 10 days, for all loan accounts held by individual clients in order to send out various communications. The system is able to receive POST API calls and the data is represented in plain text, each value separated by " - ". ## Configuration ![Example configuration for a webhook set up to send a notification when there is a repayment due in the net 10 days](@site/static/img/support/unpaid_repayment_due_in_10_days_webhook.png) *** --- # Repayments Schedule Editing URL: https://docs.mambu.com/docs/repayments-schedule-editing/ When [creating a new loan product](/docs/setting-up-new-loan-products), you can control the extent to which loan schedules can be edited by selecting the desired **Repayments Schedule Editing** options in the **Repayment Scheduling** section of the form. ![Repayments Schedule Editing options for loan products](@site/static/img/support/repayments-schedule-editing-loan-product.png) If you enable **Repayments Schedule Editing** for the loan product, you can edit the repayments schedule of the loan accounts created under that product at the time the loan account is created, as well as in the later states of the loan account, `Partial Application`, `Pending Approval`, `Active`, or `In Arrears`. For more information about the loan account states, see [Loan Account's Life Cycle and States](/docs/loan-account-life-cycle-and-states). The following **Repayment Schedule Editing** options can be activated for loan products: * Adjust Payment Dates * Adjust Principal Payment Schedule * Adjust Interest Payment Schedule * Adjust Fee Payment Schedule * Adjust Penalty Payment Schedule * [Configure Payment Holiday](/docs/payment-holidays) For more infomation about each of these options, see [Editing or Customizing Repayment Schedules](/docs/editing-customizing-repayment-schedules). These **Repayment Schedule Editing** options are available for **Fixed Term** and **Dynamic Term** loan products. ## Repayment schedule editing options for Fixed Term loan products The option to edit the schedule is available for all **Fixed Term** products, using any [**Interest Calculation Method**](/docs/interest-calculation-methods-in-loans): * Flat * Declining Balance * Declining Balance (Equal Installments) Fixed term products have the additional flexibility of editing the repayment schedules for each account individually. This can be used to adjust due dates, apply or waive fees and penalties, and to reallocate balances. ## Repayment schedule editing options for Dynamic Term loan products For **Dynamic Term** loans, the available **Repayment Schedule Editing** options depend on the [**Interest Calculation Method**](/docs/interest-calculation-methods-in-loans). With dynamic loans, interest is always calculated based on the principal in the schedule, so the interest is never directly editable. ![Select the Interest Calculation Method](@site/static/img/support/interest-calculation-method-dynamic-balance-equal-installments.png)
    :::note For **Dynamic Loans**, when you select **Adjust Number of Installments**, **Adjust Payment Dates** and **Adjust Principal Payment Schedule** are automatically selected as well. ::: ### Repayment schedule editing options for Dynamic Term loan products with Declining Balance interest calculation method **Dynamic Term** loans with the [**Interest Calculation Method**](/docs/interest-calculation-methods-in-loans) **Declining Balance** offer the following [**Repayment Schedule Editing**](/docs/editing-customizing-repayment-schedules) options, depending on the [**Pre-Payments Recalculation**](/docs/prepayment-recalculation-methods) method. ![Select the Pre-Payments Recalculation method](@site/static/img/support/pre-payments-recalculation.png) | Prepayments Recalculation | Adjust Payment Dates | Adjust Principal Payment Schedule | Adjust Interest Payment Schedule | Adjust Fee Payment Schedule | Adjust Penalty Payment Schedule | Adjust Number of Installments | Configure Payment Holidays | | --- | --- | ---| --- | --- | --- | --- | --- | | No Recalculation | ✔ | ✔ | | | | ✔ | ✔ | | Reschedule Remaining Repayments | | Recalculate the Schedule, Keep the Same Number of Terms | ✔ | ✔ | | | | ✔ | ✔ | | Recalculate the Schedule, Keep the Same Principal Amount | ✔ | ✔ | | | | ✔ | | ### Repayment schedule editing options for Dynamic Term loan products with Declining Balance (Equal Installments) interest calculation method **Dynamic Term** loans with the [**Interest Calculation Method**](/docs/interest-calculation-methods-in-loans) **Declining Balance (Equal Installments)** offer the different **Repayment Schedule Editing** possibilities depending on options selected.
    Payments Method Pre-Payment Allocation Mark Installment as Paid When Adjust Payment Dates Adjust Principal Payment Schedule Adjust Interest Payment Schedule Adjust Fee Payment Schedule Adjust Penalty Payment Schedule Adjust Number of Installments Configure Payment Holidays
    Standard and Optimized Payments On Next Installments Full Due is Paid (on/after Due Date) ✔ ✔ ✔ ✔
    Principal Expected is Paid (before/on Due Date) ✔ ✔
    On Upcoming Pending Installment Only Full Due is Paid (on/after Due Date) ✔ ✔ ✔ ✔
    Principal Expected is Paid (before/on Due Date) ✔ ✔
    Balloon Payments No prepayment calculation N/A ✔ ✔
    :::note If you wish to use the Repayment Schedule Editing for On Upcoming Pending Installments Only, please get in touch with your Mambu Customer Success Manager or contact us through Mambu Support to discuss your requirements. ::: ### Change the monthly repayment due date For Dynamic Term loans with Declining Balance (Equal installments) interest calculation method, you can change the monthly repayment due date. This functionality is available via API 2.0 only. For more information, see our [API Reference](/api/api-v2/loans/change-due-dates-settings). For example: * If the next expected installment due date is the 10th and on the 3rd a customer requests a change of the due date to 25th, then the installment amount being moved from the 10th to the 25th increases by the additional 15 days of interest. However, the future installments amount doesn't change.
    * If the next expected installment due date is the 15th and on the 3rd a customer requests a change of the due date to the 5th, then the installment amount being moved from the 15th to the 5th decreases by the additional 10 days of interest. However, the future installments amount doesn't change. :::warning * We recommend that you don't change the monthly repayment date if there are multiple monthly repayment dates at a product or account level. * We recommend that you don't change the monthly repayment date if the due date has passed. ::: ## Repayments schedule editing for Revolving Loans and Credit Cards For Revolving Loans and Credit Cards, you can also control the extent to which loan schedules can be edited. For more information, see [Revolving Loans & Credit Cards](/docs/revolving-credit-loans#repayment-scheduling). --- # Reports Overview URL: https://docs.mambu.com/docs/reports-overview/ Mambu offers a variety of ways to generate reports. This section focuses on management reports, but there are additional ways to access structured or filtered information that should be kept in mind. ## Additional reporting tools The following additional reporting tools are also available: ### Custom views The Mambu UI is highly-customizable and can easily be set up to display custom subsets of information with temporary or saved custom views. Examples of custom views include: * Listing all the clients that are in an active state. * Listing all loan accounts that are 90 days in arrears (in other words, late for 90 days). * Listing all the withdrawal transactions higher than USD700,000 - to review them for reporting purposes. For more information, see [Custom Views](/docs/custom-views). ### Custom columns You can customize your own preset columns in Mambu UI pages such as All Clients, All Groups, All Accounts, Journal Entries, and Transactions Lookup. This allows you to easily get the specfic perspective on your data that you need. For more information, see [Customizing Columns](/docs/customizing-columns). ### Accounting Reports You can easily generate the following accounting reports in Mambu: * Balance Sheet * Profit & Loss report (or Income Statement) * Trial Balance For more information, see [Accounting Reports](/docs/accounting-reports). ### Jasper custom reports If you use Jaspersoft Studio, you can create custom reports that contain data from Mambu database tables. Once your reports have been created in Jaspersoft Studio and you have the appropriate JRXML template, you may import this file to Mambu to display the Jasper report using data from various entities in Mambu. For more information, see [Jasper Custom Reporting](/docs/jasper-reporting-overview). --- # Rescheduling and Refinancing Loans URL: https://docs.mambu.com/docs/rescheduling-and-refinancing-loans/ :::note Payment Holidays If you are looking for information on setting up payment holidays to help your clients through any difficulties, please see our dedicated [Payment Holiday](/docs/working-with-payment-holidays) page. ::: There might be several reasons that require rescheduling or refinancing a loan, such as unexpected events like a natural disaster that prevent the client from keeping up with the repayments, or as part of a negotiation with the client. Or you may have a client who has been making timely repayments and might just need more principal, which would require you to refinance or top-up a loan. This section explains both features and how to use them. ## Rescheduling This option allows you to keep the same principal balance or reduce it, but create a new schedule for the loan and, if needed, different loan terms. When a loan account is rescheduled, you can redefine all the loan terms that were available when the loan was created, including the loan product, and also change the custom field values or the guarantees. When rescheduling a loan account, the Loan Amount will be filled in with the original account principal balance and you can adjust that amount by selecting the **Reduce Amount** box. If you reduce the amount, part of the principal remaining will be written off. ![Rescheduling loans form with focus on the outstanding balances](@site/static/img/support/reschedule-loan.png) By default, any interest, fees, or penalties will be capitalized or written off on the new account and not transferred from the old one: * You can write off balances, completely or partially, by adjusting the amounts in the **Outstanding Balances** section. * Disbursement fees - deducted, capitalized, or upfront - will not be displayed in the reschedule form. * The only fees transferred from the old account to the new one are Late Repayments and Payment Due fees. Both the original and the newly created accounts will have a transfer transaction logged, to show the amount of principal that was rescheduled. :::note When rescheduling a loan, the previous loan account will then be closed and replaced by the new account. You can provide the new loan account ID via API. As the ID has to be unique, we suggest adding v2 or #2 or A, B, C, or any other prefix or suffix that helps with matching; otherwise, the newly created loan account will be given a default ID that will not help you match the two loan accounts. For more information, see our related [API documentation](/api/api-v2/loans/reschedule) ::: ## Refinancing This option enables transferring the principal balance plus some additional amount to a new loan account, with new terms. Loan refinancing allows you to set the **Top Up Amount** that should be added to the refinanced principal and change the Loan product for the new loan (if applicable). By default, any interest, fees, or penalties will be capitalized or written off on the new account and not transferred from the old one: * You can write off balances, completely or partially, by adjusting the amounts in the **Outstanding Balances** section. * Disbursement fees - deducted, capitalized, or upfront - are available in the **Refinancing Loan Account** form to select and save and the same fees would also be available at disbursement. * You can preview the schedule with fees in the refinancing form. * The fees that are required on the product will become optional. The only fees that are transferred from the old account to the new one are Late Repayments Fees and Payment Due Fees. The new loan account will be in **Partially Disbursed** account sub-state and you will need to disburse the top-up amount, in a Disbursement transaction. No other transactions can be posted on the account until the top-up amount is disbursed. When **Refinancing** a loan account, the fees that were marked as **Required** when the Loan Product was defined will become **Optional** and can be applied on the Refinanced loan account at disbursement. :::note The options to select fees during refinance and preview the schedule with fees are only available for **Dynamic loans** and **Tranched loans**. ::: ## How to reschedule or refinance a loan account To reschedule or refinance a loan, you need the `Reschedule/Refinance Loan Account` permission, as well as the permission to `Create Loan Accounts`. To reschedule or refinance a loan account, open the account and select **Close** > **Reschedule** or **Refinance**. ![Close drop-down with options like Pay-Off, Refinance, Reschedule and Write-Off](@site/static/img/support/loans--loan-account-actions-menu.png) :::warning Please Be Aware The **Reschedule** and **Refinance** options are only visible when it is possible to perform those actions on an account. The options are removed from the menu when:
    • the account principal balance is 0
    • the account is locked
    • the account is partially disbursed
    ::: ## Filling out the form ### Loan product By default, the new loan account is created under the same loan product like the original account, but you choose a different loan product if necessary. ### Keep the same account ID When you reschedule or refinance a loan, you can choose whether to keep the same account ID for the new loan. To keep it, select the **Keep same account ID** checkbox. ![Keep same account id option in the Rescheduling or refinancing a loan dialog](@site/static/img/support/keep-same-account-id.png) :::note After refinancing or rescheduling a loan, the account ID of the refinanced or the rescheduled loan is the same as the account ID of the original loan. However, the account ID of the original loan, which is closed, will be updated with a new ID which will depend on whether the product settings have incremental or random ID generation. For more information, see [Setting up new loan products - New account settings](/docs/setting-up-new-loan-products#new-account-settings). ::: #### Example Consider an exmaple where you have a loan product with random ID generation settings consisting of four letters and three digits. You create a new loan and the ID MADI459 is automatically generated. Then you reschedule or refinance the loan and you select the **Keep the same ID** checkbox. The new account will have the same account ID MADI459 and the ID of the old account will be updated to, for example, ABCD123. If you reschedule or refinance the account with the ID MADI459 again and you select the **Keep the same ID** checkbox, then again, the active refinanced or rescheduled account will have the ID MADI459 and the old account, which is closed, will be updated to a new ID, for example, WXYZ123. To get the details and transactions of all the versions of the account, use the [get details of previous versions](/api/api-v2/loans/get-versions-by-id) and the [get transactions for all versions](/api/api-v2/loans_transactions/get-transactions-for-all-versions) endpoints in our API 2.0. ### Outstanding balances The default amounts are 0 but you can specify the amount of interest, fees, and penalties to be capitalized on the new account. ### Account terms #### Loan amount By default, the amount displayed here corresponds to the principal that was still due in the loan you're now rescheduling or refinancing. #### Interest rate By default, this will be the same interest rate that was being applied to the previous account, but it can be changed according the selected loan product. ### Disbursement details Enter the disbursement and first repayment date of the new loan. ### Schedule preview After entering the new terms you can see how the repayment schedule will look like by just selecting **Preview Schedule**. ### Association By default, the new loan is associated to the same branch as the initial loan. ### Account notes Add all the information you consider relevant about the rescheduled or refinanced loan. :::warning Please Be Aware If you are rescheduling into the same loan product of the original account, the rescheduled or the refinanced loan will need to comply with the currently applicable loan product rules. If the original loan parameters differ from the current loan product settings (for example, the interest rate that the loan had before is higher than currently applicable, you will receive an error message and won't be able to reschedule / refinance. ::: When a new loan account is created at rescheduling or refinancing, the old loan account's custom field values are copied to the new loan account. This is the equivalent of adding those custom field values to the account, and therefore the user performing the reschedule or the refinance operation must have permission to edit all the applicable custom field values. ## Undo a reschedule or a refinance If you rescheduled or refinanced a loan under wrong loan terms or by accident, you can undo this action. To do so: 1. Open the account. 2. On the right-hand side of the screen, select **More** > **Undo Reschedule** or **Undo Refinance**. 3. Confirm by selecting **Close**. Mambu will reactivate the original account and change the state of the new account to `Closed (Withdrawn)`. For audit purposes, the Transfer transactions are kept on both accounts, but these transactions will be reversed. --- # Revamp of Mambu APIs URL: https://docs.mambu.com/docs/revamp-of-mambu-apis/ As part of our ongoing commitment to enhancing your experience with our platform, we're transitioning to API v2 to deliver more streamlined and efficient integrations between your systems and the Mambu cloud banking platform. These enhancements include: * Enhancements in design, with the inclusion of an idempotency mechanism to ensure data handling is more consistent and reliable. * Seamless pagination for effortless data retrieval, and more refined details which will add precision to your operations. * An enhanced developer-friendly framework with more mature security controls. ## Recap of our previous communication In January 2024, we informed you about the revamp of our APIs and the transition to API v2. This transition was outlined in three phases: * Phase 1: Targeting endpoints with 1-to-1 mirroring of functionality, scheduled for completion by April 30, 2024. * Phase 2: Focused on endpoints with redesigned functionality in API v2. * Phase 3: Addressing entirely new endpoints. ## What is changing? Phases 1 & 2 are now combined for a streamlined transition and are rescheduled for Q2 2025. Phase 3 is planned for 2026. Redesigned endpoints originally planned for phase 2 are now included in phase 1. The updated endpoints offer faster responses, new and improved functionality exclusive to API v2, and a streamlined API framework for easier maintenance. The extension of the first two phases to Q2 2025 offers sufficient time for you to adapt your systems infrastructure and seamlessly migrate to the new endpoints. Here's the updated timeline, which is subject to change: * 31 January 2024: Commencement of the notice period and change notification * 16 April 2024: Notification of extended transition timeline and first reminder * 18 July 2024: Second reminder * 22 October 2024: Third reminder * 28 November 2024: Final reminder * August 04: API v1 will be disabled in the Sandbox environments. This marks the start of the official Sandbox testing period for customers. * September 22: API v1 will be disabled in Production. ## What actions do you need to take? Complete these actions to avoid receiving the error message below: * Conduct an audit of your systems architecture to identify any use of API v1 endpoints within the scope of phases 1 and 2 that need to be transitioned. * Transition your integration code from API v1 to equivalent v2 endpoints before August 25 2025. Failure to do so will result in the following error message: ```json 410 “returnCode”: 3, “returnStatus”: “INVALID_API_OPERATION” ``` ## API v1 endpoints we will stop supporting in production as of September 2025
    Click to view the full list of deprecated endpoints (large table) | Mambu API v1 endpoint Base URL https://TENANT_NAME.mambu.com/api | Correspondent Mambu API v2 endpoint Base URL https://TENANT_NAME.mambu.com/api| | --- | --- | | `DELETE /documents/` | `DELETE /documents/` | | `DELETE /documents/` | `DELETE /documents/` | | `DELETE /loans/` | `DELETE /loans/` | | `GET /branches` | `GET /branches` | | `GET /branches/` | `GET /branches/` | | `GET /centres` | `GET /centres` | | `GET /centres/` | `GET /centres/` | | `GET /clients` | `GET /clients` | | `GET /clients/` | `GET /clients/` | | `GET /customfields/` | `GET /customfields/` | | `GET /customfieldsets` | `GET /customfieldsets` | | `GET /documents/` | `GET /documents/` | | `GET /groups` | `GET /groups` | | `GET /groups/` | `GET /groups/` | | `GET /loans` | `GET /loans` | | `GET /loans/` | `GET /loans/` | | `GET /loans//templates/` | `GET /loans//templates/` | | `GET /tasks` | `GET /tasks` | | `GET /userroles` | `GET /userroles` | | `GET /users` | `GET /users` | | `GET /users/` | `GET /users/` | | `PATCH /clients/` | `PATCH /clients/` | | `POST /clients` | `POST /clients` | | `POST /clients//documents` | `POST /clients//documents` | | `POST /database/backup` | `POST /database/backup` | | `POST /documents` | `POST /documents` | | `POST /groups` | `POST /groups` | | `POST /indexratesources//indexrates` | `POST /indexratesources//indexrates` | | `POST /loans` | `POST /loans` | | `POST /users` | `POST /users` | | `PATCH /linesofcredit/` | `PATCH /creditarrangements/` | | `GET /linesofcredit//accounts` | `GET /creditarrangements//accounts` | | `PATCH /linesofcredit//custominformation` | `PATCH /creditarrangements/` | | `DELETE /linesofcredit//custominformation/` | `PATCH /creditarrangements/` | | `GET /linesofcredit` | `GET /creditarrangements` | | `GET /currencies` | `GET /currencies` | | `GET /currencies/` | `GET /currencies/` | | `GET /transactionchannels` | `GET /organization/transactionChannels` | | `GET /settings/organization` | `GET /setup/organization` | | `DELETE/savings/` | `DELETE/deposits/` | | `POST /groups/search` | `POST /groups:search` | | `POST /clients/search` | `POST /clients:search` | | `POST /notifications/messages/search` | `POST /communications/messages:search` | | `POST /savings/search` | `POST /deposits:search` | | `POST /loans/search` | `POST /loans:search` | | `POST /loans/transactions/search` | `POST /loans/transactions:search` | | `POST /linesofcredit/search` | `POST /creditarrangements:search` |
    ## New endpoints added to phase 1 | Mambu API v1 endpoint Base URL https://TENANT_NAME.mambu.com/api | Correspondent Mambu API v2 endpoint Base URL https://TENANT_NAME.mambu.com/api | |-------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `GET /savings//comments` | `GET /comments?` | | `POST/savings//comments` | `POST /comments`, expects a JSON payload in the form `", "ownerType": "", "text": "string text"}` | | `DELETE /branches//documents/` | `DELETE /documents/`, API returns 204 (No content) for successful deletion, as opposed to 200 returned by V1. | | `DELETE /centres//documents/` | `DELETE /documents/`, API returns 204 (No content) for successful deletion, as opposed to 200 returned by V1. | | `DELETE /clients//documents/` | `DELETE /documents/`, API returns 204 (No content) for successful deletion, as opposed to 200 returned by V1. | | `DELETE /documents/` | `DELETE /documents/`, API returns 204 (No content) for successful deletion, as opposed to 200 returned by V1. | | `DELETE /groups//documents/` | `DELETE /documents/`, API returns 204 (No content) for successful deletion, as opposed to 200 returned by V1. | | `DELETE /loanproducts//documents/` | `PATCH /loanproducts/` | | `DELETE /loans//documents/` | `DELETE /documents/` | | `DELETE /savings//documents/` | `DELETE /documents/` | | `DELETE /savingsproducts//documents/` | `DELETE /documents/` | | `DELETE /users//documents/` | `DELETE /documents/` | | `GET /branches//documents` | `GET /documents/documentsMetadata` + `GET /documents/`, V2 metadata endpoint expects entity type as required query parameter. In this case, entity=BRANCH | | `GET /branches//documents/` | `GET /documents/` | | `GET /centres//documents` | `GET /documents/documentsMetadata` + `GET /documents/`, V2 metadata endpoint expects entity type as required query parameter. In this case, entity=CENTRE | | `GET /centres//documents/` | `GET /documents/` | | `GET /clients//loans/` | `GET /loans` and specify account holder id | | `GET /clients//linesofcredit` | `GET /clients//creditarrangements` | | `GET /clients//documents` | `GET /clients//documentsMetadata` + `GET /documents/`, V2 metadata endpoint expects entity type as required query parameter. In this case, entity=CLIENT | | `GET /clients//documents/` | `GET /clients/documents/` | | `GET /database/backup/LATEST ` | `GET /database/backup/LATEST ` | | `GET /documents` | `GET /documents/documentsMetadata` + `GET /documents/` | | `GET /documents/` | `GET /documents/` | | `GET /groups//documents` | `GET /documents/documentsMetadata` + `GET /documents/`, V2 metadata endpoint expects entity type as required query parameter. In this case, entity=GROUP | | `GET /groups//documents/` | `GET /documents/` | | `GET /groups//linesofcredit` | `GET /groups//creditarrangements` | | `GET /loanproducts//documents` | `GET /documents/documentsMetadata` | | `GET /loanproducts//documents/` | `GET /documents/` | | `GET /loanproducts//schedule` | `POST /loans/schedule:preview` | | `GET /loans//documents` | `GET /documents/documentsMetadata` | | `GET /loans//documents/` | `GET /documents/` | | `GET /repayments` | `GET /installments` (returns all installments between two dates compared with api v1 that excludes the paid installments) | | `GET /loans//transactions` | `GET /loans//transactions` | | `GET /linesofcredit/` | `GET /creditarrangements/` | | `GET /linesofcredit//custominformation/` | `GET /creditarrangements/` with full details | | `GET /users//documents` | `GET /documents/documentsMetadata` + `GET /documents/` | | `POST /branches//documents` | `POST /documents` | | `GET /users//documents/` | `GET /documents/` | | `POST /centres//documents` | `POST /documents` | | `POST /documents` | `POST /documents` | | `POST /groups//documents` | `POST /documents` | | `POST /loanproducts//documents` | `POST /documents` | | `POST /loans//documents` | `POST /documents` | | `POST /savings//documents` | `POST /documents` | | `POST /savingsproducts//documents` | `POST /documents` | | `POST /users//documents` | `POST /documents` | | `GET /branches//comments` | `GET /comments`, Expects `ownerType` and `ownerKey` as required parameters (i.e. `BRANCH` + branch encoded key) | | `GET /centres//comments` | `GET /comments`, Expects `ownerType` and `ownerKey` as required parameters (i.e. `CENTRE` + centre encoded key) | | `GET /clients//comments` | `GET /comments`, Expects `ownerType` and `ownerKey` as required parameters (i.e. `CLIENT` + client encoded key) | | `GET /groups//comments` | `GET /comments`, Expects `ownerType` and `ownerKey` as required parameters (i.e. `GROUP` + group encoded key) | | `GET /loanproducts//comments` | `GET /comments` and filter for loan product | | `GET /loans//comments` | `GET /comments` and filter for loan account | | `GET /loans//custominformation/` | `GET /loans/` with details level full | | `GET /savingsproducts//comments` | `GET /comments`, Expects `ownerType` and `ownerKey` as required parameters (i.e. `SAVINGS_PRODUCT` + savings product encoded key) | | `GET /users//comments` | `GET /comments`, Expects `ownerType` and `ownerKey` as required parameters (i.e. `USER` + user encoded key) | | `POST /branches//comments` | `POST /comments` | | `POST /centres//comments` | `POST /comments` | | `POST /clients//comments` | `POST /comments` | | `POST /groups//comments` | `POST /comments` | | `POST /loanproducts//comments` | `POST /comments` | | `POST /loans//comments` | `POST /comments` | | `POST /savingsproducts//comments` | `POST /comments` | | `POST /users//comments` | `POST /comments` | | `POST /linesofcredit` | `POST /creditarrangements` | | `POST /linesofcredit//loans/` | `POST /creditarrangements/:addAccount` | | `GET /glaccounts` | `GET /glaccounts` | --- # Reviewing a Client's Loan History URL: https://docs.mambu.com/docs/reviewing-a-clients-loan-history/ When working with clients you may wish to view their loan history in order to come to a decision on whether to approve or disapprove a particular loan product or apply different fees and penalties based on that client's previous behaviour. You can access an overview of a client's closed loan accounts by opening their account and navigating to the **Closed Accounts** tab. Here you will find a table of all closed loans along with their respective amounts, closure dates and the manner in which they were closed, for example, with all obligations met, rejected or rescheduled. ![client loan history)](@site/static/img/support/loans_client_history%281%29.png) ## Max loan size The maximum loan amount that this client has previously been approved for will be highlighted in the top row. This can help you to quickly assess whether al loan is in keeping with what this client has previously received. ## On time repayment rate The *On Time Repayment Rate* is the percentage of installments paid on or before the due date. Any instalments paid after the due date, even in the case of them having been paid during an arrears tolerance period, will be counted as **not** being on time. An overall On Time Repayment Rate, calculated based on the average rate for all previously closed loans, is also provided. --- # Revolving Loans URL: https://docs.mambu.com/docs/revolving-credit-loans/ *Revolving loans* are types of loans that allow multiple disbursements and repayments on the account. They are usually used for lines of credit, credit cards, and Buy Now Pay Later products. Revolving loans are mostly created the same way as other loan products. For more information, see [Setting Up New Loan Products](/docs/setting-up-new-loan-products). ## Billing cycles Revolving loans support billing cycles. *Billing cycles* refer to the length of time between the last billing statement closing date and the next one. The main aspects of this functionality are: * An installment is generated at the end of the billing cycle based on all the transactions within the billing cycle period. * You can have a timeframe for the repayment of the generated installment, because this functionality allows you to distinguish between a billing cycle date and a due date. * You can create billing statements for your clients. ### Setting up billing cycles at product level Billing cycles are supported in revolving loans with: * Repayment by amount, calculated as principal payment plus a percentage of the outstanding principal after last disbursement and total due payment plus the percentage of outstanding principal not yet due. * Repayment by installment. When [setting up a new loan product](/docs/setting-up-new-loan-products), select the **Revolving Credit** product type from the dropdown and in the **Repayment Scheduling** section of the form: 1. Under **Payment Interval Method**, select **Fixed Days of Month**. 2. Under **Monthly Repayment Days**, add one or more days of the month when you want repayments to be made to your accounts. You can leave this field empty and configure it later at account level or you can enter one or several days which you can also change later at the account level. 3. Under **Start of Billing Cycle**, enter the start date of the billing cycle. You can also leave this field empty and configure it later at account level or you can enter a number which you can also change later at the account level. 4. Under **Repayment Method**: * Select **Amount** and one of these two options, then select the **Enable Billing Cycles** checkbox. * **Principal Payment** with **% of Outstanding Principal After Last Disbursement**. * **Total Due Payment** with **% of Outstanding Principal Not Yet Due**. ![Screenshot 2023-01-27 at 13.11.28.png](@site/static/img/support/loans--repayment-scheduling-configuration-9.png) * Select **Installments**, and the **Enable Billing Cycles** checkbox will be selected by default. ![loans--repayment-scheduling-configuration-11.png](@site/static/img/support/loans--repayment-scheduling-configuration-11.png) :::note You cannot change the settings related to billing cycles at product level once you have accounts using that product. ::: Billing cycles for **Principal Payment** with **% of Outstanding Principal After Last Disbursement** and **Installments** are an early access feature. ### Setting up billing cycles at account level When [creating a new loan account](/docs/creating-a-new-loan), in the **Account Terms** section of the form, the default values configured when setting up the loan product for **Monthly Repayment Days** and **Start of Billing Cycle** will appear. You can choose to change these dates at account level. ![Set up billing cycles at account level](@site/static/img/support/Billing_cycles_Loan_accounts.png) ## Interest rates Interest on revolving loans is accrued on a daily basis, which allows you to charge your clients only for the days they used the loan amount. For more information, see [Interest calculation methods in loans](/docs/interest-calculation-methods-in-loans#calculating-the-days-in-a-year). ### Interest calculation method Currently revolving loans support only the Declining Balance interest calculation method. This method reflects the actual cost of the loan, as the interest is calculated on the outstanding balance. Clients only pay interest on the actual amount they still owe and not on the total amount. In this case, as they start making repayments, the interest due keeps decreasing over the duration of the loan. The interest can be calculated based on either of the following methods: * **Principal Only** which computes the interest by multiplying the daily interest rate by the principal and then dividing by the number of days that have elapsed between payments: * `Interest Amount = Outstanding Principal Balance * Annual Interest Rate % * NoOfDays / DaysInYear` * **Principal and Interest**, which computes the interest by adding the outstanding principal balance and the unpaid interest, then multiplying by the annual interest rate and dividing by the number of days that have elapsed between payments: * `Interest Amount = (Outstanding Principal Balance + Unpaid Interest) * Annual Interest Rate % * NoOfDays / DaysInYear` ### Accrued interest posting frequency With this option, you can specify the moment when the accrued interest is applied on the account. On revolving loans, only the **On Repayment** option is available, meaning that the interest will be applied in the account on the installment due date. ### The start of interest accrual and late interest Revolving loans without billing cycles start accruing interest from disbursement and they support late interest accrual by default. Revolving loans with billing cycles allow you to select when to start the interest accrual: after the disbursement or after the due date. This configuration is closely related to late interest. The start accruing interest from disbursement in revolving loans with billing cycles is an early access feature. ### Interest Rate Source Revolving loans support can either have a fixed interest rate source or an index interest rate source. ### Days in Year For more information, see [Interest Calculation Methods in Loans - Days in Year](/docs/interest-calculation-methods-in-loans#calculating-the-days-in-a-year). ### Changing the interest rate You can change the interest rate on revolving loans within the product constraints, if any. You can also select the date from which the new interest rate should be applied under **Entry Date**. :::note Interest rate changes can be postdated to any future date without limitations, or backdated up to the date when the interest was applied last or the last **Applied Interest** transaction. When backdating an interest rate change, the current interest accrued will also be updated to reflect the new interest rate. ::: ## Repayment Scheduling ### Payment Interval Method To set the payment interval method, in the **Repayment Scheduling** section of the **Creating a new loan product** form, choose from: * **Interval**: The default option, which specifies that repayments should be made after certain periods of time, such as daily, weekly, monthly, or yearly. * **Fixed Days of Month**: Option which specifies that repayments should always fall on specific days of the month, such as the 1st and the 15th of every month. :::note Billing cycles are supported only for the **Fixed Days of Month** payment method. ::: ### Short Month Handling If you selected **Fixed Days of Month** as a payment interval method and entered the 29th, 30th, or 31st of the month, you can choose to move the installment when the month has fewer days. The installment for that month can be due on either the **Last Day of Month** (such as the 28th), or on the **First Day of the Next Month**. :::note This functionality does not impact the billing cycle day. If the billing cycle day is the 31st and the month is shorter, the billing cycle day will be by default the last day of the month. No special set up is necessary at the product level. ::: ### Rounding of repayment currency For more information, see [Rounding of Repayment Currency](/docs/setting-up-new-loan-products#rounding-of-repayment-currency). ## Repayment methods You can choose from the following options: ### Installment You can customize the repayment installments at product level by selecting the default, minimum, and maximum installment constraints. :::note The repayment installments option is supported only for **Fixed Days of Month** payment interval and for products **with** the billing cycle functionality. When **Fixed Days of Month** is selected, the option for repayment installments appears. With this method, interest accrual after disbursement and late interest calculation is enabled by default. ::: ### Amount You can customize the repayment amount at product level for the principal and total due payments by selecting the default, minimum, and maximum installment constraints. #### Principal Payment * **Flat Amount**: Each installment will have a fixed amount of principal as due. * **% of Outstanding Principal**: Each installment will set a percentage of the current account outstanding principal balance as due. * **% of Outstanding Principal after Last Disbursement**: Each installment will be generated after each disbursement and will set a percentage of the current account outstanding principal balance plus the disbursed amount as due. :::warning When the option **Include Fees in Floor Amount** is selected, the **Repayment Schedule Editing** will be disabled. ::: For the **% of Outstanding Principal** and **% of Outstanding Principal after Last Disbursement** options, you can also define: * **Repayment Amount ceiling**: The maximum amount that can be collected. * **Repayment Amount floor**: The minimum amount that can be collected as repayment and applies by default to Principal only. :::note You can also include interest and/or fees in the floor repayment amount to ensure that the due amount is not higher than the minimum amount agreed upon with the client. If the options **Include Interest in Floor Amount** or **Include Fees in Floor Amount** are not selected, the client will need to pay the floor amount plus the interest and/or fees. ::: **Example** If the floor is set at EUR50 and 5% of the Outstanding Principal Amount calculated is less than the Repayment Floor Amount, Mambu will still expect a repayment of EUR50. The repayment will always be the floor amount or higher, up to the ceiling amount, if defined. #### Total Due Payment * **Flat Amount**: Each installment will have a fixed amount of the total balance. * **% of Total Balance**: Each installment will set a percentage of the total balance. The default payment allocation order on the schedule is: interest, fees, principal. :::note When this option is enabled on the product, penalties are disabled and you will not be able to apply certain automated fees such as Late Repayment or Payment Due (Applied Upfront) fees. ::: * **% of Outstanding Principal Not Yet Due**: Each installment will set a percentage of the outstanding balance which is not yet due. When using this option, interest and fees balances are included in the payment amount. This option was designed in the credit card context, when customers are communicating to their clients monthly repayments for their credit card accounts. :::note When this option is enabled on the product, overdue penalties can be configured, but you will not be able to apply certain automated fees such as Late Repayment or Payment Due (Applied Upfront) fees. ::: For **% of Total Balance** and **% of Outstanding Principal Not Yet Due**, you can also define: * **Total Due Amount Floor**: The minimum amount to be collected as repayment. * **Principal Amount Ceiling**: Only the principal will be included in the ceiling amount. ## Repayment schedule Revolving loans schedules usually consist of one upcoming installment. The installment is generated on the billing date or the due date, depending on the product configuration. There is no schedule prior to disbursement. To show future installments, select the **Preview schedule** checkbox and enter the number of installments you want to be able to preview. For optimal system performance, we suggest that you limit preview installments to 24. If you need more, please raise a support case via the [Customer Service Portal](/docs/customer-service-portal). ![The option to preview future installments](@site/static/img/support/loans--repayment-scheduling-configuration-7.png) :::note Preview schedule is enabled for all types of revolving products except for principal payment as percentage of outstanding principal and total due payment as percentage of outstanding principal not yet due without billing cycles. You will see the option to select the **Preview schedule** checkbox in the product configuration, but if you select it for the two unsupported products, you will get an error. Products with the **Installments** repayment method show by default the schedule with all numbers of installments defined at the product or account level. ::: On the account overview page, go to the **Schedule** tab and select the information you wish to see in the schedule table. ### Schedule installments * **Amount Due** ![The schedule of a Revolving loan showing the amount due](@site/static/img/support/loans--loan-account-schedule-5.png) * **Amount Paid** ![The schedule of a Revolving loan showing the amount paid](@site/static/img/support/loans--schedule-installments.png) * **Amount Expected** ![The schedule of a Revolving loan showing the amount expected](@site/static/img/support/loans--schedule-installments-3.png) * **Empty Repayments** ![The schedule of a Revolving loan showing the empty repayments](@site/static/img/support/loans--loan-account-schedule-7.png) :::note Taxes will be displayed, if they are configured at the product level. Currently penalties are not displayed in Revolving loan schedules. ::: ### Generate installments #### Accounts with billing cycles Installments are generated by the cron jobs, when the **Billing Cycle End Date** is reached. **Example** | Disbursement Transaction | Start of Billing Cycle | End of Billing Cycle | Due Date | | --- | --- | --- | --- | | 20-01-2020 | 06-01-2020 | 05-02-2020 | 15-02-2020 | The installments are generated on the **End of Billing Cycle** date, at the end of that day (EOD). The installments are generated on 06-02-2020 00:00:00, but the interest will not be applied yet. Interest will be applied on the **Due Date** (15-02-2020). The generated installment becomes due 10 days after the installment was generated. #### Accounts without billing cycles Installments are generated by the cron jobs, when the **Due Date** is reached. **Example** | Disbursement Transaction | Installment generation | Due Date | | --- | --- | --- | | 20-01-2020 | 15-02-2020 | 15-02-2020 | The installments are generated on 15-02-2020 00:00:00, which is the **Due Date**. The interest is applied and the installment becomes due on the **Due Date**. ## Backdated disbursements All backdated installments must be generated to the current moment. If the installment of the last **Billing Cycle** is overdue, the next future installment must be generated. ## Repayment schedule editing When [creating a new revolving loan product](/docs/setting-up-new-loan-products), you can control the extent to which loan schedules can be edited for loan accounts based on these loan products by selecting the desired **Repayments Schedule Editing** options in the **Repayment Scheduling** section. :::note You need the **Edit Schedule** permission to be able to edit the repayment schedule. ::: If enabled for the loan product, editing the repayments schedule of loan accounts is available at the time the loan account is created, as well as in the following [states](/docs/loan-account-life-cycle-and-states) of the loan account: `Partial Application`, `Pending Approval`, `Active`, and `In Arrears`. For more information about how to edit a schedule, see [Editing and customizing repayment schedules](/docs/editing-customizing-repayment-schedules#editing-revolving-credit-loan-schedules). ### Adjust payment dates If you need to adjust the payment dates of a revolving loan, make sure you take this information into account: * The due dates for the installments are mandatory and must always be in an ascending order. * The installments due dates must not be before the disbursement date. * There can be multiple installments due on the same day. * If the account is assigned to a credit arrangement, the last installment due date will be validated against the “Credit arrangement valid until date”. * The dates will be filled after you select **Recalculate** and/or **Save Changes**. ### Adjust number of installments If you need to adjust the number of installments of a revolving loan, make sure you take this information into account: * You can add more installments or delete previously added instalments keeping in mind that only custom installments that don’t have anything paid can be deleted. * The installments will be filled after you select **Recalculate** and/or **Save Changes**. * If the account doesn't have installments due or defined, the following message will be displayed under **Schedule**: "No installments are due for this account". You will be allowed to add or delete installments, with the same account constraints. :::warning We strongly recommend not adding more than one manual installment in advance on revolving loans. ::: On end-of-day (EOD) processes or when the disbursement is backdated: * The due date and past-due installments will be populated. * Installments will be added according to the **Payment Interval Method** selected. * Installments will be marked as **Grace** if the installment is due or past-due, but no principal or interest is allocated to it. :::note The changes available always depend on the product settings. All changes will be logged under the **Activities** tab. ::: Revolving loans generate manual installments and compute the interest by taking into consideration the Principal Balance, while Declining Balance Dynamic Term loans generate a schedule and compute the interest by taking into consideration the Principal Expected. The amount of interest on revolving loan accounts will be recomputed based on the transactions that are posted. The table below shows the Repayment Schedule Editing options available for Revolving loans with payment depending on defined repayment option:
    Repayment Method Repayment Option Payment Option Adjust Payment Dates Adjust Number of Installments
    Amount Principal Payment Flat Amount Yes Yes
    % of Outstanding Principal Yes Yes
    % of Outstanding Principal After Last disbursement Yes Yes
    Total Due Payment Flat Amount
    % of Total Balance
    % of Outstanding Principal Not Yet Due Yes Yes
    Installments
    :::note The **Repayment Schedule Editing** option is disabled for accounts with billing cycles. However, it is possible to edit the **Repayment method value** (percent or amount) as described in the next section. ::: ### Editing Revolving accounts You can edit the following: * The approved loan amount under **More** > **Edit Approved Amount**. * The interest rate on current, past or future dates by editing an interest rate under **More** > **Edit Interest Rate**. * The penalty rate on current date only by editing an interest rate under **More** > **Edit Penalty Rate**. * Reduce the balance of fees and penalties on current date under **More** > **Reduce balance**. * The repayment amount by editing the percent or the amount of payment under **More** > **Edit Repayment Method Value**. ![The Edit Repayment Method Value option available under More](@site/static/img/support/loans--loan-account-details-5.png) You can edit revolving loans: * Using the current date: all future installments will be changed; the change will not impact an already generated installment. * Using a date in the past: all installments after the defined date will be recalculated. :::note You cannot edit revolving loans using a date in the future. ::: ## Repayment collection Allows you to define how the repayments should be posted in the repayment schedule. ![Repayment Collection options for Revolving Credit loans](@site/static/img/support/Revolving_Repayment_Collection.png) ### Payment Allocation Method #### Horizontal Payments When a repayment is entered for an account using **Horizontal Payments**, it is the actual repayment schedule that will determine what should be paid first based on the due dates. The amount entered will always be used to pay each installment, and only move to the next installment due when the previous installment has been completely paid. #### Vertical Payments Accounts using **vertical payments** will be paid based on the account balances of **principal**, **interest**, **fees** and **penalties**, following the allocation order defined in the product. Payments are allocated based on the type of outstanding balance, such as interest or principal, regardless of the repayment schedule. :::warning The interest accrued until the repayment day, is paid last. Fees and penalties are not tied to a specific date. As soon as they are applied, they become due and can be paid at any point in time. ::: ### Pre-payments acceptance and recalculation Some organizations don’t allow prepayments for certain products. By default, for Revolving loans, Mambu will display the option **Accept Pre-Payments**. If you want to block the prepayments for a specific Revolving loan product, select the **Do Not Accept Pre-Payments** option. There are two ways you can recalculate prepayments: * **No recalculation**: This option is available for all types of Revolving loans. The overpaid amount will reduce the outstanding balance and the number of installments will be recalculated based on reduced outstanding principal. * **Reduce amount of installment**: This option is available only for the revolving products with repayment by installments. The overpaid amount will reduce the outstanding balance and the amount of the remaining installments will be recalculated based on the reduced outstanding princial, keeping the same number of installments. ### Apply interest on pre-payment On revolving loan accounts, when a prepayment is made, it is usually desired to collect interest first. However, for this to happen interest has to be applied before the prepayment. By default Mambu is set to do this automatically. If this is not desired, the manual interest application can be selected. When you select manual interest application, a prepayment will cause interest to be applied after the payment. ### Repayment allocation order In case of prepayments, partial repayments, or payments of fees and penalties, the allocation order defined at the product level will determine what will be paid first. If you want the principal to be paid first, then the interest, fees, and finally penalties, then principal would be on top of the list and penalties on the bottom. To move the items, just drag and then drop them at the right place. ## Arrears settings In the **Arrears Settings** section of the form, select one of the two available calculation methods of setting accounts into arrears: * **Arrears Tolerance Period (no of days)**: You can set the number of days of tolerance. This allows loan repayments to be late while the account remains in the **Active** state. For more information, see [Arrears Settings](/docs/arrears-settings). ![Arrears Settings for Revolving Credit loans](@site/static/img/support/Revolving_Arrears_Settings.png) * **Arrears Tolerance Day**: You can set one specific day of the month on which the account will go into arrears. It means that after this date, your payment is late. ![Arrears Tolerance Day](@site/static/img/support/monthly-arrears-tolerance-day.png) ## Penalties settings Penalties are applied automatically when an installment is in arrears. The penalties are being computed based on the following calculation methods: | Calculation formula | Description | | --- | --- | | No Penalty | No penalty is applied when a repayment is late. | | Overdue Principal * Number Of Late Days
    * Penalty Rate | The most common method, where the penalty rate is applied on the principal due late amount and the number of late days. | | (Overdue Principal + Overdue Interest)
    * Number Of Late Days * Penalty Rate | This method is similar to the previous one, but includes the overdue interest in the calculation. | | Outstanding Principal * Number Of Late Days
    * Penalty Rate | This method mirrors adding a penalty interest rate on top of the usual interest rate. | ![Penalties Settings](@site/static/img/support/Revolving_Penalties_Settings.png) What penalties are available depends on the **Repayment Amount** option defined in the **Repayment Scheduling** section. To understand how they are linked, see the table below.
    Repayment Option
    Amount Installments
    Principal Payment Total Due Payment
    Penalty Option Flat Amount % of Outstanding Principal % of Outstanding Principal After Last Disbursement Flat Amount % of Total Balance % of Outstanding Principal Not Yet Due
    No Penalty Yes Yes Yes Yes Yes Yes Yes
    Overdue Principal * # of Late Days * Penalty Rate Yes Yes Yes Yes Yes
    (Overdue Principal + Overdue Interest) * # of Late Days * Penalty Rate Yes Yes Yes Yes Yes
    Outstanding Principal * # of Late Days * Penalty Rate Yes Yes Yes Yes
    For more information about how penalties are defined and applied, see [Loan Penalties Setup](/docs/loan-penalties-setup#penalty-tolerance-period). ## Internal controls ![Internal Controls for Revolving Credit loans](@site/static/img/support/Revolving_Internal_Controls.png) For more information about how the internal controls are defined and used, see [Internal Controls](/docs/internal-controls). ## Product fees There are different types of fees that can be applied on loan accounts after being created or activated for each product. For more information, see [Loan Fees Setup](/docs/loan-fees-setup). ![Product Fees settings for Revolving Credit loans](@site/static/img/support/Revolving_Product_Fees.png) What fees are available depends on the **Repayment Amount** option defined in the **Repayment Scheduling** section. To understand how they are linked, see the table below.
    Repayment Option
    Amount Installments
    Principal Payment Total Due Payment
    Fee Type Flat Amount % of Outstanding Principal % of Outstanding Principal After Last Disbursement Flat Amount % of Total Balance % of Outstanding Principal Not Yet Due
    Manual Fee Yes Yes Yes Yes Yes Yes Yes
    Deducted Disbursement Yes Yes Yes Yes Yes Yes Yes
    Capitalized Disbursement Yes Yes Yes Yes Yes Yes Yes
    Upfront Disbursement Yes Yes Yes Yes Yes Yes Yes
    Late Repayment Yes Yes Yes Yes
    Payment Due
    :::note You will see the entire list of product fees in the product setup, but the limitation will be visible only after you save the product. ::: ## Product links For more information, see [Linking Deposit and Loan Accounts](/docs/linking-savings-and-loan-accounts). ## Securities For more information about how you can define and use securities, see [Securities Settings](/docs/securities-settings). ## Taxes Currently on Revolving loan accounts, you can only use the **Exclusive** taxes which can be defined for the following repayment options.
    Repayment Method Repayment Option Payment Option Exclusive Inclusive
    Amount Principal Payment Flat Amount Yes
    % of Outstanding Principal Yes
    % of Outstanding Principal After Last Disbursement Yes
    Total Due Payment Flat Amount
    % of Total Balance
    % of Outstanding Principal Not Yet Due Yes
    Installments
    For more information, see [Tax calculation method](/docs/setting-up-new-loan-products#tax-calculation-method). ## Locking Revolving accounts You have two options to define the total due after locking an account: * Total balance: the entire loan amount that has been used should be paid. * Current due amount: only the late installment amount should be paid. This second option is an early access feature. For more information about locking and unlocking loan accounts, see [Locking Loans](/docs/locking-loans). It is important to mention, that before the locking account it is needed to decide what to do with accrued, but not applied interest from the last interest application date until locking moment. The recommendation is to make interest application before locking account: - the applied interest amount would be reflected in the schedule on nearest due date and can be paid with repayment in the period of account is locked (even if account is locked with interest suspension) - the interest from the beginning of the locking account will be accrued, but not reflected in the schedule on installments and can not be paid until the account will be unlocked. If interest will not be applied before locking an account, this interest amount will be reflected in the schedule on nearest due date and it can not be paid (as it is not applied) with repayment in the period the account is locked and this installment will become with status "Late". ## Accounting rules For more information, see [Accounting Rules](/docs/setting-up-new-loan-products#accounting-rules). --- # Risk Report URL: https://docs.mambu.com/docs/risk-report/ The risk report is the management report related to risk management. For more information on the rest of the management reports, see [Management Reports](/docs/management-reports). With this report you can easily see which clients have loans or overdrafts in arrears, filter the results by branch, credit officer, and product or find out what the provision amount is based on the risk levels you defined before in your financial setup, for more information, see [Defining Risk Levels](/docs/defining-risk-levels). :::warning The risk report **only includes data entered in your base currency**. For example, if there is an overdraft that is in a currency other than your base currency, it will not be included in the report. ::: You can find the report in the navigation bar, under **Reporting** > **Risk**. ![Reporting report under Reporting menu item](@site/static/img/support/managing-your-organization--risk-report-3.png) You can select to view the risk report for either loans or overdrafts. ## Filter by the number of days in arrears Select the **By Arrears Age** option in the dropdown to filter by the number of days in arrears. There you will see the total principal at risk as well as a list of all of your clients who have loans in arrears, to which you can apply different filters to in order to have a more granular view. To see all the filters select a specific branch and you will then be able to also filter by credit officer and centre. ![Risk Report example](@site/static/img/support/managing-your-organization--risk-report.png) ## Filter by the level of risk Select the **By Risk Level** option in the dropdown to filter by risk levels. Using this filter allows you to see both the principal at risk and the percentage amount of principal you should provision in case the clients do not complete payment. The risk levels and provision amount are based on the categories you defined under financial setup for more information, see [Defining Risk Levels](/docs/defining-risk-levels). To see this information: 1. Select the risk level. 2. Select **Generate Report**. ![Risk level filter with defined options](@site/static/img/support/managing-your-organization--risk-report-dashboard.png) :::note You can still filter down to each risk level to see the list of clients who are under that category. To do that, select the risk level you want to look at. ::: --- # Roles URL: https://docs.mambu.com/docs/roles/ A *role* is a way to to group permissions and to control other forms of access within Mambu. A user in Mambu may be assigned permissions either directly or through a role. They cannot however be assigned both. For more information, see [Understanding Users, Roles, and Permissions](/docs/permissions). :::warning Please be aware We recommend assinging permissions to users through roles because it allows for more control over access in Mambu. For more information, see [Access managed by role](/docs/understanding-users-roles-and-permissions#access-managed-by-role). ::: :::warning In this article we are discussing user roles. These should not be confused with group role names that can be assigned to members of a group. They should also not be confused with client roles which is an alternative naming for client types, for more information, see [Clients and Groups Overview](/docs/clients-and-groups-overview). ::: ## Permissions for managing roles The following permissions are required for you to be able to perform the relevant management actions on roles: * **View Roles** (`VIEW_ROLE`) * **Create Roles** (`CREATE_ROLE`) * **Edit Roles** (`EDIT_ROLE`) * **Delete Roles** (`DELETE_ROLE`) You must have at least one of the above permissions to be able to see the **Roles** tab under **Administration** > **Access**. :::warning For security reasons, we recommend tightly controlling which users have role and user management permissions. For more information, see [Limiting role and user management permission assignment](/docs/understanding-users-roles-and-permissions#limiting-role-and-user-management-permission-assignment). ::: ## Creating a role To create a new role: 1. On the main menu, go to **Administration** > **Access**. 2. Select the **Roles** tab. 3. Select **Add Role**. 4. In the **Create Role** dialog, enter all the necessary information. For more information on the fields, see [Fields for user roles](#fields-for-user-roles) below. 7. Select **Save Changes**. ![Create Role view from where the name of the role, rights and permissions are set.](@site/static/img/support/permissions_roles_create_new_role.png) ## Fields for user roles | Name | Description | Required | | --- | --- | --- | | Role Name | The name for the role. It must be unique and have a maximum length of 255 characters. | ✔ | | ID | The ID for the role. Only alphanumeric characters, dashes, and underscores are allowed. If no ID is provided, then the system will automatically generate one. | ✘ | | Type | An optional type for the user role. The options are administrator, teller, and credit officer. | ✘ | | Access Rights | The platform access rights for the user role. The options are Mambu and API. Selecting API reveals additional API-only permissions. | ✘ | | Permissions | The list of permissions that can be assigned to the user role. | ✘ | | Notes | Additional notes that can be attached to the user role. | ✘ | :::warning If you are creating a user for the Mambu UI, do not forget to select the **Mambu** checkbox under **Access Rights**. Otherwise your user will not be able to sign in to Mambu. ::: ## Editing a role You can edit a role to update the name or permissions associated with that role. To edit a role: 1. On the main menu, go to **Administration** > **Access** > **Roles**. 2. Locate the role you want to modify and select **Actions** > **Edit**. 3. Update the information as needed. 4. Select **Save Changes**. 5. Confirm. :::note Whenever a role is updated, any users assigned to it will have their permissions updated as well. ::: ## Deleting a role You might want to delete roles if you created a role that is no longer applicable. However, there are some types of roles that you can’t delete: * You can’t delete the preconfigured built-in roles Admin and Mambu Support. * You can’t delete roles that are currently assigned to one or more users. You must first remove the role from the relevant users. To delete a role: 1. On the main menu, go to **Administration** > **Access** > **Roles**. 2. Locate the role you want to delete and select **Actions** > **Delete**. 3. Select **Confirm**. --- # Rounding Repayment Schedule URL: https://docs.mambu.com/docs/rounding-repayment-schedule/ Depending on the number of installments, some loan amounts end up with a small difference when divided by the installments. There are two different options for dealing with those cases: ## 1. No Rounding If you choose *no rounding*, when there is a discrepancy between the loan amount to be disbursed and the total balance after rounding, Mambu will show you a warning message asking you to either adjust the loan amount or the number of installments, until you do so the loan cannot be created. ## 2. Round Remainder into Last Repayment If you choose to *Round Remainder into Last Repayment*, Mambu will automatically add the discrepancy amount to one of those repayments. ### Example: Suppose you create a loan of USD1000 with 3 installments. This would result in a repayment schedule with installments of USD333.33 which would sum a total of USD999.99 instead of USD1000. In this case, if you had chosen one of the rounding options, the cent that is missing would be added to the last repayment. ***
    Ask the Mambu Community

    If you have a question about how anything works or have come across something you haven't seen explained here, get in touch with our community of fellow users and Mambuvians where someone will lend a hand.

    Ask a question about Lending

    * If you don't already have an account you will be prompted to create one when you first visit the site.

    --- # Running Proposals URL: https://docs.mambu.com/docs/running-proposals/ The profit sharing process consists of three steps: 1. [Profit Calculation](/docs/profit-calculation) 2. [Profit Approval](/docs/profit-approval) 3. [Profit Application](/docs/profit-application) The profit calculation process is triggered by the EOD (end-of-day) process. The default proposal is created on the second day of the profit calculation cycle. In the middle of this cycle, you can view indicative information for the period from the start day of the profit calculation cycle until the present day. At the end of the profit cycle, the profit calculation is finished and distributed for relevant accounts. For more information refer to [Manual and Automated EOD Process](/docs/manual-and-automated-eod-process). ## Testing in sandbox Currently we have provided the temporary option **Jobs** in the **Profit sharing** service, for manual triggering of the profit calculation process. 1. Navigate to **Profit Sharing** > **Jobs**. 2. For proposal generation, you will need to run a job on the second day of profit calculation cycle. 1. select a date from the calendar and click **Start job**. 3. For the proposal's final results, you will need to run a job on the first day of the next profit calculation cycle. 1. Select a date from the calendar and and click **Start job**. 4. For the cycle's final results you need to search for a job on the last day of the profit calculation cycle. 1. Select a date from the calendar and click **Search**. The list shows each pool cycle's calculation. The following fields are shown: | Field name | Description | | --- | --- | | ID | ID of the proposal. | | Pool ID | ID of the pool. | | Pool Name | Name of the pool. | | Equivalent Rate | The calculated percentage of profit in the pool for the cycle. This can be shown either in decimal or percentage, depending on the pool allocation. | | Average Balance | The average account balance for each pool. | | Status | The current status of the proposal. | | Profit Amount | The calculated (distributable) profit amount for the pool. _Profit amount_ = Total income - total expense. | | Total Income | The calculated total amount of income allocated to the pool. | | Total Expenses | The calculated total amount of expense allocated to the pool. | ## Reviewing profit cycles To view the complete breakdown of a proposal, select **Actions** > **View cycles**. ![View cycles](/img/support/view-cycles.png) The overview shows the following information: ### Cash flow calculation cycles Cash flow calculation cycles give an overview of the total cashflow of the accounts in a pool. The following fields are shown in this section: | Field name | Description | | --- | --- | | Pool Cycle ID | The ID of the pool cycle. | | Cashflow | The income or expense association used for a cash flow calculation. | | Type | The type of account linked to the pool - either Income or Expense. | | Allocation Method | The allocation method for the pool calculation. | | Account | The GL account used in the pool. | | Account Percentage | The percentage of profit sharing allocated to that pool in each account. | | Amount | The total cash flow amount for the account. | ### Product calculation cycles Product calculation cycles show the average balance and profit rates for the products in a pool. The following fields are available in this section: | Field name | Description | | --- | --- | | Pool Cycle ID | The ID of the pool cycle. | | Product | The product used in the calculation cycle. | | Profit Rate | The percentage of profit accumulated in the calculation cycle. | | Average Balance | The average balance of the accounts in the product over the calculation period. | | Account Number | The number of accounts contained in the product. | | Start Date | The start date of the profit calculation cycle. | | End Date | The end date of the profit calculation cycle. | ## Generating proposals On the second day of a new profit calculation period, a proposal is automatically generated. 1. Navigate to **Profit Sharing** > **Proposals**. 2. There will be two tabs visible: **Open** and **Closed** ![Open and close buttons](/img/support/open-close-button.png) The **Open** tab shows indicative proposals that are currently being processed. Once the profit sharing process is complete, the proposal is moved to the **Closed** tab. Proposals here will have one of two statuses: * *Approved* - the profit calculation is approved but has not yet been applied to all accounts due to different payment cycle dates. * *Applied* - the calculated profit has been approved and successfully applied to all relevant accounts. :::note The profit sharing process is fully automated. As a result, proposals will appear in the **Closed** proposals tab once their profit cycle is complete. You will typically not see active proposals in the **Open** proposals tab. ::: ## Proposal details Proposals present the profit calculation results at the Pool, Product, and Account levels for all pools that share that period's start date and have common Income and Expense categories. 1. Navigate to **Profit Sharing** > **Proposals**. 2. Click the **Details** button. The **Proposal** screen will open, showing a breakdown of the entire profit calculations used to derive the profit sharing proposal. ![details button](/img/support/details-button.png) ![proposals screen](/img/support/proposal.png) --- # Sandbox URL: https://docs.mambu.com/docs/sandbox/ Your Mambu instance includes a *production tenant* and a *sandbox tenant*. Your live application is hosted on your production tenant. While the sandbox tenant is a fully functional, isolated testing space that runs on a separate tenant. You can use your sandbox to test configurations, updates, and new products or features before making them available to your clients in production. This allows you to "play in the sandbox" to try out new features and workflows, train your staff, or develop applications without changing your live data. The complete Mambu UI and Mambu API are both fully available in the sandbox and production tenants. You may log into the Mambu UI at the following URLs: * Sandbox: `https://TENANT_NAME.sandbox.mambu.com` * Production: `https://TENANT_NAME.mambu.com` For more information on the sandbox API, see [Sandbox](/api/pages/api-v2/sandbox) in our API Reference. :::note If you have federated authentication enabled, you must set up separate applications for both tenants in your IdP. For more information, see [Using sandboxes with federated authentication enabled](/docs/enable-federated-authentication-with-mambu#using-sandboxes-with-federated-authentication). ::: The two tenants are part of the same instance, but are otherwise mostly independent. What you do in your sandbox does not affect production data, and vice versa, with one important exception: :::warning Sandbox tenants do not have redundant servers or database backups. We strongly recommend that you do not use a sandbox for live client data. ::: The sandbox is generally one version ahead of the production tenant. As such, it may include changes that are currently in, or may soon be in, the production tenant. For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). ## Sandbox management To manage your sandbox, go to the Customer Service Portal. For more information and instructions, see [Customer Service Portal - Sandbox Management](/docs/customer-service-portal#sandbox-management). ## Distinguishing the sandbox from production You may distinguish sandbox from production by looking at the base URL. Also, the sandbox UI has a blue bar with the label **Sandbox Environment** at the bottom of each page. ![Mambu dashboard with blue sandbox environment bar](@site/static/img/support/Artboard%202.PNG) ## Populating your sandbox with data To populate your sandbox with data, you may: * Clone production data to your sandbox * Use Configuration as Code (CasC) ### Cloning production data to your sandbox There are two options available for cloning production data to your sandbox: **Clone with Production Anonymized Client Data** and **Clone with Production Data**. For more information on how to clone, see [Customer Service Portal - Cloning production to sandbox](/docs/customer-service-portal#cloning-production-to-sandbox). For security and compliance reasons, when you clone your production data to sandbox, API keys are not copied over. You must create new API keys for your newly cloned sandbox tenant. For more information, see [API Consumers - API keys](/docs/api-consumers#api-keys). #### Client data anonymization If you clone production with anonymized client data, your data will be modified as described below: **Notifications** | Action | Items | |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Unsubscribed | All clients are unsubscribed from notifications | | Deleted | - Notification requests associated with the client
    - Notification messages associated with the client
    - Notification messages associated with client's loan accounts
    - Notification messages associated with client's savings accounts
    - Client tasks | **Client fields** | Action | Items | |---|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Obfuscated | - First name
    - Last name | | Deleted | - Middle name, gender, notes, email address, birth date, home phone, mobile phones, address, assigned branch key, assigned centre key, assigned credit officer key.
    - Client identification documents (also corresponding attachments from remote file storage)
    - Client profile picture and signature picture (from images table)
    - Client attachments (from remote file storage and documents table)
    - Client custom field values
    - Portal preferences
    - Client comments
    - Client activities (activities, sub-activities and field change items) | **Client loan accounts** | Action | Items | |---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Obfuscated | - Loan name | | Deleted | - Notes
    - Custom field values for client loan accounts
    - Attachments for client loan accounts (from remote file storage and documents table)
    - Client loan accounts transactions | | Deleted | - Transaction comments
    - Transactions custom field values | **Client loan accounts guarantees** | Action | Items | |---|----------------------------------| | Obfuscated | - Asset name | | Deleted | - Guarantees custom field values | **Client loan repayments** | Action | Items | |---|--------------------------------------------------------------------------------------------------------------------------------------------------------| | Deleted | - Repayments notes
    - Comments for client loan accounts
    - Client loan accounts activities (activities, sub-activities and field change items) | **Client deposit accounts** | Action | Items | |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------| | Obfuscated | - Account name | | Deleted | - Notes
    - Custom field values for client savings accounts
    - Attachments for client savings accounts (from remote file storage and documents table) | **Client savings accounts transactions** | Action | Items | |---|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Deleted | - Transaction comments
    - Transactions custom fields
    - Comments for client savings accounts
    - Client savings accounts activities (activities, sub-activities and field change items) | **Client lines of credit** | Action | Items | |---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Deleted | - Notes
    - Custom field values for client lines of credit
    - Attachments for client lines of credit (from remote file storage and documents table)
    - Lines of credit activities (activities, sub-activities and field change items) | **Client guarantees (guarantees in which the client is guarantor)** | Action | Items | |---|----------------------------------| | Obfuscated | - Asset name | | Deleted | - Guarantees custom field values | :::note Queues are not cloned The cloning process does **not** clone the **infrastructure queues** used by Notifications (Streaming, Webhook, SMS, and Email). As a result, notification dispatch will not work out-of-the-box after a clone. **Workaround** Before reusing Notifications in the cloned sandbox, **duplicate your notification templates** in the **target sandbox**. This rebuilds the configuration so the system can produce and dispatch new messages from the sandbox environment. If you use custom routing, ensure any external endpoints and credentials are updated for sandbox use. ::: ### Using Configuration as Code to populate your sandbox Configuration as Code is a feature that allows you to batch configure Mambu elements using YAML-formatted requests. For more information, see [Configuration as Code Overview](/docs/configuration-as-code-1/). --- # Schedulers and holidays URL: https://docs.mambu.com/docs/schedulers-and-holidays/ The scheduler and holidays settings control when incoming and outgoing payments are processed. Schedulers have two jobs, sending transactions for AML processing to the AML callout and creating or processing payments messages, for example, from an incoming SEPA Direct Debit collection request. Schedulers can be configured to only work during set hours, process payments at set intervals, and put payments in a paused state on days defined as holidays or non-working days. ## Schedulers Schedulers can be configured from the **Configuration** > **Schedulers** tab, which will be available to users with an administrator role. ![Schedulers Configuration in Mambu Payment Gateway](@site/static/img/support/payments--schedulers-table.png) Schedulers run at regular intervals between the configured start and end times to process transactions. For each supported payment method, for example SEPA Credit Transfers or SEPA Direct Debit, you will need to configure two schedulers, one for incoming transactions and one for outgoing transactions. SEPA Instant Credit Transfers are processed 24 hours a day, 365 days a year, irrespective of any schedulers or holidays you may have set up for your institution. If using an anti-money laundering (AML) service, the scheduler will first request an AML check and only process the payment after the response indicates that the payment has passed all the checks. For incoming payments, processing will be immediate. For outgoing payments, the payment message will be generated once the response indicating AML checks have passed has been received and processed on the next run of the scheduler. You can additionally request to enable a dedicated scheduler for AML checks, for example, if you would like to send requests to your AML service on a specific schedule or need to spread requests out due to rate limiting. Incoming or outgoing payments that have a requested settlement date, for example SEPA Direct Debit collections that may be submitted with a requested collection date (`ReqdColltnDt`) in the future, are first processed by the scheduler to create the necessary payments messages, then again on the requested date to process the transactions themselves. When a transaction is processed by a scheduler, the necessary withdrawal or deposit Mambu transactions are typically posted against the account using an API call with a value date (`valueDate` field) set to `now`. Processed payments sent to a scheduler will be queued and transformed into a payment message the next time it is run. This means that, for example, if a scheduler is set to run between 9:00 AM and 5:00 PM and a transaction is processed at 7:00 PM, it will be bulked into a payment file and sent through the configured callout at 9:00 AM the next day when the scheduler restarts. If the payment was an incoming payment with a settlement date on the previous day, the value date of the transaction posted to Mambu will be backdated to that day, however, the booking date will remain with a value of `now`. ### Scheduler start and end times When configuring your scheduler, you may use the **From Time** and the **To Time** fields to set a start and end time. For example, you may configure your schedulers to run during business hours, or have them running from 00:00 to 23:59. It is not possible to configure different times for different days of the week or have custom start and end times for defined holidays. Schedulers of the same type cannot overlap. For example, you cannot create an Incoming SEPA Scheduler to run between 00:00 and 12:00, and another Incoming SEPA Scheduler to run between 11:00 and 23:59. :::warning Please be aware The **From Time** and **To Time** values are in UTC so remember to add or subtract the correct number of hours for your local time offset. If sticking to strict business hours, you may also need to change the scheduler start and end times if your country makes adjustments for daylight saving. ::: ### Cadence You can set your schedulers to run at defined intervals starting from once a minute. ### Bank BIC In the **Bank BIC** field you should enter the Bank Identifier Code (BIC) for the bank or branch for which this scheduler should apply to. Generally, you should have incoming and outgoing schedulers configured for each BIC and each payment type you support. ### Starting and stopping schedulers The **Start/Stop** column will show the current status of a given scheduler. A scheduler can have one of three states: sleeping, active, or stopped. If a scheduler is not currently processing transactions, the status **Sleeping** will be shown. You can manually stop a scheduler by selecting the **Stop** icon on its row. In a stopped state, you can edit the scheduler by selecting **Update** in the **Actions** column. When updating a scheduler, you may either change its start or end time or increase or decrease the frequency at which it runs. Selecting the **Start** icon will restart the scheduler. Any payments due to be processed by a paused scheduler will be held in a queue indefinitely and processed when the scheduler is restarted. ## Holidays Holidays can be defined from the **Configuration** > **Holidays** screen and be given a date, group, and description. ![Holidays Configuration in Mambu Payment Gateway](@site/static/img/support/payments--holidays-configuration.png) Incoming or outgoing payments with a requested settlement date falling on a defined holiday will only be processed by a scheduler after the holiday has ended. Schedulers do not work on holidays. For example, if you have defined December 25 and December 26 as holidays and a payment is received with a requested settlement date of December 25, it will be processed at the earliest on December 27, with this date also being used for the interbank settlement date (`IntrBkSttlmDt`) field in the confirmation message passed back to the originator bank. Saturday and Sunday are always considered non-working days and, except for SEPA Instant Credit Transfers, payment messages will not be sent on these days by default. ### Holidays date Holidays can only be defined for a given day and can not be set to recur on the same day each year. For example, if you configure holidays for Christmas you will need to set them for each year, which, in many countries may be on different days as they could fall on a weekend and so, the resulting bank holiday will be moved to the 27th and 28th of December rather than the 25th and 26th. ### Holidays group The **Holidays group** field indicates where the holiday applies. The options are **Local**, **EBA** (Euro Banking Association), or **TARGET 2**. If you select **Local**, then the holiday applies to your institution, for example a national holiday in the country in which you operate or a non-working day for your institution only. If the holidays applies for other areas then you may select **TARGET 2** or **EBA**. You can filter the view of currently defined holidays for a group by providing a holiday group and set of dates in the filter fields above the Holidays table. :::warning Please be aware **TARGET 2** holidays only apply to the following schedulers: Outgoing TGT Scheduler, Incoming TGT Scheduler. All other schedulers will still execute if a TARGET 2 holiday is configured. **Local** and **EBA** holidays apply to **all schedulers except** Outgoing TGT Scheduler and Incoming TGT Scheduler. These schedulers will still run if a Local or EBA holiday is configured. ::: ## Description The description field can be used for supplying the name of the holiday, for example, Independence Day or Annual General Meeting (AGM). ## Impact on processing times The settlement and booking dates of incoming and outgoing transactions may be impacted by scheduler start and end times, holidays defined in the Mambu Payment Gateway, as well as any holidays or non-working days configured for your Mambu Core Banking System. Depending on your CSM and the payment scheme of a given transaction, there may also be special rules that have to be taken into account during processing. The behaviour of a rejection or return after settlement will be the same as for any other incoming or outgoing transaction, with the addition of the original interbank settlement being included in the payment instruction in the `TxInf.OrgnlTxRef.IntrBkSttlmDt` field. For rejections before settlement, there is no withdrawal or deposit being made against the client's Mambu account, so the only dates which may be affected by any defined holidays are the creation and interbank settlement dates in the Mambu Payment Gateway. To illustrate how holidays and non-working days defined in the Mambu Core Banking System and Mambu Payment Gateway may affect the interbank settlement date, creation date, value date, and booking date, we will provide examples for SEPA Credit Transfer, SEPA Direct Debit (Core), and SEPA Direct Debit (B2B) payments. In the following examples in this article we will be using a few specific terms which we define as: - **Requested Execution/Collection Date** - for a SEPA Direct Debit payment, this will be the value of the `ReqdColltnDt` field. This date is when the payment will be debited from the debtor account and credited to the creditor account. If it falls during a non-banking business day (weekend or configured holiday), it will be automatically updated to the nearest future banking business day. - **Interbank Settlement Date** - for a SEPA payment, this will be the value of the `IntrBkSttlmDt` field. This represents the date on which the funds were made available to the creditor. For SEPA Direct Debit payments this is the Requested Execution or Collection Date if it falls during a banking business day, or the nearest future banking business day if not. - **Creation Date** - for SEPA payments this is the value of the `CreDtTm` field and represents when a collection or transfer request was created, for SEPA Direct Debit collections the creation date can be up to 14 days before the requested execution date. In Mambu, the creation date is the value of the `creationDate` date, which is automatically generated and represents the time and date on which a deposit, transfer, or withdrawal transaction was made using the API. - **Value Date** - in Mambu this is the date on which funds will be made available to or removed from a client's account. When deposits, withdrawals, or transfers are made by Mambu Payment Gateway, the current timestamp at the time of the API request will be used for this field. This same timestamp will also be used to populate the `IntrBkSttlmDt` when sending confirmation of an incoming SEPA payment, a successful Direct Debit collection, or an outgoing SEPA transfer. - **Booking Date** - in Mambu this is the date on which a transaction will be posted to the accounting ledger, the booking date can differ from the value date if, for example, it was posted on a day marked as a holiday or non-working day, in which case, it will be post-dated to the next working day. For more information on booking and value date in Mambu, see [Booking Date vs Value Date](/docs/booking-date-vs-value-date). Dates used in the examples include: - Friday 5th - Monday 8th August to show behaviour on Saturday and Sunday which are defined as non-working days in Mambu Core Banking and Mambu Payment Gateway - Tuesday 8th March to show a day configured as a holiday in Mambu only - Wednesday 4th May to show a day configured as a holiday in Mambu Payment Gateway only - Thursday 5th June to show a holiday configured in both Mambu Payment Gateway and Mambu Core Banking ### SEPA Instant Credit Transfer For SEPA Instant Credit Transfers the holiday settings do not apply, additionally, you can not configure custom times for the scheduler, this will run every minute. For Instant Credit Transfers, the only date which can differ from the execution date is the Mambu Booking Date, which will be moved to the next working day, as configured in Mambu, but only has an impact on accounting and not when the value of a transfer will be reflected in a client's account. ### SEPA Credit Transfer SEPA Credit Transfers must be submitted on the day of execution, the requested execution date can not be in the future or in the past. Timelines for settlements, recalls and other post-transaction operations are generally specified in banking business days so non-working days and holidays should not be considered when working out the last day a recall or rejection can be made. | requested execution date | interbank settlement date | creation date (Mambu transaction) | value date | booking date | notes | |---|---|---|---|---|---| | Saturday 6th August | Monday 8th August | Saturday 6th August | Saturday 6th August | Saturday 6th August | The payment will trigger the necessary mambu transactions on 6th of August, however the settlement date will be the next working day, 8th of August 6th August | | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | Wednesday 9th March | booking date is moved to next working day | | Wednesday 4th May | Thursday 5th May | Wednesday 4th May | Wednesday 4th May | Wednesday 4th May | processing is done immediately, the payment message is generated with settlement date the next working day | | Thursday 5th June | Friday 6th June | Thursday 5th June | Thursday 5th June | Thursday 5th June | processing is done immediately, the payment message is generated with settlement date the next working day| ### SEPA Direct Debit (Core) SEPA Direct Debit payments can involve both a collection request and a payment message. Timelines for settlement and returns are specified by the scheme in banking business days so non-working days and holidays should not be considered when working out the last day a return can be made. Timelines for refunds are specified by the scheme in calendar days so holidays and non-working days still count when working out the last date a request for refund can be made by a party to the transaction. | requested execution date | interbank settlement date | creation date (Mambu transaction) | value date | booking date | notes | |---|---|---|---|---|---| | Saturday 6th August | Monday 8th August | Monday 8th August | Monday 8th August | Monday 8th August | settlement date is moved to next working day | | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | | | Wednesday 4th May | Thursday 5th May | Thursday 5th May | Thursday 5th May | Thursday 5th May | processing is moved to the next working day, interbank settlement date is specified as next business day | | Thursday 5th June | Friday 6th June | Friday 6th June | Friday 6th June | Friday 6th June | processing is moved to next working day | ### SEPA Direct Debit (B2B) SEPA Direct Debit B2B payments can involve both a collection request and a payment message. The timelines for rejections and returns are specified by the scheme in banking business days so non-working days and holidays should not be considered when working out the last day a recall or rejection can be made. The scheme does not provide for refunds. | requested execution date | interbank settlement date | creation date (Mambu transaction) | value date | booking date | notes | |---|---|---|---|---|---| | Saturday 6th August | Monday 8th August | Monday 8th August | Monday 8th August | Monday 8th August | settlement date is moved to next working day | | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | Tuesday 8th March | | | Wednesday 4th May | Thursday 5th May | Thursday 5th May | Thursday 5th May | Thursday 5th May | processing is moved to the next working day, interbank settlement date is specified as next business day | | Thursday 5th June | Friday 6th June | Friday 6th June | Friday 6th June | Friday 6th June | processing is moved to next working day | --- # SEPA Credit Transfer Inquiries URL: https://docs.mambu.com/docs/sct-inquiries/ SEPA Credit Transfer Inquiries allow SEPA participants to request extra information or clarifications regarding the status of a SEPA Credit Transfer. There are several possible inquiry types supported by the SEPA scheme, including: - [Claim of Non-Receipt](#initiating-a-claim-of-non-receipt-camt02700106): the Beneficiary has claimed they did not receive the original Credit Transfer. In this case, the Originator Bank is asked by the Originator to investigate whether the Credit Transfer has been executed. The SEPA scheme assumes that the Beneficiary contacts the Originator outside the scheme, and the Originator, in turn, requests the start of the inquiry process with their Bank. - [Claim for Value Date Correction](#initiating-a-claim-for-value-date-correction-camt08700105): the Beneficiary has claimed that the initial SEPA Credit Transfer has been credited with a value date later than the expected value date. In a similar manner, the SEPA scheme assumes that the Beneficiary contacts the Originator outside the scheme, and the Originator will request the start of the inquiry process with the Originator Bank. - [Request for Status Update](#initiating-a-request-for-status-update-pacs02800101): the Originator Bank can request a response for a previously sent Inquiry, to which the Beneficiary Bank has not yet responded. Requests for status updates should be sent if an answer has not been received within 10 banking days of the original inquiry. You can send as many status update requests as you want, although we recommend not sending too many, so as to give the receiving back time to respond. Generally, there are two ways to initiate an inquiry: using our API, or using the Mambu Payment Gateway (MPG) UI. This page will tell you how to do both. For any inquiry, the SEPA scheme gives the receiving party a maximum of 10 banking days to respond. The response must be in the form of a camt.029 message, which you will be able to view from the list of incoming SEPA CT messages in the MPG UI. Once an inquiry has been answered, there may be compensation due, such as an interest payment refund or other fees that were incurred because of an incorrect value date or non-receipt of payment. The amount of compensation due may be included in the camt.029 message ## Initiating a Claim of Non-Receipt (camt.027.001.06) ### Initiate via the API To initiate a Claim of Non-Receipt (camt.027.001.06) inquiry for an existing SEPA Credit Transfer (pacs.008.001.02), a Payments user must execute the following API call: `POST /api/v1/payments/inquiries:claimNonReceipt` ```json { "groupHeader": { "messageIdentification": "", "settlementDate": "" }, "paymentIdentification": { "transactionIdentification": "" }, } ``` The information highlighted in green must contain the reference for the original Credit Transfer: message identification, settlement date, and transaction identification. Executing the API call will trigger the creation of a Claim of Non-Receipt instruction with the status `To Be Sent`. It will be picked up with the next `Outgoing SEPA Scheduler` execution. You can find more information on the [claim of non-receipt](https://api.mambu.com/payments-api//#sepa-credit-transfer-inquiries-claimnonreceipt) API call in our Mambu Payments Gateway API Reference. ### Initiate via Mambu Payment Gateway UI To initiate a Claim of Non-Receipt inquiry for an existing Credit Transfer through the MPG UI, navigate to the transaction details page and click `Initiate Claim` in the SEPA Inquiries section ![sct-initiate-claim](@site/static/img/support/sct-initiate-claim.png) In the confirmation dialog, select the Claim of Non-Receipt inquiry type and confirm by pressing the `Initiate` button. This action will will trigger the creation of a Claim of Non-Receipt instruction with status `To Be Sent`, which will be picked up with the next `Outgoing SEPA Scheduler` execution. ![sct-initiate-claim-non-receipt](@site/static/img/support/sct-initiate-claim-non-receipt.png) ## Initiating a Claim for Value Date Correction (camt.087.001.05) ### Initiate via API To initiate a Claim for Value Date Correction (camt.087.001.05) inquiry for an existing SEPA Credit Transfer (pacs.008.001.02), a Payments user must execute the following API call: `POST /api/v1/payments/inquiries:claimValueDateCorrection` ```json { "groupHeader": { "messageIdentification": "", "settlementDate": "" }, "paymentIdentification": { "transactionIdentification": "" }, "claimedValueDate": "yyyy-MM-dd" } ``` The information highlighted in green must contain the reference for the original Credit Transfer: message identification, settlement date, and transaction identification. The `claimedValueDate` field must contain the value date which the Beneficiary states is the expected value date. You can find this information by calling the [payment details endpoint](https://api.mambu.com/payments-api//#sepa-credit-transfers-paymentdetails) with the ID of the original payment. Executing this API call will trigger the creation of a Claim for Value Date Correction instruction with status `To Be Sent`, which will be picked up with the next `Outgoing SEPA Scheduler` execution. You can find more information on the [value date correction](https://api.mambu.com/payments-api//#sepa-credit-transfer-inquiries-claimvaluedatecorrection) SPI call in our API Reference. ### Initiate via Mambu Payment Gateway To initiate a Claim for Value Date Correction inquiry for an existing Credit Transfer through the MPG, navigate to the transaction details page and click `Initiate Claim` in the SEPA Inquiries section ![sct-initiate-claim](@site/static/img/support/sct-initiate-claim.png) In the confirmation dialog, select the Claim for Value Date Correction inquiry type, introduce the expected value date and confirm by pressing the `Initiate` button. This will trigger the creation of a Claim for Value Date Correction instruction with status `To Be Sent`, which will be picked up with the next `Outgoing SEPA Scheduler` execution. ![sct-initiate-value-date-correction](@site/static/img/support/sct-initiate-value-date-correction.png) ## Initiating a Request for Status Update (pacs.028.001.01) To initiate a Request for Status Update (pacs.028.001.01) for an already submitted inquiry, a Payments user must execute the following API call: ### Initiate via API `POST /api/v1/payments/inquiries:requestStatusUpdateOnInquiry` ```json { "messageTypeName": "CAMT_087_001_05 or CAMT_027_001_06", "assignment": { "identification": "", "creationDateTime": "" }, "caseIdentification": "" } ``` The information highlighted in green must contain the reference for the original Inquiry instruction: message type, assignment identification, assignment creation date and case identification. You can find this information by calling the [payment details endpoint](https://api.mambu.com/payments-api//#sepa-credit-transfers-paymentdetails) with the ID of the original payment. Executing this API call will trigger the creation of a Request for Status Update instruction with status `To Be Sent`, which will be picked up with the next `Outgoing SEPA Scheduler` execution. You can find more information on the [inquiry status update](https://api.mambu.com/payments-api//#sepa-credit-transfer-inquiries-requeststatusupdateoninquiry) API call in our API reference. ### Initiate via Mambu Payment Gateway To initiate a Request for Status Update for an existing Inquiry through the MPG, navigate to the Inquiry details page and click `Request Status Update` in the SEPA Inquiries section ![sct-initiate-status-update](@site/static/img/support/sct-initiate-status-update.png) In the confirmation dialog, confirm by pressing the `OK` button. This action will will trigger the creation of a Request for Status Update instruction with status `To Be Sent`, which will be picked up with the next `Outgoing SEPA Scheduler` execution. ![sct-confirm-status-update](@site/static/img/support/sct-confirm-status-update.png) --- # Secondary Marketplace for Peer-to-Peer Loans URL: https://docs.mambu.com/docs/secondary-marketplace-for-p2p-loans/ The *Secondary Marketplace* is where you can sell and buy loan fractions, allowing a loan funder to sell a portion of the loan (or fraction) to a different funder. This has no impact on the loan borrower, but is a tool for funders to manage their funds easily in case they want to liquidate their funding of a specific loan. With the Secondary Marketplace functionality loan fraction shares owned by funders can be sold to other funders at face value. *** ## Selling a loan fraction share The sale of a loan fraction share can be triggered from the funding account, as seen below. ![Selling a Loan Fraction Share from Sell button.](@site/static/img/support/loans--deposit-account-funding-tab.png) A dialog will open which will allow you to add buyers for the respective loan fraction. A loan fraction can be sold to as many buyers as needed. ![Sell Loan Fraction view with Remaining Amount and Remaining Percentage labels and Source, Account and Amount fields. Available buttons are Add Buyer, Cancel and Sell](@site/static/img/support/loans--sell-loan-fraction-3.png) When filling in the data of the buyers and the purchased amount, the Remaining amount and the fraction share percentage changes dynamically to the new values. ![Sell Loan Fraction view with Remaining Amount and Remaining Percentage labels and Source, Account and Amount fields. Available buttons are Add Buyer, Cancel and Sell.](@site/static/img/support/loans--sell-loan-fraction.png) The original funder of the loan can sell the fraction share in its entirety or retain a portion, as can be seen in the above screenshots. The loan fraction share % is calculated as: `Purchase Amount / (Current Fraction Amount) * Current Loan Fraction %` For the above example, it means: `1,500 / 2,411.88 * 60% = 37.31%` for the new investor. The same calculation is performed for the original funder, if they retain a fraction share amount. :::warning We have identified a **rare edge case scenario** when you might get an invalid fraction share % for the new purchasing funders. Due to rounding, there might be cases when the amount to be sold generates an uneven fraction share %. In such cases you will get the validation error below; requesting a slightly different amount input. The difference will only need to be a few cents. The validation message will state:

    `The current amount input generates uneven investment percentages, which result in a total invested percentage for the new funders to be above or below the actual fraction share. Please adjust the amount input, by either decreasing or increasing the value.` ::: After the sale is performed, transactions are triggered for the sale and the purchase of the fraction share on the corresponding accounts: * **Loan fraction sold**: a single transaction is logged on the seller's account. * **Loan fraction bought**: logged for each account that purchases a portion from a loan fraction. :::note As long as there is no subsequent transaction after it, you can reverse a loan fraction sold. This is because a sale may be linked to more than one loan fraction bought transaction. ::: *** ## Accounting for loan fraction share sales and purchases If accounting is enabled for the funding account, "Savings Control" will be credited for the loan fraction sold transaction, as well as for the loan fraction bought transaction. Example: Given a loan fraction of 500, which is sold to two Buyers for 200 and 300 respectively. The corresponding Journal Entries are booked as: | Transaction | General Ledger Account | Debit | Credit | General Ledger Type | | --- | --- | --- | --- | --- | | Fraction Sold | Savings Account Seller | | 500 | Liability Account | | Fraction Bought | Savings Account Buyer 1 | 200 | | Liability Account | | Fraction Bought | Savings Account Buyer 2 | 300 | | Liability Account | If a funder chooses to purchase fraction shares within the same loan, from multiple funders, they are amassed into one fraction share for the buyer. For example, if Buyer A purchases fraction shares (either fully or partially) from Funder Z and Funder Y within the same loan, they will be under the same fraction share version for Buyer A - regardless of when the purchase is made. *** ## Interest impact of selling a loan fraction share For funders that sell a loan fraction, the interest that was accrued up to the moment of the sale will be applied to the initial funder, also known as the seller. The interest that is accrued after the sale of the loan should be applied to the new funder, also known as the buyer or the buyers. Example: Given a loan account with the next expected installment of USD102.00, out of which USD100.00 is principal and USD2.00 is interest and assuming the funder sells his loan fraction in the middle of the installment, halfway through the due period. When the borrower makes a repayment, the original funder will receive half of the interest, which was accrued at the moment of sale (USD1.00), and the other half of the interest and the whole principal (USD101.00) will be repaid into the new funder's account. *** ## Selling a loan fraction share and account overview For peer-to-peer (P2P) loans Mambu provides the fraction share percentage for funders. This information is available when creating a loan account and adding new funders—as well as in the sale dialog (see the screenshots above)—and on the loan account **Funding** tab, as you can see below: ![Funding tab at Loan Account level with Funding Source sections](@site/static/img/support/loans--loan-account-funding-tab.png) On the loan **Funding** tab, there are additional details for each funder about when a loan fraction was bought and its amount. Additionally, the **Valid From** date—when the funding share was created—is detailed. --- # Securities Settings URL: https://docs.mambu.com/docs/securities-settings/ In order to make the **Securities** module available at loan account level, it has to be enabled at loan product level. Mambu supports two types of securities which you can choose from, based on your operational requirements: * **Enable Guarantors**: will make the **Guarantors** section available for loan accounts under this product. * **Enable Collateral**: will make the **Collateral Assets** section available for loan accounts under this product. ![Securities settings with Enable Guarantors and Enable Collateral options.](@site/static/img/support/loans--securities-settings.png) To learn more details about how different securities can be tracked for loan accounts, please read [Loan Securities - Guarantors and Collateral Assets](/docs/loan-securities-guarantors-and-collateral-assets). *** ## Required Securities Validation With this option, you can define a % of the loan amount that has to be covered by securities (both guarantors and collateral assets). This coverage % is **validated at loan approval and loan disbursement** and takes into account ALL securities added for the loan, meaning it sums up all the amounts of either guarantees or collateral, then validates the loan amount % coverage. If the loan amount has insufficient coverage (less that the % defined in the product settings), it will not be possible to approve the account. --- # Sending Secure Information URL: https://docs.mambu.com/docs/sending-secure-information/ Sensitive information, including financial details, usernames, passwords, and personally identifiable information of third parties, needs to be protected. At Mambu, we use the [FlowCrypt](https://flowcrypt.com) browser extension as our preferred method for encrypting email communications. If your organization does not use Gmail, please follow the instructions below to set up a compatible GPG solution. ## Setting up FlowCrypt in Google Mail 1. Install the Flowcrypt extension for your browser from the [FlowCrypt site](https://flowcrypt.com/). 1. Allow the extension access to your Google account. 1. Create a new encryption key or import an existing key. 1. Create a strong passphrase for your key. 1. Start sending encrypted emails with Gmail! ## Setting up and using GPG You may also use GNU Privacy Guard (GPG) to facilitate secure email with your email client. Consult the appropriate guide for your operating system or client: * [Mac](http://support.gpgtools.org/kb/how-to/first-steps-where-do-i-start-where-do-i-begin-setup-gpgtools-create-a-new-key-your-first-encrypted-mail) * [Windows](http://gpg4win.org/doc/en/gpg4win-compendium_12.html) * [Linux/Ubuntu](https://help.ubuntu.com/community/GnuPrivacyGuardHowto) For Microsoft Outlook, GPG4Win [has an optional component](http://www.gpg4win.org/doc/en/gpg4win-compendium_33.html) which can be used for GPG signing and encryption. [GPG4o](https://www.giepa.de/products/gpg4o/?lang=en) also provides GPG for Outlook, but it is not available in a free version. :::warning We recommend disabling storage of draft emails, as they are often stored in plaintext by email clients and providers such as Gmail or Yahoo. ::: ### Encrypting local files with GPG Local files can also be encrypted using GPG. From the command-line (Mac/Linux), use the following command for encryption: ```bash gpg "file-to-be-decrypted" ``` --- # SEPA Credit Transfer XML Messages URL: https://docs.mambu.com/docs/sepa-credit-transfer-technical-information/ This page provides information on how SEPA messages map to our Mambu Payments Gateway API, and how specific fields are derived from related transactions, such as in the case of inquiries or recall requests. Use the chevrons to expand or collapse the nested sections of the messages you are intereseted in. For more information on each specific field, refer to the European Payment Council's [SEPA implementation guidelines](https://www.europeanpaymentscouncil.eu/document-library/implementation-guidelines/sepa-credit-transfer-scheme-inter-psp-implementation), where documentation is available in PDF or XSD format. ## pacs.008.001.02 The pacs.008 message is created from the [initiate payment](https://api.mambu.com/payments-api//#sepa-credit-transfers-initiatepayment) API call and represents a payment from a debtor to a creditor. ```xml SCTORD156820211213000000012649 // generated value. Will be unique for each message created 2021-12-13T13:24:39 // the date and time the message was created 1 // the number of transactions included in this message. If many requests are received in a short space of time, they may be bulked into one message 46290.42 // these values come from the POST /payments call and will be the value of instructedAmount.currency and instructedAmount.amount. If the SEPA message includes a number of transactions, this will represent the sum total amount being sent 2021-12-13 // the date of settlement, as SEPA Credit Transfers can not be scheduled, this will generally be the same date as the message was generated as the transfer will be initiated immediately. If the message is generated after the configured schedule cut-off time, the settlement date will be the next business day CLRG // this indicates how the message will be settled, if using a Clearing and Settlement Mechanism, the value will be CLRG ST2 // this indicates the clearing house being used. The value will be taken from Configuration > System Properties > ACH Clearing System BTRLRO22 // the instructing agent, this will be your institution's BIC, as entered in Configuration > System Properties > Bank BIC BTRLRO22 // the instructed agent, this will be your ACH's BIC, as entered in Configuration > System Properties > ACH BIC e788ef660735414198cfb36a066d158d // the instruction ID is a generated value returned in the response to the inititial POST /payments API call as paymentId e2e1234567890-1 // the unique, user supplied end to end reference provided in the POST /payments API call in the field paymentIdentification.endToEndIdentification. If this value was not provided, this field will be present in the SEPA message with a value of NOTPROVIDED trxID1234567890-1 // the unique, user supplied transaction ID for this payment, provided in the POST /payments API call in the field paymentIdentification.transactionIdentification. If no value is provided, the generated Mambu Withdrawal Transaction ID will be used SEPA // the service being used for this transaction, provide in the POST /payments API call in the field serviceLevel. Only SEPA or TGT are allowed 46290.42 // these values come from the POST /payments call and will be the value of instructedAmount.currency and instructedAmount.amount SLEV // indicates which party will bear the cost of any charges, the value SLEV indicates that charges will be applied following the rules for the scheme being used, in this case SEPA. This is automatically added as it is the only allowed value in the SEPA EPC rules John Spartan // the value provided in the ultimateDebtor field in the POST /payments API call Mike Harrigan // the value provided in the debtorName field in the POST /payments API call US // the value provided in the countryCode field in the POST /payments API call, this will be a two-letter, ISO 3166 alpha-2 country code Santee Street 840 Los Angeles CA 90014 // this field is created based on the concatenated values of debtorAdress.street, debtorAdress.buildingNumber, debtorAdress.city, debtorAdress.postalCode in the POST /payments API call, if provided mYiD0987654321 // this value will be taken from the debtorIdentification.privateIdentification field in the POST /payments API call mYpRoPiD0987654321 this value will be taken from the debtorIdentification.proprietary field in the POST /payments API call HMPO // this value will be taken from the debtorIdentification.issuer field in the POST /payments API call RO10BTRL0000001234567890 // this value will be taken from the debtorAccount.identification.iban field in the POST /payments API call BTRLRO22XXX // this value will be taken from the debtorAgent.institutionIdentification.bicfi field in the POST /payments API call, if provided, otherwise it will be derived from the debtorAccount.identification.iban INGBNL2AXXX // this value will be taken from the creditorAgent.institutionIdentification.bicfi field in the POST /payments API call, if provided, otherwise it will be derived from the creditorAccount.identification.iban Alan Dutch Schaefer // this value will be taken from the creditorName field in the POST /payments API call MX // this value will be taken from the creditorAddress.country field in the POST /payments API call and will be a two-letter, ISO 3661 alpha-2 country code Carretera a Palenque 8 Palenque 29960 // this field is created based on the concatenated values of creditorAdress.street, creditorAdress.buildingNumber, creditorAdress.city, creditorAdress.postalCode in the POST /payments API call, if provided mYiD1234567890 // this value will be taken from the creditorIdentification.privateIdentification field in the POST /payments API call mYpRoPiD1234567890 // this value will be taken from the creditorIdentification.proprietary field in the POST /payments API call UKPA // this value will be taken from the creditorIdentification.issuer field in the POST /payments API call NL07INGB9227934553 // this value will be taken from the creditorAccount.identification.iban field in the POST /payments API call Simon Phoenix // this value will be taken from the ultimateCreditor field in the POST /payments API call, if provided PENS // this value will be taken from the purposeCode field in the POST /payments API call and must match a purpose code supported by the SEPA scheme ``` ## camt.027.001.06 This message is generated when a claim of non-receipt is made using either the [claim non receipt API](https://api.mambu.com/payments-api//#sepa-credit-transfer-inquiries-claimnonreceipt) or the [user interface](/docs/sct-inquiries#initiate-via-mambu-payment-gateway-ui). ```xml BTRLRO222021121300000000000014 // a unique, generated ID used to identify the case BTRLRO22XXX // the BIC of the bank making the claim. If the claim was initiated by you, this will be the BIC of your institution as provided in Configuration > System Properties > Bank BIC INGBNL2AXXX // the BIC of the bank who should respond to the claim. This will be the counterparty of the transaction in question 2021-12-13T14:50:26 // the date and time on which the claim was initiated BTRLRO22202112130000000000000000014 // a unique, generated ID used to identify the case BTRLRO22 // the BIC of the bank making the claim. If the claim was iniated by you, this will be the BIC of your institution as provided in Configuration > System Properties > Bank BIC SCTORD156820211213000000012650 // the unique ID of the original message for which this claim of non-receipt was lodged pacs.008.001.02 // the type of message for which this claim of non-receipt was lodged. For SEPA Credit Transfers this will be pacs.008.001.02 b32b146844bc46cc9f80e31f7f1343c4 // the instruction ID of the payment for which this claim of non-receipt was lodged. This will also match the paymentId that was included in the response to the POST /payments API call e2e1234567890-1 // the end-to-end ID, if provided, of the transaction to be investigated. If none was provided the value of this field will be NOTPROVIDED trxID1234567890-2 // the transaction ID of the transaction to be investigated 46290.42 // the amount of the transaction for which this claim of non-receipt was lodged, taken from the original payment instruction 2021-12-13 // the date on which the original transaction was marked as sent and settled, taken from the original payment instruction CLRG // the original settlement method of the transaction for which this claim of non-receipt was lodged, taken from the original payment instruction SEPA // the original service level method of the transaction for which this claim of non-receipt was lodged, taken from the original payment instruction. For SEPA Credit Transfers this will always have the value SEPA John Spartan // the ultimate debtor of the transaction for which this claim of non-receipt was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction Mike Harrigan // the debtor name of the transaction for which this claim of non-receipt was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction Santee Street 840 Los Angeles CA 90014 // the address of the debtor of the transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.AdrLine from the original payment instruction RO10BTRL0000001234567890 // the IBAN of debtor of the transaction for which this claim of non-receipt was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAcct.Id.IBAN from the original payment instruction BTRLRO22XXX // the BIC of the debtor agent financial institution of the transaction for which this claim of non-receipt was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAgt.FinInstnId.BIC from the original payment instruction INGBNL2AXXX // the BIC of the creditor agent financial institution of the transaction for which this claim of non-receipt was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAgt.FinInstnId.BIC from the original payment instruction Alan Dutch Schaefer // the name of the creditor of the transaction for which this claim of non-receipt was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Nm from the original payment instruction MX // the country of the creditor of the transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.Ctry from the original payment instruction Carretera a Palenque 8 Palenque 29960 // the address of the creditor of the transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.PstlAdr.AdrLine from the original payment instruction NL07INGB9227934553 // the IBAN of the creditor of the transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAcct.Id.IBAN from the original payment instruction Simon Phoenix // the ultimate creditor, if provided, of the transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.UltmtCdtr.Nm from the original payment instruction PENS // the purpose code that was provided for the original transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Purp.Cd field in the original payment instruction INQR // a code indicating that this is an inquiry The beneficiary is requesting a claim non receipt // human-readable, generated string instructing the counterparty of the specific claim, in this case, non-receipt of funds ``` ## pacs.028.001.01 This represents a request for a status update on a submitted inquiry and will be generated either when the request is made via the [request status update API](https://api.mambu.com/payments-api//#sepa-credit-transfer-inquiries-requeststatusupdateonrecall) or when the request is initiated [via the UI](/docs/sct-inquiries#initiating-a-request-for-status-update-pacs02800101). ```xml SCTINV156820211213000000000422 // a unique, generated ID used to identify the case 2021-12-13T15:21:56 // the date and time on which the request for a status update was made BTRLRO22XXX // the BIC of the bank making the request for status update. If the request was initiated by you, this will be the BIC of your institution as provided in Configuration > System Properties > Bank BIC INGBNL2AXXX // the BIC of the bank who should be responding to the claim. This will be the counterparty of the transaction in question BTRLRO222021121300000000000014 // the unique ID of the case for which the request for status update was made camt.027.001.06 // the message type of the case for which the request for status update was made, for example, a claim of non-receipt has the message number camt.027 BTRLRO22202112130000000000000000422 // a unique, generated ID used to identify the case b32b146844bc46cc9f80e31f7f1343c4 // the instruction ID of the payment being investigated. This will also match the paymentId that was included in the response to the POST /payments API call e2e1234567890-1 // the end-to-end ID, if provided of the transaction being investigated. If none was provided the value of this field will be NOTPROVIDED trxID1234567890-2 // the transaction ID of the transaction being investigated 46290.42 // the currency and amount of the transaction being investigated 2021-12-13 // the settlement date of the transaction being investigated CLRG // the settlement method which was used in the transaction being investigated SEPA // the service level of the transaction being investigated John Spartan // the ultimate debtor of the transaction being investigated, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction Mike Harrigan // the debtor name of the transaction being investigated, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction Santee Street 840 Los Angeles CA 90014 // the address of the debtor of the transaction being investigated, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.AdrLine from the original payment instruction RO10BTRL0000001234567890 // the IBAN of debtor of the transaction being investigated, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAcct.Id.IBAN from the original payment instruction BTRLRO22XXX // the BIC of the debtor agent financial instiution of the transaction being investigated, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAgt.FinInstnId.BIC from the original payment instruction INGBNL2AXXX // the BIC of the creditor agent financial institution of the transaction being investigated, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAgt.FinInstnId.BIC from the original payment instruction Alan Dutch Schaefer // the name of the creditor of the transaction being investigated, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Nm from the original payment instruction MX // the country of the creditor of the transaction being investigated, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.Ctry from the original payment instruction Carretera a Palenque 8 Palenque 29960 // the address of the creditor of the transaction being investigated, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.PstlAdr.AdrLine from the original payment instruction NL07INGB9227934553 // the IBAN of the creditor of the transaction being investigated, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAcct.Id.IBAN from the original payment instruction Simon Phoenix // the ultimate creditor, if provided, of the transaction for which this claim of non-receipt was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.UltmtCdtr.Nm from the original payment instruction ``` ## camt.056.001.01 This message type is generated when there is a request for cancellation or recall of a SEPA credit transfer made using either the [recall outgoing payment API](https://api.mambu.com/payments-api//#sepa-credit-transfers-recalloutgoingpayment) or the Mambu Payment Gateway UI. ```xml SCTSOL156820211214000000001033 // a unique, generated ID for this case BTRLRO22 // the BIC of the bank making the cancellation request. If the request was initiated by you, this will be the BIC of your institution as provided in Configuration > System Properties > Bank BIC BTRLRO22 // the BIC of the bank who should be responding to the cancellation request. This will typically be the counterparty of the transaction in question 2021-12-14T09:46:27 // the date and time on which the cancellation request was made 1 // the number of transactions to be cancelled included in this request 568R1348000000000000000000000001196 // a unique, generated ID for this cancellation request SCTORD156820211213000000012649 // the unique ID of the original message for which this cancellation request was lodged pacs.008.001.02 // the type of message for which this cancellation request was lodged, for SEPA Credit Transfers this will be pacs.008.001.02 e788ef660735414198cfb36a066d158d // the instruction ID of the payment to be cancelled e2e1234567890-1 // the end-to-end ID, if provided, of the payment to be cancelled. If none was provided the value of this field will be NOTPROVIDED trxID1234567890-1 // the transaction ID of the payment to be recalled 46290.42 // the currency and amount of the transaction for which this cancellation request was lodged 2021-12-13 // the date on which the original transaction was marked as sent and settled, taken from the original payment instruction BTRLRO22XXX // the BIC of the bank making the cancellation request. If the request was initiated by you, this will be the BIC of your institution as provided in Configuration > System Properties > Bank BIC DUPL // the reason given for the cancellation, depending on the option selected. Will be one of DUPL, FRAD, CUST or TECH CLRG // the original settlement method of the payment for which this cancellation request was lodged, taken from the original payment instruction ST2 // the clearing house used for the payment for which this cancellation request was lodged, taken from the original payment instruction SEPA // the original service level method of the transaction for which this cancellation request was lodged, taken from the original payment instruction and, for SEPA Credit Transfers, will always have the value SEPA John Spartan // the ultimate debtor of the transaction for which this cancellation request was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction Mike Harrigan // the debtor name of the transaction for which this cancellation request was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction US // the country of the debtor of the transaction for which this cancellation request was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.Ctry from the original payment instruction Santee Street 840 Los Angeles CA 90014 // the address of the debtor of the transaction for which this cancellation request was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.AdrLine from the original payment instruction mYiD0987654321 // the ID number of the debtor of the payment to be cancelled, taken from FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Id.PrvtId.Othr.Id mYpRoPiD0987654321 // the proprietary ID number of the debtor of the payment to be cancelled, taken from FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Id.PrvtId.Othr.SchmeNm.Prtry HMPO // the ID issuer of the debtor of the payment to be cancelled, taken from FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Id.PrvtId.Othr.Issr RO10BTRL0000001234567890 // the IBAN of debtor of the transaction for which this cancellation request was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAcct.Id.IBAN from the original payment instruction BTRLRO22XXX // the BIC of the debtor agent financial instiution of the transaction for which this cancellation request was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAgt.FinInstnId.BIC from the original payment instruction INGBNL2AXXX // the BIC of the creditor agent financial institution of the transaction for which this cancellation request was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAgt.FinInstnId.BIC from the original payment instruction Alan Dutch Schaefer // the name of the creditor of the transaction for which this cancellation request was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Nm from the original payment instruction MX // the country of the creditor of the transaction for which this cancellation request was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.Ctry from the original payment instruction Carretera a Palenque 8 Palenque 29960 // the address of the creditor of the transaction for which this cancellation request was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.PstlAdr.AdrLine from the original payment instruction mYiD1234567890 // the ID number of the debtor of the payment to be cancelled, taken from FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Id.PrvtId.Othr.Id mYpRoPiD1234567890 // the proprietary ID number of the debtor of the payment to be cancelled, taken from FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Id.PrvtId.Othr.SchmeNm.Prtry UKPA // the ID issuer of the debtor of the payment to be cancelled, taken from FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Id.PrvtId.Othr.Issr NL07INGB9227934553 // the IBAN of the creditor of the transaction for which this cancellation request was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAcct.Id.IBAN from the original payment instruction Simon Phoenix // the ultimate creditor, if provided, of the transaction for which this cancellation request was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.UltmtCdtr.Nm from the original payment instruction ``` ## camt.087.001.05 This message is generated when there is a request for value date correction for a payment made either using the [claim value date correction API](https://api.mambu.com/payments-api//#sepa-credit-transfer-inquiries-claimvaluedatecorrection) or via [the UI](/docs/sct-inquiries#initiating-a-claim-for-value-date-correction-camt08700105). ```xml BTRLRO22202112130000000000000000007 // a unique, generated ID for this case BTRLRO22 // the BIC of the bank making the claim for value correction. If the request was initiated by you, this will be the BIC of your institution as provided in Configuration > System Properties > Bank BIC BTRLRO22 // the BIC of the bank who should be responding to the claim. This will typically be the counterparty of the transaction in question 2021-12-13T16:14:30 // the date and time on which the claim for value date correction was made BTRLRO22202112130000000000000000007 // a unique, generated ID for this case BTRLRO22 // the BIC of the financial institution who created the case. If the claim for value date correction was initiated by you, it will the BIC of your bank SCTORD156820211213000000012650 // the unique ID of the original message for which this claim for value date correction was lodged pacs.008.001.02 // the type of message for which this claim for value date correction was lodged. For SEPA Credit Transfers this will be pacs.008.001.02 2021-12-13T14:49:39 // the creation date of the original transaction for which this claim for value date correction was lodged API // the channel through which the original transaction was received. If the transaction was created using Mambu's POST /payments API, the value will be API e2e1234567890-1 // the end-to-end ID, if provided, of the transaction to be corrected. If none was provided, the value of this field will be NOTPROVIDED trxID1234567890-2 // the transaction ID of the transaction to be corrected 46290.42 // the currency and amount of the transaction for which this claim for value date correction was lodged 2021-12-12 // the date on which the original transaction was marked as sent and settled, taken from the original payment instruction 46290.42 // the currency and amount of the original transaction for which this claim for value date correction was lodged, taken from the original payment instruction CLRG // the original settlement method of the transaction for which this claim for value date correction was lodged, taken from the original payment instruction SEPA // the original service level method of the transaction for which this claim for value date correction was lodged, taken from the original payment instruction. For SEPA Credit Transfers, will always have the value SEPA TRF // specifies the means of payment that will be used to move the amount of money. For SEPA this value will only be TRF John Spartan // the ultimate debtor of the transaction for which this claim for value date correction was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction Mike Harrigan // the debtor name of the transaction for which this claim for value date correction was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.Nm from the original payment instruction US // the country of the debtor of the transaction for which this claim for value date correction was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.Ctry from the original payment instruction Santee Street 840 Los Angeles CA 90014 // the address of the debtor of the transaction for which this claim for value date correction was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.AdrLine from the original payment instruction RO10BTRL0000001234567890 // the IBAN of debtor of the transaction for which this claim for value date correction was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAcct.Id.IBAN from the original payment instruction BTRLRO22XXX // the BIC of the debtor agent financial institution of the transaction for which this claim for value date correction was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.DbtrAgt.FinInstnId.BIC from the original payment instruction INGBNL2AXXX // the BIC of the creditor agent financial institution of the transaction for which this claim for value date correction was lodged, taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAgt.FinInstnId.BIC from the original payment instruction Alan Dutch Schaefer // the name of the creditor of the transaction for which this claim for value date correction was lodged, will be taken from the value of FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.Nm from the original payment instruction MX // the country of the creditor of the transaction for which this claim for value date correction was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Dbtr.PstlAdr.Ctry from the original payment instruction Carretera a Palenque 8 Palenque 29960 // the address of the creditor of the transaction for which this claim for value date correction was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.Cdtr.PstlAdr.AdrLine from the original payment instruction NL07INGB9227934553 // the IBAN of the creditor of the transaction for which this claim for value date correction was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.CdtrAcct.Id.IBAN from the original payment instruction Simon Phoenix // the ultimate creditor, if provided, of the transaction for which this claim for value date correction was lodged, taken from the FIToFICstmrCdtTrf.CdtTrfTxInf.UltmtCdtr.Nm from the original payment instruction 2021-12-13 INQR // a code indicating that this is an inquiry The beneficiary is requesting a value date correction // human-readable, generated string instructing the counterparty of the specific claim, in this case, value date correction ``` --- # Introduction URL: https://docs.mambu.com/docs/sepa-credit-transfers/ Single Euro Payments Area (SEPA) credit transfers are generally one-time payments of less than a billion euros from one Euro-denominated account to another, no matter where inside the Eurozone they are. SEPA does not require that transfers are free, but payments are usually free for the end user. ## SEPA credit transfers in Mambu The Mambu Payment Gateway (MPG) works as a middle layer between the outside world of SEPA XML messages and Mambu's API-based architecture. It takes incoming SEPA messages, turns them into transactions in a customer account, and generates SEPA-compliant messages for outgoing payments. The MPG also manages the translation of externally-exposed IBANs to a given Mambu account ID. ## SEPA credit transfers timeline ![sepa-ct-timelines](@site/static/img/support/sepa-ct-timelines.png) :::note In this section, _days_ refers to _banking business days_. Allowances are made for national holidays, weekends, and so on. ::: - **Transfer Initiated**: A customer initiates a transfer from their bank to an account within the eurozone. While the funds are in transit the payer can request the transfer to be cancelled. - **Within one day after initiation**: The funds should be settled in the receiver bank account within one day. - **Within three days of settlement**: If a transfer has arrived but, for example, the bank account does not exist or there are other issues with the data, the receiving back can reject the payment within three days of receipt - **Within 10 days of settlement**: The payer can request a recall for their payment within 10 days of it having settled. Reasons can include duplicate transfers, technical errors, and so forth. - **Within 13 Months of settlement**: In cases of fraud, the payer has up to 13 months to request recall of the payment. In either recall case, the bank receiving the request has 15 days to respond to the request. ## Supported use cases - Processing incoming SEPA credit transfers - Initiating outgoing SEPA credit transfers - Manually rejecting an outgoing payment - Recalling a SEPA credit transfer - Rejecting or accepting SEPA credit transfer recall request - Dispute management, including handling claims of non-receipt, value date corrections and accepting or requesting status updates for ongoing disputes :::warning Please note Mambu recommends that Incoming SEPA Credit Transfer messages should contain **at most 30.000 payments inside a single file**. Submitting files with larger amounts of payments may result in delay of processing. In case the volume of payments is larger and cannot accomodate this number, consider limiting the number of payments that are included in a single file and send multiple, smaller files instead. ::: ## Some things to consider - While not a requirement, we recommend carrying out anti-money laundering (AML) checks for incoming and outgoing payments. - Incoming and outgoing SEPA payments made via the Mambu Payment Gateway will have the associated Mambu transactions enriched with remittance information. In addition to the [Mambu Payments Gateway API documentation](https://api.mambu.com/payments-api/), we recommend reviewing our [Mambu API v2 documentation](https://api.mambu.com), specifically the deposit account [withdrawal](/api/api-v2/deposits_transactions/make-withdrawal) and [deposit](/api/api-v2/deposits_transactions/make-deposit/) operations when planning your integration. --- # SEPA Direct Debit (Creditor flow) URL: https://docs.mambu.com/docs/sepa-direct-debit-creditor-flow/ A total of 36 countries, including all EU member states, are signed up to the Single Euro Payment Area (SEPA) scheme. This scheme facilitates payments among individuals and businesses. While the technical mechanisms for the two types of payer are largely the same, there are big differences in the amount of protection provided for payers, as well as slightly stricter rules on mandate collection, when it comes to business to business payments. Whereas SEPA CORE provides a lot of protection for payers including very generous payment rejection and recall rules, the SEPA B2B scheme is designed more to provide security and stability for the receiver of a payment; once a payment has gone through, that is that, and all reconciliation must be made directly between the two parties and not via the bank processing the payment. Additionally, the timeline for B2B payments is shorter, with payments being submitted one working day before they are due, rather than the up to five days allowed under the SEPA CORE rules. Offsetting this finality of payment, the rules about mandate collection are somewhat stricter in B2B payments with the debtor needing to provide two signed mandates, one to their bank and one to the creditor, ensuring that both parties are in complete agreement with the conditions of the recurring or one-off direct debit before it is transacted. ## Example use case A European business client of your bank purchases goods from a supplier, also located within mainland Europe, and is issued an invoice, in Euros, for the sale with a due date at the first of the following month along with two SEPA Mandates, one to return to the debtor and one to provide to you to confirm and authorise the payment. ## Prerequisites - A transaction channel for SEPA payments must be set up in your Mambu instance - Schedulers for SEPA B2B payments must have been configured in the Mambu Payment Gateway (MPG) - The creditor must have an associated Creditor Identifier - The creditor account in Mambu must be mapped to an IBAN - The debtor bank account must be identified as a business with a valid Creditor Identifier and not a private individual's account ## Steps 1. The creditor provides a signed mandate for the payment, which can be attached to their account in Mambu using the user interface or API. 2. At least one business day before the payment an API call is made to the `/collections` API. By default, a SEPA CORE Direct Debit will be initiated. If you want to initiate a SEPA B2B transaction, make sure that the `localInstrument` field is set to `B2B`. If sending payment details more than one business day before the expected transaction date, the `requestedExecutionDate` or `requestedExecutionTime` fields must be provided in your API call. ```json { "serviceLevel": "SEPA", "localInstrument": "B2B", "instructedAmount": { "amount": "2500", "currency": "EUR" }, "purposeCode": "Invoice #2020-08-534", "requestedExecutionDate": "2020-10-01", "paymentIdentification": { "endToEndIdentification": "202008534abc123def456" }, "creditorName": "Business Client", "creditorAddress": { "buildingNumber": "12", "city": "Madarcelona", "countryCode": "ES", "postalCode": "1BD 2PR", "street": "Main Street" }, "creditorAccount": { "currency": "EUR", "identification": { "iban": "ES3821005222656462935915" } }, "debtorName": "Business Products R Us", "debtorAddress": { "buildingNumber": "86", "city": "Champino", "countryCode": "FR", "postalCode": "24450", "street": "Scarlet Street" }, "debtorAccount": { "currency": "EUR", "identification": { "iban": "FR9714508000503718333273E30" } } } ``` 3. The payment will be created and marked as `PENDING`, appearing in the SEPA DD Pending page of the MPG. 4. If the payment has been requested between 14 and 1 day in advance of the actual requested execution date, on the next time the scheduler is [configured to run](/docs/payments-settings#7-set-incoming-and-outgoing-schedulers-configuration), Mambu will generate a `PACS.003` message and send it through the SEPA Callout. ![SEPA Direct Debit Outgoing Payment](@site/static/img/support/SEPA_Direct_Debit_outgoing_payment.png) 5. On the actual requested execution date, a deposit transaction will be created in Mambu to reflect the amount being transferred. The Mambu transaction will use the SEPA DD transaction channel, contain a reference to the end2end reference ID provided in the `endToEndIdentification` of the request to the `/collections` API and will have been created by the Collections API user created when setting up your MPG integration. 6. As SEPA B2B does not allow for recall of collections after they have been made, there is no possibility for the creditor or their bank to charge back or reverse the collection, although it can be rejected by the debtor for up to two working days after the settlement date, in which case the payment will be marked as rejected in the MPG and a further transaction recorded in the client's account, this time crediting the amount of the original transaction. --- # SEPA Direct Debit (Debtor flows) URL: https://docs.mambu.com/docs/sepa-direct-debit-debtor-flows/ ## Example Use Case A bank client has opened an account with an online music streaming service based in a European country and signed up for a one-year subscription. They have provided their bank details and a signed [sepa mandate](https://www.europeanpaymentscouncil.eu/other/core-sdd-mandate-translations) and are expecting their subscription to start immediately, with the first payment being taken from their account over the next few days and, for the remainder of the contract, to be billed for the same amount on the 15th of every month. ## Prerequisites - Mambu Payment Gateway (MPG) feature must be enabled - Account must be mapped to an iban using our accounts API - Direct Debit SEPA messages must be sent to the same endpoint as for SEPA Credit Transfer. - Bank account must be in Euro denomination ## Steps 1. The online service's bank sends a pacs.003.001.02 Collection Instruction XML file to your bank, which is routed via the clearing system to Mambu's `payments/incoming` API 2. The payment is accepted and logged by the MPG and a transaction is scheduled for the settlement date indicated in the pac.003.001.02 message. At this point the transaction will be visible in the MPG in the € SEPA DD PENDING list of pending SEPA DD transactions (which is sorted by creation date), but not yet recorded as a transaction in the client’s account. 3. On the collection date Mambu creates a transaction from the payer's bank to the creditor bank using the IBAN given in the pacs.003 message. If the transaction fails but retries are configured, the payment status will remain in Pending Settlement and further retries will be executed according to the retry schedule. If the account has sufficient funds, the payment status will change to ‘SETTLED’ and the date recorded. The transaction will then be visible in the incoming SEPA DD page, where you can click for further information, including a full audit trail for the transaction. See the troubleshooting section below for information on what happens if the payment fails, for example, if there is not enough money in the account to cover the transaction. 4. On the 10th of the next month and for the following 10 months, the online service sends another pacs.003 message to the bank with the settlement date indicated as the 15th and steps 2 and 3 are repeated 5. With the final payment a Collection Instruction will be received with `FNAL`, this code indicates that we are dealing with the last transaction in the series. Given the mandate management is not yet supported by Mambu, please keep in mind that the recurrence code will not be validated on our side and the collections will be processed regardless of the value of the code. ![SEPA Direct Debit Positive Flow](@site/static/img/support/sepa_dd_positive_flow.png) ## Troubleshooting The main places where you can troubleshoot any issue with the transaction are the following: ### Mambu Payment Gateway UI 1. You can check the information and status of a specific collection directly from the web app. ![Check the status of a SEPA Direct Debit collection in the UI](@site/static/img/support/SEPA_dd_collection_status.png) 2. [Instructions API](https://api.mambu.com/payments-api/#welcome): this API can be used to retrieve the pacs.003.001.02 information in json format, as well as other metadata like the Collection ID. 3. [Collection Details API](https://api.mambu.com/payments-api/#welcome): based on the generated Collection ID, you can view the details of a collection transaction as well as its status. 4. Collection Order Activity Event Streaming: subscribing to this topic will allow you to be notified on each status change during collection processing. ![Sepa Direct Debit Streaming API Configuration](@site/static/img/support/sepa_dd_notifications.png) --- # Refunding a SEPA Direct Debit URL: https://docs.mambu.com/docs/sepa-direct-debit-refunds/ *Refunds*, also referred to as *chargebacks*, are claims by the debtor for reimbursement of a collection taken from their account. For business-to-consumer (B2C) payments made using SEPA Direct Debit, banks must provide consumers with a no-questions-asked refund of any collection. This refund should be made immediately and it is then up to the bank to reclaim the refunded amount from the merchant. Any dispute resolution must be handled outside of the scheme, typically according to the terms and conditions the consumer agreed to. For business-to-business (B2B) payments, refunds are not guaranteed or provided for in the scheme and so must be handled between the debtor and creditor directly according to their agreed contractual obligations. The SEPA Core Direct Debit scheme recognizes two main types of refund request; refunds for authorized payments, and refunds for unauthorized payments. Each type has its own timeline. For business-to-business payments, the SEPA Direct Debit B2B scheme only provides for refunds for unauthorized payments, that is, fraudulent payments, payments taken after cancelling a mandate, before confirmation of a mandate or taken after a mandate had expired. The scheme considers a mandate to have expired if 36 months have passed since the last payment was taken. Any refund request made for an unauthorized payment, by either a business or a consumer, must be backed by supporting evidence. A refund is linked to a collection order and the SEPA message must contain the original collection order ID. When a refund is made, the credit to the debtor is made immediately and a refund message is generated and picked up by the outgoing Direct Debit scheduler at the next opportunity. ## Acceptable reasons and time limits The SEPA scheme defines acceptable time limits and reasons. A reason code must be supplied when making a refund request. ### Time limits | Instrument | Timeline | |------------|----------| | CORE | Within 8 weeks of settlement, or 13 months in cases of unauthorized transactions | | B2B | Within 13 months of settlement in cases of unauthorized transactions | ### Reason codes | Code | Acceptable usage | Example | |------|--------------------|-----------| | `MD01` | Unauthorized | No mandate, mandate not yet confirmed, fraud or otherwise unauthorized transaction | |`MD06` | Customer request | SEPA Core offers debtors a no-questions-asked refund within eight weeks of settlement | ### Statuses for a refund | Status | Description | |--------|-------------| | `To be refunded` | The refund request has been made and will be processed | | `Refunded` | The payment has been refunded and a refund message generated but not necessarily sent yet | ## Refunding a collection via UI To refund a payment from the UI: 1. Navigate to the payment your customer has requested a refund for in the **SEPA DD Incoming** screen. 2. Select the instrument used (CORE or B2B). 3. Select a **Settlement Date**. 4. Open the transaction. 5. When you are confident that this is the correct transaction, click again to open the detail view. From this view you can choose the appropriate reason for the refund from the drop-down list. 6. Select **Refund payment**. Once the refund request has been processed, the transaction will receive the status `To be refunded`. Once the refund has been successfully completed, in the same detail view you will see the related refund transaction and its current status. The original transaction will receive the status `Refunded` and the related Mambu transaction ID for the refund will be visible in the `Additional information` field as `storno transaction`. ![refunded-sepa-direct-debit](@site/static/img/support/refunded-sepa-direct-debit.png) ## Refunding a collection via API To refund a payment via API you will need to use our [Direct Debit Refund](https://api.mambu.com/payments-api//#sepa-direct-debit-refund) endpoint that takes a `collectionId` as path parameter and a JSON body containing the `reasonCode` for the refund. Acceptable reason codes are listed in [acceptable reasons and time limits](#acceptable-reasons-and-time-limits), any other value with result in an `HTTP 400 error` with the error reason `badReversalReasonCode`. If the operation was successful you will receive an `HTTP 200 ok` response, the refund will be added to the queue, and processed by the SEPA Direct Debit scheduler. You can follow the progress of the refund in the Mambu Payment Gateway UI. When you open the detail view for a refunded payment, the original transaction and linked refund will be shown side by side. --- # Introduction URL: https://docs.mambu.com/docs/sepa-direct-debit/ SEPA Direct Debit has been one of the main ways to transfer funds across the Eurozone since 2016. In contrast to a standard credit transfer, where a payer instructs their bank to send a specified amount to another bank account, a Direct Debit mandate authorises the receiver to collect amounts from a payer's account. The transfer can be one-time only or, more commonly, a recurring transaction, making Direct Debit the ideal scheme for paying off loans or items purchased on credit. The fact that the amount of each payment is not fixed and so can vary from transaction to transaction makes a direct debit scheme perfect for credit cards or telephone bills, which can go up or down each month. Online stores also benefit from the flexibility of Direct Debit, as with a single mandate they are authorised to make withdrawals as customers make purchases at irregular times and of irregular amounts. The SEPA Direct Debit scheme provides a robust dispute mechanism. Individual payers can ask their bank for a refund of any unauthorised payments for up to 13 months and the scheme guarantees debtors a no-questions-asked refund within the first 8 weeks. The scheme also makes use of pre-authorisation, so transactions will not go through if, for example, the debtor does not have sufficient funds in their account to cover the payment, or payment details can not be verified. For business customers the rules are slightly different, with no possibility of recalling a payment and more emphasis being placed on both parties being in full agreement with stricter guidelines on having the correct mandates in place before transferring any money and much shorter timelines. ## SEPA Direct Debit in Mambu Mambu supports processing and executing incoming and outgoing SEPA Direct Debit Collection Instructions made to a client's account, with the resulting transactions being automatically created and all steps logged and auditable through our Mambu Payment Gateway. The below timeline covers the flow for a payment being made by a private individual, meaning it follows the [SEPA CORE rulebook](https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payment-schemes/sepa-direct-debit/sepa-direct-debit-core-rulebook-and). ![Sepa Direct Debit Timeline](@site/static/img/support/SDD_timeline.png) - **Mandate signed** → the customer signs a mandate authorising the receiver to withdraw funds directly from their bank account (**not yet supported by Mambu**) - **Up to 14 days before** transfer date → the receiver sends the payer's bank a collection notice indicating the day on which the transaction should take place and the amount to be credited. During this time the payer can indicate that they do not want the transaction to be processed by rejecting or refusing the transaction - **Up to 5 banking business days** from transfer date → the payer's bank makes the transfer, in the case of funds not being available or technical error they can retry for up to 5 banking business days, after which the transaction is marked as failed and the receiver notified. During this time the receiver can also issue a reversal and refund the payment - **Within 8 weeks** of transaction → the payer can dispute the transaction amount or validity of the mandate and, with no questions asked, instruct their bank to reverse the transaction - **Up to 13 months** from transaction → the payer can dispute the transaction and, if proven to be unjustified, can instruct their bank to reverse the transaction ## Supported use cases - Processing Incoming Direct Debit Payments - Initiating Outgoing Direct Debit Payments - Dispute Management - Reversing or refunding Direct Debit Payments - Blocking some or all Incoming Direct Debits for an Account :::warning Please note Mambu recommends that Incoming SEPA Direct Debit messages should contain **at most 30.000 payments inside a single file**. Submitting files with larger amounts of payments may result in delay of processing. In case the volume of payments is larger and cannot accomodate this number, consider limiting the number of payments that are included in a single file and send multiple, smaller files instead. ::: ## Some things to consider - While accounts can be in any base currency, the transfer must be carried out in Euros, exchange rates should be set up from the account currency to Euros and kept up to date. - Customers can set up notifications related to Direct Debit Processing and execution status through the [Streaming API](/docs/streaming-api) mechanism, by specifying the Collection Order Activity event. ![sepa_dd_notifications](@site/static/img/support/sepa_dd_notifications.png) - Customers can be notified about transactions related to Direct Debit Payments, you can do this in Mambu using [automated email or sms notifications](/docs/automated-email-notifications), for example, triggering a notification on a transactions using the `_direct_debit_sepa_` transaction channel. - Mambu currently supports the flows set out in the [2017 SEPA Direct Debit Core Rulebook](https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payment-schemes/sepa-direct-debit/sepa-direct-debit-core-rulebook-and) which provides for business to consumer use, as well as outgoing business to business payments according to the [SEPA Direct Debit Business to Business rulebook](https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payment-schemes/sepa-direct-debit/sepa-direct-debit-b2b-rulebook-and-implementation). --- # Introduction URL: https://docs.mambu.com/docs/sepa-instant-credit-transfer-introduction/ With the rise of the digital economy, both clients and merchants can buy and sell goods anywhere and at any time, even for purchases that cross national borders. Both parties into these transactions expect the financial institutions working behind the scenes to react in real-time and would consider a system that clocks off at 5pm or doesn't work on weekends to be far behind our modern times. The European Payments Council's SEPA Instant Credit Transfer (SCT Inst) became operational in 2017 to make the Eurozone one of the largest financial markets in which creditors and debtors can make and receive transactions within ten seconds, rather than wait days for settlement and clearance, and be sure that transactions of up to EUR100,000 take place in real time, 24 hours a day and 365 days a year. Financial institutions who signed up and adopted the scheme early have proven that instant payments can be a key differentiator in increasingly heated and far less locked in marketplace, with Deloitte even noting that banks offering instant payments and a user friendly app have seen SCT Inst being used a real alternative to card payments, which, owing to the fee-free nature of SEPA credit transfers, is also a very attractive proposition for merchants who would otherwise have to sacrifice a percentage of their profits to card processing fees. ## SEPA Instant Credit Transfers in Mambu The Mambu Payment Gateway accepts incoming SEPA Instant Credit Transfer messages in XML ISO 20022 format as per the [Europen Payment Council rulebook](https://www.europeanpaymentscouncil.eu/what-we-do/sepa-payment-schemes/sepa-instant-credit-transfer/sepa-instant-credit-transfer-rulebook). Our `/payments/incoming` API endpoint takes care of posting the transactions to a connected Mambu account, optionally going through any defined Anti-Money Laundering (AML) flows you may have set up for your organisation. All this while keeping within the 10 second window the SEPA scheme demands. For more information, see [Incoming Messages](https://api.mambu.com/payments-api//#-incoming-messages) in our API Reference. Just like with standard SEPA Credit Transfers, the transactions are fully auditable in the Mambu Payment Gateway web application. The timelines for Instant Credit Transfers are largely similar to those of standard SEPA payments, the only difference being that rather than allowing for a banking business day for settlement, funds must settle within 10 seconds of the transaction being initiated. The scheme does allow for a 20 second time to respond to allow for periods of high load on banking systems. Additionally, notification of rejected payments, for example, due to the account being closed or suspended, must be made within the same 10 second time-frame. - Transfer Initiated → A client initiates a transfer from their bank to an account within the eurozone. While the funds are in transit the payer can request the transfer to be cancelled. - Within 10 seconds after initiation → The funds should be made available to the receiver. - Within 10 seconds after initiation → If a transfer has been initiated but, for example, the receiving bank account does not exist or there are other issues with the data, the receiving back can reject the payment within 10 seconds of receipt - Within 10 days of settlement → The payer can request a recall for their payment within 10 days of it having settled. Reasons can include duplicate transfers, technical errors, and so forth. - Within 13 months of settlement → In cases of fraud, the payer has up to 13 months to request recall of the payment. In either recall case, the bank receiving the request has 15 banking business days to respond to the request. ## Supported use cases - Processing incoming SEPA Instant Credit Transfers - Automatically rejecting an incoming payment - Initiating and receiving checks via an AML provider ## Some things to consider - You must be signed up to a clearing and settlement mechanism (CSM) that provides support for instant payments. - SEPA Instant Credit Transfers are processed 24 hours a day, 365 days a year, irrespective of any holidays you may have set up for your institution. --- # SEPA Instant Creditor Flows URL: https://docs.mambu.com/docs/sepa-instant-creditor-flows/ Creditor flows represent scenarios where your client is receiving money from a another party, the debtor. ## Example use case A client of another bank (the debtor) makes a SEPA Instant Credit Transfer to a client of your bank (the creditor) to repay them for tickets to a concert they purchased and went to together. ## Prerequisites - Mambu Payment Gateway (MPG) feature must be enabled - Account must be mapped to an IBAN using our accounts API - Bank account must be in Euro denomination - Your nominated clearing and settlement mechanism (CSM) must support instant payments ## Steps 1. The debtor's bank sends a pacs.008 message through the clearing and settlement mechanism, specifying all required details including the amount to be transferred and setting the local instrument code as `INST`. 2. The payment is logged by the Mambu Payment Gateway and validated with first checks being made including that the amount does not exceed the maximum permitted amount of EUR100,000, that the target IBAN is mapped to a Mambu deposit account, and that the current time compared to the timestamp of the payment initiation has not exceeded the cut off time specified in your configuration. 3. The Mambu Payment Gateway posts a positive hold on the debtor account. 4. Upon receiving the confirmation from the Mambu API that the hold was placed successfully, the Mambu Payment Gateway responds with a pacs.002 message with the status `ACCP`. 5. The Mambu Payment Gateway clears the hold and posts a deposit transaction to the creditor account in the amount specified in the SEPA message. --- # SEPA Credit Transfers URL: https://docs.mambu.com/docs/sepa/ SEPA Credit messages are XML files composed of 3 building blocks: 1. **Group Header** - It contains elements such as Message Identification, Creation Date and Time. 2. **Payment Information** - Contains Debtor and Payment Type Information for one or more Transaction Information Blocks. 3. **Transaction Information** It contains elements related to the credit side of the transaction, such as Creditor. ## Supported Flows Mambu supports the following flows and messages in the platform: ![image.png](@site/static/img/support/image%2851%29.png) :::note The Mambu Payment Gateway (MPG is the Mambu Service responsible for generating SEPA compliant messages.) ::: :::note To send messages you will need to configure the callout URL on the MPG UI and to receive messages you will need to use the [incoming message endpoint](#incoming-payment---pacs00800102). ::: *** ### Basic End-to-End Flows ![image.png](@site/static/img/support/image%2875%29.png) :::note Outgoing Payments can also be rejected for a certain number of reasons such as:
    • **Backdate payment** - At the moment MPG doesn’t support this functionality e.g Today is 28.06 and if the user tries to receive an incoming payment on 27.06
    • **Duplicated MsgId** - An outgoing pacs.008 with a same MsgId of one previous message
    • **Unrecognized message format** - The message structure was not as it was expected
    ::: ### Outgoing Payments * * * ## Outgoing payment - pacs.008.001.02 #### Description The Mambu Payment Gateway receives and checks if it has sufficient information to execute a payment instruction and that the instruction fulfils the conditions required by its procedures as to execution of the instruction including the authenticity of the instruction, and the checking of the format of the IBAN and BIC. ### initiatePayment This endpoint generates a new payment in Mambu. The system will then verify if it the payment is an intra- or inter-bank payment. :::warning SEPA Core Service The MPG follows the guidelines for SEPA Core Mandatory subset - EPC Guidelines - thus using messages only containing message elements defined as part of the SEPA Core Mandatory Subset (shaded in yellow in Sepa Rulebook). ::: **Action**: `POST` **Endpoint**: [/v1/payments/](https://api.mambu.com/payments-api//#payments-initiatepayment) **Sample request body** ```json { "instructedAmount": { "currency": "EUR", "amount": "10" }, "creditorAccount": { "currency": "EUR", "identification": { "iban": "RO71INGBGS9EE7TWIGHCXRO8" } }, "creditorName": "Michael", "purposeCode": "BONU", "remittanceInformationUnstructured": "Information about the transfer", "debtorAccount": { "currency": "EUR", "identification": { "iban": "RO68BTRLUAAJ01WQB7ZFEN7I" } }, "debtorName": "John Doe" } ``` :::note Additional Information Other tags can be added to the payment initiation request such as the payment purpose code or the remittance information ::: #### Sample response body **200 - Success - The payment was generated** ```json { "transactionStatus": "RCVD", "paymentId": "28c09684547d49111b0e05d501e15b5f" } ``` **400 - Bad Request - The payment wasn’t generated** ```json Example 1 { "tppMessages": [ { "category": "ERROR", "code": "FORMAT_ERROR", "path": "initiatePayment.arg0.instructedAmount.currency", "text": "instructedAmount.currency size must be between 3 and 3" }, { "category": "ERROR", "code": "FORMAT_ERROR", "path": "initiatePayment.arg0.instructedAmount.currency", "text": "instructedAmount.currency invalid ISO 4217 Alpha 3 currency code" } ] } ``` ```json Example 2 { "tppMessages": [ { "category": "ERROR", "code": "FORMAT_ERROR", "path": "initiatePayment.arg0.instructedAmount.amount", "text": "instructedAmount.amount numeric value out of bounds (<20 digits>.<14 digits> expected)" } ] } ``` :::note IBAN validations Mambu validates the bank code in an IBAN and derives the BIC from the IBAN. Validations on the IBAN structure, control sum and specific country rules are also run. ::: :::info Retry mechanism If the callout to send an outgoing payment is not succefull the MPG will retry to send the data until it gets a successful response without any changes on the message or request. ::: * * * ## Payment status ### paymentDetails The endpoint returns payment information including: - Status - Debtor IBAN - Currency - Amount - Creditor name **Action**: `GET` **Endpoint**: [/v1/payments/``](https://api.mambu.com/payments-api//#payments-paymentdetails) #### Parameters | Name | Value | | --- | --- | |paymentID |The payment ID in MAMBU | #### Sample responses **200 OK** ```json { "transactionStatus": "ACSP", "lastStatusUpdateTimestamp": "2019-06-27T14:11:20Z", "debtorAccount": { "identification": { "iban": "RIU20BTRLJD3GCKBUJF3DET1A" }, "currency": "EUR" }, "instructedAmount": { "currency": "EUR", "amount": "1000" }, "creditorAccount": { "identification": { "iban": "RIU10INGBCBN4EVKBNFJ8YNGT" }, "currency": "EUR" }, "creditorName": "George" } ``` **400 Bad Request** ```json Example 1 { "tppMessages": [ { "category": "ERROR", "code": "SERVICE_INVALID", "path": "paymentId", "text": "Unable to find payment details for payment 2809684547d49208b0e05d501e15b5f" } ] } ``` ## Incoming payment - pacs.008.001.02 ![Screenshot 2019-07-24 at 05.48.31](@site/static/img/support/payments--diagram-sepa-payment-integration-flow.png) Mambu Payment Gateway allows clients to receive funds from external entities through API. ### incomingMessage The endpoint creates a new incoming payment in Mambu. :::warning Validations The MPG validates if the BICs present on the sepa messages are valid. If the insitution BICs on the file are not valid the MPG will reject the file. ::: **Action**: `POST` **Endpoint**: [/v1/payments/incoming](https://api.mambu.com/payments-api//#payments-incomingmessage) **Request Headers** | Name | Value | | --- | --- | | Content Type |application/xml | | Name |Description | | --- | --- | | body *required | Initiate an incoming Payment | **Sample request body** ```xml Message ID 2019-12-23T09:40:13 1 1 2019-12-23 CLRG ST2 INGSMMXXX BTRLRO22 PaymentID PaymentID PaymentID SEPA 1 SLEV Jane Doe ES GFA RO10INGBCBN4EVKBNFJ8YNGT CECAESMMXXX BTRLRO22 John Doe ES V94025590 RO71BTRLV67M9G4XI3IEJ5D2 Incoming Payment ``` #### Sample Responses **202 - Accepted - The payment was generated** ```json { "messageId": "11123137676731217", "messageType": "urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02" } ``` **400 - Bad Request - The payment wasn’t generated** ```json Example 1 { "tppMessages": [ { "category": "ERROR", "code": "FORMAT_ERROR", "path": "initiatePayment.arg0.instructedAmount.currency", "text": "instructedAmount.currency size must be between 3 and 3" }, { "category": "ERROR", "code": "FORMAT_ERROR", "path": "initiatePayment.arg0.instructedAmount.currency", "text": "instructedAmount.currency invalid ISO 4217 Alpha 3 currency code" } ] } ``` ```json Example 2 { "tppMessages": [ { "category": "ERROR", "code": "FORMAT_ERROR", "path": "initiatePayment.arg0.instructedAmount.amount", "text": "instructedAmount.amount numeric value out of bounds (<20 digits>.<14 digits> expected)" } ] } ``` If the payment gets accepted then the status that will be presented in the MPG is **Settled**. ![Screenshot 2019-07-24 at 05.57.30](@site/static/img/support/payments--sepa-incoming-transaction-details.png) Within Mambu UI the client balance is updated with the amount of the incoming payment If for any reason the payment is not accepted then the MPG user will verify that the payment has been rejected. At the same time the user will be able to see that a pacs.004 was returned back on the outgoing section* ![Screenshot 2019-07-24 at 05.58.54](@site/static/img/support/payments--sepa-incoming-transaction-details-3.png) :::note The reasons for an incoming payment to be rejected are:
    • **Backdate payment** - At the moment MPG doesn’t support this functionality e.g Today is 28.06 and if the user tries to receive an incoming payment on 27.06
    • **Duplicated MsgId** - An incoming pacs.008 with a MsgId
    • **Unrecognized message format**
    ::: ### Mambu Payment Gateway Status | Action | From state | To state | Post Conditions | | --- | --- | --- | --- | | Receive payment | | Received | The bulk credit instruction file (pacs.008) is received | | Debulk | Received | Debulked | The bulk file is divided into each individual credit transfer instruction | *** ### Recall a Payment * * * #### Description A recall happens when an Originator Bank requests to cancel a SEPA Credit Transfer. The recall procedure must be submitted by the Originator Bank before 10 Banking Business Days after the execution date of the initial SCT Transaction. A recall procedure can be initiated for the following reasons: * Customer Request (Wrong IBAN or Wrong amount) * Duplicate payment * Technical problems * Fraudulent Credit Transfers :::note Recall Reasons While initiating a Recall request, you can specify the reason for the recall. All valid reject codes applicable are listed for this field. ::: The relevant SEPA messages in this flow and supported by Mambu are: * Camt.056 - Cancelation request (Outgoing and Incoming) * Pacs.004 - Reply positively to a cancelation request (Outgoing and Incoming) * Camt.29 - Reply negatively to a cancelation request (Outgoing and Incoming) :::note Matching original transactions On receiving a positive / negative response for a recall request from beneficiary bank, the system matches the same with the original transaction ::: ## Outgoing payment recall - camt.056.001.01 A Mambu Payment Gateway user can request for a recall by open a payment sent and already Settled on the MPG UI ![image.png](@site/static/img/support/image%287%29.png) On the MPG - outgoing list , find and open a payment with status settled. ![Screenshot 2019-07-24 at 06.00.55](@site/static/img/support/payments--transaction-details.png) After the user clicks to visualise the detail of the payment, the user will be able to initiate a return process for the payment by selecting a return reason and clicking on the cancel button. Bear in mind that the return will only be sent after a second level user approves this request on the pending section. ![Screenshot 2019-07-24 at 06.01.02](@site/static/img/support/payments--outgoing-sepa-transaction-details.png) **Step 4: Payment status is updated to To be Canceled ** **Step 5: 4-eye recall authorization** ![Screenshot 2019-07-24 at 06.01.14](@site/static/img/support/payments--outgoing-payment-recall-authorization.png) In the left menu, MPG users have the section Pending available to manage pending recall to be authorized or denied. After clicking to authorize the payment users are prompted with a successful notification on the authorization. On the payment detail view the MPG user can also track the different stages of a given Payment: ![Screenshot 2019-07-24 at 06.06.48](@site/static/img/support/payments--outgoing-payment-recall-details.png) :::note Outgoing Recall The recall message can be found in the Outgoing section ::: When the payment recall is successful the Payment status is updated to Recall Accepted. If the payment recall is rejected, the payment status is updated to Recall Rejected. In a different scenario if the MPG user does not authorize to proceed with the recall, then the user must click Reject After the user confirms the operation he will be prompted with a successful notification. :::warning Initiate a Recall after the 10th business day Keep in mind that a recall can only be initiated within 10 business days from the date the initial credit transfer was sent . If initiated after the 10th business day the system will return an error and will not allow the user to proceed with the operation. ::: ## Incoming Payment Recall - camt.056.001.01 #### Description The incoming SCT recall process starts when the Mambu Payment Gateway receives a request for recall for an original SCT. If the original SCT can be returned, the MPG user can confirm the return request on the MPG and the system will generate a return message. If the original SCT cannot be returned, or if the customer is not in agreement, the MPG user rejects the request and the system sends a result of investigation. ![image.png](@site/static/img/support/image%288%29.png) **Step 1**: An MPG user can accept or deny a payment recall request open **Step 2**: Initiate an Incoming Recall request through API for a payment received and with status Sent **Step 3**: Open MPG and look for the previous payment **Step 4**: After the schedule is triggered the payment status is updated to To be Canceled rand a new section is shown with a new status Pending **Step 5**: Authorisation - meaning that the Payment recall request is pending authorisation by the beneficiary bank **Step 6**: Open menu Pending to authorize or deny this payment recall request #### Initiate an Incoming Recall request through API The endpoint creates a new incoming recall payment in Mambu. **Action**: `POST` **Endpoint**: [/payments/incoming](https://api.mambu.com/payments-api//#payments-incomingmessage) | Name |Description | | --- | --- | | body *required | Initiate an incoming Recall | **Sample request body** ```xml f57a3f2c544f41ae843f624843c70a02 *** *** 2020-05-26T16:53:16 1 98a8011be00e406999d8822c0a25d4be d3a99efb5a8b45339829b4d620cc73cd pacs.008.001.02 5ad276a2fd674e53981e0ac065a6285c NOTPROVIDED cbc00eddeabf426eb288a81d2edde058 100 2020-05-26 Foo bar DUPL CLRG REP SEPA John Doe *** *** *** BT *** ``` #### Sample responses **202 - Accepted - The payment was generated ** ```json { "messageId": "1112313767631217", "messageType": "urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02" } ``` **400 - Bad Request - The incoming recall wasn’t generated** ```json { "proc": "error", "description":"Incorrect body" } ``` *** ## Outgoing payment return - pacs.004 #### Description The Payment Return message is used to undo a payment previously settled (e.g. Beneficiary deposit account is closed) or to reply positivly to a cancelation request (camt.056) In case the credit is not possible, then the system will automatically generate a sepa message (pacs.004). In this situation the pacs.008 status will be updated to "To be returned" and after the outgoing scheduler is run a pacs.004 is triggered (MS03) However, in case of a cancelation request by the originator bank an ad-hoc investigation must be run (e.g call the originator if the bank can debit his account). If beneficiary bank is allowed to debit beneficiary then a pacs.004 can be send. In this situation the MPG user can authorize the recall on the MPG by going to the pending section and authorizing the request. The system will generate the pacs.004 (status: to be sent) and when the scheduler is triggered the status will be updated to Sent. ## Incoming payment return - pacs.004 #### Description As an originator bank, returns can be received to inform that a return was sent given the situation of the beneficiary bank not being able to credit the beneficiary or to inform about a positive response to a recall request. **Action**: `POST` **Endpoint**: [/payments/incoming](https://api.mambu.com/payments-api//#payments-incomingmessage) | Name |Description | | --- | --- | | body *required | Initiate an incoming Return | **Sample request body** ```xml PositiveResponseID 2019-12-23T09:18:57 1 1 2019-12-23 CLRG ST2 mask2 SCTORD156820191223000000001194 pacs.008.001.02 NOT PROVIDED 31630 1 1 BTRLRO22 AC01 2019-12-23 CLRG SEPA John Doe RO71BTRLV67M9G4XI3IEJ5D2 BTRLRO22 INGBROBUXXX Bruno RO28INGBT26QJ2VR5QYA2COV ``` ### Mambu Payment Gateway Status | Action | From state | To state | Post Conditions | | --- | --- | --- | --- | | Return | Received / Debulked | Returned | Individual credit transfer instruction is returned and corresponding pacs.004 file is generated | | Send | Returned | Sent | Generated pacs.004 file is sent to CSM via MPG callout | ## Outgoing payment return Rejection - camt.029 #### Description This message is used in case of a Return request rejection. In this situation the Mambu Payment Gateway user will reject the recall on the MPG by going to the pending section and authorizing the request. ![image.png](@site/static/img/support/image%2868%29.png) The system will generate the camt.029 (status: to be sent) and when the scheduler is triggered the status of the message is updated to Sent. ![image.png](@site/static/img/support/image%2866%29.png) ## Incoming payment return Rejection - camt.029 ### Description Rejected Cancelations requests can be received to inform that a cancelation (camt.056) was not accepted by the beneficiary bank. **Action**: `POST` **Endpoint**: [/payments/incoming](https://api.mambu.com/payments-api//#payments-incomingmessage) | Name |Description | | --- | --- | | body *required | Initiate an incoming Reject cancelation | **Sample request body** ```xml NegativeResponsetoaRecall BTRLRO22 INGBROBUXXX 2019-11-28T12:27:39 RJCR NegativeResponsetoaRecall ORIGINAL PACS.008 pacs.008.001.02 SCTORD156820191128000000000023 NOTPROVIDED 107 RJCR BTRLRO22 AGNT 30 2019-11-28 CLRG ST2 SEPA test John Doe RO83BTRLY3TSFANS83CS8NHG BTRLRO22 INGBROBUXXX Bruno RO41INGBIJEHFMQA3Y4VY19V ``` ## Get SEPA messages Retrieves the details of existing SEPA messages. **Action**: GET **Endpoint**: [/instructions?network=SEPA&direction=O&messageType=pacs.008](https://api.mambu.com/payments-api//#payments-findsepamessages) #### Parameters | Name | Value | | --- | --- | | Network |The network where the payment was routed e.g SEPA | | Direction |Incoming (I) or Outgoing (O) e.g SEPA | | messageType |Message type to. be retrieved e.g pacs.008 | | dateFrom | Earliest date of SEPA Message you are searching for (`YYYY-MM-DD`) | | dateTo | Last date of SEPA messages you are searching for (`YYYY-MM-DD`) | **Sample response body** ```json { "instructions": [ "FIToFICstmrCdtTrf": { "grpHdr": { "msgId": "SCTORD1568201", "creDtTm": "2019-07-19T08:47:53Z", "nbOfTxs": "1", "ttlIntrBkSttlmAmt": { "value": 100, "ccy": "EUR" "intrBkSttlmDt": "2019-07-19T00:00:00Z", sttlmInf": { "clrSys": { "prtry": "ST2" "instgAgt": { "finInstnId": { "bic": "BTRLRO23" "cdtTrfTxInf": [ "pmtId": { "instrId": "40b1d0c833304e36b9496766734539d", "endToEndId": "NOTPROVIDED", "txId": "188409" "pmtTpInf": { "svcLvl": { "cd": "SEPA" "intrBkSttlmAmt": { "value": 100, "ccy": "EUR" "chrgBr": "SLEV", "dbtr": { "nm": "John Doe" "dbtrAcct": { "id": { "iban": "RO47BTRL9WW43DGA66YOGSFID" "dbtrAgt": { "finInstnId": { "bic": "BTRLRO23" "cdtrAgt": { "finInstnId": { "bic": "LHVBEE23XXx" "cdtr": { "nm": "Jane Doe" "cdtrAcct": { "id": { "iban": "EE297700771000701245" "rmtInf": { "ustrd": "P5471063" "_metadata": { "transactionSn": 58, "transactionStatus": "SENT", "paymentId": "40b1d0c833304e36b9496766783459d" "_metadata": { "bulkSn": 54, "direction": "O", "messageId": "pacs.008", "procstatus": "RELEASED", "transactions": 1 ``` --- # Setting-up a Maturity Period URL: https://docs.mambu.com/docs/setting-up-a-maturity-period/ The Maturity Period is the time during which no withdrawals can be made in a Savings Plan or Fixed deposit account. The duration of the period can be defined in the product's settings and is then manually activated under each account after a first deposit has been made. Only administrators and users with the *Make early withdrawal* permission can make withdrawals during a maturity period. To activate the maturity period: 1. Open the deposit account. 2. On the right hand of the screen, click on **Begin Maturity Period**. 3. Enter the maturity date. 4. Click on **Change Status**. :::note The maturity date determines the end of the Maturity Period, so after this date the accounts won't continue accruing interest and the clients will be able to withdraw their money with the accrued interest. ::: :::warning Only administrators or users with the permission to "Activate Maturity" can begin the maturity period of an account. ::: ![Begin Maturity Period button and pop-up](@site/static/img/support/deposits--begin-maturity-period.png) :::note You can undo this action by going to **More** > **Undo Begin Maturity Period**. ::: ![More drop-down with Undo Begin Maturity Period](@site/static/img/support/deposits--deposit-account-details-5.png) --- # Setting up Shari'ah-based Deposit Products URL: https://docs.mambu.com/docs/setting-up-deposit-products-with-profit-sharing/ Shari'ah-compliant deposit products are designed for financial offerings that adhere to Islamic principles. Instead of earning a fixed interest rate, these products operate on a profit-sharing model, where returns are shared between the customer and the institution based on a pre-agreed ratio. This guide covers the specific settings required to create such a product. For general instructions on all available fields, please refer to our main guide on [Setting Up New Deposit Products](/docs/setting-up-new-deposit-products). :::note It is important to be aware of the following features of Shari'ah deposits: * Base currency only: The profit-sharing feature is currently available only for deposits in your organization's base currency. Multi-currency is not supported. * Permanent product type: The choice between a conventional (interest-bearing) and a Shari'ah-compliant (profit-sharing) product is permanent. Once a product is saved, you cannot convert a conventional product into a Shari'ah-compliant one, or vice-versa. ::: ## Create a Shari'ah-based deposit product 1. Navigate to **Administration** > **Products** > **Deposits** and click **New Deposit Product**. 2. In the **Creating a New Deposit Product** screen, select the **Product Category** drop-down and choose from the following list: **Shari'ah-based Personal Deposit**, **Shari'ah-based Business Deposits**, **Shari'ah-based Daily Banking Accounts**, and **Shari'ah-based Business Banking Accounts** with **Profit Sharing: Yes**. ![Product category](/img/support/shariah-deposit-product-category.png) 3. Select the **Product Type** drop-down and choose from the following list: **Current Account**, **Savings Account**. ![Product type](/img/support/shariah-product-type.png) 3. Select whether to **Apply withholding taxes** in **Profit Settings** 4. Choose **Accounting Rules**. More information about it check in "Islamic Banking Accounting". 5. Choose **Technical Overdraft**, if it is needed. Shari'ah based deposit product will be marked with **Calculation Method: Profit sharing** and this parameter will be reflected under each account created in this product. ![Calculation method profit sharing](/img/support/calculation-method-profit-sharing.png) --- # Setting Up New Deposit Products URL: https://docs.mambu.com/docs/setting-up-new-deposit-products/ A *deposit product* allows you to set up in advance the parameters for a type of deposit that you wish to regularly offer. Deposit products are flexible and highly-customizable templates for creating individual deposit accounts. Creating deposit products allows you to categorize, advertize, sort, and compare deposit types using easy-to-recognize names that your customers can quickly understand. For example, you may wish to offer a *Junior Deposit* that features a particular interest rate and uses a particular pattern to generate IDs. To do so, you may create a corresponding deposit product and set your desired terms. This makes it quick and easy to create the actual individual deposit accounts. You can also [compare the different products' performance](/docs/management-reports#earnings-report) and identify the most successful products as well as those that need to be modified to achieve your goals. For more information, see [Managing Deposit Products](/docs/managing-deposit-products) and [Linking Products to Accounting](/docs/linking-products-to-accounting#for-savings--deposit-accounts). ## Deposit products vs. Deposit accounts All deposit accounts are associated with deposit products. For that reason, the terms and constraints you define when creating a deposit product will apply to all of the deposit accounts created using that product. However, some attributes can be changed when creating a new account from a product. These include fields like **Maximum Withdrawal** and **Minimum Deposit** amounts, **Overdraft Limits** and **Overdraft Terms**, depending on the type of deposit product being used to create a deposit account. ![Relationship between a deposit product and a deposit account](@site/static/img/support/deposit-products-deposit-accounts.png) ## Creating a new deposit product To create a new product: 1. On the main menu, go to **Administration** > **Products** > **Deposits**. 2. In the bottom-right corner, select **New Deposit Product**. 3. Enter all the required information. (We will cover all the configuration options in depth.) 4. Select **Save Product**. ![Administration - Products - Deposits. All defined Deposits products will be found here. The New Deposit Product button is highlighted](@site/static/img/support/create-new-deposit-product.png) After saving the product you can click on **Show deactivated products** to view all activated and deactivated products. You can later activate a product from the **Actions** dropdown list. ![Show deactivated products option checked.](@site/static/img/support/show-deactivated-deposit-products.png) ## Filling out the form ### Product name Enter a relevant product name. The new product name should be easily recognizable or associated with the deposit's purpose so that staff members or other users dealing with products can easily identify it. ### Product ID The product ID is a mandatory and unique alphanumeric code you give your products, allowing them to be identified in the database. Enter an ID between 1 and 16 characters. ![Creating a new deposit product form with id field mandatory and needs to be between 1 and 16 characters long](@site/static/img/support/deposit-product-id.png) ### Product category vs product type The *product category* is a label that helps us better understand how your product is used so we can provide better service and address the specific needs of your use cases, whereas the *product type* determines the set of features available in the configuration. To understand which category goes with which type, please see the following table:
    Product Groups Product Categories Product Types
    Current account Savings account Savings plan Fixed deposit
    Stored Value Accounts Stored Value Accounts Yes No No No
    Consumer Deposits Daily Banking Yes No No No
    Personal Deposits No Yes Yes Yes
    Business Deposits Business Banking Yes No No No
    Business Deposits No Yes Yes Yes
    :::note The **Funding account** product type is used to enable the funding of peer-to-peer (P2P) lending which we don't support anymore. If you select the **Uncategorized** product category, you can select any product type. ::: #### Deposit product categories The product category, or label, helps us better understand how your product is used so we can provide better service and address the specific needs of your use cases. You must assign categories to all of your deposit products. If your product falls under no specific category, select **Uncategorized**. ![Deposit product categories: personal deposit, business deposit, daily banking accounts, business banking accounts, stored value accounts and uncategorized](@site/static/img/support/deposit-product-categories%281%29.png) To set the product category for a deposit product, choose from: * **Stored Value Accounts**: Transactional accounts which support digital wallets, prepaid or stored value cards. * **Daily Banking Accounts**: Transactional accounts with typical banking capabilities, such as debit or credit cards, for personal use. * **Personal Deposit**: Savings accounts, term deposits, and similar products for individuals. * **Business Banking Accounts**: Transactional accounts with typical banking capabilities, such as debit or credit cards, for business use. * **Business Deposit**: Savings accounts, term deposits, and similar products for businesses. * **Uncategorized**: Accounts that fall under no specific category, such as settlement accounts for loans, nostro, and technical accounts. If you select **Uncategorized**, we recommend you to fill in the product description and add the use case of the product. Product category is included as a column in all product views, and can be used as a **column** and **sorting filter** in Custom Views. ![Deposit product category filter for custom views](@site/static/img/support/Deposit%20Product%20Category%20filter%20for%20Custom%20Views.png) #### Deposit product types Mambu supports five types of deposit products: * **Current Account**: A regular savings product, but that allows for [Overdrafts](/docs/overdraft-products). Choosing this option will allow account balances to go negative up to a certain defined limit. * **Savings Account**: Allows you to create accounts where clients can make deposits and withdrawals when they wish. The interest is posted at the frequency you choose and accrued over time. It doesn't allow overdrafts. * **Fixed Deposit**: As the name suggests, fixed deposits have a fixed term after which they should be withdrawn or closed. With this type of product, clients are able to make deposits until the minimum opening balance has been reached. At this point, you can begin the maturity period, during which they will be unable to deposit, but will be able to withdraw. Before the maturity date, you have the option to undo maturity. * **Savings Plan**: Uses a maturity period like fixed deposits, but once the minimum opening balance has been reached, they will still be able to make deposits, even during the maturity period itself. However, they will no longer be able to make deposits once the maturity period has ended. * **Funding Account**: Used to enable the funding of peer-to-peer (P2P) lending. ![Deposit product types, like Current Account, Savings Account, Fixed Deposit, Savings Plan, Funding Account.](@site/static/img/support/deposits--deposit-product-creation-form.png) ### Product state Select the **Active** checkbox under **State** if you would like to make the product available as soon as it is created. ### Product description The description provides more detailed information about the product and is visible under the product's overview. Other Mambu users can see this information for reference when creating new accounts using this product so you can include any relevant information or refer to any other relevant documents the customers may need. ### Product availability Product availability controls: * whether the product is available to Clients, [Groups](/docs/types-of-loan-groups#pure-groups), or [Groups (solidarity)](/docs/types-of-loan-groups#solidarity-groups), and * which branches in your organization can offer it. To specify individual branches, uncheck the box next to **All Branches** and the **Branch** field will display. Click in the **Branch** field to select from a list of branches. To filter results, you may begin typing the name of a branch. To remove a branch from the list, click on the red delete icon to the right of the branch name. ![Product availability section with checkbox for All branches unchecked and an example branch displayed with red delete icon](@site/static/img/support/deposits--product-availability.png) When an account is created for a client, group or branch, Mambu will only allow you to select compatible products from the dropdown list. ### New account settings ID settings allows you to customize the IDs generated for all deposit accounts which will later be created under this product. You may either choose a random pattern or incremental numbers for your account IDs. #### Random pattern ![New accounts settings random pattern](@site/static/img/support/new-deposit-account-settings-random.png) #### Incremental number Some organizations may prefer to use incrementing, sequential ID numbers that begin with a specified number. :::warning While incremental ID assignment is permitted in Mambu, it can cause bottlenecks if large numbers of accounts are created. Random ID assignment is recommended for most organizations due to the cloud-native, horizontal scalability of Mambu. ::: To configure incremental IDs, select the **Incremental Number** option from the dropdown and enter the number you want the sequence to start from. Letters may not be used. ![New accounts settings incremental number](@site/static/img/support/new-deposit-account-settings.png) ### Currencies Mambu allows defining deposit products in various currencies, including cryptocurrencies and performing transactions on the accounts in the selected currency. Your customers have the flexibility to buy, sell and hold cryptocurrencies into any Mambu supported deposit account. You can manage both Fiat and cryptocurrencies, support new currencies as the market shifts, and customise transactions based on your own use cases. In order to support deposit accounts in different currencies, you must add the currency under **Administration** > **Financial Setup** > **Currency** and set the exchange rate. For more information, go to [Currencies](/docs/currencies). ### Interest rate Select the **Interest paid into account** checkbox if you want your product to pay interest. ![Interest Rate screen with options to be set for the interest rate](@site/static/img/support/deposits--interest-rate-configuration-3.png) #### Interest rate terms Mambu supports several types of interest terms: * **Fixed**: The interest rate remains the same regardless of the account balance or age. With fixed interest, you can specify the upper and lower limits for the interest rate, as well as a default rate. When creating deposit accounts using this product, you will see the default rate pre-filled into the **Interest Rate** field; however any number between the minimum and the maximum values can be entered. * **Index**: The interest rate is tied to a specific benchmark with rate changes based on the movement of the benchmark. The actual rate offered to the end-customer is a sum of the benchmark or index and a positive interest spread, the spread coming from the **Rate sources** defined in the **Administration** tab of the Mambu UI. * **Tiered per Balance**: Usually used in savings accounts that pay interest at increasingly higher rates as the account balance increases. Each tier consists of a range of account balances and interest rates earned by customers who fall within that range. For example: * the first tier may include balances of USD0 to USD5,000 and pay 1% interest. * the second tier may include balances of USD5,000.01 to USD10,000 and pay 3% interest. * the third tier may include balances of USD10,000.01 to USD25,000 and pay 5% interest. ![Interest rates section showing the 3 tiers described above](@site/static/img/support/deposits--interest-rate-terms.png) Interest is applied on the total deposit balance, according to the respective balance tier. Any amounts exceeding the upper limit of the last tier will still only earn the highest tier amount of interest. So, from our example, an account with a balance of USD50,000 will still earn interest at a rate of 5%. Calculation example: ![Screen Shot 2018-11-13 at 14.37.21.png](@site/static/img/support/deposits--interest-calculation-summary.png) * **Tiered per Period**: With this option, you can select a time period for each tier in which an associated interest rate percentage will be applied according to the age of the deposit account. When interest is accrued on the account, Mambu will determine the interest rate from the tier that matches the age of the account. ![Interest Rate Tiers table showing interest rates increasing from 1% to 3% to 5% after 1, 30, and 60 days, respectively](@site/static/img/support/deposits--interest-rate-tiers.png) * **Tiered per Bands**: This option is appropriate for products that pay or charge different interest rates for each tier or for each specific portion of the balance on an account. **Example** The first band may include balances from USD0 to USD25,000 with 3% interest. The second band may include balances from USD25,000.01 to USD100,000 and charge -1% interest for the balance portion that exceeds USD25,000. The third band may include balances above USD100,000.01 and charge -3% interest for the balance portion that exceeds USD100,000. Interest is applied on the deposit balance portion according to the respective tier. If the account balance is USD150,000: * the balance portion with 3% interest rate is USD25,000 * the balance portion used for -1% interest calculation is USD75,000 * the balance portion used for -3% interest calculation is USD50,000 #### How is the interest rate charged? Use this setting to specify how interest rate is determined. Available options include: % per year, % per month, % per 4 weeks, % per week, and % per X days. ![How is the interest rate charged? drop-down menu with options](@site/static/img/support/deposits--interest-rate-charging-frequency.png) #### What account balance is used for calculations? Deposits and withdrawals on an account will cause its balance to go up or down between two postings of interest. As such, you can choose to calculate interest based on the minimum daily balance, average daily balance, or end of day balance. ![What Account Balance is Used for Calculations? dropdown with options](@site/static/img/support/deposits--account-balance-calculation-method.png) For more information about how the different options affect the interest calculation, see [Interest Calculation Methods in Deposit Accounts](/docs/interest-calculation-methods-in-deposit-accounts). #### When is the interest paid into the account? Use this setting to specify how often the interest is posted into the account. Options include: * On the first day of every month * Every day * Every week * Every other week * Every month * Every three months * Every six months * Every year :::note The every week, every other week, every month, every three months, every six months, and every year options are strictly related to the activation date of the account. An exception to this is when, for example, the account is activated on the 31st of January and you select **Every month**, then the interest will be paid on the 28th of every coming month. ::: Interest can also be added on fixed dates. If you choose **On Fixed Dates**, you must specify the date of the month for each of the 12 months of the year. Click the green plus icon to add another month. For *Fixed deposit* and *Savings plan* product types, you can choose another option, which is also the default option, **On account maturity**. ![options for when the interest can be paid into the account](@site/static/img/support/When-is-the-interest-paid-into-the-account.png) :::note With the **When is the Interest Paid Into the Account?** setting, you also define when you wish to apply negative interest on Overdraft accounts. ::: #### Days in year Depending on your internal practices, you may calculate interest over 365 or 360 days in a year. Given that interest accrues daily during a deposit's lifetime, the interest due for any deposit depends on the number of days in the month and is determined by the difference in the number of days between the last deposit and the current one. In a 360-day year, every month is considered as having 30 days. The 365 days option takes the actual number of days in each month into account. ![Days in Year drop down with options](@site/static/img/support/days-in%20year.png) #### Withholding taxes It is a regulatory requirement in many countries that organizations offering deposit accounts have to pay taxes on the interest generated by those accounts and paid to clients. These are generally called withholding taxes because they are deducted from the interest paid to the client. To enable withholding taxes, select the **Apply withholding taxes** checkbox under the **Interest Rate** section. ![Apply withholding taxes checkbox](@site/static/img/support/deposits--deposit-product-configuration-interest-and-taxes.png) Apply withholding taxes can be enabled only when: * The **Interest paid into account** checkbox is selected. * At least one withholding tax rate source is defined under **Administration** > **Rates**. For more information, see [Customizing Index Interest Rates & Tax Rates](/docs/customizing-index-rates). * The interest calculation method with positive interest rate is selected. Once the withholding taxes option is enabled, the actual applicable tax will have to be specified at account opening. For more information, see [Creating a Deposit Account](/docs/creating-a-deposit-account). After interest is applied on the account, Mambu will post a withholding tax transaction on the account, that will subtract the tax percentage of the applied interest from the account balance. :::warning This option can be disabled even if there are accounts opened in the product. If taxes are disabled, new accounts won't have applicable taxes, but the old accounts will retain them. If the product has accounting enabled, then a "Taxes Payable" liability GL account has to be linked and will be used for booking the amount of taxes withheld and for the government. The tax percent, source name, and amount are available as placeholders in your contracts, receipts, and templates. ::: ### Deposits and withdrawals When you make a *deposit*, you add money to an account, and when you make a *withdrawal*, you subtract money from an account. #### Recommended deposit amount In *Fixed Deposits* and *Savings Plans* products, you can determine if there should be a recommended deposit. The amount you enter here only serves as a guideline and not as a constraint. The client will still be able to make deposits that fall under or above this value. :::note You can also define a [maximum deposit balance](/docs/maximum-deposit-account-balance) at the account level. ::: #### Maximum withdrawal amount You can determines an exact value beyond which the client can't withdraw money in a single transaction. ![Maximum withdrawal amount](@site/static/img/support/deposits--deposits-and-withdrawals-configuration.png) ### Opening balance In *Fixed Deposit* products, you can determine a minimum amount that clients must deposit before the maturity period begins. :::note This is a mandatory field, but you can always enter `0`, in which case the maturity period can begin with the first deposit transaction. ::: ![Opening Balance section with Default opening Balance, Min Opening Balance and Max Opening Balance fields.](@site/static/img/support/deposits--opening-balance-configuration.png) ### Term length In Fixed Deposits and Savings Plans products, you can define the period of time between the account opening and the maturity date, in which the client cannot withdraw money. To define the term length, enter the default, minimum and maximum values, and choose the time unit from the dropdown: **days**, **weeks**, or **months**. During the term length you cannot make any withdrawals unless you are an administrator or you have the *Make early withdrawal* permission. ![Term Length with Default Term Length, Min Term Length, Max Term Length and time unit Days, Weeks, Months](@site/static/img/support/deposits--term-length-configuration.png) ### Internal controls The internal controls section allows you to define a few internal controls for the deposit product. #### Automatically setting accounts as Dormant You may choose to automatically set accounts as Dormant after a number of days, where there has been no financial activity on that account other than posting of interest. Funds can be claimed by the owner or beneficiary at any time even if the account is in a Dormant state. To enable this option, select the **Automatically set accounts as Dormant** checkbox. One advantage of using this option is that it reduces the risk of incorrect reports and it helps you select the clients that are active in the system but with no activity on their accounts and then decide a course of action. :::note This option is available for all types of deposit products. However, the system will not set an account to Dormant if it has a maturity date (Fixed deposits and Savings Plan products). ::: #### Allowing accounts to be used for Offset You may choose to allow accounts created under this product to be used for Offset purposes. This way, deposit accounts are linked to loan accounts, similar to settlement accounts. The balance on the Offset deposit account is offset against the outstanding principal of the loan for interest calculation purposes. When calculating interest for a Dynamic Term loan account with the Offset deposit account enabled, Mambu will deduct the balance on the offset deposit account from the outstanding principal of the loan account before multiplying by the interest rate, instead of multiplying the interest rate directly with the outstanding principal balance of the loan. For more information, see [Redraw and Offset Settings](/docs/redraw-facility-and-offset-loans). To enable this option select, the **Allow accounts to be used for Offset** checkbox. #### Arbitrary fees These are fees which can be applied manually to the accounts at any point during its lifetime and with any given amount. To activate arbitrary fees, select the **Allow Arbitrary Fees** checkbox. ![Arbitrary Fees check box](@site/static/img/support/deposits--product-fees.png) :::note Arbitrary fees can be applied on an ad hoc basis. However, if you apply these kind of fees, you will not be able to separate accounting or reporting based on the fee type. Moreover when going through an audit retrieving the reason for fee application will be more difficult. We strongly recommend creating and applying manual fees for each scenario instead. ::: #### Manual fees These are fees, for which you already know the amount you want to apply. To set up a manual fee, select **Add Fee** > enter the name and the amount of the fee. ![Add Fee button and Manual fee screen](@site/static/img/support/deposits--product-fees-configuration-3.png) #### Monthly fees These are fees that are automatically applied to the accounts after being set up in the deposit product. To define monthly fees: 1. In the **Product Fees** section of the **Creating a New Deposit Product** form, on the bottom-right corner, select **Add Fee**. 2. Under **Type**, choose **Monthly Fee**. 3. Enter the amount. 4. Choose the method for calculating the day when the fee will be applied. See an example in the following table. 5. Save. ![Monthly Fee with Apply Date Method options](@site/static/img/support/deposits--product-fees-configuration.png) |Account Activation Date|Monthly from Activation|First Day of Every Month| |--------------------------------|--------------------------------|--------------------------------| |**1st October**|First fee →**1st November**
    Fees applied **1st** of each subsequent month|First fee →**1st November**
    Fees applied **1st** of each subsequent month| |**16th October**|First fee →**16th November**
    Fees applied **16th** of each subsequent month|First fee →**1st November**
    Fees applied **1st** of each subsequent month| |**31st October**|First fee →**30th November**
    Fees applied **last day** of each subsequent month (for February, 28th or 29th)|First fee →**1st November**
    Fees applied **1st** of each subsequent month| For more information about how to apply or adjust fees, see [Managing Fees in Deposit Accounts](/docs/managing-fees-in-deposit-accounts). ::: ### Accounting rules If you want to link your deposit products to accounting, you must [Enable accounting](/docs/linking-products-to-accounting) and then select the appropriate GL account for each action. ### Custom fields If you have configured custom field definitions for your deposit products, you'll have them listed and grouped by custom field set at the very end of the **Creating a new deposit** form. Once the product is created, the custom field values will show up at the bottom of the deposit product overview page. For more information, see [Custom Fields](/docs/custom-fields). --- # Setting Up New Loan Products URL: https://docs.mambu.com/docs/setting-up-new-loan-products/ A *loan product* allows you to set up in advance the parameters for a type of loan that you wish to regularly offer. Loan products are flexible and highly-customizable templates for creating individual loans. Creating loan products allows you to categorize, advertize, sort, and compare loan types using easy-to-recognize names that your customers can quickly understand. For example, you may wish to offer a *Payday Loan* that features a particular interest rate and uses a particular pattern to generate IDs. To do so, you may create a corresponding loan product and set your desired terms. This makes it quick and easy to create the actual individual loans. ´ You can also [compare the different products' performance](/docs/management-reports#earnings-report) and identify the most successful products as well as those that need to be modified to achieve your goals. For more information, see [Managing Loan Products](/docs/managing-loan-products) and [Linking Products to Accounting](/docs/linking-products-to-accounting). ## Loan products vs. Loan accounts All loan accounts are associated with loan products. For that reason, the terms and constraints you define when creating a loan product will apply to all of the loan accounts created using that product. However, some attributes can be changed when creating a new account from a product. These may include loan amount constraints or interest rate constraints, depending on the type of loan product being used to create a loan account. ![creating_new_loan_product_product_account_relationship](@site/static/img/support/creating_new_loan_product_product_account_relationship.png) ## Create a new loan product To create a new loan product: 1. On the main menu, go to **Administration** > **Products** > **Loans**. 2. In the bottom-right corner, select **New Loan Product**. 3. Enter all the required information. (We will cover all the configuration options in depth below.) 4. Select **Save Product**. ![Administration view where Loans and Deposits products are displayed](@site/static/img/support/loans--loan-products-list-3.png) After saving the product, you can click on **Show deactivated products** to view all activated and deactivated products. You can later activate a product from the **Actions** dropdown list. ![Show deactivated products option checked.](@site/static/img/support/loans--loan-products-list.png) ## Filling out the form ### Product name Enter a relevant product name. The new product name should be easily recognizable or associated to the loan's purpose so that staff members or other users dealing with products can easily identify it. ### Product ID The product ID is a mandatory and unique alphanumeric code you give your products, allowing them to be identified in the database. ### Product category vs product type The *product category* is a label that helps us better understand how your product is used so we can provide better service and address the specific needs of your use cases, whereas the*product type* determines the set of features available in the configuration. To understand which category goes with which product type so that your products can be accurately labeled, please see the following table:
    Product Categories Product Types
    Fixed Term Loan Dynamic Term Loan Interest-Free Loan Tranched Loan Revolving Credit
    Personal Lending Yes Yes Yes Yes Yes
    Purchase Financing Yes Yes Yes No Yes
    Retail Mortgages No Yes No Yes No
    SME Lending Yes Yes Yes Yes Yes
    Commercial No Yes No No No
    :::note The product type is not dependent on the product category. Linking product types and categories helps to set up good labels for your products. ::: ### Loan product categories The product category, or label, helps us better understand how your product is used so we can provide better service and address the specific needs of your use cases. You must assign categories to all of your products. If your product falls under no specific category, select **Uncategorized**. ![Creating a New Loan Product form with the available product categories, personal lending, purchase financing, retail mortgages, SME lending, commercial, and uncategorized](@site/static/img/support/loan-produc-categories.png) To set the product category for a loan product, choose from: * **Personal Lending**: Personal loans for individuals, including vehicle loans, payday loans, and so on. * **Purchase Financing**: Financing for retail and e-commerce purchases. * **Retail Mortgages**: Non-commercial real estate loans for individuals. * **SME Lending**: Loans to small and medium enterprise (SME) customers for working capital. * **Commercial**: Complex loans for larger corporations. * **Uncategorized**: Accounts that fall under no specific category, such as nostro and technical accounts. If you select **Uncategorized**, we recommend you to fill in the product description and add the use case of the product. Product category is included as a column in all product views, and can be used as a **column** and **sorting filter** in Custom Views. ![Product Category filter Custom Views](@site/static/img/support/Product%20Category%20filter%20Custom%20Views.png) #### Loan product types Mambu supports five types of loan products: * **Fixed Term Loan**: Applies fixed interest for the lifetime of an account. The interest due is calculated when the account is opened, and does not change if a customer over- or underpays. * **Dynamic Term Loan**: Interest is dynamically recalculated. * **Interest-Free Loan**: No interest is charged. For example, this product type is often used by banks offering Sharia-compliant products. * **Tranched Loan**: Allows disbursing a loan over multiple tranches instead of entirely up-front. For instance, if a USD5000 loan is approved, you may disburse USD2000 now and USD3000 later in a two-tranched loan. * **Revolving Credit**: Allows multiple disbursements and repayments on the account. It has a payment plan associated with it, in which some amount of principal and interest may be paid. See also [Loans for Groups](/docs/types-of-loan-groups). ### Product state Select the **Active** checkbox under **State** if you would like to make the product available as soon as it is created. ### Product description The product description provides more detailed information about the product and is visible under the product's overview. Other Mambu users can see this information for reference when creating new accounts using this product, so you can include any relevant information or refer to any other relevant documents the customers may need. ![Loan Product description at loan product creation.](@site/static/img/support/loans--product-description.png) ### Product availability Product availability controls: * whether the product is available to Clients, [Groups](/docs/types-of-loan-groups#pure-groups), or [Groups (solidarity)](/docs/types-of-loan-groups#solidarity-groups), and * which branches in your organization can offer it. To specify individual branches, uncheck the box next to **All Branches** and the **Branch** field will display. Click in the **Branch** field to select from a list of branches. To filter results, you may begin typing the name of a branch. To remove a branch from the list, click on the red delete icon to the right of the branch name. ![Product Availability section with Clients, Groups, Groups (Solidarity) and All Branches options](@site/static/img/support/loans--product-availability.png) When an account is created for a client, group, or branch, Mambu will only allow you to select compatible products from the dropdown list. ### New account settings ID settings allows you to customize the IDs generated for all loan accounts created under this product. You may choose either a random pattern or incremental numbers for your account IDs. #### Random pattern ![New Account Settings with ID Type set to Random Pattern](@site/static/img/support/loans--new-account-settings-3.png) #### Incremental number Some organizations may prefer to use incrementing, sequential ID numbers that begin with a specified number. :::warning While incremental ID assignment is permitted in Mambu, it can cause bottlenecks if large numbers of accounts are created. Random ID assignment is recommended for most organizations due to the cloud-native, horizontal scalability of Mambu. ::: To configure incremental IDs, select the **Incremental Number** option from the dropdown and enter the number you want the sequence to start from. Letters may not be used. ![New Account Settings with ID Type set to Incremental Number](@site/static/img/support/loans--new-account-settings.png) #### Initial account state Additionally, you can choose between two default initial states when a new Loan account is created under a given product: **Pending Approval** or **Partial Application**. For more information on the initial account states, please see the article [Loan Accounts' Life Cycle and States](/docs/loan-account-life-cycle-and-states). ### Currencies Mambu allows defining loan products in various currencies and disbursing loans and collecting repayments on the accounts in the selected currency. In order to support loan accounts in different currencies, you must add the currency under **Administration** > **Financial Setup** > **Currency** and set the exchange rate. For more information, go to [Currencies](/docs/currencies). ### Loan amount The amount limits set here define the constraints applicable when a user creates a new loan account using this product. Only loan amounts that fall within the minimum/maximum range defined at the product level will be accepted for client loan accounts. The **Default Amount** is the loan amount populated by default whenever a user creates a new loan account. These fields may be left empty to configure a product default with no set limits. ![Loan Amount section with Default, Min and Max amounts.](@site/static/img/support/loans--loan-amount-configuration.png) #### Accounts managed under credit arrangements You may configure accounts created for this product to be managed as part of a line of credit or not. In the **Accounts Managed under Credit Arrangement** field, you will find the following options: * **Optional**: (default) Accounts may be managed as part of a credit arrangement or line of credit, but it’s not required to have a line of credit extended in order to open an account. * **Required**: Accounts cannot be approved if they are not associated with an existing credit arrangement. * **No**: Accounts may not be managed under credit arrangements. For more information, see [Creating a New Credit Arrangement](/docs/creating-a-new-credit-arrangement). ### Tranches For **Tranched Loan** products, you can specify the maximum number of tranches in which the loan amount can be disbursed. The number of tranches for a given loan account must be specified when you create it. ![Tranches section with Max Tranches text area](@site/static/img/support/loans--tranches-configuration.png) ### Interest rate Depending on the Loan Product type you have selected, you can choose from up to three available methods for calculating interest as indicated in the table below. For **Interest Free** loans, there are no options available. |Type|
    Flat
    |
    Declining Balance
    |
    Declining Balance
    (Equal Installments)
    | |------|-----|-------------------------|-------------------------------------------------------| |**Fixed Term**|
    ✔
    |
    ✔
    |
    ✔
    | |**Dynamic Term**||
    ✔
    |
    ✔
    | |**Tranched**||
    ✔
    || |**Revolving Credit**||
    ✔
    || For more information on each method, see [Interest Calculation Methods in Loans](/docs/interest-calculation-methods-in-loans). :::note Interest for all the loan accounts created under a product is calculated using the same method. ::: #### Accrued interest posting frequency Use this option to specify when accrued interest is applied in the account: * **On Disbursement**: All due interest for the total duration and amount of the loan is accrued and applied in the account up front on the disbursement date. * **On Repayment**: Interest is applied in the account on the installment's due date. If you select **On Repayment** for a **Fixed Term Loan**, you will be able to select the option to **Accrue Interest After Maturity**. ![Option to accrue interest after maturity](@site/static/img/support/accrue-interest-after-maturity-option.png) When this option is enabled, loans in arrears will continue to accrue interest after the fixed maturity period. ![interest accrual after maturity for loans in arrears](@site/static/img/support/interest-accrued-for-loans-in-arrears-after-maturity.png) :::warning Interest accrued after a loan has matured is not automatically applied. It must be applied manually by going to **More** > **Apply Accrued Interest**. An extra installment will be added to the repayment schedule for the currently-accrued amount. ::: Other available options will depend on the product type selected. #### Interest type Select the interest type from the dropdown. For a detailed description of each interest type, go to [Interest Types](/docs/interest-types). #### How is the interest rate charged? Choose the time period for which the interest rate should be charged. Available options include % per year, % per month, % per 4 weeks, % per week, and % per day. #### Define the interest rate To set the interest rate for the new product, select how it is charged and enter the **default**, **minimum** and **maximum** values. ![Interest Rate section at Product Level and Account Terms section at Account Level](@site/static/img/support/loans--interest-rate-configuration.png) :::warning If you change the calculation method in the product at a later date, all accounts created **before** the change will **keep the original method** for calculating interest. Only loan accounts created **after** the product has been edited will use the new calculation method. ::: #### Calculating interest for Revolving Credit For **Revolving Credit** loan products, you can select whether to calculate interest using the **Principal Only**, as is often the case in business loans, or based on **Principal and Interest**, as is common for credit cards. #### Days in year Depending on your internal practices, you may calculate interest over 365 or 360 days in a year. Given that interest accrues daily during a loan's lifetime, the interest due for any loan depends on the number of days in the month and is determined by the difference in the number of days between the last repayment and the current one. In a 360-day year, every month is considered as having 30 days. The 365 days option takes the actual number of days in each month into account. For more information on the different day count methodologies, see [Interest Calculation Methods in Loans](/docs/interest-calculation-methods-in-loans#calculating-the-days-in-a-year). #### Repayments interest calculation for Fixed Term Loans There can be occasions where the days between installments can differ from a regular schedule. For example, when there are either more or fewer days between disbursement and the first repayment than for the other installments, or when an installment's date is moved because of a holiday. In this setting, you may specify whether you would like to consider the real number of days when calculating interest for the installment, or if all installments should have the same interest regardless of the number of days between each installment. For example, consider a loan that is usually repaid once every two weeks. It is disbursed on December 1, but the first repayment date is set to December 20. Although the repayment date is 19 days away from disbursement, if you do not want the interest calculation to consider the first repayment duration, you should use the option **Using Repayment Periodicity**. With that setting, it will be calculated as though it is just 14 days' worth of interest, like all other repayments. Every installment will be calculated with the same amount of interest, regardless of the actual number of days that have passed. If you were to use **Actual Number of Days** instead, then the interest is calculated based on the actual number of days between December 1 and December 20 - that is, 19 days. This setting affects all installments with an unusual number of days because of holidays, or for any other reason. For more information, see [Interest Calculation Methods in Loans](/docs/interest-calculation-methods-in-loans). ### Repayment scheduling Use this setting to choose how the repayment schedule will behave with prepayments, postpayments, or any extraordinary events. With the **Fixed method**, the expected principal and interest are the same throughout the whole loan life cycle, regardless of extraordinary repayments. Its flexibility comes from the fact that it allows for editing the repayment schedules and manually moving due dates, reallocate principal, fees, and interest amounts between repayments. With the **Dynamic method**, the repayments can be automatically recalculated when there is a prepayment or a postpayment. It is often useful for long-term loans. :::note If you choose the Dynamic method for schedule calculation, the **Accrued Interest Posting Frequency** will automatically be set to **On Repayment**. This results from a possibility in Dynamic method to recalculate the interest during the life of the loan. ::: #### Payment interval method For Dynamic Term Loans, you can choose between: * **Interval**: Use this setting to specify that payments should be made after certain periods of time—a month, a week, or some other value. You can then further customize the repayment frequency and constraints for offsetting the first due date. * **Fixed Days of Month**: Choose this option if repayments should always fall on specific days of the month, such as always on the 1st and 15th of every month. This option is commonly used for payday loans, for instance. #### Short month handling If the Fixed Days of the Month option is set to have payments due on the 29th, 30th, or 31st day of the month, Short Month Handling will "move" the installment when the month has fewer days. The system will create the installment for that month to be due to either last day of the month (such as the 28th) or the first day of the next month, depending on your choice. ![Repayment Scheduling screen with Payment Interval Method set to Fixed Days of Month, Monthly Repayment Days set to "31" and Short Month Handling set to "To Last Day of Month"](@site/static/img/support/loans--repayment-scheduling-configuration-3.png) #### Defining the number of installments To define the number of installments, enter the default, minimum, and maximum values in the appropriate fields. ![Repayment Scheduling section at Product Level and Account Terms section at Loan Account Level.](@site/static/img/support/loans--repayment-scheduling-configuration.png) :::note For a more flexible product that allows you to select any repayment frequency when creating a loan account, leave this section blank. ::: #### Defining an amortization period For **dynamic term loans** with a **declining balance equal installment** interest calculation method, you can define an amortization period with the standard payment method. ![amortization period](@site/static/img/support/loans--repayment-scheduling-5.png) If the amortization period is defined when the loan product is created, the amortization period will be visible and editable when creating the loan account, and shown as a line item in the loan account overview. In cases where the amortization period is longer than the number of installments, the system will compute the PMT as if the loan schedule was created for a longer period than the actual loan term. This results in the last installment being a balloon payment, due to a remaining principal balance. >**For example** > >* **Loan amount**: 1,000,000 >* **Number of installments**: 36 monthly installments >* **Amortization period**: 240 months > >The PMT is computed based on the assumption that the loan is given for 240 months. Then, the loan schedule is created in the following way: > >* The first 35 installments are computed using the standard Mambu calculation. >* Installment 36 is a balloon payment which includes the outstanding principal balance, as well as interest due as per the standard calculation. :::note The **amortization period** feature is available both via the UI and the API. Please reach out to your Customer Success Manager or contact [Mambu Support](/docs/mambu-support) to have it enabled. ::: #### First due date offset constraints You can set the constraints for the number of offset days that can be established for the first repayment date. The number of days you enter in **Default** will be automatically added to the first repayment due date when a new account is created under this product. The **Minimum** and **Maximum** values will determine the actual constraints for the offset days and ensure that users can only set a number of offset days that is within that limit. ![Repayment Scheduling section at Product level with Payment Interval Method, installment Constraints and First Due Date Offset Constraints (days)](@site/static/img/support/loans--repayment-scheduling-3.png) #### Principal collection frequency It is common in some countries to have repayment schedules in which clients pay principal on a certain number of installments and only interest on the others. If you use this methodology, you can set the principal collection frequency by entering the number of installments for which there should be no principal collection. ***Example of a loan account with Collection Repayment Frequency set at every three repayments.*** ![Schedule of a Loan Account with Collection Repayment Frequency set at every 3 repayments](@site/static/img/support/loans--loan-account-repayment-schedule.png) #### Grace period The grace period determines if the repayment schedules will include installments in which either principal only, or both interest and principal, are not paid. To define the Grace Period, **click the dropdown list** to choose the option you wish. There are three options: * **No Grace Period**: Clients must pay principal and interest right away. * **Principal Grace Period**: Clients pay only interest for the duration of the grace period. * **Pure Grace Period**: Clients do not pay interest or principal for the duration of the grace period. ![Repayment Scheduling section with Grace Period drop-down](@site/static/img/support/loans--repayment-scheduling.png) ***Repayment schedule with no grace period*** ![Schedule Preview section at Account Level when No Grace Period was set.](@site/static/img/support/loans--schedule-preview.png) ***Repayment schedule with Principal Grace Period*** ![Schedule Preview section at Account Level when Principal Grace Period was set.](@site/static/img/support/loans--schedule-preview-11.png) ***Repayment schedule with Pure Grace Period*** ![Schedule Preview section at Account Level when Pure Grace Period was set.](@site/static/img/support/loans--schedule-preview-5.png) #### Rounding of repayment schedules Depending on the number of installments, some loan amounts end up with a small difference when divided by the number of installments. There are two options for dealing with this case: * **No Rounding**: When there is a discrepancy between the loan amount to be disbursed and the total balance after rounding, Mambu shows a warning message asking you to either adjust the loan amount or the number of installments. * **Round Principal Remainder into Last Repayment**: Mambu automatically adds the discrepancy amount to the last repayment. For example, suppose you create a loan of USD1000 with three installments. This would result in a repayment schedule with installments of USD333.33 which would sum up to a total of only USD999.99 instead of USD1000. In this case, if you choose the rounding options, the missing cent is added to the last repayment (that is, to the second and third repayment schedules in this example). :::warning Mambu cuts the calculations to 20 decimals, stores 20 decimals, and usually rounds to two decimals, depending on the currency used. ::: #### Rounding of repayment currency In some countries, it is not common to use the currency's decimal values in daily life. In this case, when calculating repayment schedules, the repayments should be displayed as an amount that the client can actually pay. This typically means rounding installments to display a whole number. If you want Mambu to automatically round your repayment schedules, choose one of the following options when creating a new product: * **No Rounding**: Decimals are left as they are. * **Round to Nearest Whole Unit**: 62.2 becomes 62 and 62.5 becomes 63. * **Round Up to Nearest Whole Unit**: 62.2 becomes 63. ***Repayment schedule with Rounding*** ![Schedule Preview at Loan Account level with Rounding to Neareast Whole Unit selected.](@site/static/img/support/loans--schedule-preview-3.png) ***Repayment Schedule with No Rounding*** ![Schedule Preview at Loan Account level with No Rounding selected.](@site/static/img/support/loans--schedule-preview-9.png) #### Repayments schedule editing For more information about editing loan schedules, go to [Repayments Schedule Editing](/docs/repayments-schedule-editing). ### Repayment collection For settings for the Payment Allocation Method, pre-payment options, and Repayment Allocation Order, see [Repayment collection](/docs/repayment-collection/). #### Overdue payments settings The setting Overdue Payments is usually set to Increase Overdue Installments. However, for a particular configuration (that is, if you select Reduce Number of Installments for Pre-Payment Recalculation), you can choose Increase Last Installment. ![Repayment Collection section at Product Level with various options.](@site/static/img/support/loans--repayment-collection-configuration.png) The purpose of the setting is to determine what to do with Interest from Arrears. When a loan is in arrears, additional regular interest is calculated on the overdue principal balance. This additional interest usually must be repaid in addition to the scheduled installment amount (that is, Increase Overdue Installments). If Increase Last Installment is selected, Mambu will not adjust the overdue installments, which results in an underpayment of principal. The principal will then be recouped in the last installment. For illustration, see below for two identical loan accounts, one with Increase Overdue Installments, the other with Increase Last Installment. The loans were backdated so that there are late installments. The repayment made shows how the late or last installments were affected. **Increase Last Installment** ![Increase_the_Last_Installment_-_Before_Repayment.png](@site/static/img/support/loans--overdue-payments-setting.png) ![Increase_Last_Installment_-_After_Repayment.png](@site/static/img/support/loans--overdue-payments-settings.png) **Increase Overdue Installment** ![Schedule with Increase Overdue Installment option before a repayment is made.](@site/static/img/support/loans--loan-account-schedule-view.png) ![Schedule with Increase Overdue Installment option after a repayment is made.](@site/static/img/support/loans--loan-account-schedule-3.png) ### Arrears settings Arrears settings control how the number of days in which a loan is in arrears is calculated. These settings affect anything that is derived from a loan's days in arrears, such as penalties, notification templates, and reports. For more information, see [Arrears Settings](/docs/arrears-settings/) ### Penalties settings Penalties are charges that are applied when loans go into arrears. For more information, see [Loan Penalties Setup](/docs/loan-penalties-setup). ### Internal controls In this section, you can set up automatic controls for loans, such as the dormancy period, the number of days to wait before locking accounts in arrears, or automatically locking accounts in arrears when interest, fees, and penalties are more than a certain percentage of the current principal balance or of the original principal amount. For more information, see [Internal Controls](/docs/internal-controls). ### Fees Different types of fees may be applied to loan accounts. They are defined under each product. For more details on each type of fee and the available options, see [Loan Fees Setup](/docs/loan-fees-setup). ### Product links Select **Enable Linking** to allow loan repayments to be automatically made from a settlement deposit account. For more information, go to [Linking deposit and loan accounts](/docs/linking-savings-and-loan-accounts). ### Funding sources You can capture multiple funding accounts for a single loan account. We refer to this feature as loan fractionalization or peer-to-peer (P2P) lending. Mambu then keeps track of each individual funding account that contributes to a loan being disbursed and, as loan repayments are made by the borrower, returns the funds to investors together with a fraction of the interest paid by the borrower. To enable funding sources: 1. Select the **Enable funding sources** checkbox. 2. Enter the minimum, maximum, and default commission values of the funding source. 3. Choose the funder interest commission allocation from the list. 4. Select **Lock funds on funding account at approval** to lock the funding account after it is approved. ![Funding sources section with organization interest commission default, minimum and maximum values, the interest commission allocation options, percentage of the loan funding and fixed interest commissions and the lock funds on funding account at approval option](@site/static/img/support/funding-sources-for-loans.png) For more information, see [Funding Sources - P2P Lending](/docs/funding-sources-p2p-lending). ### Securities Loan securities are used by organizations to secure some guarantee against the loan amount. For more information, go to [Securities Settings](/docs/securities-settings). ### Taxes Many countries require organizations that offer loan accounts to pay taxes on the interest, fees, or penalty income generated on those accounts. These taxes are generally called "value-added taxes" or VAT, because they are collected on revenues. ![Taxes section at Product Level with Apply taxes to, Tax Rate Source and Tax Calculation Method options.](@site/static/img/support/loans--taxes-configuration.png) The option under this section allows you to enable the value-added tax functionality by checking either of the "Apply taxes to" checkboxes for Interest, Fees and/or Penalties under the **Taxes** section. For any of the checked options, Mambu will calculate taxes each time they are applied on the loan accounts, depending on the type of tax, as described below. #### Tax Rate Source To be able to add taxes on a loan product, a tax rate source must be previously defined under the **Administration** > **Financial Setup** > **Rates** section. For more information, see [Customizing Index Interest Rates & Tax Rates](/docs/customizing-index-rates). #### Tax Calculation Method Value-added taxes on loan accounts may be either exclusive or inclusive. **Inclusive VAT** Inclusive taxes are already included and calculated for any interest, fee, or penalty income. If the total interest, fee, or penalty income computed is USD100 and the Value Added Taxes (VAT) is 10% of that, the formula used is `x + 10% of x = $100`. `x` is the interest amount, while `10% of x` is the VAT amount. To find just the interest income you would solve for `x` with the formula `x = USD100 / (1+10%)` and get an interest income of USD90.91. The VAT amount added to that is USD9.09 to get a total of USD100. **Exclusive VAT** Exclusive taxes are calculated on top of the stated interest, fee, or penalty amount. For example, a 10% exclusive tax rate on an interest income of USD100 will result in USD10 as VAT, which will be added on top of the USD100 interest, meaning a total charge of USD110 (USD100 interest + USD10 taxes). ### Accounting rules These settings control whether the product will be linked to the accounting module and which methodology to use. After choosing the methodology—Cash or Accruals based accounting—you may define the accounting rules for that product. To do so, select the appropriate GL account for each action. For more details on each methodology and on the accounting rules, see [Cash vs. Accruals Accounting](/docs/cash-vs-accruals-accounting). --- # Setting up SEPA Direct Debit URL: https://docs.mambu.com/docs/setting-up-sepa-direct-debit/ To use SEPA payments, you must provide a few details in the configuration panel of the Mambu Payment Gateway. ## System Properties ![SEPA Direct Debit System Properties](@site/static/img/support/sepa_dd_system_properties.png) ### Basic configuration - Bank BIC: Enter the Bank Identifier Code (BIC) for your banking institution. This value is usually the BIC of the main branch, and is eight characters long - AML BIC Sender and AML BIC Receiver: If you are using a service to fulfill Anti Money Laundering (AML) and Know Your Customer (KYC) requirements, the BIC of your provider should be entered in these fields ### Incoming Direct Debit configuration Enter a setting for the maximum number of days the system should retry if we cannot execute the debit transaction. For example, this can happen if the account is locked or does not containenough funds. If this value isset to `0` or unspecified, the Direct Debit will automatically be returned if the initial debit transaction fails. ## Schedulers ![SEPA Direct Debit Schedulers Setup](@site/static/img/support/sepa_dd_schedulers_setup.png) Schedulers must be configured for each channel you wish to support. For example, if you want to offer both private and business to business payment flows, you must configure incoming and outgoing schedulers for both SEPA Direct Debit and SEPA Direct Debit B2B. For incoming consumer SEPA Direct Debit payments, you will also need to configure and start a scheduler for processing retries in case of settlement failure on the debtor’s side. Note that the Retry scheduler is disabled if the Incoming Direct Debit Retry Days property is set to `0` or is unspecified, as described above. --- # Setting up SEPA Instant Credit Transfer URL: https://docs.mambu.com/docs/setting-up-sepa-instant-credit-transfer/ To use SEPA Instant, there are a few configuration options that need to be defined in the Mambu Payment Gateway. Generally, these are the same settings that need to be defined for any SEPA compliant payment method. ## System Properties ### Basic configuration - Bank BIC: Enter the Bank Identifier Code (BIC) for your banking institution. This value is usually the BIC of the main branch, and is eight characters long - ACH BIC: Enter the BIC for your clearing and settlement mechanism (CSM) - ACH Clearing System: Enter the code for your CSM, which will be included in generated SEPA messages such as transaction success acknowledgements and rejections - AML BIC Sender and AML BIC Receiver: If you are using a service to fulfil Anti Money Laundering (AML) and Know Your Customer (KYC) requirements, the BIC of your provider should be entered in these fields ### Extra system properties - SEPA Instant timeout in seconds: Enter a value greater than 1 to define when the system will automatically generate and send a rejection message for incoming instant payments that take longer than this value to process. There is no upper limit to this option, although we recommend not going above 20 seconds to stay within the spirit of the SCT Inst scheme. ### AML configuration - AML Instant Credit Transfer Incoming Enabled: When enabled, this option will forward incoming payments to your defined AML service provider who will perform checks against the parties to the transaction. Depending on the response, the payment may be held or stopped. For more information, see [AML & Suspense Accounts](/docs/aml-suspense-accounting) in our User Guide. ## Schedulers configuration For SEPA Instant Credit Transfers there is no need to set up a scheduler, payments will be automatically processed in real time. --- # Shari'ah Based Deposits vs Interest Based Deposits URL: https://docs.mambu.com/docs/shariah-based-deposits-vs-interest-based-deposits/ ## Standard deposit products versus Shari'ah-based deposit products This section shows a comparison between features supported in standard deposit products, versus Shari'ah-based deposit. ### Product types supported | Product type| Standard deposit product | Shari'ah-based deposit product | | --- | --- |--------------------------------| | **Current account** | Yes | Yes | | **Savings account** | Yes | Yes | | **Fixed deposits** | Yes | Yes | | **Savings plan** | Yes | Yes | ### Overdraft support For more information, refer to [Overdraft Products](/docs/overdraft-products). | Overdraft| Standard deposit product | Shari'ah-based deposit product | | --- | --- | --- | | **Allow overdraft** | Yes | No | | **Allow technical overdrafts** | Yes | Yes | ### Calculation method | Calculation method | Standard deposit product | Shari'ah-based deposit product | |--------------------------| --- |--------------------------------| | **Interest/Profit rate** | Yes | Yes | | **Profit sharing** | No | Yes | :::note The interest rate section will be hidden from the Shari'ah-based Deposit Product with profit sharing functionality form. To understand the profit calculation methods for Shari'ah-based deposit products, refer to [Profit Calculation and Distribution](/docs/profit-calculation). ::: --- # Shari'ah Deposit Principles and Process URL: https://docs.mambu.com/docs/shariah-deposit-principles-and-process/ Mambu has expanded our conventional banking platform to offer a comprehensive, fully Shari'ah-compliant Islamic banking feature. By allowing our customers to choose between conventional and Islamic banking options, Mambu is able to serve a wider customer segment by ensuring strict segregation and compliance for Islamic operations while continuing to serve our conventional clients effectively. The principles of Islam, expressed by Shari'ah law, provide the foundation and the contracts built on these principles provide the structure for financial products. ## Principles of Islamic banking The basic principles that all Shari'ah-compliant products adhere to are: * **Shari'ah-based**: Operating on Shari'ah principles, which prohibit the charging or payment of interest (riba) * **Prohibition of interest**: Charging, collecting, or paying interest within financial contracts is strictly prohibited. * **Asset-backed financing**: Transactions are real asset based. Due to existence of goods and services no expansion of money takes place and thus no inflation is created. * **Profit or loss sharing**: Financial contracts ensure the equitable sharing of profits or losses among participants. * **Avoidance of Haram transactions**: Transactions involving forbidden (haram) products are strictly forbidden. * **Transparency and ethical considerations**: Islamic banks often emphasise ethical and socially responsible investments. They ensure transparency and adherence to Shari'ah principles. * **Zakat and charity**: Islamic banks offer accounts and products that facilitate Zakat (Islamic almsgiving) payments. They may encourage charitable giving as part of their operations. * **Contractual framework**: specialised contracts, such as Mudarabah (profit-sharing), Murabaha (cost-plus-profit sale), Ijara (leasing), and more, which comply with Shari'ah principles are used. ## Islamic funding Mambu offerings include: | Offering | Contract types | Description | | --- | --- | --- | | Shari'ah-compliant current accounts | Qard Hassan, Wadiah, and Wakala| On-interest bearing, based on the principle of safe-keeping, voluntary gift (hibah). | | Shari'ah-compliant savings accounts | Qard Hassan, Wadiah, and Wakala | Investment with expected profit rates each month. | | Shari'ah-compliant [fixed deposit](/docs/setting-up-shariah-based-deposit-products) accounts | Tawarruq| investment with expected profit rates for different investment periods. | The main functionality which enables Mambu to support Shari'ah-compliant deposit products is the profit sharing tool. ## Profit sharing process The following stages are used for profit sharing: * Calculation of distributable income or revenue for the profit calculation period. * Calculation of distributable expenses for the profit calculation period. * Calculation of equivalent profit rate for the pool(s). * Calculation of profit rate and amount for the product(s). * Distribution of profit for each account. * Profit approval based on the generated proposal. * Profit application. The diagram below outlines the key parameters involved in profit calculation: * **Income(s) & expense(s)**: Represent the profit or revenue for the investment period and can be allocated across multiple Pools based on specific allocation methods. * **Pools**: Represent total deposits in all accounts used to carry out bank's investment and business activities. The profit calculation cycle, balance type, days in a month/year and GL accounts for accounting are set up on a pool level. * **Product** and **Accounts**: Manages profit payment frequency, predefined profit rate rules (fixed rate, min, and max), customer/ bank share %, minimum eligible balance. ## Cloud hosting providers Profit Sharing is available for customers with Mambu shared and dedicated tenants on AWS, GCP, and Azure. ## Restrictions and security **Early Access Limitations:** Some restrictions may apply to features in early access. Please discuss your requirements with your Mambu Customer Success Manager. These limitations ensure efficient utilisation of early access features while maintaining system stability and security. Islamic Profit Sharing uses a High Availability setup that includes multiple availability zones for both compute and data services. ### User rights A user is anyone who accesses and uses Mambu via the UI or the API. Users are assigned permissions which determine the information they can access and the tasks they can perform. For more information about see [Understanding Users, Roles, and Permissions.](/docs/understanding-users-roles-and-permissions) "Profit Sharing" permission(s) need to be given to user/ role to view information or to perform an action in Mambu that relates to profit sharing. **1. Create a New User** ![Screenshot 2024-02-01 at 12.21.19.png](/img/support/shariah-new-user.png) **2. Create a Role** ![Screenshot 2024-02-01 at 12.22.58.png](/img/support/shariah-new-role.png) **3. Create API Consumer** For more information, refer to [API Consumers](/docs/api-consumers). ## Getting help For help with Islamic Profit Sharing, please see the various channels available that you can use on the [Getting Support](/docs/mambu-support) page. The release notes for Islamic Profit Sharing can be found on our [Release Notes](https://community.mambu.com/c/release-notes) page. --- # Software Requirements URL: https://docs.mambu.com/docs/software-requirements/ The following tools are required on the local machine to start creating Jasper reports for Mambu. ## Jaspersoft Studio [Jaspersoft Studio](https://www.jaspersoft.com/products/jaspersoft-studio) is a report designer provided by Jaspersoft. It is the the tool used to create all custom reports uploaded to Mambu. You may choose to use the commercial or community version of the software. :::warning For full library support with our integration, we recommend you use the latest version of Jaspersoft Studio. For more information, see [Jaspersoft Studio Releases](https://community.jaspersoft.com/project/jaspersoft-studio/releases) on the Jaspersoft Community website. ::: ## MySQL Community Server 8.0 :::warning You must only update your MySQL server if the Mambu team has informed you that your tenant has been upgraded to MySQL 8.0, but you are still using MySQL 5.7 locally. Updating before we have upgraded your tenant may lead to problems. ::: All report templates must be built using the Mambu Database Schema, which can be easily imported into the MySQL server. For full compatibility with our integration, we recommend the MySQL Community Server [8.0 version](https://dev.mysql.com/downloads/mysql/8.0.html#downloads). During the installation process a username and password is required. Make sure these are stored for later use in the [Data Adapter setup](/docs/data-adapter). ## JDBC Driver for MySQL (MySQL Connector/J) A [software library](https://dev.mysql.com/downloads/connector/j) used to manage the connection between Jaspersoft Studio and the MySQL database. :::note The JDBC driver should just be referred to while setting up the Data Adapter from Jaspersoft Studio; it doesn't have an actual installation process. ::: ## MySQL Workbench (recommended) [MySQL Workbench](https://dev.mysql.com/downloads/workbench) is an easy-to-use tool to import and manage databases on MySQL servers. It can be used in the initial phase of creating a report, when designing the structure of the query for data extraction. --- # AML Standard Flows URL: https://docs.mambu.com/docs/standard-aml-flows/ ## Standard AML Flow for an Incoming Payment
    **Accepted** - The Beneficiary Account is credited with the amount specified in the payment --- **Rejected** - The Payment is returned and a Payment Return instruction (pacs.004.001.02) is issued by the Mambu Payment Gateway (MPG) ![AML standard flow for an incoming payment which is rejected](@site/static/img/support/aml-standard-rejected-flow-incoming-payment.png) --- **Suspended** - The payment is parked in the MPG until a definitive AML result has been provided ![AML standard flow for an incoming payment which is suspended](@site/static/img/support/aml-standard-suspended-incoming.png) --- **Accepted** when the payment was originally **Suspended** - The Beneficiary Account is credited with the amount specified in the payment --- **Rejected** when the payment was originally **Suspended** - The Payment is returned and a Payment Return instruction (pacs.004.001.02) is issued by the MPG ![AML standard flow for an incoming payment which is rejected after having been suspended](@site/static/img/support/aml-standard-rejected-flow-originally-suspended.png) --- ## Standard AML Flow for an Outgoing Payment
    **Accepted** - The Originator Account was already debited part of the standard outgoing payment clearing flow, and now a Credit Transfer Instruction (pacs.008.001.02) is issued by the MPG ![AML standard flow for an outgoing payment which is accepted](@site/static/img/support/aml-standard-accepted-outgoing.png) --- **Rejected** - The Payment is marked as failed and the funds are credited back to the Originator Account ![AML standard flow for an outgoing payment which is rejected](@site/static/img/support/aml-standard-rejected-flow-outgoing-payment.png) --- **Suspended** - The payment is parked in the MPG until a definitive AML result will be provided --- **Accepted** when the payment was originally **Suspended** - The Originator Account was already debited part of the standard outgoing payment clearing flow, and now a Credit Transfer Instruction (pacs.008.001.02) is issued by the MPG ![AML standard flow for an outgoing payment which is accepted after having been suspended](@site/static/img/support/aml-standard-accepted-flow-outgoing-originally-suspended.png) --- **Rejected** when the payment was originally **Suspended** - The Payment is marked as failed and the funds are credited back to the Originator Account ![AML standard flow for an outgoing payment which is rejected after having been suspended](@site/static/img/support/aml-standard-rejected-outgoing-originally-suspended.png) --- # Tasks URL: https://docs.mambu.com/docs/tasks/ Tasks are used to keep track of to-dos in Mambu. They are assigned to users and can be linked to specific individual clients or groups. Tasks facilitate workflows and daily activity management across teams since activities that need to be performed can be easily assigned, followed up on, and marked as complete. You can create tasks for yourself or assign them to other users. You may create tasks either through the Mambu UI or API v2. For more information about managing tasks using API v2, see [Tasks](/api/api-v2/tasks/tasks) in our API Reference. :::warning Access to other branch's tasks If you have access to other branches, you can view and create tasks for those branches by selecting that branch in the menu in the top left. If you only have access to one branch, you **cannot** view tasks from any other branch. ::: ## Permissions for tasks In order to view, create, edit, and delete tasks, you must have the appropriate permissions: * **View Tasks** (`VIEW_TASK`) * **Create Tasks** (`CREATE_TASK`) * **Edit Tasks** (`EDIT_TASK`) * **Delete Tasks** (`DELETE_TASK`) ## Creating new tasks Tasks can be created from the dashboard, from a client's profile or from the top bar task indicator. To create a task from the dashboard: 1. In the **Your Tasks** widget, select **New Task**. 2. Enter all the information in the **Creating Task** dialog. See [Fields for tasks](#fields-for-tasks). 3. Select **Save Task**. ![Create Task from Dashboard](@site/static/img/support/users-and-access-control--dashboard-tasks-overview.png) To create a task from a client profile: 1. Go to the client profile page. 2. Select **New Task**. 3. Enter all the information in the **Creating Task** dialog. See [Fields for tasks](#fields-for-tasks). 4. Select **Save Task**. ![Create Task from Clients' profile](@site/static/img/support/users-and-access-control--client-profile-overview.png) :::note When a task is created from an individual client or group profile, the task will be automatically linked to them. The task is immediately stored in the client's profile. ::: To create a task from the top bar task icon: 1. Select the task icon in the top bar. 2. Select **New Task**. 3. Enter all the information in the **Creating Task** dialog. See [Fields for tasks](#fields-for-tasks). 4. Select **Save Task**. ![Create task from task option in top bar.](@site/static/img/support/users-and-access-control--general-settings-with-tasks-due-panel.png) ## Fields for tasks When creating a task there are different fields. | Field | Description | Required | | --- | --- | --- | | Summary | Description of what the user who the task is assigned to should do. For example, "Evaluate client's business" or "Follow up on late repayment". | Yes | | Linked To | An optional link to an individual client or group the task relates to. | No | | Assigned To | The user who should complete the task. Can be yourself or another user in the system. | No | |Due Date | When the task should be completed. | No | | Notes | Any details the assignee might need to complete the task. | No | | Apply Template | Select a template from the list. For more information, see [Task templates](#task-templates).| No | ![Creating Task form with Summary, Linked To, Assigned To, Due Date and Notes fields.](@site/static/img/support/create-a-new-task.png) ## Task templates Templates can be created for common tasks to speed up the workflow by automatically filling in information based on placeholders. You may choose to apply a template when creating a task. You must have either the **Create Templates** (`CREATE_COMMUNICATION_TEMPLATES`) or **Edit Templates** (`EDIT_COMMUNICATION_TEMPLATES`) permissions to create task templates. ### Creating task templates To create a task template: 1. Go to **Administration** > **Templates** > **Tasks**. 2. Select **Add Template**. 3. In the **Creating A New Task Template** dialog, enter all the necessary information. See [Task templates fields](#task-templates-fields). 4. Select **Save Changes**. ### Task templates fields | Field | Description | Required | | --- | --- | --- | | Name | The name for the task template. Must be unique and have a maximum length of 255 characters. | Yes | | Target | The target for the task, can either be `clients` or `groups`. Select the target to view the **Placeholder** dropdown, which is populated with the relevant placeholders. | Yes | | Contents | The description of the task. Consists of `text`, `links`, `images`, or `placeholders`. For more information on how to use the rich text editor and the HTML editor, see [Content Editors](/docs/content-editors).| No | | Placeholder | A dropdown to select placeholders to include in the content of the task template. The **Placeholder** dropdown appears only after selecting the target of the task, as it depends on whether client or group is chosen. For more information, see [Placeholders](/docs/placeholders). | No | ## Finding and completing tasks ### Finding tasks Tasks assigned to a user can be found in three places. * **The Dashboard:** In the Your Task widget on the right side. The number of overdue, upcoming, and tasks due today can be seen, as well as the tasks corresponding to each category. * **The task icon in the top bar**: The number beside the search box shows the number of tasks due; clicking it will show the task list. * **All tasks view**: Which can be accessed both from the dashboard or the task icon. For details on how to filter tasks, see [Filtering tasks](#filtering-tasks). ![All tasks button from dashboard and Tasks view](@site/static/img/support/users-and-access-control--tasks-dashboard.png) ### Completing tasks To complete a task, open the Tasks view, **check the box associated to that task**. Alternatively, you can the **Tasks due** top bar menu item and either check the box to mark a task as complete or open it and select **Complete**. Completed tasks will be automatically checked out, but stored under the user's activity feed. If a task was linked to a client or group, you can also open the **Tasks** tab in the client or group's detail view and edit the filter options to show completed tasks. To reopen a completed task, **click on the check box beside the completed task.** ![Completing tasks from Dashboard view](@site/static/img/support/users-and-access-control--your-tasks-dashboard.png) :::note If your organization requires a log of actions taken, you can easily edit a task before closing it in order to add additional notes, such as steps taken or feedback from the client. ::: ## Filtering tasks Tasks can be filtered in the same way as other Mambu items such as clients and loans. To start filtering tasks, select **All Tasks**, from either the dashboard or top bar task option. For more information, see [Customizing Columns](/docs/customizing-columns). ### Creating a task filter 1. Select the Filter dropdown 2. Select **Add New Filter** if the filter will be stored for later use, or **Custom Filter** for a one-time filter. 3. Select the filters to be used and define their conditions. 4. Save. ### Using a previously saved filter 1. Select the Filter dropdown. 2. Select the previously saved filter. ### Creating a new column preset 1. Click on Custom Columns. 2. Add new column preset. 3. Select the desired columns and give the preset a name. ### Using a previously saved column preset 1. Click on Custom Columns. 2. Select the previously saved preset. ### Editing columns on-the-fly 1. Click on Edit Columns. 2. Select and arrange columns as required. ## Editing and deleting tasks A task can be **Edited** or **Deleted** by selecting **Actions** and selecting the desired option. ![Actions button with Edit and Deleted options](@site/static/img/support/users-and-access-control--tasks-list-view.png) :::warning After deleting a task it will not be possible to open it again and, in case it was linked to an individual client or group, it will disappear from their task history so it could be better to simply mark a task as complete with a note to say why it was not completed in order to maintain full accountability. ::: --- # Technical Overdraft URL: https://docs.mambu.com/docs/technical-overdraft/ An overdraft occurs when money is withdrawn from a bank account and the available balance goes below zero. In this situation, the account is said to be "overdrawn". If there is a prior agreement with the account provider for an Authorised Overdraft, and the amount overdrawn is within the authorised overdraft limit, then interest is normally charged at the agreed rate. If the negative balance exceeds the agreed-upon terms, then additional fees may be charged and higher interest rates may apply; this is generally recognized as a Technical or Unauthorised Overdraft. :::note Technical Overdraft is available for current accounts only. Mambu allows withdrawing below the authorised overdraft limit only for card transactions (when the settlement type is *Financial Advice*, meaning that requests are accepted without balance validations). ::: **Example:** **Given** a client who has a current account which has Authorised Overdraft enabled and the client's total balance is \ with an overdraft limit of \ **When** withdrawing \ via \ **Then** the result of the withdrawal operation will be \ and the resulting account will have the following balances: available balance, \, and technical overdraft amount, \. **Replace the <> with the example results below:**
    Total Balance Overdraft Limit Amount Card Settlement Type Execution Result Expected Available Balance Technical Overdraft Amount
    -100 100 1 Financial Request fail 0 0
    -100 100 1 Financial Advice success -1 1
    0 0 1 Financial Request fail 0 0
    0 0 1 Financial Advice success -1 1
    100 100 1 Financial Request success 199 0
    100 100 1 Financial Advice success 199 0
    100 100 201 Financial Request fail 200 0
    100 100 201 Financial Advice success -1 1
    *** ## Technical Overdraft Interest Rate For the initial phase, the Authorised Overdraft settings are applied for Technical Overdraft as well as for Current Account type of products. If no authorised overdraft interest is set (or authorised overdraft is not enabled on the current account), then no interest will be applied for technical overdraft amounts. Mambu will allow setting up a different interest rate for Technical Overdraft in a future phase, please follow our future release updates. *** ## Repayments and Technical Overdraft When the client makes a deposit, the Technical Overdraft due amounts will be repaid first, before Authorised Overdraft, Fees and so on. See below the balances order over which Mambu will apply deposits: Reversing a transaction, or backdating a credit that covers technical overdraft amounts, is allowed when the original instruction of "Advice=True" was submitted. This means that if the account re-enters a Technical Overdraft state or it has hold or locked (guaranteed) balances, these conditions will be honoured under such scenarios. See below examples: **Example 1:** Customer wishes to pay back some or all of the oustanding Technical Overdraft Balance, backdating that deposit, where the Advice=True on the original card settlement. Given we have an account with: * Overdraft limit = 500 * Authorised Overdraft amount due = 500 * Technical Overdraft amount due = 1000 Transaction 1: 1/1 - Card Advice Transaction of 1000 is posted. Available Balance = -1000 Transaction 2: 3/1 - Deposit of 1500 is posted. Available Balance = 500 Transaction 3: 10/1 - Backdate a Deposit of 300 with a `Valuedate` of 2/1. When Transaction 3 is posted, Transaction 2 is adjusted, and the Available Balance equals -1000, i.e. 500 minus 1500 (Transaction 2 adjusted) before being reapplied. This means that the account is taken back into a Technical Overdraft balance prior to the reapplication of Transaction 3. This is allowed, as it respects the fact that Transaction 1 was posted with Advice=True. **Example 2:** Customer wishes to pay back some or all of the oustanding Technical Overdraft Balance, backdating that deposit, where the Advice=True on the original card hold. Given we have an account with: * Overdraft limit = 0 * Technical Overdraft amount due = 0 Transaction 1: 1/1 - Deposit of 100 is posted. Available Balance = 100 Transaction 2: 3/1 - Deposit of 100 is posted. Available Balance = 200 Transaction 3: 5/1 - Card Hold, with Advice=True, is posted of of 100.01 is posted. Available Balance = 99.99 Transaction 4: 10/1 - Backdate a Deposit of 5 with a ValueDate of 2/1. When Transaction 3 is posted, the Available Balance equals -0.01, i.e. 100 minus hold of 100.01. Ordinarily this would not be allowed at the Hold Balance is greater than the Available balance. But due to the fact that the Hold was posted with Advice=True, it will be respected, and the validation will allow Transaction 4 to be posted. *** ## How is Technical Overdraft impacted, if the Authorised Overdraft limit is increased? Mambu will redistribute the Technical Overdraft amount due if the Authorised Overdraft limit is increased. As such, if the Authorised Overdraft limit is increased high enough, the Technical Overdraft amount due may become 0. For example, if an account with an Authorised Overdraft limit of 100, which is used up, and a Technical Overdraft amount due of 200 has its Authorised Overdraft limit raised to 400, then the Technical Overdraft amount due will become 0 and the Authorised Overdraft amount due will be 300. *** ## Account Impact Mambu allows the retrieval of information related to Technical Overdraft at account level, just as we do for Authorised Overdraft. Retrievable information: * Interest Rate * Interest Accrued * Amount Due * Interest Due The Technical Overdraft amount will also be stored at transaction level, as part of the transaction details, and will also be taken into account when writing off a deposit account with overdrawn amounts. --- # Teller Users URL: https://docs.mambu.com/docs/teller-users/ A *teller* is a user with the user type **Teller**. The user type may be assigned to a user when creating or editing them. For more information, see [Creating a User - User Rights section](/docs/creating-new-users#user-rights-section). Teller users have access to tellering widgets on the dashboard that allow them to manage teller transactions and handle tills management. ![When creating a new teller user select Teller under user rights](@site/static/img/support/create-a-new-teller-user.png) :::warning A user cannot have both the **Administrator** and **Teller** user types assigned to them at the same time. Branch assignment is mandatory for all teller users. ::: ## Tellering permissions The following permissions determine which tellering tasks a teller user is able to perform: * **Open Till** (`OPEN_TILL`) * **Close Till** (`CLOSE_TILL`) * **Add Cash** (`ADD_CASH`) * **Remove Cash** (`REMOVE_CASH`) * **Post Transaction without a Till** (`POST_TRANSACTIONS_WITHOUT_OPENED_TILL`) * **View Background Tasks** (`VIEW_BACKGROUND_TASKS`) For more information, see [Permissions - Tellering](/docs/permissions#tellering). :::note Teller users rarely need to carry out actions that involve background tasks. However, if you do have a teller user that requires access to such actions, you must assign them the **View Background Tasks** (`VIEW_BACKGROUND_TASKS`) permission. Actions that require background tasks include managing deposit and loan accounts, updating general ledger (GL) account closures, and generating balance sheet report. ::: ## Access to tellering dashboard widget There are two tellering widgets that are accessible from the dashboard to teller users: **Tellering** and **Tellers**. To grant a teller user access to these tellering widgets, you must either: * Assign transaction channel permissions to the teller user. * Configure the usage rights for the default transaction channel. ### Assigning transaction channel permissions You may grant teller users access to the tellering widgets by assigning any of the below transaction channel permissions to the user directly or through a role: * **View Transaction Channels** (`VIEW_TRANSACTION_CHANNELS`) * **Create Transaction Channels** (`CREATE_TRANSACTION_CHANNELS`) * **Edit Transaction Channels** (`EDIT_TRANSACTION_CHANNELS`) * **Delete Transaction Channels** (`DELETE_TRANSACTION_CHANNELS`) For more information about permission assignment, see [Understanding Users, Roles, and Permissions](/docs/understanding-users-roles-and-permissions). ### Configuring the usage rights for the default transaction channel A transaction channel represents a form of payment such as cash, SWIFT transfer, credit card repayment, or intrabank transfer. Mambu ships with **Cash** as the default transaction channel. For more information, see [Transaction Channels](/docs/transaction-channels). To grant a teller user access to the tellering widget through access to the default transaction channels, you must either: * Make the default transaction channel accessible to all users. * Assign the teller user a role which has access to the default transaction channel. For more information on managing transaction channel usage settings, see [Transaction Channels - Usage Rights](/docs/transaction-channels#usage-rights). --- # Terminating a Loan URL: https://docs.mambu.com/docs/terminating-a-loan/ When you *terminate a loan*, the total outstanding principal plus all accrued charges become due immediately (as of the termination date). To terminate a loan account, you must have the *Terminate Loan Accounts* permission. This feature is currently available for: * Dynamic Loans * Interest calculation method: Declining Balance Equal Installments * Pre-payment allocation: On upcoming pending installment only * Pre-payment recalculation: Reduce Number of Installments (RNI) * Pre-payment recalculation: Reduce Amount per Installment (RAI) * Types of fee allowed: Manual Fees only ## Terminating a loan account To terminate a loan account: 1. Open the loan account. 2. On the right-hand side of the screen, select **Close** > **Terminate**. 3. Enter the reason for terminating the loan. 4. Choose the current date or a date in the past. 5. Confirm. ![The Terminate loan account option under Close](@site/static/img/support/terminate-loan-account.png) :::note When a loan account is terminated, the number of installments in the schedule is kept the same, only the state of the installments is changed. ::: You can also terminate a loan using the API by making a request to a dedicated endpoint: `POST /api/loans/:terminate` using the payload `{ "valueDate":"2021-01-30T00:00:00+00:00", "notes":"Notes about the account termination process" }` For more information, see our [API documentation](/api/api-v2/loans/terminate-loan-account). ## Undoing loan account termination You can undo the termination of a loan account by adjusting the termination transaction. 1. Open the loan account overview page and go to the **Transactions** tab. 2. Find the terminated transaction and, on the right-hand side of the screen, select **Actions** > **Adjust**. 3. Select **Undo Loan Account Termination Transaction**. ![Adjust the terminate transaction to undo the loan account termination](@site/static/img/support/undo-termination-transaction.png) :::warning Please be aware You can't undo an account termination if there is a transaction posted after the termination that cannot be adjusted (such as `INTEREST_LOCKED`). ::: --- # Mambu Tips and Tricks URL: https://docs.mambu.com/docs/tips-tricks/ This article describes various useful shortcuts and optimizations that can improve your experience using Mambu. ## Shortcut for entering thousands or millions You can use K or M to enter large numbers more easily in *all amount fields* in Mambu. * Use `K` to enter thousands (example: type `1K` instead of `1000`) * Use `M` to enter millions (example: type `5M` instead of `5000000`) ![Apply repayment screen with Amount, Currency, Value Date and Channel](@site/static/img/support/managing-the-mambu-ui--apply-a-repayment.png) ## Display more results in a list You can edit the number of items displayed on a page or in a custom view by selecting the **Show** dropdown in the top right corner in the respective page, as shown below. ![Pagination with number of issues to show](@site/static/img/support/managing-the-mambu-ui--pagination-controls.png) ## Deactivating and reactivating a fee on products You can deactivate or reactivate a fee by clicking on the small green dot, which turns grey when deactivated. ![Fee activation - deactivation button](@site/static/img/support/managing-the-mambu-ui--product-fees-configuration-form.png) ## Multiple item selection On the **All Clients** and **All Groups** page, you can use the checkboxes next to the items in the list to reassign multiple clients or groups to other branches, centres, or credit officers. To select multiple consecutive items in the list, you can select the first item you would like to include in your selection and, while pressing and holding **Shift** on your keyboard, select the last item of the desired range. To deselect, just press and hold **Shift** and click the first item again. Once your selection is ready, to reassign multiple clients or groups select **Actions** > **Reassign**. ![All Clients with clients selected](@site/static/img/support/managing-the-mambu-ui--clients-list-view.png) --- # Token Management URL: https://docs.mambu.com/docs/token-management/ A *card token* is a string of symbols that replaces a payment card number and is used to uniquely identify a payment card. A card token can: * partially replace a card number, keeping the Bank Identification Number (BIN) and the last four digits * fully replace a card number and have the same length as a card number * fully replace a card and have a different length than a card number :::note Card tokens cannot exceed 72 characters. ::: One card token can be linked to only one account. However, one account can have multiple tokens linked to it. Using the API, you can register card tokens for loan or deposit accounts. For more information, see [Deposits Account - Create Card](/api/api-v2/deposits/create-card/) or [Loan Account - Create Card](/api/api-v2/loans/create-card). :::warning For security reasons, we highly recommend you do not use a real card number as a card token. ::: You can see all card tokens that have been registered for a [loan](/api/api-v2/loans/get-all-cards) or [deposit](/api/api-v2/deposits/get-all-cards/) account. You can also remove a card token that has been registered on a [deposit](/api/api-v2/deposits/delete-card/) or a [loan](/api/api-v2/loans/delete-card) account. :::warning You can't delete a token associated to a card that has already been used. ::: Currently, card tokens don't have a status or expiration date. --- # Tracking Activities URL: https://docs.mambu.com/docs/tracking-activities/ Activities tracking allows you to see information about Mambu UI and API events that take place in your tenant. :::note Activities tracking is intended to provide basic day-to-day insight into general Mambu usage. We also offer a tracking API called audit trail for your reporting and auditing needs. In addition to Mambu UI and API events, audit trail also tracks API consumer events such as issuing API keys, which are not covered by the activities functionality. For more information, see [Audit Trail](/docs/audit-trail-v2). ::: ## Latest Activity feed All users can view a snapshot of latest activities from their dashboard. This helps provide an overview of actions taken via the Mambu UI in the branches that they have access to. Users can customize their activity feed to filter out actions they are not interested in. For more information, see [Dashboard - Latest Activity](/docs/dashboard#latest-activity). ## Latest client or group activity Every client or group detail page includes a list of the latest activity related to the client or group. You can see older actions by selecting **Show more** at the bottom of the list. ![Latest activity available for a client from their detail page](@site/static/img/support/client_view_latest_activity.png) ## Latest loan or deposit account activity For deposit or loan accounts, there is an **Activity** tab which shows the latest actions taken such as account approval, loan disbursement, or when an account went into or out of arrears. ![latest activity tab for a deposit or loan account](@site/static/img/support/account_latest_activity.png) ## Latest credit arrangement activity For credit arrangements, there is an **Activity** tab which shows the latest actions taken regarding that specific credit arrangement. ![Credit arrangment latest activity](@site/static/img/support/auditing--credit-arrangement-activity-tab.png) ## System activities custom views :::warning To view activities menu items and custom views your user has to have the **Audit Transactions** (`AUDIT_TRANSACTIONS`) permission. ::: *Custom views* are a tool to generate reports on the fly and easily retrieve filtered lists of information. You can create both temporary custom views and saved custom views for activities. ### Saved custom views Saved custom views are accessible from menu items in the navigation bar. There is a predefined system activities menu item called **Activities**. You can create additional system activity menu items and create saved custom views to assign to them. For more information, see [Menu Items](/docs/menu-items) and [Custom Views](/docs/custom-views). ![Saved custom views for activities](@site/static/img/support/auditing--activities-dropdown-menu.png) ### Temporary custom views You can create temporary custom views for activities by using the **View** menu in the top bar. For more information, see [Temporary Custom Views](/docs/custom-views#temporary-custom-views). ![temporary custom views for activities accessible through view menu](@site/static/img/support/auditing--activities-navigation-menu.png) ## Activities API The activity log can be access by using API v1. For more information, see [Activities](/api/api-v1/activities/activities) in our API Reference. This feature is not supported by API v2. --- # Transaction Channels URL: https://docs.mambu.com/docs/transaction-channels/ A *transaction* is any operation implying changes in the balance of an account. Some transactions are posted through transaction channels. A *transaction channel* is a form of payment such as cash, SWIFT transfer, credit card repayment, or intra-bank transfer. Transactions made between a client and a financial institution, such as disbursements, repayments, deposits, and withdrawals are posted through transaction channels. Transactions that happen within the processes of a financial institution, like applying interest, fees, or penalties are usually not posted through transaction channels. Mambu has one predefined transaction channel, **Cash** - which you may rename. This transaction channel cannot be deleted. ![Transaction Channels main view, where all defined transaction channels are displayed](@site/static/img/support/managing-your-organization--transaction-channels.png) ## Permissions for transaction channels The following permissions are required for a user to be able to perform the relevant management actions on transaction channels: - `VIEW_TRANSACTION_CHANNELS` - `CREATE_TRANSACTION_CHANNELS` - `EDIT_TRANSACTION_CHANNELS` - `DELETE_TRANSACTION_CHANNELS` If these permissions are not assigned to a user, that user will not be able to see the **Transaction Channels** tab under **Administration** > **Financial Setup**. ## Posting transactions through transaction channels When posting a transaction, you will be able to select the transaction channel to post it through by using the **Channel** dropdown in the relevant dialog. For more information and examples of using transaction channels while posting transactions such as disbursements, repayments, deposits, or withdrawals, see: - [Disbursing a Loan](/docs/disbursing-a-loan) - [Processing Loan Repayments](/docs/processing-loan-repayments) - [Deposits, Withdrawals, and Transfers](/docs/deposits-withdrawals-and-transfers) ![Selecting a transaction channel](@site/static/img/support/managing-your-organization--apply-a-repayment.png) ## Creating transaction channels To create a new transaction channel: 1. On the main menu, go to **Administration** > **Financial Setup** > **Transaction Channels**. 2. Select **Add Channel**. 3. Enter all the necessary information. For more information, see [Transaction channel fields](#transaction-channel-fields) below. 4. Select **Save Changes**. ![Add Transaction Channel view, that can be accessed by pressing the Add Channel button from the main view.](@site/static/img/support/managing-your-organization--add-transaction-channel.png) ## Transaction channel fields ### General fields | Field | Description | Required | | --- | --- | --- | | Name | Maximum of 255 characters. | YES | | ID | Maximum length of 32 characters, must be unique, and must not contain spaces. | YES | ### Loan and saving constraints Loan and savings constraints allow you to determine the transactions for which the transaction channel can be used. Loan constraints apply to loan products and saving constraints apply to deposit products. By default the **Unconstrained Usage** option is selected which means there are no constraints set. To set up constraints, select **Limited Usage** and define them by selecting **Add Filter**. There are three constraint types: | Constraint type | Description | | --- | --- | | Amount | Limits the use of the transaction channel to transactions of certain amounts. | | Type | Limits the use of the transaction channel to certain types of transactions. | | Product | Limits the use of the transaction channel to specified products. | Selecting **Match All** allows a transaction to use the transaction channel if it matches all the constraints. Selecting **Match Any** allows a transaction to use the transaction channel if it matches at least one of the constraints. ### Accounting Use the **GL Account** dropdown to select the general ledger (GL) account to associate to the transaction channel. This will allow you to log different journal entries depending on which payment method you use while keeping your books updated. We recommend having separate GL accounts for each transaction channel. :::note If the **Accounting in Multicurrency** feature is enabled you are able to use a transaction channel only if the related GL account will be in the same currency as the GL accounts in the accounting rules of the transaction's products. ::: ### Usage Rights You may choose to make a transaction channel accessible to all users by selecting **All Users**. Or you may make it accessible only to users with certain roles assigned by selecting the specific roles. If access to a transaction channel is limited to certain roles, only users with those roles will see it as an option in the **Channel** dropdown when posting transactions. These usage rights settings can decrease possibilities of fraud in your system. ## Custom fields for transactions by channel Custom field definitions are additional fields you can create in Mambu to capture any additional information required for your business processes. You may create custom field definitions for transactions and make them available to specific transaction channels. The custom field definitions will then appear under the custom field set section when posting transactions through a specific transaction channel. For more information, see [Custom Fields](/docs/custom-fields). ## Editing, deleting, and deactivating transaction channels To edit, delete, or deactivate a transaction channel: 1. On the main menu, go to **Administration** > **Financial Setup** > **Transaction Channels**. 2. Find the transaction channel you want to manage in the list and select **Actions** and then either **Edit**, **Delete**, or **Deactivate** depending on the operation you want to carry out. :::warning If you need to change the GL account on a transaction channel already in use, you should make sure that you reflect the changes with manual journal entries. ::: You cannot delete transaction channels that have been used. If a channel has been used before but you don't want it to be available anymore, you may deactivate it and users won't be able to see it as an option when logging a transaction. All deactivated channels are hidden from the list of available channels. To see them, select **Show deactivated transaction channels** in the top-left corner of the page. The predefined transaction channel cannot be deleted or deactivated. ## Rearranging transaction channels You can define in which order the transaction channels will be displayed to users. To rearrange the existing transaction channels: 1. On the main menu, go to **Administration** > **Financial Setup** > **Transaction Channels**. 2. Select **Rearrange**. 3. Drag and drop the channels in the order you want. 4. Select **Save Changes**. --- # Transaction Holds URL: https://docs.mambu.com/docs/transaction-holds/ A *transaction hold* refers to a kind of transaction authorization in which the balance is unavailable to the account holder until it is either settled or cancelled. Transaction holds are a flexible tool that can be useful or necessary for several common processes and flows, such as: * Single Euro Payments Area (SEPA) instant payment flows * check settlements in the US or other countries * multicurrency settlements * other scenarios where a hold must be posted prior to an actual transaction For any type of deposit account, you can create, settle, reverse, and retrieve authorization holds directly on the account. Once you create a hold, the hold balance on the deposit account increases by the specified amount, and the available balance decreases by the specified amount. Transaction holds are available via requests to the Mambu v2 API. For more information, see [`GET /deposits//authorizationholds`](/api/api-v2/deposits/get-all-authorization-holds/). :::warning Transaction holds are separate from **card authorization holds**, which are used to verify electronic transactions initiated with a debit or credit card. For more information, see [Authorization Holds](/docs/authorization-holds). ::: ## Required permissions To perform any action relating to holds on deposit accounts, you must have the following permissions in the **Holds (via account ID)** category assigned to your user account: * **Create Holds** (`CREATE_HOLDS`) * **View Holds** (`VIEW_HOLDS`) * **Update Holds** (`UPDATE_HOLDS`) * **Delete Holds** (`DELETE_HOLDS`) ## Posting transaction holds You can post a debit or credit transaction hold to any type of deposit account by making a `POST` request to the [`/deposits//authorizationholds`](/api/api-v2/deposits/create-authorization-hold/) endpoint. Here are some important things to consider when posting transaction holds: * Transaction holds can be done against all types of deposit accounts, regardless of the overdraft settings. * The `externalReferenceId` field is mandatory and must be a unique 32 characters. * The specified amount cannot be greater than the available balance of the deposit account, or the transaction hold will fail. * The `creditDebitIndicator` field is mandatory. Enter either `DBIT` or `CRDT`. * The source field specifies the source of the hold: `CARD` or `ACCOUNT`. * For credit-type holds, the amount is validated against maximum deposit value. * The hold will be registered in **Pending** state. * Holds never expire. ## Settling transaction holds Transaction holds are settled with withdrawal or deposit transactions. A debit-type transaction hold in the **Pending** state can be settled by making a `POST` request to the [`/deposits//withdrawal-transactions`](/api/api-v2/deposits_transactions/make-withdrawal) endpoint. A credit-type transaction hold in the **Pending** state can be settled by making a `POST` request to the [`/deposits//deposit-transactions`](/api/api-v2/deposits_transactions/make-deposit/) endpoint. Here are some important things to consider when making a withdrawal to settle a transaction hold: * The amount cannot differ from the amount of the authorization hold, or the action will fail. * The `valueDate` field is not supported in cases where the `holdExternalReferenceId` is specified in the action. If the `valueDate` is specified, the request will fail. * Once the withdrawal to settle the hold is made: * For debit-type holds, the hold balance on the deposit account will decrease by the specified amount, the available balance will remain the same, and the total balance will decrease. * For credit-type holds, the forwardBalance on the deposit account will increase by the specified amount. Available balance will not be increased. * Once the settlement is made, the hold identified by `holdExternalReferenceId` is updated to **Settled**. ## Reversing transaction holds You can reverse any transaction hold that is in the **Pending** state by making a `DELETE` request to the [`/deposits//authorizationholds/`](/api/api-v2/deposits/reverse-authorization-hold/) endpoint. Once the request is successfully made, the hold balance on the deposit account decreases by the amount of the reversed hold, the available balance increases by the same amount, and the hold transaction goes into the **Reversed** state. --- # Transactions per Account URL: https://docs.mambu.com/docs/transactions-per-account/ ## Business case From an account view create an excel extract which will include all the transactions of a specific type. A single transaction type (eg. **DISBURSEMENT**, **REPAYMENT**, **PENALTY_APPLIED**) will be provided as an input by the user. ## Technical concepts Usage of [default parameters](/docs/developer-handbook#default-parameters), dynamic values for report parameters, and excel export. ## Sources * [jrxml template report](https://s3.amazonaws.com/mambu-notifications/Resources/TransactionTypeReport.jrxml) * [resulting excel report](https://s3.amazonaws.com/mambu-notifications/Resources/TransactionTypeReport.xlsx) ## Preview ![transaction type report open in Excel](https://s3.amazonaws.com/mambu-notifications/Resources/TransactionTypeReport.png) *** --- # Transfer Account Ownership URL: https://docs.mambu.com/docs/transfer-account-ownership/ Customers are able to transfer the ownership of an account to a different owner. This can be done in the following directions: * From an individual user to a group * From a group to an individual user * Between groups and individual users. Some restrictions apply before transferring an account: * Account is in the _active_, _approved_, or _active_in_arrears_ state. * Target owner is in _active_ or _inactive_ state. * Account is not linked to any loan account. * Account doesn’t have pending authorization holds or blocked funds. Permissions required to access this feature: * `Edit_Deposit_Account` * `Manage Deposit Account Recipient` To start the process use the [POST /deposits/\:transferOwnership](/api/api-v2/deposits/transfer-ownership) endpoint. This will trigger and complete the process. :::warning Important When initiating a transfer to an owner on a different branch, make sure the account’s product is also available on the new owner’s branch if you intend to change the branch as well. ::: ## Post-transfer restrictions The following actions are restricted once the ownership has been transferred: * The ability to view the previous owner's financial activity is restricted for the new owner by default. To retain visibility of the previous owner's financial activity after a transfer, the `BYPASS_ACCOUNT_OWNERSHIP_TRANSFER_VIEW_RESTRICTION` permission must be granted. For API access, this permission must be granted on the API consumer. * The ability to adjust transactions which are dated before the transfer. * Posting/editing/deleting interest availability with a start date before the transfer. * Applying interest with value date before the transfer date. * Changing interest rate before the transfer date. --- # Truncating and rounding interest URL: https://docs.mambu.com/docs/truncating-and-rounding-interest-deposits/ It's uncommon to use more than two decimals in daily life. In order to show usable values we truncate and round interest to display a whole number or a number with fewer decimals. ### Number of decimals used for interest calculation We use 20 decimals for the calculation of interest accruals. ### Number of decimals stored in the database When storing interest accruals in the database, we truncate the **amount** to 10 decimals. ### Number of decimals displayed in Journal Entries For Journal Entries (JE) tables, we calculate the interest accrual aggregate per deposit product, which is the aggregation of all interest accruals taken from all the deposit accounts created under the respective deposit product. Therefore we sum the related interest accrual amounts that contain 10 decimals and we round the end result to the number of decimals requested by the base currency of the tenant (please see below). ![JE interest accrual rounded to two decimals](@site/static/img/support/je-interest-accruals-deposits.png) ### Number of decimals used for amounts The interest amount is rounded to the number of decimals preset on the base currency (zero for Japanese Yen (JPY), two for American Dollar (USD) and European Euro (EUR), three for Jordanian Dinar (JOD), eight for Bitcoin, and so on). The currencies available and their decimal number are available under **Administration** > **Financial Setup** > **Currency** > **Add Currency**: ![The add currency dialogue emphasizing the number of decimals for the selected currency, in this case, Bitcoin 8](@site/static/img/support/decimal-digits-per-currency.png) :::note In the Deposit's API responses, interest accruals are not truncated, they are displayed using 10 decimals. ::: --- # Truncating and rounding interest URL: https://docs.mambu.com/docs/truncating-and-rounding-interest-loans/ It's uncommon to use more than two decimals in daily life. In order to show usable values we truncate and round interest to display a whole number or a number with fewer decimals. ### Number of decimals used for interest calculation We use a precision of 20 decimals for the calculation of interest accruals. ### Number of decimals stored in the database When storing the interest accruals in the database, we use the same precision of 20 decimals for the **amount** of interest accruals. ### Number of decimals displayed in Journal Entries For Journal Entries (JE) tables, we calculate the interest accrual aggregate per loan product, which is the aggregation of all interest accruals taken from all the loan accounts created under the respective product. Therefore we sum the related interest accrual amounts that contain 10 decimals and we round the end result to the number of decimals requested by the base currency of the tenant (please see below). ![JE interest accrual rounded to two decimals](@site/static/img/support/je-interest-accruals-loans.png) ### Number of decimals used for the amounts The interest amount is rounded to the number of decimals preset on the base currency (zero for Japanese Yen (JPY), two for American Dollar (USD) and European Euro (EUR), three for Jordanian Dinar (JOD), eight for Bitcoin, and so on). The currencies available and their decimal number are available under **Administration** > **Financial Setup** > **Currency** > **Add Currency**: ![The add currency dialogue emphasizing the number of decimals for the selected currency, in this case, Bitcoin 8](@site/static/img/support/decimal-digits-per-currency.png) Then, the **Rounding of Repayment Currency** option selected at product level is taken into account: * **No Rounding**: Decimals are left as they are. * **Round to Nearest Whole Unit**: 62.22 becomes 62 and 62.52 becomes 63. * **Round Up to Nearest Whole Unit**: 62.22 becomes 63. --- # Loans for Groups URL: https://docs.mambu.com/docs/types-of-loan-groups/ ## Solidarity Groups Solidarity groups, sometimes called hybrid groups, are a type of loan product often used for microcredit. It allows you to monitor the individual transactions of each individual in a group. So, when you disburse a certain loan amount you will be able to allocate different amounts to each member. Different loan accounts with their own unique ID and repayment schedule will be created for a single Solidarity Loan Account as each member will have distinct amounts to repay. ![sub accounts for loans disbursed to solidairty groups](@site/static/img/support/solidarity_loan_aub_loan_accounts.png) There are some specific cases where you should consider choosing this method. One of the advantages of this method is that knowing how much each member receives prevents risky situations for your organization, in which some members of the group get a much larger percentage of the loan than others, which could increase the risk of default. In cases where the group loan is not fully paid, you might also want to allow some members to proceed to the next loan but not the ones who defaulted. If your organization follows this policy then the solidarity group method is the best option to consider. In order to create a Loan Product targeted to Solidarity Groups, you will first need to make it unavailable to any other kind of client by unchecking **_Client_** and **_Groups_** in the **_Product Availability_** section. *** ### Implications of writing-off a solidarity group's member The member's account will be written off even if the other members are still active and the other members' repayments will still be logged. :::note If you are unsure whether to use the Solidarity or Pure Group methodology, please contact us through [Mambu Support](/docs/mambu-support). ::: ## Pure Groups The Pure Group type of product allows you to manage the group loans as a whole, with a single disbursement and maintaining the same repayment schedule for the entire group. ![Single loan schedule for pure group loan](@site/static/img/support/pure_group_loan_schedule.png) :::warning As you can see in the image above, in this Loan for a Pure Group, the amount will be used for the whole group and not individually ::: In this case, the group provides credit worthiness to all its members, so if a member misses a repayment, it's the other members responsibility to pay his/her amount to your organization. This type of loan is easier to manage than the solidarity groups, but there are also some trade-offs that you should consider when deciding which type of product to choose. With this method Mambu won't keep track of which members defaulted and the entire group would then be considered delinquent. Another disadvantage of this method is that you might not know how much each member received from the loan which may increase the risk of default in cases where some members receive a much larger allocation than others. You could keep track of this information using notes in the group's profile, but you might want to consider this solution only in exceptional cases. Otherwise you should consider choosing the Solidarity Group type in which Mambu does that automatically. *** ## Tracking individual loan cycles Whether you choose the Pure Group or the Solidarity Group type of loans, Mambu will keep a record of how many loan cycles each member went through. This happens as soon as the account state is set to `Closed (with obligations met)` and the information will then be available in the clients' profiles. In pure groups the loan cycle will be increased by one to all group members as soon as the loan is closed with the obligations met, while in solidarity groups this will happen individually. So if a member makes his last repayment, there will be one more loan cycle in his profile even if the other members of the group still have outstanding repayments to make. --- # Types of Loan Products URL: https://docs.mambu.com/docs/types-of-loan-products/ ## Overview The type of Loan Product can be selected when a new product is created. Mambu supports five type of loans as listed and explained below: ![Create Loan Product with Product Type drop-down enabled.](@site/static/img/support/loans--creating-a-new-loan-product.png) ### Fixed Term Loan A type of product with Fixed interest payments, which are calculated at loan account creation and will not be recalcuated with prepayments. ### Dynamic Term Loan A type of product with Dynamically calculated interest payments, allowing for interest recalculation and reduction when prepayments are performed. ### Interest-Free Loan A type of product with no interest charged. ### Tranched Loan A type of product with Dynamically calculated interest payments, that allows for loan disbursement in a configurable number of tranches. ### Revolving Credit A type of product that allows multiple disbursements and repayments on the account, similar to an overdraft, except that it has a payment plan associated with it in which some amount of principal and interest may be paid. ### Offset Loan A type of loan product which allows for a dynamic interest calculation and enables the **_Redraw_** facility, ultimately allowing a borrower to withdraw money from the amount they've already prepaid. You can read more about this kind of loan product [here](/docs/redraw-facility-and-offset-loans). :::note Products can be made available to both Clients and Groups or to Solidarity Groups. ::: ***
    Ask the Mambu Community

    If you have a question about how anything works or have come across something you haven't seen explained here, get in touch with our community of fellow users and Mambuvians where someone will lend a hand.

    Ask a question about Lending

    * If you don't already have an account you will be prompted to create one when you first visit the site.

    --- # Understanding Users, Roles, and Permissions URL: https://docs.mambu.com/docs/understanding-users-roles-and-permissions/ A *user* is anyone who accesses and uses Mambu via the UI or the API. Users are assigned *permissions* which determine the information they can access and the tasks they can perform. Each permission has a name and covers one action or a small subset of action - for example `VIEW_CLIENT_DETAILS`. Permissions can be assigned to users either directly or through a role. A *role* is a way to group permissions and to control other forms of access within Mambu. For more information about roles, see [Roles](/docs/roles). For a full list of permissions, see [Permissions](/docs/permissions). :::note Roles or permissions may also be assigned to API consumers and apply in the same way. For more information, see [API Consumers](/docs/api-consumers). ::: ![A list of permissions](@site/static/img/support/users-and-access-control--permissions-configuration-panel.png) ## Assigning permissions to a user You may choose to assign permissions to a user directly or they can be assigned through a role. You cannot do both. We recommend assigning permissions to users through roles because it allows for more control over access in Mambu. For more information, see [Access managed by role](#access-managed-by-role). :::note Some permissions may only be assigned to a role, and cannot be assigned directly to a user. ::: ### Permissions assigned directly to a user You can assign permissions directly to the user either via the Mambu UI or API. For more information, see [Creating a User - Permissions](/docs/creating-new-users#permissions). ### Permissions assigned through a role To assign permissions to a user through a role, you have to both create a role and assign all the relevant permissions to it, and assign the role to the user. A user can only have one role. Roles make it easier to add or remove permissions for multiple users as you only need to update the permission at the role level and not for each individual user who has been assigned a permission. ## Access managed by role There are activities and groups of information where access can only be managed by assigning a user a role instead of assigning a set of permissions directly to a user. These instances can be split up into two main types. The first type when access is granted to users that have a specific role assigned to them which is irrespective of what permissions are assigned to the role itself. For more information, see [Access granted to roles irrespective of assigned permissions](#access-granted-to-roles-irrespective-of-assigned-permissions). The second type is when users are granted access provided that they have a specific role assigned to them and that this role has specific permissions assigned to it. For more information, see [Access granted only to roles with appropriate permissions](#access-granted-only-to-roles-with-appropriate-permissions). ### Access granted to roles irrespective of assigned permissions In some cases, you grant access to specific pieces of information in Mambu using roles. In these cases, the access is granted to those roles irrespective of what permissions are assigned to them. #### Custom fields example For example, when you are working with custom fields there are two types of access that you can manage. One kind of access is to determine which users can view, create, edit, or delete custom field definitions. Another kind of access is to determine which users are able to manage custom field values for specific custom field definitions. To assign a user the right to view, create, edit, or delete custom field definitions you have to assign the appropriate permissions to them either directly or through a role; for example, by assigning the `EDIT_CUSTOM_FIELD` permission. However, to allow a user to enter a custom field value for a particular custom field definition when it appears in a form they have to have a specific role assigned to them and that role has to be selected in the **Rights** section of that particular custom field definition. The permissions assigned to the role are irrelevant in this case. The only way the user can have access to enter a custom field value is to have their role selected. For more information about custom field permissions, see [Custom field permissions](/docs/custom-fields#custom-field-definition-permissions) and for more information about granting access to roles to manage custom field information, see [Custom Fields - Rights section](/docs/custom-fields#configuring-rights-for-roles). ### Access granted only to roles with appropriate permissions In other cases, you have to assign appropriate permissions to a role and subsequently assign the role to a user for them to have access. Assigning permissions directly to a user will not work unless the option to grant access to all users is selected. For example, access to view menu items with views is managed at the role level with specific permission assignment. If the **All Users** option is not chosen for the **Clients** menu item then in order for a user to see the **Clients** menu item the role assigned to them must have the `VIEW_CLIENT_DETAILS` permission assigned to it and the role has to be selected in the **Usage Rights** section of the menu item form. If either of these conditions is not met, the user will not have access. For more information, see [Menu item types and permissions](/docs/menu-items#menu-item-types-and-permissions). ## Guidelines for assigning roles and permissions ### Administrators Administrators have access to sensitive data and can do practically anything in Mambu. We recommend you have a minimum of two administrators for account management purposes. For example, an administrator can reset another administrator's password. In the case of an account lockout it is useful to have another administrator in your organization. We recommend a maximum of four administrators in your organization for data security. ### General permission assignment We recommend assigning the least amount of access a user needs to get their job done, meaning the least permissive role or the least amount of permissions. For example, if you want a user to manage users, roles, access preferences, and federated authentication, we do not recommend assigning the administrator user type. Instead, we recommend you create a role titled "access admin" and assign this role to the user. ### Limiting role and user management permission assignment Role and user management permissions allow a user to alter the access settings for other users as well as their own user in the system. :::warning For security reasons, we strongly recommend tightly controlling which users have these permissions. ::: User management permissions: * `CREATE_USER` * `EDIT_USER` * `VIEW_USER_DETAILS` * `DELETE_USER` Role management permissions: * `CREATE_ROLE` * `EDIT_ROLE` * `VIEW_ROLE` * `DELETE_ROLE` --- # User Link Custom Field Showcase URL: https://docs.mambu.com/docs/user-link-custom-field-showcase/ Fields are values associated with a Mambu entity such as a client, group, or loan account. Native fields are fields Mambu provides by default. You may also create custom field definitions to capture additional relevant information. For more information, see [Custom Fields](/docs/custom-fields). By default, automated SMS and email notifications can only be sent to individual clients, members of a group, or credit officers. In this showcase, we will show how you can use a user link custom field definition to also send automated email or SMS notifications that relate to individual clients or groups to users in Mambu. Examples where this may be helpful, include: * Notifying a user about a change in client state. For example from pending approval to rejected or from active to blacklisted. * Notifying a user that their client has an unpaid repayment due. * Notifying a user that their client's loan was approved. ## Step 1: Create a custom field set To start the process of creating a user link custom field definition we must go to **Administration** > **Fields**. The automated email notifications that will be sent to a user may relate to either individual clients or groups. In our example, the notifications will relate to individual clients so we must select the **Client** entity when creating our custom field set and the associated custom field definition. We will create a standard custom field set called **Email Notifications**. For general steps on how to create a custom field set, see [Creating a new custom field set](/docs/custom-fields#creating-a-new-custom-field-set). ![Create Email Notifications Custom Field Set](@site/static/img/support/managing-your-organization--create-new-custom-field-set-3.png) :::note User link custom field definitions for notifications can only be created for client or group entities. User link custom field definitions created for other entities will not be available when defining notifications. ::: Now that we have created the custom field set, we are ready to create the associated custom field definition. ## Step 2: Create a custom field definition Once we have created our **Email Notifications** custom field set, we are ready to create the **Subscribed Users** user link custom field definition. For general steps on how to create a custom field definition, see [Creating a custom field definition](/docs/custom-fields#creating-a-custom-field-definition). When creating the custom field definition we will use **Subscribed Users** as the name and use the **Type** dropdown to select **User Link**. We should verify that the **Email Notifications** custom field set is selected and that we have adjusted the usage settings appropriately to make the custom field definition available to all the necessary client types. ![User Link Custom field Definition](@site/static/img/support/managing-your-organization--custom-field-definition-form.png) Now that we have created our **Subscribed Users** custom field definition, let's look at how we can assign users to individual clients. ## Step 3: Assign a user to a client To assign a user to an individual client, you must visit the client profile and select **Edit**. In the dialog, you must find the **Email Notifications** custom field set and use the **Subscribed Users** field to select the desired user you want to assign. The user will then be entered as the custom field value. ![Subscribed Users custom field definition in Email Notifications custom field set](@site/static/img/support/managing-your-organization--email-notifications-subscribed-users.png) Now that we have assigned a user to an individual client, we may set up our automated notification. ## Step 4: Create an automated notification template You may set up either automated email or SMS notifications to be sent to users when certain client or group activity occurs. In our example, we will create an automated email notification by going to **Administration** > **Email**. The email notification will notify a user that a client they are assigned to has been approved. By default, when you select **Client** as the **Target** of your automated email notification, the only available recipients are client and credit officer. However, now that we have created our **Subscribed User** custom field definition we will find that this is an additional option in our recipients list. For more information on all the available fields when creating emails, see [Creating automated email notifications](/docs/automated-email-notifications#create-an-automated-email-template). ![Email notification](@site/static/img/support/managing-your-organization--create-email-notification.png) Now that we have created our automated email notification template, whenever an individual client that has a user assigned is approved, the assigned users will receive an email notification. --- # User Management and Audit Trail URL: https://docs.mambu.com/docs/user-management-and-audit-trail/ This article discusses how to manage users and use the audit trail feature in Mambu Payment Gateway once you already have your first user set up. For more information about registering your first user for Mambu Payment Gateway, see [Getting Started - Mambu Payment Gateway First User Registration](/docs/payments-settings#5-register-a-user-in-mambu-payment-gateway). User management in Mambu Payment Gateway is handled in **Security** > **Users**. ![Users submenu under security menu item](@site/static/img/support/users-and-access-control--users-administration.png) ## User roles Roles in the Mambu Payment Gateway determine what a user has access to. Users may be assigned one or multiple roles. See the table for a list of roles and what they may access: | Role | Description | | --- | --- | | Administrator | Manage system properties, AML status, scheduler settings, and users. | | AML Officer | View payments and AML status. | | Authorizer | View payments, audit trail, alerts, start/stop schedulers, and manage holidays. | | Viewer | View payments, alerts, and audit trail. | | Maker | View pending payments, alerts, and payment responses. | ## Multi-factor authentication (MFA) Mambu Payment Gateway supports two types of authentication, either regular authentication using just a username and password or multi-factor authentication (MFA) where a code is sent to a mobile phone number associated with your account. To enable MFA, an admin user must set up the SMS configuration in system properties. For more information, see [SMS Configuration](/docs/payment-gateway-system-properties#sms-configuration). MFA may be enabled for specific users when creating or editing them. :::warning Forgotten password If you have forgotten your password you can use the forgotten password link to receive an email containing a link to change your password. If MFA has been enabled for your account, you will also need to provide the code which will be sent to your mobile phone number. ::: ## Viewing Users To view a list of users, you must go to **Security** > **Users**. You may sort users in the users table by selecting the arrows in the column headings. This allows you to sort them alphabetically, by date, or by whether they have a certain setting enabled or not. You may also filter users by email, first name, last name, or role. ## Creating users Administrator users may create users. To create a new user: 1. On the main menu, go to **Security** > **Users**. 2. Select **Create user**. 3. Enter all the necessary information. 4. Select **Create user**. The new user will receive an email containing a link with which they can confirm their account and will be required to set a new password at first login. ![payments_create_user](@site/static/img/support/payments_create_user.png) ## Editing users Administrator users may edit users. To edit a user: 1. On the main menu, go to **Security** > **Users**. 2. Edit the information directly from the list. 3. Save the information by selecting the checkmark icon. You may: * Enable or disable a user. If a user is disabled they will no longer be able to log in to the Mambu Payment Gateway. * Enable or disable MFA. If MFA is enabled, a phone number is mandatory. * Edit the roles assigned to a user. ## Resetting a user password To reset a user password: 1. Find the user in the list of users that you need to reset the password for. 1. In the **Resend confirmation email** column, select **Send**. 1. The user will receive an email with a link to reset their password :::warning Passwords must contain: * One digit * One upper case letter * One special character * By default the length must be between 8 and 128 characters. You may change the minimum length by editing the **Password Minimum Length** value in Extra System Properies. For more information, see [Extra System Properties](/docs/payment-gateway-system-properties#extra-system-properties). ::: ## Audit trail Mambu Payment Gateway keeps an audit trail that tracks payment message changes as well as user actions. ### General audit trail The audit trail log accessible from **Security** > **Audit Trail** shows a list of all the actions that have been taken by either users or the Mambu Payment Gateway. The actions in the list may be filtered according to an action type or a time period or date. ![The audit trail submenu under the security menu item](@site/static/img/support/auditing--audit-trail.png) ### Payment message audit trail You may also access a specific audi trail log for a payment message from the message detail screen. This feature enables you to track all stages through the payment flow. To view the audit trail log, select **Show audit trail** on the payment message detail screen. To close the audi trail log, select **Close audit trail**. ![Option to show audit trail in payment message](@site/static/img/support/payments--outgoing-sepact-payment-details.png) ![Option to close audit trail in payment message](@site/static/img/support/payments--payment-message-audit-trail.png) --- # Using JumpCloud as Your Identity Provider URL: https://docs.mambu.com/docs/using-jumpcloud-as-your-identity-provider/ This guide will walk you through the steps to set up Single Sign-On (SSO) with SAML 2 authentication in Mambu, using JumpCloud as your Identity Provider (IdP). ## Prerequisites - Administrator access to both Mambu and JumpCloud - Understanding of SAML 2.0 concepts - Roles Defined In Mambu - JumpCloud Groups Defined - Custom Attribute defined for groups to map RoleID ## Step 1: Configure JumpCloud as the IdP 1. Log in to the [JumpCloud Admin Portal](https://console.jumpcloud.com/). 2. Navigate to **User Authentication > SSO Applications**. 3. Click **+ Add New Application**. 4. Enter the name of the application in the Search field (e.g. Mambu) and select it. 5. Click **Next**. 1. In the Display Label, type your name for the application. - Optionally, you can enter a Description, adjust the User Portal Image and choose to hide or show the application in the User Portal. (e.g., "Mambu Sandbox/Prod SSO"). 2. In the **IdP Entity ID** field, enter a unique identifier for JumpCloud (e.g., `jumpcloud-mambu-sso`). 3. In the **SP Entity ID** field, you'll need to enter Mambu's SAML URL depending which one you are setting up: - **Production**: https://\.mambu.com/saml/login - **Sandbox**: https://\.sandbox.mambu.com/saml/login 6. Click **Save Application**. 7. Click **Configure Application**. 8. Select the **SSO** tab. 9. Configure the **ACS URL** (Assertion Consumer Service URL): - **Production**: https://\.mambu.com/saml/login - **Sandbox**: https://\.sandbox.mambu.com/saml/login 10. Save the IdP URL; you will need this for the Mambu configuration. - Ensure the Attributes are mapped. These are case sensitive. - **RoleID** represents the Role Name in Mambu. If your user groups match the `RoleName` of Mambu, in the User Attributes you can set `RoleID` to the JumpCloud user attribute `memberOf`. For more information see [this page](https://jumpcloud.com/support/saml-attribute-notes#group-attributes). ![JumpCloud SSO user attribute mapping, showing RoleID mapped to the memberOf attribute](@site/static/img/support/users-and-access-control--jumpcloud-sso-attribute-mapping.png) - Alternatively, you could add a custom attribute in each user group with the value of the Role Name in Mambu. ![JumpCloud user group custom attribute, with RoleID-mambu set to the Mambu role name](@site/static/img/support/users-and-access-control--jumpcloud-user-group-custom-attribute.png) - Using the custom attribute your SSO Attributes should look like this: ![JumpCloud SSO attribute mapping using the RoleID-mambu custom attribute](@site/static/img/support/users-and-access-control--jumpcloud-sso-attributes-custom.png) 11. Save the configuration. 12. Download the **IdP Certificate** from JumpCloud. You will need this for the Mambu configuration. ## Step 2: Configure Mambu as the Service Provider (SP) 1. Log in to your Mambu instance with administrator privileges. 2. Navigate to **Administration > Access > Federated Authentication**. 3. Select the option to Enable SSO authentication. 4. Enter a Display Name (e.g., "JumpCloud SSO") 5. In the **Single Sign-On Endpoint**, enter the following URL with the application name you specified in Step 1.4: `https://sso.jumpcloud.com/saml2/\`. 6. Obtain the fingerprint of the identity provider (IdP) certificate, which is required by Mambu. - Run the following command in a terminal and replace \/certificate.pem with your certificate's location and name downloaded from step 1.15: - `openssl x509 -sha256 -in /\/certificate.pem -noout -fingerprint` - Enter the value in the **Certificate Fingerprint** field. 7. In the **Issuer ID** field enter the value of the **IdP Entity ID** specified in Step 1.5.b. 8. In the **ACS URL** field, enter the Mambu tenant URL used in Step 1.5.c: - **Production**: https://\.mambu.com/saml/login - **Sandbox**: https://\.sandbox.mambu.com/saml/login ![Mambu Federated Authentication — Enable Single Sign-On configuration for JumpCloud](@site/static/img/support/users-and-access-control--jumpcloud-mambu-federated-auth.png) 9. Click **Test Configuration**. - This will validate communication back to JumpCloud and validate the certificate and URLs. 10. If successful, click **Save**. - Although you may get a message that this is irreversible, you can still disable Federated Authentication in Mambu if needed. ## Step 3: Assign users to branches To assign users to specific branches using Federated Authentication, branch assignment must be done through the IdP. This requires attribute mapping. Add the user attribute `BranchID` to JumpCloud's SAML configuration. The value at user or group level must match the ID for the branch defined in Mambu. For more information, please refer to the [supporting documentation](/docs/managing-sso-provisioned-users#branch-assignment). ## Step 4: Test the SSO connection 1. In another browser or using incognito mode, open the Mambu URL and click the **Login with JumpCloud SSO** link below the password field to initiate a test SSO login. 2. You will be redirected to JumpCloud for authentication. 3. After being successfully authenticated in JumpCloud, you will be redirected back to Mambu and logged in. 4. Verify that user access and roles are correctly mapped at the **Administration > Access > Users** view. ## Step 5: Optional Single Log Out (SLO) Some IdPs support Single Log Out functionality where, when a user logs out of one system, the IDP logs them out of all integrated systems. At the time of this writing JumpCloud did not support SLO. Please check with JumpCloud support if Single Log Out is supported. For more information on SLO from Mambu, refer to the [support documentation](/docs/enable-single-logout). ## Troubleshooting | Issue | Solution | |-------|----------| | Login fails | Verify that the IDP and SP Entity IDs, ACS URLs, and certificates are correctly configured in both JumpCloud and Mambu. | | Login Fails "Email already in use" | A user is already defined in Mambu with the email address of the person attempting to login. Ensure that each user has a unique email address. If a user was created prior to enabling SSO, edit the username in Mambu to match that of JumpCloud. | | Incorrect user roles | Ensure that user attributes are correctly mapped between JumpCloud and Mambu. The mapped values should be the Role Name and not the Role ID. | | Certificate errors | Check that the correct certificate is uploaded and that it is not expired. | | Session timeouts differ | The session expirations times for Mambu and your IdP are independent from one another. Once you log into Mambu, the system will only take into account your Mambu session expiration time. | --- # Withdrawing a Deposit Account Application URL: https://docs.mambu.com/docs/withdrawing-a-deposit-account-application/ If the client or your organization decides to withdraw the request for a deposit account, you can do it only if the account is in the *Pending Approval* state. To withdraw a deposit account application: 1. Open the deposit account. 2. On the right hand side of the screen, click on **Close** > **Withdraw**. 3. Add any notes about the reason for the withdrawal. 4. Click on **Change Status**. ![Close drop-down with Withdraw or Reject options.](@site/static/img/support/deposits--deposit-account-details-with-close-actions.png) --- # Withdrawing a Loan URL: https://docs.mambu.com/docs/withdrawing-a-loan/ ## Withdrawing a loan account application Loan accounts that are still in the approval process can be withdrawn from the process by the client or the organization, as long as the loan state is `Pending Approval` or `Partial Application`. To withdraw a loan account application: 1. Open the account. 2. On the right-hand side of the screen, select **Close** > **Withdraw**. 3. Add a note (optional). 4. Select **Close**. ![Withdrawing a Loan Account form Close drop-down menu](@site/static/img/support/loans--loan-account-details-with-action-menu-3.png) :::note When a loan account is withdrawn, it will be displayed in the **Closed Accounts** tab for the client and it cannot be edited anymore, except for its custom field values or name. All attachments and activities are kept for future reference. ::: *** ## Undoing a loan withdrawal When a loan account is withdrawn by mistake, it can be brought back to its previous state. To undo a loan withdrawal: 1. Open the account. 2. On the right-hand side of the screen, select **More** > **Undo Withdraw**. 3. Add a note (optional). 4. Select **Change State**. --- # Working with Credit Arrangements (Lines of Credit) URL: https://docs.mambu.com/docs/working-with-credit-arrangements-lines-of-credit/ ## Overview A “Credit Arrangement” is a maximum amount a client (individual, group or company) can take in loans and overdrafts. It is similar in function to the “Maximum Exposure” defined in **General Setup > Internal Controls**. The main difference is that a Credit Arrangement can be extended separately and will be different per client, whereas the Maximum Exposure is a validation that is pre-set at system level and is the same for all clients. A client or a group may have multiple Credit Arrangements, each linked with specific loan and overdraft accounts. Each Credit Arrangement can have its own constraints, including maximum credit exposure amount and validity dates. The parameters of all loan and overdraft accounts linked to a Credit Arrangement must be within those constraints. Mambu has added this functionality to give you additional flexibility in creating credit arrangements by combining multiple accounts (including loan and overdraft accounts) into one agreement. *** ## Credit Arrangements States In Mambu, Credit Arrangements can be set up to transition between states: *Pending Approval* and *Approved*. In **Administration**, under **Internal Controls** you can select the "New Credit Arrangement Initial State" to be either *Approved* or *Pending Approval*. If the configuration above is set to *Pending Approval*, then all Credit Arrangements will be created with this state and it will require user approval. Users must have the "Approve Credit Arrangements" permission enabled in order to perform the approve action. Additional actions possible on Credit Arrangements in Pending Approval state, and their corresponding permissions: | Action | Required Permission | | --- | --- | |Undo Approval|"Undo Approval Credit Arrangement"| |Close - Withdraw|"Withdraw Credit Arrangements"| |Undo Withdraw|"Undo Withdraw Credit Arrangements"| |Close - Reject|"Reject Credit Arrangements"| |Undo - Reject|"Undo Reject Credit Arrangements"| :::note To add accounts to a Credit Arrangement, it must first be approved; you can't add accounts to a Credit Arrangements that is in the _Pending Approval_ state. ::: Activities will be captured on the account every time a Credit Arrangement transitions between states. Rejecting or Withdrawing a Credit Arrangement is only possible from the _Pending Approval_ state. Active Credit Arrangements (those in the _Approved_ state) can no longer be withdrawn or rejected. It is also not possible to edit the terms of Credit Arrangements in the _Closed-Withdrawn_ or _Closed-Rejected_ states. :::warning Once accounts have been added to a Credit Arrangement, it can no longer be deleted. Credit Arrangements in the _Pending Approval_ state can always be deleted, since accounts cannot be added in this state, and the same is true for Credit Arrangements in the _Approved_ state that do not cotnain any accounts. ::: *** ## Creating a New Credit Arrangement and Exposure Limits The Credit Arrangements can be defined for each client or group. The option to create a new Credit Arrangement is available direclty on the client or group profile, under **New Account** > **New Credit Arrangement**. ![New Credit Arrangement option from New Account drop-down](@site/static/img/support/loans--client-profile-header-with-new-credit-arrangement-menu.png) When creating a new Credit Arrangement, you must select the type of Exposure limit against which the Credit Arrangement will be validated: * **Original (approved) loan/overdraft amount** - is the maximum credit exposure of all loan and overdraft accounts original loan amounts linked to the Credit Arrangement. In other words: the **sum of original loan amounts** and **Total overdraft limits** may not be in excess of the Credit Arrangement Amount. * **Current (outstanding) loan/overdraft balances** - is the maximum credit exposure of all loan and overdraft accounts current balances linked to the Credit Arrangement. In other words, the current outstanding loan/overdraft balances is the sum of all current loan accounts balances and total overdraft balances. :::note Only the outstanding funds of the linked accounts are considered in the validations of the credit arrangement exposure limit. ::: * **ID** - each Credit Arrangement will be given a unique, automatically generated identifier. The identifier template is predefined at the database level and can only be changed by the Mambu technical team. If you need assistance with this, please contact us through [Mambu Support](/docs/mambu-support). :::note It is possible to edit and change the ID manually when creating or editing a Credit Arrangement. ::: * **Start Date** - each Credit Arrangement has a start date called _Starts From_ - accounts can only be disbursed (loan accounts) or activated (overdraft accounts) after this date. * **End Date** - each Credit Arrangement has an end date called _Valid Until_ and loan accounts can only be disbursed if the expected maturity (as per the schedule) is before this end date. Similarly, overdraft accounts can only be approved or added if the expiry date is before this end date. * **Notes** - allow you to include any additional information about the Credit Arrangement. :::info Additional Notes: * Loans with multiple tranches will only have the first tranche dates validated against the credit arrangement constraints, since the other tranches are not firmly confirmed when the account is created. * Clients and groups can have more than one credit arrangement. * Clients and groups may have some accounts linked to a credit arrangement and at the same time accounts outside of the credit arrangement. ::: *** ## Viewing a Credit Arrangement Once a Credit Arrangement is created, it will be displayed as a separate tab on the client or group **Overview** (like a loan account). If you open the tab, you can see the Credit Arrangement details and a list of all the accounts managed under the Credit Arrangement. You can also add notes or change the Credit Arrangement parameters. Any changes made to the Credit Arrangement are captured and stored in the audit log, which is always accessible in the **Activity** tab. The **Overview** section of the Credit Arrangement tab includes the following information: * **Available Credit Amount** for **Original (approved) loan/overdraft amount** * Calculated as: `Credit Arrangement limit - ( Sum of all linked original loan amounts + Sum of all linked Overdraft Limits)` * **Consumed Credit Amount** for **Original (approved) loan/overdraft amount** * Calculated as: `Sum of all linked original loan amounts + Sum of all linked Overdraft Limits` * **Available Credit Amount** for **Current (outstanding) loan/overdraft balances** * Calculated as: `Credit Arrangement limit - (Sum of all linked Loan Accounts Balances - Sum of all linked Overdrafts Balances)` * **Consumed Credit Amount** for **Current (outstanding) loan/overdraft balances** * Calculated as: `Sum of all linked Loan Accounts Balances - Sum of all linked Overdrafts Balances` * **Approved Credit Amount** - the sum of all loan and overdraft amounts of Approved and Active accounts linked to the Credit Arrangement. * **Accounts Summary** - shows information of accounts linked to the Credit Arrangement. * **General information and Details** - show detailed information about the Credit Arrangement parameters. * **State** - shows the current state of the Credit Arrangement: _Pending Approval, Approved, Active,_ or _Closed_. A Credit Arrangement moves to the _Active_ state when accounts are added to it. * **Approval Date** - the date when the credit arrangement was approved. ![Credit Arrangement view from Details tab](@site/static/img/support/credit-arrangements--credit-arrangement-details.png) *** ## Adding accounts to a Credit Arrangement The possibility to add loan or overdraft accounts to a Credit Arrangement is defined in the settings of the respective products, with 3 available alternatives: * **Optional:** Accounts in a product with the _Optional_ setting defined can be managed as part of a Credit Arrangement, but it’s not neccessary to have a Credit Arrangement extended in order to open an account in that product. * **Required:** Accounts in a product with the _Required_ setting defined cannot be approved if they’re not associated with a Credit Arrangement. * **Restricted:** Accounts in a product with the _Restricted_ setting defined are not allowed to be managed under Credit Arrangements. This setting is available in the _Loan Amount_ section for Loan Products and in the _Overdraft Conditions_ section for Deposit Products. When a Credit Arrangement is created, no accounts are associated with it automatically and only existing loan and overdraft accounts can be added to it. In other words, loan or overdraft accounts have to be created for a client or group first, and only then can they be linked to a Credit Arrangement. Users can add active accounts to a Credit Arrangement under the following conditions: * **Loan Accounts** ­can be added if the disbursement date is after the Credit Arrangement start date and the maturity date is before the Credit Arrangement _Valid Until_ date. Additionally, the sum of loan amounts (original funds) cannot exceed the Credit Arrangement maximum exposure _Amount_. * **Overdraft Accounts** ­can be added if the overdraft expiry date is before the Credit Arrangement expiry date and if the overdraft balance doesn’t exceed the Credit Arrangement maximum exposure Amount. Overdrafts that don’t have an expiry date or maximum overdraft amount can’t be added in Credit Arrangements. The **Add Account** option for a Credit Arrangement is available under the **More** button in the upper left-hand corner of the screen. You can choose from a list of the available loan accounts or deposit accounts allowing overdrafts, which: * already exist for a given client, * have a product setup allowing accounts to be added to Credit Arrangements, * are in the following states: _Partial Application, Pending Approval, Approved,_ or _Active_, * are not yet assigned to a Credit Arrangement, * have terms falling within the constraints of the Credit Arrangement. Once an account is linked to a Credit Arrangement, the link will be visible in the account’s **Overview**. *** ## Removing Accounts from a Credit Arrangement Accounts that are not yet closed can be removed (unlinked) from the Credit Arrangement as long as the product setup does not require the account to be linked to a Credit Arrangement. To remove an account from a Credit Arrangement: 1. Go to the client or group overview page.credit arrangement. he option is also available under the **More** button. 2. Choose the account you wish to remove from the list of the loan and overdraft accounts that have been linked to the Credit Arrangement. 3. On the right-hand side of the screen, select **Actions** > **Remove Account**. 4. Confirm. :::note Removing an account from a Credit Arrangement will update the *Available Credit Amount Balances* and the *Approved Credit Amount* values. ::: *** ## Rescheduling/Refinancing Accounts under a Credit Arrangement Accounts that are linked to a Credit Arrangement can only be rescheduled or refinanced into a different product if the new product also allows for its accounts to be linked to a Credit Arrangement. As with any account, the balance and start and end date constraints (outlined in [Adding accounts to a Credit Arrangement](#adding-accounts-to-a-credit-arrangement), above) need to be met. The rescheduled or refinanced loan will remain linked to the original loan's Credit Arrangement. *** ## Editing a Credit Arrangement Credit Arrangements can be adjusted at any time, even after accounts are linked to them. For example, the Credit Arrangement _Amount_ can be increased and the _Valid Until_ date extended. The parameters of the credit line can be edited with the “Edit” button. **Editing a Credit Arrangement allows you to change the:** * **Amount** - the new _Amount_ can be higher, lower, or equal to the sum of total loan & overdraft amounts of accounts linked to the Credit Arrangement. When the Credit Arrangement _Amount_ is below the exposure limit, the available credit balance becomes negative. Any changes made to the Credit Arrangement limit will be logged in Mambu and can be viewed in the **Activity** tab. ![Available Credit Amount exposure limit was edited](@site/static/img/support/loans--credit-arrangement-details.png) * **ID** * **Start Date** - cannot be changed to any date after the earliest disbursement / activation date across all the loan and overdraft accounts linked to the Credit Arrangement * **End Date** - cannot be changed to any date earlier than the latest maturity / overdraft expiry date across all the loan and overdraft accounts linked to the Credit Arrangement *** ## Closing a Credit Arrangement Credit Arrangements that are past their Valid Until dates or are no longer needed can be closed. This option is only available for Credit Arrangements where every account linked to them is closed. After a Credit Arrangement is closed, it will no longer be possible to add/remove accounts, edit, or delete it. Closed Credit Arrangements will be displayed under the **Closed Accounts** section of the client. :::note Any account linked to a closed Credit Arrangement cannot be reopened unless the Credit Arrangement itself is reopened first. ::: *** ## Reopening a Credit Arrangement Closed Credit Arrangements can be reopened by users with the "Close Credit Arrangement" permission. *** ## Deleting a Credit Arrangement A Credit Arrangement can only be deleted from the system if no accounts are associated with it. Once the accounts have been activated, the Credit Arrangement cannot be deleted. *** ## Custom Fields for Credit Arrangements Custom Fields can be helpful in managing information pertaining to a Credit Arrangement. If you want to capture specific data for a Credit Arrangement, you can add these fields from the Administration section within the Credit Arrangement entity (as depicted in the screenshot, below). ![Administration - Custom fields for Credit Arrangements](@site/static/img/support/loans--custom-field-set-for-credit-arrangements.png) To see more details on how to create custom fields, see [Custom Fields](/docs/custom-fields). *** ## Custom Views for Credit Arrangements Credit Arrangements are also available as a parent menu type, allowing users to retrieve relevant data specific to lines of credit. Furthermore, you will find it easy to display, filter, export, and arrange your custom fields. ![New Menu Item from menu Gear button](@site/static/img/support/loans--create-new-menu-item.png) :::warning The new menu item is only visible to users with the "View Credit Arrangements Details" permission and when "Credit Arrangement" is an enabled Mambu feature. ::: To see more details on how to manage custom views, click [here](/docs/custom-views). ***
    Ask the Mambu Community

    If you have a question about how anything works or have come across something you haven't seen explained here, get in touch with our community of fellow users and Mambuvians where someone will lend a hand.

    Ask a question about Lending

    * If you don't already have an account you will be prompted to create one when you first visit the site.

    --- # Working With Overdue Loans URL: https://docs.mambu.com/docs/working-with-overdue-loans/ When a borrower fails to make a scheduled repayment on time, their loan is said to have *gone into arrears*. Depending on the [arrears settings](/docs/arrears-settings) used when creating a product, loans will be marked as having gone into arrears either as soon as a due date has been reached and no payment registered, or, only after a certain grace period. With a grace period, a product can be created with, say three days of grace within which a loan will be marked as late but not in arrears. By doing this, borrowers can be given a little leeway before penalties or increased interest rates for loans in arrears are applied to their account. ## Identifying late repayments When viewing a loan account, you will see up to two indicators once a borrower has missed a scheduled repayment. For products with no grace period, a loan account will be marked as in arrears from the day after the due date. This is shown in the loan account overview page as **Days In Arrears**. For a product with a grace period, a loan will intially be marked simply as **Late** with the **Days Late** visible from the overview page. Any late payment will have an impact on the borrower's **On Time Repayment Rate**, which is displayed in their [Loan History](/docs/reviewing-a-clients-loan-history). ![loan account overview for an overdue loan showing days late and days in arrears](@site/static/img/support/loan_account_overview_days_late_and_days_in_arrears.png) When the grace period ends and there has still not been a repayment made, the account will also start displaying the count of **Days In Arrears** and the state of the loan account will change from `Active` to `In Arrears`. As you can see from the example image, the **Days in Arrears** count shows the number of days late, minus the grace period configured for the product. ## Interest from arrears vs. regular interest in case of late installments on dynamic loans Mambu provides a breakdown of the costs of loans, allowing you to distinguish between the regular interest calculated using the Outstanding Principal Balance (in case of late installments) and the interest from arrears as a breakdown of this regular interest. ### Interest from arrears Interest from arrears is calculated separately and captured at the account and transaction level in custom views and custom filters. ![Interest from Arrears functionality displayed on Loan Account - Details - View.](@site/static/img/support/loans--loan-account-details-3.png) The following formulas are used: * for simple and capitalized interest `Interest from Arrears = Overdue Principal * Annual Interest Rate * Number of Days in the Interval / Days in Year` * for compound interest `Interest from Arrears = (Overdue Principal + Overdue Interest) * ((1 + Annual Interest Rate)^)}-1)` ### Regular interest in case of late installments The regular interest in case of late installments, also known as *late interest*, depends on the **Accrue late interest** option at the product level. For a loan to accrue late interest, the option must be selected. Otherwise, interest will always be calcuated using the **Expected Principal Balance** regardless if there are late payments or not. This is how interest is calculated when installments are not paid on time and the loan accrues late interest: * for simple and capitalized interest `Interest = Outstanding Principal Balance * Annual Interest Rate * Number Of Days Late / Days In Year` * for compound interest `Interest = (Outstanding Principal + Unpaid Interest) * ((1 + Annual IR)^)}-1)` For more information about the different balances of a loan, see [Loan Account Overview Details](/docs/loan-account-overview-details). #### Example with simple interest Loan account setup: * Loan Amount = USD1000 * Interest Rate = 10% per year * Number of installments = 5 * First installment: March 1st, 2022 * Principal amount = USD200 * Interest amount = USD8.33 * Installment state: Late We calculate the interest from arrears on the next due date, April 1st: Interest from arrears = 200 * 10% * 30/360= USD1.67 If the installment had not been late, the interest amount would have been calculated as follows: Interest = 800 (Expected Principal Balance) * 10% * 30/360 = USD6.67 Since the installment is late, the interest is calculated as follows: Interest = 1000 (Outstanding Principal Balance) * 10% * 30/360 = USD8.33, currency rounded to 8.34. This amount reflects the late interest. Note that USD8.34 ( interest calculated at Outstanding Principal Balance) is the sum between USD6.67 (expected interest calculated at Expected Principal Balance) and USD1.67 (Interest from Arrears). So the interest applied by Mambu on April 1 (of USD8.34) is late interest since installment from March 1, was not paid and it includes the interest from arrears amount. :::note The following considerations should be kept in mind when handling overdue loans: * Interest from arrears is always part of the regular interest. It should never be added to the regular interest balance as this would mean duplicating the amount. * Interest from arrears becomes due immediately after application. It will be displayed in the **Interest from Arrears Due** balance in the account's overview page. * Interest from arrears is always paid first. * The arrears tolerance period does not affect the interest from arrears. Interest from arrears will be calculated even if we have an arrears tolerance period set on the account. ::: --- # Working with Payment Holidays URL: https://docs.mambu.com/docs/working-with-payment-holidays/ A *payment holiday* is a break in payments that you may offer clients when they have difficulty paying back a loan. No fee or penalty is charged during a payment holiday period, but you may configure the payment holiday so that interest is still accrued and applied after the payment holiday ends. For more information, refer to [Payment Holidays](/docs/payment-holidays/) ## Setting up payment holidays To set up a payment holiday: 1. When [editing a loan product](/docs/managing-loan-products), in the **Repayment Scheduling** section of the form, under **Repayment Schedule Editing**, select **Configure Payment Holidays**. 2. Open the loan account. 3. On the right-hand side of the screen, select **More** > **Edit Schedule**. 4. In the **Editing Repayment Schedule** dialog, under **Payment Holidays**, select the check boxes next to the installments for which you want to set up a payment holiday. 5. Save the changes. ![Configure Payment Holiday via Edit Schedule at Loan Account Level](/img/support/set-up-payment-holiday-2.png) You can also set up a payment holiday via API v1.0 using the repayments endpoint: `/loans//repayments` For more information, see [Update Loan Repayments](/api/api-v1/repayments/update-loan-repayments) in our API v1.0 documentation. :::warning You cannot set up Payment Holiday if: * Installments are already paid or partially paid. * Interest, fees, or penalties have been applied. ::: With Payment Holiday, you can choose to apply: * **No principal, no interest**, meaning: * Installment(s) is marked as Grace. * Principal and interest are set to 0. * The schedule is extended with one or more installments depending on how the payment holiday was defined. * The maturity date of the loan account will be extended with the number of installments marked as Payment Holiday. * No penalties or fees are charged. * **Principal, but no interest**: The interest rate is set to 0. ## Applying interest after payment holidays After the payment holiday period ends, you can apply the accrued interest using the Mambu API. The way that you do so differs, depending on whether the loan is dynamic term or fixed term. For both operations, the total due will be increased by the interest amount. ### Dynamic term loans For dynamic term loans, you will use **the v2 API**. Make a `POST` request to the `/loans/:applyInterest`endpoint, specifying `isPaymentHolidaysInterest=true`, and specifying the value of `paymentHolidaysInterestAmount` as the amount of interest accrued during the payment holiday that you wish to apply with the current installment. For more information and request examples, see [Loan Accounts - Apply Interest](/api/api-v2/loans/apply-interest) in our API v2 Reference. ### Fixed term loans For fixed term loans, you will use **the v1 API**. Make a `PATCH` request to the `/loans//repayments` endpoint, specifying how much of the interest accrued during the payment holiday you wish to apply with the remaining installments. For more information and request examples, see [Update Loan Repayments](/api/api-v1/repayments/update-loan-repayments) in our API v1 Reference. --- # Writing Off a Loan URL: https://docs.mambu.com/docs/writing-off-a-loan/ *Writing off* a loan account takes the remaining loan balances off the portfolio, registering them as a loss. To write off a loan account: 1. Open the loan account. 2. On the right-hand side of the screen, select **Close** > **Write Off**. In the **Write Off Loan Account** dialog, you'll see an overview of the loan's **Outstanding Balances** consisting of principal, interest, fees and penalties. 3. Add a note about the reason you are writing off the account. 4. Select **Write Off**. ![Write Off Loan Account option under Close. Other available buttons are pay off, refinance, reschedule and terminate.](@site/static/img/support/write-off-loan-account.png) This will settle the remaining loan balances with a specific transaction type (Write off), and close the account, changing its state to **Closed (Written off)** . :::note A Loan account can only be written off if the [minimum days in arrears before write off ](/docs/internal-controls setting allows it.) ::: *** ## Collecting Securities If the loan has guaranteed amounts from other client's savings accounts, you can collect the guaranteed amounts before you write off the loan account. If selected, these amounts will be withdrawn from the deposit account and entered as a payment on the loan account before the write off transaction is posted, thus effectively reducing the amount to be written off. :::note Only users with the specific "Collect Securities" permission have access to this additional automation. ::: ## Undoing a Write Off You may need to revert the write off action and change the state of the loan account. To undo a write off: 1. Open the loan account. 2. On the right-hand side of the screen, select **More** > **Undo Write Off**. 3. Add a comment about the reason you are undoing the write off. 4. Select **Change State**. This will reopen the loan account and revert the loan write off transactions, so the account will go back to the state it was before the write off. --- # Cbe - v9.165 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.165/ This page contains the following releases for v9.165: * [v9.165](#v9165) * [v9.165.7](#v91657) * [v9.165.6](#v91656) * [v9.165.5](#v91655) * [v9.165.4](#v91654) * [v9.165.3](#v91653) * [v9.165.2](#v91652) * [v9.165.1](#v91651) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.165 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Custom field limits now enabled in sandbox environments Custom field limits are now enforced in sandbox environments, giving you a more accurate preview of production behaviour during testing. *Internal references:* [ADM-3613](https://mambucom.jira.com/browse/ADM-3613) #### Health check API message updated The health check API response message has been updated to reflect current system status more accurately. *Internal references:* [ADM-3618](https://mambucom.jira.com/browse/ADM-3618) #### Schedule correctly recalculated after custom repayment The loan schedule is now correctly computed and displayed after a custom repayment (overpayment or prepayment) is posted, preventing incorrect schedule states. *Internal references:* [LPRC-2914](https://mambucom.jira.com/browse/LPRC-2914) #### Additional work - Non-customer-facing backend and infrastructure changes. --- ## Improvements ### Data #### Cursor-based pagination for Search API A new, more performant cursor-based search method is now available as an alternative to offset-and-limit pagination. Instead of an offset, callers supply a `cursor` query parameter (use `"_"` to start from the beginning of the data set); each response then returns an `Items-Next-Cursor` header containing the cursor value to pass in the next call — when that header is empty, the full data set has been traversed. Cursor-based searching is supported for journal entries (`/gljournalentries:search`), deposit transactions (`/deposits/transactions:search`), and loan transactions (`/loans/transactions:search`); items are always sorted by the cursor field (`entryId` for journal entries, `transactionId` for deposit and loan transactions), and at least one `BETWEEN` filter on `creationDate` or `valueDate` must be present. *Internal references:* [SCAL-904](https://mambucom.jira.com/browse/SCAL-904) #### Extended comparison operators for LONG custom fields The `MORE_THAN`, `LESS_THAN`, and `BETWEEN` operators are now supported when filtering on custom fields of the `LONG` data type, enabling more precise range-based searches. *Internal references:* [SCAL-937](https://mambucom.jira.com/browse/SCAL-937) #### Groundwork for upcoming features - Internal caching layer being built for accounting configuration data (general settings, accounting rules, and accounting closures) to improve journal-entry posting performance. - Groundwork for resumable cloning imports for large database tables. - Groundwork for moving the IPS UI React codebase and Pool/Pool Settings API contracts into the CBE codebase. - Groundwork for cashflow REST API endpoints in support of the income and expense category merge initiative. - Groundwork for backward compatibility of deposit product-to-account propagation for interest availability changes. #### Additional work - Non-customer-facing internal maintenance, configuration tuning, infrastructure changes, build tooling updates, and backend-only fixes across data, EOD, accounting, notifications, and platform services. --- ### Analytics #### Restricted view access for users with Manage Streaming permissions A security vulnerability has been resolved where users with **Manage Streaming** permissions could view non-streaming notification templates by manipulating the URL; permissions are now strictly enforced so that each role can only access the templates it is authorised to see. *Internal references:* [NTF-2741](https://mambucom.jira.com/browse/NTF-2741) #### Faster loading of Client, Group, and User pages Optimised the notification count query on the **Client**, **Group**, and **User** UI pages; when the notification count is very large, the **Communications** button no longer displays a count (avoiding a slow query) but remains fully functional so users can still open and view all notifications. *Internal references:* [NTF-2906](https://mambucom.jira.com/browse/NTF-2906) #### Improved notification creation performance Reduced the data retrieved during placeholder processing, resulting in faster notification creation. *Internal references:* [NTF-2860](https://mambucom.jira.com/browse/NTF-2860) #### More resilient streaming publisher connections Increased the application timeout interval for the streaming publisher so that transient message-broker or network issues are tolerated for up to two minutes before a reconnect is attempted, rather than failing immediately. *Internal references:* [NTF-3059](https://mambucom.jira.com/browse/NTF-3059) #### Faster and more reliable template subscription processing The template subscription process now attempts to subscribe clients in a single bulk insert first, falling back to batched inserts only if the single insert times out, improving both speed and reliability. *Internal references:* [NTF-2796](https://mambucom.jira.com/browse/NTF-2796) #### Improved SQL performance for client and group data retrieval SQL query optimisations now apply to the `GET /api/groups` (full details) and `POST /api/clients:search` endpoints, specifically in the image-retrieval area, reducing unnecessary database round-trips. *Internal references:* [NTF-3045](https://mambucom.jira.com/browse/NTF-3045) #### Graceful shutdown of streaming threads during deployments Streaming threads are now cleanly closed during application deployments, preventing in-flight messages from being dropped or left in an inconsistent state. *Internal references:* [NTF-2934](https://mambucom.jira.com/browse/NTF-2934) #### Additional work - Internal notifications maintenance, logging enhancements, and test improvements. --- ### Deposits #### `interestAccrualCalculation` field available on Deposit Products API The `interestAccrualCalculation` field is now supported across all Deposit Products API endpoints: `GET` (single and list) endpoints now return the field, and the `POST` and `PUT` endpoints accept it so products can be created and updated with the correct accrual calculation method configured. *Internal references:* [DIF-1689](https://mambucom.jira.com/browse/DIF-1689), [DIF-1490](https://mambucom.jira.com/browse/DIF-1490), [DIF-1489](https://mambucom.jira.com/browse/DIF-1489) #### Groundwork for upcoming features - Groundwork for interest rate changes based on value dates, including backward-compatibility handling for product propagation. #### Additional work - Non-customer-facing deposit configuration and batching optimisation changes. --- ### Mortgages #### Additional work - Backend-only mortgage fixes and internal test improvements. --- ### Transactions and Interest #### Additional work - Non-customer-facing transactions and interest backend fixes. --- ### Accounting #### Additional work - Backend-only accounting changes, including summary algorithm and GL account filter improvements. --- ### Islamic Banking #### Groundwork for upcoming features - Groundwork for IPS balance summary job scheduling and pool configuration REST API integration in support of the Islamic Profit Sharing feature set. --- ### Developer #### Additional work - Internal security hardening for inter-service communication and non-customer-facing developer tooling updates. --- ## Bug fixes ### Access Control #### SSO certificate expiry experience improved Users now receive clearer feedback when an SSO certificate is approaching or has passed its expiry date, reducing the risk of unexpected authentication failures. *Internal references:* [CIAM-3117](https://mambucom.jira.com/browse/CIAM-3117) ### Clients and Groups #### Client state correctly updated when multiple accounts are closed simultaneously The client state is now correctly changed to inactive when multiple accounts are closed at the same time via API. *Internal references:* [NTF-2870](https://mambucom.jira.com/browse/NTF-2870) ### Lending #### Preview Pay Off Amounts API now compatible with interest-free revolving credit accounts The `Preview Pay Off Amounts` API endpoint no longer throws an error when called against revolving loan accounts with zero interest. *Internal references:* [REV-3813](https://mambucom.jira.com/browse/REV-3813) #### Product-level floor amount settings locked after first account is created The **Include Interest in Floor Amount** and **Include Fees in Floor Amount** fields on the product level are now correctly disabled once the first account has been created, preventing unintended configuration changes. *Internal references:* [REV-3572](https://mambucom.jira.com/browse/REV-3572) #### Repayment amount validation now correctly checked against Total Due When posting a repayment against a specific instalment, the amount from the payload is now validated against the instalment's **Total Due** rather than **Total Expected**. *Internal references:* [LPRC-2588](https://mambucom.jira.com/browse/LPRC-2588) #### Loan schedule no longer incorrect after account termination The repayment schedule is now correctly generated following a loan account termination. *Internal references:* [LPRC-2571](https://mambucom.jira.com/browse/LPRC-2571) ### Mortgages #### Interest-only loan schedule correctly recalculated after a backdated Payment Holiday on the first instalment Adding a backdated Payment Holiday on the first instalment of an interest-only loan no longer produces an incorrect repayment schedule. *Internal references:* [MTGE-606](https://mambucom.jira.com/browse/MTGE-606) #### AdjustInterestForFirstInstallment setting now saved correctly in the UI Changes made to the **AdjustInterestForFirstInstallment** setting in the UI are now persisted as expected. *Internal references:* [MTGE-561](https://mambucom.jira.com/browse/MTGE-561) #### Interest-only products now visible in the UI after feature enablement Interest-only loan products are now correctly displayed in the UI once the relevant feature is enabled. *Internal references:* [MTGE-607](https://mambucom.jira.com/browse/MTGE-607) #### Total Due no longer incorrectly updated after an edit due date action Editing a due date no longer causes the **Total Due** amount on the schedule to be recalculated incorrectly. *Internal references:* [MTGE-579](https://mambucom.jira.com/browse/MTGE-579) #### Expected closing balance now shown for partially paid instalments The expected closing balance is now correctly displayed for instalments with a **Partially Paid** status. *Internal references:* [MTGE-578](https://mambucom.jira.com/browse/MTGE-578) #### Interest-only loan creation correctly blocked when feature toggle is disabled It is no longer possible to create interest-only loan accounts when the corresponding feature toggle is turned off. *Internal references:* [MTGE-571](https://mambucom.jira.com/browse/MTGE-571) #### Configuration as Code loan product update no longer returns an error The `PUT` loan product operation via Configuration as Code now completes successfully without errors. *Internal references:* [MTGE-555](https://mambucom.jira.com/browse/MTGE-555) #### Negative amounts on the schedule no longer appear when paying off an interest-only loan Paying off an interest-only loan account no longer produces negative amounts on the repayment schedule. *Internal references:* [MTGE-548](https://mambucom.jira.com/browse/MTGE-548) #### Manual interest application no longer blocked when instalment due date falls on the current date Applying interest manually, or alongside a repayment, now works correctly in scenarios where the instalment due date is the current date. *Internal references:* [MTGE-547](https://mambucom.jira.com/browse/MTGE-547) #### Total Due now consistent between preview schedule and post-creation schedule for loans with AIR The **Total Due** figures shown in the preview schedule now match those on the schedule generated after loan account creation for loans with an Adjusted Interest Rate. *Internal references:* [MTGE-543](https://mambucom.jira.com/browse/MTGE-543) #### Working day adjustment no longer affects Total Due for equal instalment loans Moving a due date forward or backward to the next or previous working day no longer incorrectly alters the **Total Due** amount for equal instalment loans. *Internal references:* [MTGE-536](https://mambucom.jira.com/browse/MTGE-536) #### Closing balance correctly calculated after a late repayment The closing balance on the repayment schedule is now accurately recalculated following a late repayment. *Internal references:* [MTGE-524](https://mambucom.jira.com/browse/MTGE-524) #### PMT of next instalment no longer incorrectly updated after repeated interest rate start date changes Changing the interest rate start date multiple times no longer causes the payment amount (PMT) of the next instalment to be calculated incorrectly. *Internal references:* [FSE-460](https://mambucom.jira.com/browse/FSE-460) #### Additional work - Internal mortgage test fixes. ### Deposits #### Centre and Credit Officer activities now display correctly in the UI Centre and Credit Officer activity information is now visible and rendered correctly on the UI. *Internal references:* [DIF-1717](https://mambucom.jira.com/browse/DIF-1717) #### Correct interest rate now shown when posting interest availabilities The interest rate displayed when posting interest availabilities now reflects the accurate value. *Internal references:* [DIF-1675](https://mambucom.jira.com/browse/DIF-1675) ### Developer #### Custom date field format corrected on Configuration as Code endpoints The format of custom date-type fields on the Configuration as Code endpoints is now consistent and correctly structured. *Internal references:* [ADM-3414](https://mambucom.jira.com/browse/ADM-3414) ### Data #### Attachment handling improved to prevent orphaned files on database rollback Uploaded attachments are no longer deleted from permanent storage during a database transaction rollback, eliminating orphaned files and improving data integrity. *Internal references:* [NTF-2785](https://mambucom.jira.com/browse/NTF-2785) #### Additional work - Internal data and infrastructure fixes. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.165 cycle. ## v9.165.7 **Release Date**: 03.06.2026 --- ## Improvements ### Notifications #### Additional work - Internal notifications maintenance. --- ## v9.165.6 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to the archival processes for transaction and savings deposit custom field data within the core banking engine. ## v9.165.5 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing infrastructure and configuration changes. --- ## v9.165.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data and infrastructure maintenance. --- ## Bug fixes ### Data #### Fee adjustment now correctly refreshes the repayment schedule Fixed an issue where adjusting a FEE transaction did not automatically refresh the schedule. *Internal references:* [REV-3865](https://mambucom.jira.com/browse/REV-3865) --- ## v9.165.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data and infrastructure maintenance. --- ## v9.165.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing infrastructure and configuration changes. --- ## v9.165.1 **Release Date**: 03.06.2026 --- ## Features ### Mortgages #### Groundwork for upcoming features - Groundwork for fee capitalisation rollback support in mortgage processing. --- ## Improvements ### Data #### Additional work - Non-customer-facing infrastructure and configuration changes. ---

    Database changes

    | Table | Changes | |---|---| | `ips_bank_share_tier` | • Removed foreign key `FK_IPS_BANK_SHARE_TIER_CLASS_SETTINGS_ID`
    • Removed index `IPS_BANK_SHARE_TIER_CLASS_SETTINGS_ID_IDX`
    • Removed index `IPS_BANK_SHARE_TIER_CLASS_SETTINGS_ID_FROM_VALUE_IDX`
    • Removed column `CLASS_SETTINGS_ID`
    • Added column `PRODUCT_SETTINGS_ID`
    • Added index `IPS_BANK_SHARE_TIER_PRODUCT_SETTINGS_ID_IDX` | | `ips_cash_flow_calculation_cycle` | • Added column `CASH_FLOW_ID`
    • Added index `IPS_CASH_FLOW_CYCLE_POOL_CYCLE_ID_CASH_FLOW_ID_UNIQUE_KEY` | | `ips_cash_flow_settings` | • Added column `ASSET_GL_ACCOUNT_ENCODEDKEY`
    • Column `SOURCE` now allows NULL | | `ips_class` | • Table removed | | `ips_class_settings` | • Removed foreign key `FK_IPS_CLASS_SETTINGS_CLASS_ID`
    • Removed foreign key `FK_IPS_CLASS_SETTINGS_POOL_ID`
    • Table removed | | `ips_pool` | • Removed index `UNIQUE_NAME_IDX` | | `ips_pool_settings` | • Added column `PROFIT_CALCULATION_BALANCE_TYPE` | | `ips_product_calculation_cycle` | • Removed column `PRODUCT_ENCODEDKEY`
    • Removed column `POOL_ID`
    • Removed column `EFFECTIVE_DATE`
    • Removed column `POOL_PROFIT_CYCLE_ID`
    • Added column `PRODUCT_SETTINGS_ID`
    • Added column `POOL_CALCULATION_CYCLE_ID`
    • Added index `POOL_CALCULATION_CYCLE_ID_IDX`
    • Removed column `PRODUCT_SETTINGS_ID`
    • Added column `PRODUCT_ENCODEDKEY` | | `ips_product_settings` | • Added column `POOL_ID`
    • Added column `BALANCE_ELIGIBILITY_TYPE`
    • Added column `BALANCE_ELIGIBILITY_MINIMUM_ELIGIBLE`
    • Added column `PROFIT_FIXED_RATE_PERCENTAGE`
    • Added column `PROFIT_FIXED_RATE_RULE`
    • Added column `PROFIT_CAPPED_RATE_PERCENTAGE`
    • Added index `IPS_PRODUCT_SETTINGS_POOL_ID_IDX`
    • Removed index `IPS_PRODUCT_SETTINGS_PRODUCT_ENCODEDKEY_UNIQUE_KEY`
    • Added index `IPS_PRODUCT_SETTINGS_PROD_ENCODEDKEY_EFFECTIVE_DATE_UNIQUE_KEY` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.166 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.166/ This page contains the following releases for v9.166: * [v9.166](#v9166) * [v9.166.7](#v91667) * [v9.166.6](#v91666) * [v9.166.5](#v91665) * [v9.166.4](#v91664) * [v9.166.3](#v91663) * [v9.166.2](#v91662) * [v9.166.1](#v91661) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.166 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Lending #### Filtering installments by state via the API The `GET /installments` endpoint now supports filtering by installment state via a query parameter; when no state is passed, the existing behaviour is unchanged and installments for all active or active in-arrears accounts are returned. *Internal references:* [LL-4402](https://mambucom.jira.com/browse/LL-4402) #### Improved interest computation performance for revolving credit loans The interest computation checkpoint for revolving credit loans has been updated from "interest since activation" to "interest since latest valid interest applied transaction", significantly improving computation performance. *Internal references:* [REV-3615](https://mambucom.jira.com/browse/REV-3615) #### Refund processing on revolving loans Refund processing is now supported on revolving loan accounts. *Internal references:* [REV-3007](https://mambucom.jira.com/browse/REV-3007) #### Fee capitalisation for mortgage loans Capitalised fees are now incorporated into interest calculations, with PMT threshold logic applied and GL entries logged when fees are manually capitalised, ensuring accurate repayment schedules and accounting records. *Internal references:* [MTGE-654](https://mambucom.jira.com/browse/MTGE-654), [MTGE-618](https://mambucom.jira.com/browse/MTGE-618), [MTGE-505](https://mambucom.jira.com/browse/MTGE-505), [MTGE-503](https://mambucom.jira.com/browse/MTGE-503) #### Interest from Arrears on Interest-Only Equal Instalment loans Lenders can now apply, pay, and manage Interest from Arrears (IFA) on interest-only equal instalment loans via both the API and UI, including a dedicated **Apply IFA** action, custom repayment support, and an automated end-of-day job to apply IFA charges. *Internal references:* [MTGE-637](https://mambucom.jira.com/browse/MTGE-637), [MTGE-631](https://mambucom.jira.com/browse/MTGE-631), [MTGE-625](https://mambucom.jira.com/browse/MTGE-625), [MTGE-612](https://mambucom.jira.com/browse/MTGE-612), [MTGE-611](https://mambucom.jira.com/browse/MTGE-611), [MTGE-603](https://mambucom.jira.com/browse/MTGE-603), [MTGE-602](https://mambucom.jira.com/browse/MTGE-602), [MTGE-601](https://mambucom.jira.com/browse/MTGE-601) #### Configurable `decoupleInterestFromArrears` setting visible on loan products The `decoupleInterestFromArrears` setting is now validated on save and its configured value is displayed on both the loan product form overview and the loan product `GET` API response. *Internal references:* [MTGE-582](https://mambucom.jira.com/browse/MTGE-582), [MTGE-551](https://mambucom.jira.com/browse/MTGE-551) #### Payment holiday behaviour selection available in the UI Users can now choose their preferred payment holiday behaviour directly from the UI for DBEI capital repayment loans, without increasing the loan term. *Internal references:* [MTGE-619](https://mambucom.jira.com/browse/MTGE-619) #### Faster schedule fixes without disrupting existing instalment statuses Schedule corrections can now be applied to accounts with schedule differences without altering the status of past or current instalments, reducing the time and risk involved in schedule remediation. *Internal references:* [LPRC-2420](https://mambucom.jira.com/browse/LPRC-2420) #### New API to transfer deposit account ownership A new API endpoint is available to transfer ownership of a deposit account, enabling institutions to reassign accounts between customers programmatically. *Internal references:* [DIF-1730](https://mambucom.jira.com/browse/DIF-1730), [DIF-1731](https://mambucom.jira.com/browse/DIF-1731) #### Groundwork for upcoming features - Groundwork for non-working day support in schedule calculations, including holiday variables and arrears non-working day configuration. - Groundwork for threshold concepts within the financial schedule engine refactor. - Groundwork for Phase 2 payment holidays on DBEI capital repayment loans without increasing the loan term. #### Additional work - Internal backend performance improvements for loans end-of-day processing, including set-based appraisal, micro-batch retry logic, batch GL journal entry processing, and EOD back-worker fixes. --- ### Islamic Banking #### Groundwork for upcoming features - Groundwork for the IPS profit-sharing calculation flow, including fixes to percentage calculation for the Average Balance allocation method and profit rate formula corrections. - Groundwork for IPS end-of-day profit-sharing jobs, including feature-toggle-controlled balance summary updates, metrics, and a private API to trigger IPS jobs. - Groundwork for IPS UI integrations covering products, accounts, pool creation, and savings product search APIs. --- ### Data #### Groundwork for upcoming features - Groundwork for improved magic search, including query optimisation, predefined result ordering, and a resilient error boundary component. #### Additional work - Internal build configuration changes. --- ## Improvements ### Data #### Faster page loads for high-volume message histories The message count in the **Communications** tab has been removed for clients, groups, deposits, loans, and credit arrangements when the number of messages is high, keeping page load times under 10 seconds. *Internal references:* [NTF-3100](https://mambucom.jira.com/browse/NTF-3100) #### Improved publishing rate for delayed and failed streaming events The batch size and processing interval for the fallback mechanism have been tuned, increasing the throughput for streaming events marked as delayed or failed. *Internal references:* [NTF-3076](https://mambucom.jira.com/browse/NTF-3076) #### API service health checks now validate active database connections The `/servicehealthcheck` endpoint verifies the database connection pool used to serve HTTP traffic, ensuring health checks accurately reflect errors that would affect live requests. *Internal references:* [BKE-182](https://mambucom.jira.com/browse/BKE-182) #### Additional work - Non-customer-facing backend maintenance, internal configuration changes, and infrastructure tuning. --- ## Bug fixes ### Data #### Schedule not refreshed after fee adjustment Fixed an issue where adjusting a FEE transaction did not automatically refresh the schedule. *Internal references:* [REV-3865](https://mambucom.jira.com/browse/REV-3865) #### Preview Pay Off Amounts API fails for interest-free revolving credit accounts The Preview Pay Off Amounts API endpoint is now compatible with interest-free revolving credit accounts. *Internal references:* [REV-3813](https://mambucom.jira.com/browse/REV-3813) #### Incorrect rounding applied to already-paid instalments For revolving loan accounts configured to round amounts on schedule, already-paid instalments with decimal amounts are now correctly left unrounded. *Internal references:* [REV-3765](https://mambucom.jira.com/browse/REV-3765) #### Schedule not refreshed after reverting a transaction preceding a terms change Fixed an issue where reverting a transaction that preceded a `TERMS_CHANGED` transaction did not automatically refresh the schedule. *Internal references:* [REV-1924](https://mambucom.jira.com/browse/REV-1924) #### Schedule edit blocked for rescheduled or refinanced accounts with fewer instalments Resolved an issue where editing the schedule of a rescheduled or refinanced account could fail if the account had fewer instalments than the minimum defined on the loan product. *Internal references:* [LL-4704](https://mambucom.jira.com/browse/LL-4704) #### Payment holiday state inconsistent when set across multiple API calls Resolved an issue where marking two instalments as payment holidays in separate API calls left the first instalment in a grace state with the payment holiday flag incorrectly set to `false` and no state visible in the UI. *Internal references:* [LPRC-2660](https://mambucom.jira.com/browse/LPRC-2660) #### Inconsistent `startDate` for exchange rates retrieved via the Currencies CasC API Resolved an issue where an exchange rate persisted via the UI would return a different `startDate` in the Currencies CasC file compared to one persisted via the `PUT configuration/currencies.yaml` endpoint. *Internal references:* [ADM-3706](https://mambucom.jira.com/browse/ADM-3706) #### Inconsistent `startDate` for accounting rates retrieved via the Currencies CasC API Resolved an issue where an accounting rate persisted via the UI would return a different `startDate` in the Currencies CasC file compared to one persisted via the `PUT configuration/currencies.yaml` endpoint. *Internal references:* [ADM-3619](https://mambucom.jira.com/browse/ADM-3619) #### Date fields on client and group overviews now reflect organisation timezone Date fields on **Clients and Groups** overviews are now displayed based on the organisation's configured timezone. *Internal references:* [NTF-2723](https://mambucom.jira.com/browse/NTF-2723) #### Additional work - Non-customer-facing internal fixes and maintenance. --- ### Mortgages #### Instalment due date not advanced when manually editing a schedule with "Move ahead to next working day" Fixed an issue where manually editing the schedule of a loan configured with **Move ahead to next working day** did not correctly advance the instalment due date. *Internal references:* [MTGE-627](https://mambucom.jira.com/browse/MTGE-627) #### Internal error when editing a loan product via CasC Resolved an internal error that occurred when attempting to edit a loan product using Configuration as Code. *Internal references:* [MTGE-617](https://mambucom.jira.com/browse/MTGE-617) #### Overpayment does not reduce instalment count for loans with interest applied on a custom date Fixed an issue where posting an overpayment on a loan with interest applied on a custom date did not reduce the number of remaining instalments. *Internal references:* [MTGE-563](https://mambucom.jira.com/browse/MTGE-563) #### Closing balance and accrued interest shown as empty on schedule before disbursement Resolved an issue where the closing balance and interest accrued fields appeared empty on the schedule prior to disbursement for interest-only mortgage accounts. *Internal references:* [MTGE-539](https://mambucom.jira.com/browse/MTGE-539) #### Fee capitalisation transaction reversal and checkbox visibility corrected Fixed an issue where reversing a fee capitalisation transaction did not behave correctly, and resolved a separate issue where the fee capitalisation checkbox was not visible under the expected conditions. *Internal references:* [MTGE-642](https://mambucom.jira.com/browse/MTGE-642), [MTGE-635](https://mambucom.jira.com/browse/MTGE-635) #### Additional work - Non-customer-facing mortgage fixes and maintenance. --- ### Islamic Banking #### Incorrect pagination on accounts overview Fixed an issue where server-side pagination on the accounts overview calculated the wrong page number. *Internal references:* [IB-1743](https://mambucom.jira.com/browse/IB-1743) #### Inactive products no longer shown in product selection The product selection list now filters to show only active IPS products. *Internal references:* [IB-1753](https://mambucom.jira.com/browse/IB-1753) #### Fixed rate percentage field correctly enforced as mandatory Resolved an issue where the fixed rate percentage field in product settings was not enforced as mandatory. *Internal references:* [IB-1747](https://mambucom.jira.com/browse/IB-1747) #### Additional work - Non-customer-facing Islamic Banking fixes and maintenance. --- ### Transactions and Interest #### Interest availability incorrectly inherits settings from product instead of account Fixed an issue where creating an interest availability record copied interest settings from the loan product rather than from the account, leading to incorrect interest availability configuration. *Internal references:* [DIF-1713](https://mambucom.jira.com/browse/DIF-1713) --- ### Cards #### Incorrect card authorisation creation date when organisation offset is not UTC Fixed an issue where the creation date returned in the `card/getAuthorization` response was incorrect when the organisation's timezone offset was not UTC. *Internal references:* [CARDS-2454](https://mambucom.jira.com/browse/CARDS-2454) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.166 cycle. ## v9.166.7 **Release Date**: 03.06.2026 --- ## Features ### Data #### Groundwork for upcoming features - Foundational work to improve and decouple the search suggestion engine, enabling a more powerful magic search experience. --- ## v9.166.6 **Release Date**: 03.06.2026 --- ## Features ### Data #### Groundwork for upcoming features - Foundational work toward archiving custom field values on deposit transactions. #### Additional work - Non-customer-facing data configuration changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing configuration changes. --- ## v9.166.5 **Release Date**: 03.06.2026 --- ## Bug fixes ### Data #### Loans Search API performance fix for account holder filtering Using the `AccountHolderId` field with the `EQUAL_CASE_SENSITIVE` operator in the Loans Search API no longer causes performance degradation. *Internal references:* [LL-4937](https://mambucom.jira.com/browse/LL-4937) #### Search retains and displays the most recent query results Magic search now correctly preserves and surfaces the last search results, ensuring users see up-to-date results from their most recent query. *Internal references:* [CDO-4138](https://mambucom.jira.com/browse/CDO-4138) --- ## v9.166.4 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data infrastructure changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing data operations maintenance. --- ## Bug fixes ### Data #### Additional work - Internal data enhancements and maintenance. --- ## v9.166.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data operations maintenance. --- ## v9.166.2 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Internal logging improvements. --- ## Improvements ### Data #### Warning when starting a job that would lock already-in-use resources An alert is now displayed in the UI when a user attempts to start a job that would lock resources already held by a running job, preventing conflicts before they occur. *Internal references:* [LED-2327](https://mambucom.jira.com/browse/LED-2327) #### Additional work - Non-customer-facing internal configuration and operational tuning changes. --- ## v9.166.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Groundwork for upcoming features - Continued investment in Magic Search enhancements to improve search capabilities. #### Additional work - Internal logging and backend-only data maintenance. --- ## Improvements ### Data #### Additional work - Non-customer-facing internal configuration and maintenance changes. --- ## Bug fixes ### Mortgages #### Incorrect date calculations resolved for months with fewer than 31 days Fixed an issue where date calculations could produce invalid dates such as 31 September, ensuring accurate scheduling and interest application across all calendar months. *Internal references:* [MTGE-698](https://mambucom.jira.com/browse/MTGE-698) ---

    Database changes

    | Table | Changes | |---|---| | `ips_cash_flow` | • Added column `STATUS` | | `ips_cash_flow_calculation_cycle` | • Added column `CASH_FLOW_TYPE` | | `ips_cash_flow_settings` | • Removed column `STATUS` | | `ips_pool` | • Added column `STATUS` | | `ips_pool_calculation_cycle` | • Added column `ACCOUNT_NUMBER` | | `ips_pool_settings` | • Column `BANK_INVESTMENT_PL_ACCOUNT_ENCODEDKEY` now allows NULL
    • Removed column `STATUS` | | `ips_product_calculation_cycle` | • Added column `ACCOUNT_NUMBER` | | `ips_product_settings` | • Removed column `STATUS` | | `savingstransactioncustomfieldarchive` | • Removed index `TRANSACTIONID_IDX`
    • Added index `TRANSACTIONID_VALUEDATE_IDX` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.167 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.167/ This page contains the following releases for v9.167: * [v9.167](#v9167) * [v9.167.10](#v916710) * [v9.167.9](#v91679) * [v9.167.8](#v91678) * [v9.167.7](#v91677) * [v9.167.6](#v91676) * [v9.167.5](#v91675) * [v9.167.4](#v91674) * [v9.167.3](#v91673) * [v9.167.2](#v91672) * [v9.167.1](#v91671) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.167 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Loans end-of-day processing now loads accounts in batches Added support for retrieving paginated loan accounts when running end-of-day on cron machines, which can significantly reduce EOD runtime for customers with large loan portfolios. Contact your Mambu Customer Success Manager to discuss early access requirements. *Internal references:* [BKE-73](https://mambucom.jira.com/browse/BKE-73) #### Requests are no longer dropped during rolling deployments During a release, the system previously forwarded requests to machines that were active but scheduled for replacement, sometimes causing those requests to return an error. Machines now wait for all in-progress requests to complete before terminating. *Internal references:* [BKE-262](https://mambucom.jira.com/browse/BKE-262), [BKE-205](https://mambucom.jira.com/browse/BKE-205) #### Archived custom field values on deposit transactions are now clearly indicated A UI message is now displayed when the custom field values of a deposit transaction have been archived, preventing confusion when those values can no longer be edited. *Internal references:* [ADM-3734](https://mambucom.jira.com/browse/ADM-3734), [ADM-3732](https://mambucom.jira.com/browse/ADM-3732) #### Groundwork for upcoming features - Building the Interest from Arrears (IFA) computation capability for Interest Only Equal Installment loans, including accrual during payment holiday periods, balance updates, accounting entries, backdated repayment recomputation, and UI handling across write-off, pay-off, and refinance/reschedule workflows. - Enabling a new compound interest type with daily rest methodology for mortgage loan products. - Extending the financial schedule engine to support custom interest application dates and multiple date fields for installment calculations. - Extending prepayment calculators to support editing principal and number of pending installments under both Reduce Amount of Installments and Reduce Number of Installments methods. - Introducing a configurable option to control whether loan accounts follow a client's branch reassignment or remain in their original branches. - Adding support for non-working day handling in financial schedule calculations, including yearly recurrence and creation-date holiday options. - Enabling credit (negative) balance support for revolving loan accounts. - Introducing refund transaction type as a filter option in the transaction search API for revolving loans. - Extending the deposit account ownership transfer feature to restrict read/write actions and search/get results for entries recorded before a transfer. - Implementing the IPS calculation flow for Islamic Banking, including cashflow validation, UI improvements, and product settings refinements. - Building IPS account payment cycle management for Islamic Banking, including internal cycle and account payment cycle data structures and job implementation. - Building profit distribution infrastructure for Islamic Banking, including bulk update methods and batch persistence execution. - Enhancing end-of-day interest accrual calculations with additional conditions before sending accrued interest amounts to the ledger. - Making the `AUTOMATED_TRANSFERS` job horizontally scalable to improve processing throughput. - Migrating the CBE frontend from GWT to React, including translation parameter and URL link support. - Improving the magic search experience with a second round of enhancements. #### Additional work - Non-customer-facing internal maintenance, including performance tuning, identity caching, concurrent transaction limiting, NPE investigation, sandbox configuration changes, and Islamic Banking logging improvements. --- ## Improvements ### Data #### Faster retry recovery for idempotent requests In-progress idempotent requests now expire faster, enabling quicker retries after crashes using the same idempotency key and reducing eventual consistency time from hours to minutes. *Internal references:* [BKE-181](https://mambucom.jira.com/browse/BKE-181) #### Improved streaming resilience Updated the logic for reusing the message bus producer, reducing the time needed to auto-recover the application's streaming capabilities after an interruption. *Internal references:* [NTF-3054](https://mambucom.jira.com/browse/NTF-3054) #### Faster task retrieval queries Introduced a new index on the query used to retrieve the total number of tasks, and improved the query used to retrieve tasks based on a user's managed branches, resulting in better overall performance. *Internal references:* [NTF-3049](https://mambucom.jira.com/browse/NTF-3049), [NTF-3048](https://mambucom.jira.com/browse/NTF-3048) #### Comment sanitisation now active across all production environments The security enhancement for comment sanitisation in the Mambu UI is now enabled in all production environments. More details can be found in the [prior release note](https://community.mambu.com/t/mambu-release-notes-v9-163-0/6228#enhanced-security-with-comment-sanitisation-in-the-mambu-ui-14). *Internal references:* [NTF-3004](https://mambucom.jira.com/browse/NTF-3004) #### Improved performance when unlocking deposit accounts Improved the performance of the `POST /deposits/:changeState` endpoint when transitioning a deposit account from locked to unlocked state. *Internal references:* [DO-448](https://mambucom.jira.com/browse/DO-448) #### Additional work - Internal data fixes, feature toggle clean-up, and backend-only maintenance work. --- ### Mortgages #### Prepayment allocation order no longer carries over between loan products Fixed an issue where the prepayment allocation field in the UI was not properly initialised, causing it to display the allocation order from a previously edited loan product rather than the current one — which could prevent saving changes to a loan product that already had active accounts. *Internal references:* [MTGE-610](https://mambucom.jira.com/browse/MTGE-610) --- ### Deposits #### Groundwork for upcoming features - Building enhancements to restrict operations on entries stored before an account transfer across search, retrieval, and write endpoints for transactions, block funds, authorization holds, availabilities, and document templates. - Improvements and bug fixes to the live migration process and auto-activation service in preparation for upcoming deposit platform changes. #### Additional work - Backend-only deposit maintenance work. --- ## Bug fixes ### Lending #### Backdated repayment late fees now correctly reapplied on Revolving Accounts Fixed an issue where late fees were not applied to backdated repayments on a Revolving Account. *Internal references:* [REV-3798](https://mambucom.jira.com/browse/REV-3798) #### Interest application method no longer resets when editing a mortgage product Fixed a UI issue where the interest application method was incorrectly reset to **On Repayment** when editing an existing mortgage product. *Internal references:* [MTGE-739](https://mambucom.jira.com/browse/MTGE-739) #### Remove Payment Holiday — Keep Same Loan Term now works via API v2 Fixed an issue where the Remove Payment Holiday option with **Keep Same Loan Term** did not function correctly when called through the v2 API. *Internal references:* [MTGE-730](https://mambucom.jira.com/browse/MTGE-730) #### Fixed loan repayment scheduling copy to Dynamic no longer fails Fixed an issue where copying or editing a fixed loan with repayment scheduling to a Dynamic schedule type would fail. *Internal references:* [MTGE-691](https://mambucom.jira.com/browse/MTGE-691) #### Loan Product Configuration as Code now supports products with custom predefined fees Fixed an issue where the Loan Product CasC `PUT` endpoint failed to update loan products that included a custom predefined fee. *Internal references:* [LPRC-2930](https://mambucom.jira.com/browse/LPRC-2930) #### Interest rate `validFrom` date preserved correctly during refinancing and rescheduling Fixed an issue where the `validFrom` date in `AccountInterestRateSetting` was incorrectly moved when an account was refinanced or rescheduled. *Internal references:* [LL-4889](https://mambucom.jira.com/browse/LL-4889) #### Interest from Arrears values now populated in Reschedule and Refinance UI forms Fixed an issue where Interest from Arrears amounts were not displayed in the Reschedule and Refinance UI forms. *Internal references:* [MTGE-756](https://mambucom.jira.com/browse/MTGE-756) #### `interestAccrued` now updated correctly after fee capitalisation reversal Fixed an issue where `interestAccrued` was not recalculated following a fee capitalisation reversal. *Internal references:* [MTGE-731](https://mambucom.jira.com/browse/MTGE-731) #### Total due now updates correctly on repayment for Interest Only Equal Installment loans Fixed an issue where the total due amount was not updated on repayment when the current repayment PMT was not recalculated for Interest Only Equal Installment (IOEI) loans. *Internal references:* [MTGE-725](https://mambucom.jira.com/browse/MTGE-725) #### Principal balance now correctly updated on adjustment transactions Fixed an issue where the principal balance was not updated when an adjustment transaction was applied. *Internal references:* [MTGE-679](https://mambucom.jira.com/browse/MTGE-679) #### IFA-related financial resources now visible in Product Update and Copy screens Fixed a UI issue where Interest from Arrears (IFA) related financial resources were not shown in the product update and copy screens. *Internal references:* [MTGE-680](https://mambucom.jira.com/browse/MTGE-680) #### Date calculations corrected for invalid calendar dates such as 31 September Fixed an issue where date calculations produced incorrect results when a computed date fell on a day that does not exist in a given month (for example, 31 September). *Internal references:* [MTGE-657](https://mambucom.jira.com/browse/MTGE-657) #### Interest due on grace instalments now correct for balloon accounts with zero outstanding balance Fixed an issue where incorrect interest due amounts were calculated on grace instalments for balloon accounts when the outstanding balance was zero. *Internal references:* [LPRC-3142](https://mambucom.jira.com/browse/LPRC-3142) #### Full due repayment on RNI loan accounts no longer reduces the number of instalments Fixed an issue where repaying the full amount due on a loan account with Reduce Number of Instalments (RNI) incorrectly decreased the instalment count. *Internal references:* [LPRC-2879](https://mambucom.jira.com/browse/LPRC-2879) #### Penalty now applied correctly when penalty rate is zero and Mambu Functions are used Fixed an issue where penalties were not applied during end-of-day processing when the penalty rate was set to zero for customers using Mambu Functions for penalty calculation. *Internal references:* [LPRC-3097](https://mambucom.jira.com/browse/LPRC-3097) --- ### Deposits #### Transactions of type Loan Fraction Sold with multiple buyers now load without error The `/deposits/transactions:search` and `/deposits//transactions` endpoints no longer return an error when loading transactions of type **Loan Fraction Sold** with multiple buyers. *Internal references:* [DO-461](https://mambucom.jira.com/browse/DO-461) --- ### Notifications #### Failed notifications now correctly included in re-enqueue operations Fixed an issue where the re-enqueuing mechanism triggered via `/communications/messages:resendAsyncByDate` and `/communications/messages:resendAsyncByKeys` processed only messages in the `SENDING_ASYNC` state; it now correctly includes `FAILED` messages as well. *Internal references:* [NTF-2999](https://mambucom.jira.com/browse/NTF-2999) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.167 cycle. ## v9.167.10 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Mortgages #### Pay-off amount now updates correctly for future dates The total pay-off amount in the **Preview Payoff** dialog now updates accurately when a future date is selected or interest is adjusted, resolving an issue where the amount remained unchanged regardless of input. *Internal references:* [MTGE-921](https://mambucom.jira.com/browse/MTGE-921) --- ## v9.167.9 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration change. --- ## Bug fixes ### Lending #### Repayments made before instalment generation now correctly reflected on schedule Fixed the schedule in cases when a payment or fee occurs before the generation of the instalment, and the product is configured to have a billing cycle, to ensure that transactions are correctly reflected on the schedule. *Internal references:* [REV-4015](https://mambucom.jira.com/browse/REV-4015) --- ## v9.167.8 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Mortgages #### Pay-off amount now updates correctly when selecting future dates The total pay-off amount in the **Preview Payoff** dialog now recalculates accurately when a future date is selected or interest is adjusted, resolving an issue where the amount remained static regardless of input changes. *Internal references:* [MTGE-921](https://mambucom.jira.com/browse/MTGE-921) #### Interest balance displayed correctly based on arrears configuration The **Interest balance** and **Total balance** shown on the Loan Summary page no longer incorrectly include the arrears balance unless **Decouple Interest from Arrears** is enabled, ensuring the displayed figures accurately reflect the loan's configuration. *Internal references:* [MTGE-881](https://mambucom.jira.com/browse/MTGE-881) #### Dynamic loans without pre-payment acceptance can now be created and edited Resolved an issue where dynamic loan products configured to not accept pre-payments could not be created or edited due to a validation step incorrectly rejecting the resulting field state, restoring full product configuration capability for these loan types. *Internal references:* [MTGE-847](https://mambucom.jira.com/browse/MTGE-847) --- ## v9.167.7 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration and infrastructure changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Data #### Accurate interest balance displayed on the Loan Summary page Resolved an issue where the **Interest balance** and **Total balance** shown on the Loan Summary page incorrectly included the arrears balance regardless of configuration. The arrears balance is now only added to the total balance when the **Decouple Interest from Arrears** option is enabled. *Internal references:* [MTGE-881](https://mambucom.jira.com/browse/MTGE-881) #### Dead database connections are now automatically dropped during failover Resolved an issue where a database failover occurring mid-query could cause tenant master connections to hang indefinitely; affected connections are now automatically dropped and recovered. *Internal references:* [BKE-271](https://mambucom.jira.com/browse/BKE-271) --- ## v9.167.6 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Lending #### Backdated repayments now correctly refresh the schedule Fixed an issue where backdated repayment transactions did not automatically refresh the schedule, causing incorrect account due amounts. *Internal references:* [REV-3964](https://mambucom.jira.com/browse/REV-3964) #### Loan product configuration-as-code updates now work with custom predefined fees Fixed an issue where the Loan Product CasC `PUT` endpoint failed to update loan products that included a custom predefined fee. *Internal references:* [LPRC-2930](https://mambucom.jira.com/browse/LPRC-2930) --- ## v9.167.5 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Improvements ### Data #### Groundwork for upcoming features - Groundwork for transferring deposit account ownership, including product availability and activation validation. --- ## v9.167.4 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Internal data and configuration maintenance. --- ## Improvements ### Mortgages #### Prepayment allocation order no longer bleeds across loan products The UI field for prepayment allocation was not properly initialised, causing it to display the allocation order from a previously edited loan product instead of the current one. This could prevent saving changes to a loan product that already had active loan accounts, since the prepayment allocation order cannot be modified once accounts exist — this issue has now been resolved. *Internal references:* [MTGE-610](https://mambucom.jira.com/browse/MTGE-610) --- ## v9.167.3 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Clients and Groups #### Branch validation enforced for groups Group records are now validated against branch constraints, preventing mismatches between a group and its assigned branch. *Internal references:* [DIF-1852](https://mambucom.jira.com/browse/DIF-1852) --- ## v9.167.2 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Deposits #### Error resolved when transferring deposit accounts to groups Transferring deposit account ownership to a group no longer triggers an internal error. *Internal references:* [DIF-1851](https://mambucom.jira.com/browse/DIF-1851) --- ## v9.167.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Improved request reliability during releases During a release, requests forwarded to machines scheduled for replacement will no longer return errors — the machine now waits until any in-progress request is complete before terminating. *Internal references:* [BKE-205](https://mambucom.jira.com/browse/BKE-205) #### Additional work - Non-customer-facing internal configuration and search architecture changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing configuration changes. ---

    Database changes

    | Table | Changes | |---|---| | `ips_cash_flow_calculation_cycle` | • Added column `ALLOCATION_PERCENTAGE` | | `ips_cash_flow_pool_settings` | • Removed foreign key `FK_IPS_CASH_FLOW_POOL_SETTINGS_POOL_ID`
    • Removed foreign key `FK_IPS_CASH_FLOW_POOL_SETTINGS_CASH_FLOW_SETTINGS_ID` | | `ips_cash_flow_settings` | • Removed foreign key `FK_IPS_CASH_FLOW_ID`
    • Removed foreign key `FK_IPS_CASH_FLOW_SETTINGS_GL_ACCOUNT_ENCODEDKEY` | | `ips_deduction_settings` | • Removed foreign key `FK_IPS_DEDUCTION_SETTINGS_DEDUCTION_ID`
    • Removed foreign key `FK_IPS_DEDUCTION_SETTINGS_GL_ACCOUNT_ENCODEDKEY` | | `ips_internal_cycle` | • Added index `INTERNALCYCLE_PAYMENTCYCLEID_PRODUCTCYCLEID_UNIQUE_IDX`
    • Removed column `STATUS_VAL`
    • Added column `AVERAGE_BALANCE` | | `ips_pool_settings` | • Removed foreign key `FK_IPS_POOL_POOL_ID_KEY`
    • Removed foreign key `FK_IPS_POOL_BANK_INVESTMENT_PL_ACCOUNT_ENCODEDKEY_KEY` | | `ips_product_settings` | • Removed foreign key `FK_IPS_PRODUCT_SETTINGS_SAVINGS_PRODUCT_ENCODEDKEY` | | `ips_system_options` | • Removed foreign key `FK_IPS_SYSTEM_OPTIONS_PROFIT_SUSPENSE_ACCOUNT_ENCODEDKEY`
    • Removed foreign key `FK_IPS_SYSTEM_OPTIONS_RESERVE_ACCOUNT_ENCODEDKEY` | | `task` | • Added index `TASK_TASKLINKTYPE_TASKLINKKEY_STATUS_IDX` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.168 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.168/ This page contains the following releases for v9.168: * [v9.168](#v9168) * [v9.168.6](#v91686) * [v9.168.5](#v91685) * [v9.168.4](#v91684) * [v9.168.3](#v91683) * [v9.168.2](#v91682) * [v9.168.1](#v91681) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.168 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Reduced request errors during deployments During a release, requests forwarded to machines that are scheduled for replacement could return errors if the machine received a termination signal mid-request. The machine now waits for any in-progress request to complete before terminating, eliminating these transient errors. *Internal references:* [BKE-205](https://mambucom.jira.com/browse/BKE-205) #### Groundwork for upcoming features - Building compound interest support with daily rest for mortgage loans, including new interest and PMT calculation formulas, fee capitalisation, and overpayment handling for both DBEI and IOEI loan types. - Extending Interest from Arrears (IFA) allocation to DBEI loans with Principal & Interest, including product creation and update support in both the UI and API. - Enabling interest application on a custom date for dynamic DBEI loans, including prepaid interest accounting and schedule and balance updates. - Introducing a feature toggle to allow fees to be excluded from automatic addition to the next instalment. - Adding semi-annual compounding frequency support for compounding interest loans. - Expanding schedule update test coverage for loans with DBEI and RAI/RNI prepayment calculation methods. - Building out IPS account payment cycle management, including creation logic review and job metrics. - Improving IPS balance calculation reliability, including query timeout handling, average balance optimisation, and prevention of overlapping hourly jobs. - Restricting deletions in the IPS configuration tree to improve configuration consistency. - Implementing IPS profit distribution logic, including customer share tiers, general ledger entry logging per product, and profit aggregation per product. - Implementing EOD profit-sharing job enhancements, including general ledger entry execution and clean-up of distribute-profit tasks after the retention period. - Implementing handling for missing calculation cycles in the IPS calculation flow. - Integrating deposit account UI changes for IPS products and accounts. - Introducing a contract provider to decouple the Flexible Schedule Engine from the `FlexibleScheduleContract` in preparation for schedule regeneration after exceptions. - Replacing a legacy interest availability feature toggle with an updated implementation in the index interest review service. - Implementing a login dialog prompting users to supply a mandatory email address. - Improving the magic search experience with multiple enhancements, including fixing result-box display on repeated input, correcting search status during text restriction scenarios, and making the `type` parameter mandatory on the `GET /api/search` endpoint. - Laying groundwork for migrating the CBE UI from GWT to React, including deferred rendering support in the React–GWT bridge and reorganisation of migration scaffolding. - Removing the superseded `useLendingImprovedQueryEod` feature toggle, replaced by `eodLoansOnWorkerUsePagination`. - Investigating JFR event streaming to observability tooling for continuous tenant profiling. - Adding batch-processing metrics and investigating slow queries identified during performance testing for the set-based deposits EOD job. - Fine-tuning the savings transactions custom fields archival job, including multi-threaded execution, replication lag awareness, and new runtime configuration options. - Extending the OpenAPI v3 Swagger generation endpoint to cover the remaining API resources. - Detecting transactions with incorrectly applied interest as part of the Zero Broken Accounts policy. - Building refund-with-fees support for the revolving loans refund process. #### Additional work - Non-customer-facing internal maintenance and configuration changes. --- ## Improvements ### Data #### Deposits backdating no longer blocked by pending authorization holds Backdating a deposit account no longer fails when authorization holds are pending, ensuring back-office corrections and adjustments can proceed without manual workarounds. *Internal references:* [DIF-1824](https://mambucom.jira.com/browse/DIF-1824) #### Stored XSS vulnerability resolved in the admin views interface A stored cross-site scripting vulnerability in the manage-all-views admin tab has been patched, improving platform security. *Internal references:* [CDO-3926](https://mambucom.jira.com/browse/CDO-3926) #### Faster notification generation through organisation information caching Placeholder processing time when generating notification message bodies is reduced by caching general organisation information, benefiting all message types including event streaming. *Internal references:* [NTF-3053](https://mambucom.jira.com/browse/NTF-3053) #### Custom field placeholders now processed in bulk during notification creation Custom field placeholders in notifications are now processed in bulk, improving efficiency and consistency when creating notifications with multiple placeholders. *Internal references:* [NTF-3080](https://mambucom.jira.com/browse/NTF-3080) #### Withdrawal endpoint now renders notifications asynchronously The deposits withdrawal endpoint processes notifications asynchronously, increasing throughput and reducing response latency under concurrent load. *Internal references:* [BKE-185](https://mambucom.jira.com/browse/BKE-185) #### Groundwork for upcoming features - Groundwork for overpayment threshold support for DBEI (capital repayment) loans, including PMT adjustment settings and RAI overpayment scenarios. - Groundwork for transferring deposit account ownership, including product availability and activation validations. - Groundwork for safely applying flexible schedule engine behaviour to existing accounts. - Groundwork for Islamic Banking IPS calculation flow, including cycle information per pool on the proposal page and profit-sharing job improvements. - Groundwork for improved multicurrency interest accrual rounding in journal entries when the Accounting in Multicurrency feature is active. - Groundwork for end-of-day deposit interest accrual reflected in journal entries, validated through integration tests. - Groundwork for accurate accounting rate retrieval when duplicate rates with a null end date exist. #### Additional work - Non-customer-facing internal maintenance, infrastructure, and configuration changes across data, search, feature toggles, build tooling, and platform services. --- ## Bug fixes ### Lending #### Schedule correctly reflects transactions when a refund follows a repayment Fixed an issue where a refund occurring after a repayment was not correctly reflected on the schedule, causing incorrect interest or principal values. *Internal references:* [REV-4056](https://mambucom.jira.com/browse/REV-4056) #### Loan product APIs now return user-friendly validation errors The create and update loan product endpoints previously returned an internal error when the fault was due to invalid user input; they now return the relevant validation exception instead. *Internal references:* [REV-3724](https://mambucom.jira.com/browse/REV-3724) #### Recalculate button now works when editing the due date on revolving accounts Revolving accounts with **Edit Schedule** enabled can now correctly recalculate the schedule before saving changes. *Internal references:* [REV-3031](https://mambucom.jira.com/browse/REV-3031) #### Edit Schedule now shows future pending installments for dynamic products Resolved an issue where future installments in **Pending** status were not visible when editing the schedule on a dynamic product. *Internal references:* [MTGE-988](https://mambucom.jira.com/browse/MTGE-988) #### Interest from arrears no longer double-counted during refinance During the refinance and reschedule flow, interest from arrears was being counted twice because it was already included in the interest balance; this has been corrected so it is only applied once. *Internal references:* [MTGE-953](https://mambucom.jira.com/browse/MTGE-953) #### Edit Due Dates now works correctly for interest-only equal installment broken interest scenarios Resolved an issue preventing due date edits from being applied on loans using an interest-only equal installment configuration with broken interest periods. *Internal references:* [MTGE-922](https://mambucom.jira.com/browse/MTGE-922) #### Schedule preview API now works when the Redraw option is enabled The `POST /loans/schedule:preview` endpoint was failing during loan account creation when the **Redraw** option was configured on the loan product; this has been resolved. *Internal references:* [LL-4977](https://mambucom.jira.com/browse/LL-4977) #### Schedule now computed correctly when amortisation period and flexible schedule are both configured Fixed an incorrect schedule calculation that occurred when an amortisation period was defined and the flexible schedule toggle was enabled. *Internal references:* [LL-4760](https://mambucom.jira.com/browse/LL-4760) #### Null periodic payment now accepted when previewing Optimised Payments schedule When calling `POST /loans/schedule:preview` with the **Optimised Payments** amortisation method, null values for the periodic payment field are now accepted; previously this incorrectly returned a `MANDATORY_PERIODIC_PAYMENT` error. *Internal references:* [LL-4617](https://mambucom.jira.com/browse/LL-4617) #### Schedule correctly reflects early payments made before installment generation Fixed the schedule for products configured with a billing cycle, where a payment or fee occurring before installment generation was not correctly reflected once the installment was created. *Internal references:* [REV-4015](https://mambucom.jira.com/browse/REV-4015) #### Compound interest calculations corrected for loans with interest from arrears decoupling Resolved multiple calculation errors affecting loans with compound interest (daily balance) and decoupled interest from arrears, including incorrect use of the previous installment's interest, wrong balance used for payment computation after an interest rate change, and incorrect interest computation following an interest rate change transaction. *Internal references:* [MTGE-930](https://mambucom.jira.com/browse/MTGE-930), [MTGE-907](https://mambucom.jira.com/browse/MTGE-907), [MTGE-902](https://mambucom.jira.com/browse/MTGE-902) #### `decoupleInterestFromArrears` field now visible and preserved correctly in loan product forms Fixed two issues: the `decoupleInterestFromArrears` field was not initially visible when editing a loan product in the UI, and the field was being set to null when updating a loan account. *Internal references:* [MTGE-911](https://mambucom.jira.com/browse/MTGE-911), [MTGE-897](https://mambucom.jira.com/browse/MTGE-897) #### Accrue Late Interest option no longer shown when it is mandatory The **Accrue Late Interest** option is no longer displayed as a configurable choice in the UI when it is set as mandatory on the loan product. *Internal references:* [MTGE-835](https://mambucom.jira.com/browse/MTGE-835) #### Pre-payment configuration fields now behave consistently across loan product types The dependency mechanism for pre-payment configuration fields in the repayment collection section has been reworked to ensure consistent behaviour across different combinations of loan product type and interest type, and to resolve a bug that prevented disbursement of DBEI loans with interest application on a custom date. *Internal references:* [MTGE-558](https://mambucom.jira.com/browse/MTGE-558) #### `decoupleInterestFromArrears` option now only visible for Interest Only loan products The `decoupleInterestFromArrears` configuration option is now correctly restricted to loan products of the **Interest Only** type. *Internal references:* [MTGE-758](https://mambucom.jira.com/browse/MTGE-758) #### Backdated full repayment and running schedule values now processed correctly Fixed a broken running schedule value for `PAYMENT_MADE` and `PENALTY_RATE_CHANGED` transactions, and resolved an error incorrectly thrown when performing a backdated correct full repayment. *Internal references:* [LPRC-3377](https://mambucom.jira.com/browse/LPRC-3377), [LPRC-2863](https://mambucom.jira.com/browse/LPRC-2863) #### Changing the number of installments no longer affects partially paid installments Resolved an issue where modifying the number of installments incorrectly impacted a partially paid installment, and a separate issue where a non-grace installment could end up with a zero principal value. *Internal references:* [LL-4948](https://mambucom.jira.com/browse/LL-4948), [LL-4939](https://mambucom.jira.com/browse/LL-4939) #### Edit Schedule V2 API now respects organisation timezone for due dates The Edit Schedule V2 API was incorrectly converting the `dueDate` field to UTC, causing issues for tenants in non-UTC timezones; the `dueDate` is now used directly as the organisation's local time. *Internal references:* [LL-3366](https://mambucom.jira.com/browse/LL-3366) #### Additional work - Non-customer-facing lending maintenance. --- ### Mortgages #### Short month interest rate option now formatted correctly on loan product overview Fixed a display formatting issue with the **Short Month Handling** interest rate option on the loan product overview page. *Internal references:* [MTGE-799](https://mambucom.jira.com/browse/MTGE-799) --- ### Deposits #### Transfer deposit account ownership now handles groups and client IDs correctly Resolved multiple errors in the deposit account ownership transfer flow: branch validation is now enforced when transferring to groups, an internal error when transferring to a group has been fixed, and an internal error thrown when a client ID was used in the transfer ownership operation has been resolved. *Internal references:* [DIF-1852](https://mambucom.jira.com/browse/DIF-1852), [DIF-1851](https://mambucom.jira.com/browse/DIF-1851), [DIF-1826](https://mambucom.jira.com/browse/DIF-1826) --- ### Clients and Groups #### Magic search results now maintain a consistent order Fixed an issue where magic search results did not preserve a stable order when multiple results were returned. *Internal references:* [CDO-4140](https://mambucom.jira.com/browse/CDO-4140) --- ### Islamic Banking #### Payment cycle creation now uses the correct period Resolved issues where account payment cycles were being created with an incorrect period, and fixed underlying batch SQL problems affecting cycle creation. *Internal references:* [IB-1894](https://mambucom.jira.com/browse/IB-1894), [IB-1868](https://mambucom.jira.com/browse/IB-1868) #### Average balances now calculated correctly in profit calculation Fixed an issue where incorrect average balances were being used during profit calculation. *Internal references:* [IB-1860](https://mambucom.jira.com/browse/IB-1860) #### Profit calculation now includes newly added products and accounts Resolved an issue where products and accounts added after the initial setup were not being considered in profit calculations. *Internal references:* [IB-1852](https://mambucom.jira.com/browse/IB-1852) #### Pool can now be added to Income and Expense (Cash Flow) Fixed an issue that prevented a pool from being added to the **Income & Expense (Cash Flow)** section. *Internal references:* [IB-1837](https://mambucom.jira.com/browse/IB-1837) #### Search now available on the proposals page A **Search** button has been added to the proposals page to allow users to filter and locate proposals more efficiently. *Internal references:* [IB-1844](https://mambucom.jira.com/browse/IB-1844) #### Product type now correctly restricted when profit sharing is enabled Fixed an issue where the product type was not being restricted as expected when profit sharing was marked on the product. *Internal references:* [IB-1808](https://mambucom.jira.com/browse/IB-1808) #### Additional work - Internal Islamic Banking UI maintenance. --- ### Notifications #### Additional work - Internal notifications maintenance. --- ### Developer #### Dead database connections now automatically dropped on failover Hanging database connections that occur when a query is in flight during a database failover are now automatically dropped, preventing indefinite hangs. *Internal references:* [BKE-271](https://mambucom.jira.com/browse/BKE-271) #### Additional work - Internal developer platform maintenance. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.168 cycle. ## v9.168.6 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance. --- ## v9.168.5 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data migration work. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Lending #### Custom repayments now correctly process fees not yet due The allocation check during repayment processing has been corrected to allow fees to be repaid even when they are not yet due in the schedule, resolving failures in custom repayments that included both principal and fee components. *Internal references:* [REV-4187](https://mambucom.jira.com/browse/REV-4187) --- ## v9.168.4 **Release Date**: 03.06.2026 --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data fixes. --- ## v9.168.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration and tuning changes. --- ## Bug fixes ### Mortgages #### Editing a dynamic product schedule now correctly displays future pending installments When editing a schedule for a dynamic product, future installments in a pending status are now visible as expected. *Internal references:* [MTGE-988](https://mambucom.jira.com/browse/MTGE-988) --- ## v9.168.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Search archived transactions with custom field data The `api/deposits/transactions:search` endpoint now includes archived custom fields in its results, ensuring that historical transaction data remains fully accessible and queryable after archival. *Internal references:* [ADM-3809](https://mambucom.jira.com/browse/ADM-3809) #### Additional work - Internal data configuration and health check improvements. --- ## Bug fixes ### Data #### Groundwork for upcoming features - Foundational work toward fine-tuned archival behaviour for savings transaction custom fields in Deposits. --- ## v9.168.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Groundwork for upcoming features - Foundational work toward fine-tuned archival behaviour for Savings Transactions custom fields. --- ## Improvements ### Data #### Groundwork for upcoming features - Scalability improvements to the Anomaly Detection Tool to support daily execution runs. --- ## Bug fixes ### Mortgages #### Interest from arrears no longer double-counted during refinance During the refinance and reschedule flow, interest from arrears was incorrectly added twice because it was already included in the interest balance. This fix ensures the interest from arrears is not counted again when calculating the total sum. *Internal references:* [MTGE-953](https://mambucom.jira.com/browse/MTGE-953) --- ### Deposits #### Dormancy job now evaluates transaction dates using organization time The deposit account dormancy job previously used UTC time when validating the last transaction entry date, which could cause incorrect dormancy assessments for organizations in non-UTC time zones. It now correctly uses organization time for this evaluation. *Internal references:* [DO-478](https://mambucom.jira.com/browse/DO-478) ---

    Database changes

    | Table | Changes | |---|---| | `ips_account_payment_cycle` | • Added column `ASSIGNED_BRANCH_KEY` | | `ips_internal_cycle` | • Added index `IPS_INTERNAL_CYCLE_PRODUCT_CALCULATION_CYCLE_ID_IDX`
    • Table removed
    • Renamed column `AVERAGE_BALANCE` → `CALCULATED_BALANCE`
    • Added column `LAST_BALANCE_CALCULATION_DATE` | | `ips_product_calculation_cycle` | • Added index `IPS_PRODUCT_CALCULATION_CYCLE_PROD_KEY_POOL_CYCLE_ID_UNIQUE_IDX` | | `savings_transactions_daily_summary` | • Added index `SAVINGS_TRANSACTIONS_DAILY_SUMMARY_ENTRY_DATE_INDEX` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.169 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.169/ This page contains the following releases for v9.169: * [v9.169](#v9169) * [v9.169.3](#v91693) * [v9.169.2](#v91692) * [v9.169.1](#v91691) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.169 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Search loan transactions by parent account holder Users can now filter results in the Search Loan Transactions V2 API using the `PARENT_ACCOUNT_HOLDER_KEY` field, making it easier to retrieve all transactions associated with a specific parent account holder. *Internal references:* [LL-4066](https://mambucom.jira.com/browse/LL-4066) #### Additional work - Non-customer-facing data and infrastructure changes. --- ### Mortgages #### Fees can be excluded from automatic installment allocation By default, fees are allocated to the next installment in the repayment schedule. Manual fees can now be configured at the product level to remain unallocated, appearing instead on a dedicated **Non-Allocated Fees** balance that is only reduced through a targeted manual repayment or during pay-off, write-off, refinance, or reschedule operations. *Internal references:* [MTGE-407](https://mambucom.jira.com/browse/MTGE-407) #### Groundwork for upcoming features - Building support for deferred interest income accounting bookings on Interest Only Equal Installments loans, including transaction accounting details and logging for interest applied and repayment events. - Advancing overpayment threshold handling for capital repayment loans, including updated PMT calculations and principal-plus-interest processing alongside manual interest application before overpayment. - Extending interest-on-a-custom-date functionality with repayment enhancements for due-date scenarios and schedule calculation before and after disbursement. - Laying the groundwork for RAI and ILI availability gating behind the FSE feature toggle, and for prepayment validation against configured prepayment acceptance values. #### Additional work - Non-customer-facing mortgage refactoring and test improvements. --- ### Lending #### Groundwork for upcoming features - Building equal-instalment support for longer first periods across the loan schedule for simple interest loans, including new data model fields for interest carry-forward at both product and account level and API updates to the loan product v2 endpoint. #### Additional work - Non-customer-facing lending maintenance and internal tooling work. --- ### Islamic Banking #### Groundwork for upcoming features - Progressing proposal creation capabilities, including API endpoints to fetch proposals, service and repository layers for creating or retrieving default proposals, and UI views for proposal listing and details. - Advancing profit distribution configuration consistency, including payment frequency support in product configuration and profit calculation, and renaming of share tier terminology throughout the backend and UI. - Extending end-of-day profit sharing jobs with cycle deletion and recreation capabilities. - Applying fixed profit rate rules and capped rate logic to the customer share calculation in the profit distribution service, with corresponding UI updates. - Improving balance calculation accuracy by incorporating transaction adjustments into summary updates. - Optimising the IPS calculation flow by using the GL journal entries summary to derive cash flow totals. --- ### Deposits #### Groundwork for upcoming features - Building the UI component for transferring deposit account ownership, including the **Transfer Ownership** button. --- ### Developer #### Additional work - Internal search API test and enhancement work. --- ### Payments #### Additional work - Non-customer-facing backend fixes to advance/arrears position and redraw balance calculations for payment transactions. --- ### Transactions and Interest #### Additional work - Non-customer-facing internal refactoring of grace installments handling and stream utility improvements. --- ### Data > **Note:** The following items were grouped under the general Data section above. The caching, archiving, and FSE refactor work is captured below. #### Additional work - Non-customer-facing configuration caching, archiving defaults tuning, and backend refactoring. --- ## Improvements ### Data #### Unauthorised deletion of custom admin views is now prevented A security vulnerability that allowed an attacker to delete admin views via an insecure direct object reference on the custom view management endpoint has been resolved. *Internal references:* [CDO-4105](https://mambucom.jira.com/browse/CDO-4105) #### Additional work - Internal data maintenance and backend-only fixes. --- ## Bug fixes ### Mortgages #### Prepayment recalculation method no longer appears on unsupported loan product types The **Choose prepayment recalculation method at repayment time** option is no longer incorrectly displayed on Dynamic Term Loan and Interest Only loan products, which do not support this setting. *Internal references:* [MTGE-1097](https://mambucom.jira.com/browse/MTGE-1097), [MTGE-966](https://mambucom.jira.com/browse/MTGE-966) #### Prepayment recalculation dropdown now shows the correct value when editing a loan product The prepayment recalculation dropdown no longer incorrectly displays **No recalculation method** when editing an existing loan product. *Internal references:* [MTGE-959](https://mambucom.jira.com/browse/MTGE-959) #### IOEI schedule preview now includes all columns for undisbursed accounts The `interestAccrued` and `closingBalance` columns are no longer missing from the Interest Only with Equal Instalments (IOEI) schedule preview when editing an undisbursed account. *Internal references:* [MTGE-963](https://mambucom.jira.com/browse/MTGE-963) #### Fee capitalisation transactions now retain their type after bulk reversal and reapplication Previously, accounts would lose fee capitalised transaction types if there were bulk adjustments; the system now maintains the state of fee capitalised transactions after a bulk adjustment. *Internal references:* [MTGE-945](https://mambucom.jira.com/browse/MTGE-945) #### Fee capitalisation without a fixed amount now correctly increases the principal balance Applying fee capitalisation using a fee configured without an amount now correctly increases the principal balance at the account level. *Internal references:* [MTGE-943](https://mambucom.jira.com/browse/MTGE-943) #### Schedule recalculation is now correct when multiple fee capitalisation transactions occur on the same day Posting a second fee capitalisation transaction on the same day as the first no longer produces an incorrectly recalculated schedule. *Internal references:* [MTGE-942](https://mambucom.jira.com/browse/MTGE-942) #### Compound interest now correctly accounts for previously applied interest Interest that has already been applied is now taken into consideration when computing subsequent interest on loans with the Compound interest type, preventing understated interest calculations. *Internal references:* [MTGE-947](https://mambucom.jira.com/browse/MTGE-947) #### Interest Application Date for the last instalment no longer falls after the due date The Interest Application Date for the final instalment is now correctly constrained so that it does not exceed the instalment due date. *Internal references:* [MTGE-939](https://mambucom.jira.com/browse/MTGE-939) #### Product types that do not support flexible schedule engine are now prevented from using fee capitalisation Loan product types incompatible with the flexible schedule engine can no longer be configured with fee capitalisation, preventing invalid product configurations. *Internal references:* [MTGE-989](https://mambucom.jira.com/browse/MTGE-989) #### Additional work - Non-customer-facing internal maintenance and build fixes. --- ### Lending #### Custom fields can now be updated via the v2 API on Payment Plan, Tranche, and blacklisted-client loan accounts `PATCH` requests to update custom fields via API v2 now work correctly for Fixed Term Loans configured with a Payment Plan, Tranche Loan accounts, and loan accounts belonging to blacklisted clients. *Internal references:* [LL-3907](https://mambucom.jira.com/browse/LL-3907), [LL-3906](https://mambucom.jira.com/browse/LL-3906), [LL-1549](https://mambucom.jira.com/browse/LL-1549) #### Interest rate change to 0% on the disbursement date no longer occurs when a new IRC is applied An interest rate change that incorrectly set the rate to 0% on the disbursement date when a new Interest Rate Change (IRC) was introduced has been resolved. *Internal references:* [LPRC-2911](https://mambucom.jira.com/browse/LPRC-2911) #### Interest Rate Changes are now reflected on undisbursed schedules IRCs are now correctly applied and visible when previewing the schedule of an undisbursed loan account. *Internal references:* [FSE-549](https://mambucom.jira.com/browse/FSE-549) #### Previewing a schedule while editing an account no longer overrides the persisted schedule Generating a schedule preview during account editing no longer overwrites the saved schedule, ensuring that the stored schedule remains intact until explicitly confirmed. *Internal references:* [FSE-554](https://mambucom.jira.com/browse/FSE-554) #### Transient fields are no longer included in schedule output Internal transient fields are no longer present in the schedule response, ensuring cleaner and more accurate output for consumers of schedule data. *Internal references:* [FSE-529](https://mambucom.jira.com/browse/FSE-529) #### Additional work - Non-customer-facing internal fixes and maintenance. --- ### Deposits #### Adjusting the most recent transaction before an account transfer is now correctly prevented The UI now blocks attempts to adjust the latest transaction on an account that is pending an ownership transfer, preventing data inconsistencies. *Internal references:* [DIF-1922](https://mambucom.jira.com/browse/DIF-1922) #### Available balance is now consistent between the UI and API The overdraft limit query has been corrected so that the available balance displayed in the UI matches the value returned by the API. *Internal references:* [DO-158](https://mambucom.jira.com/browse/DO-158) --- ### Islamic Banking #### Profit distribution calculations now produce correct results Multiple issues affecting profit distribution accuracy have been resolved: ledger entry logging dates are now correctly shifted, payment cycle profit is calculated using the correct number of cycle days, the last day of the month is no longer skipped in monthly cycle calculations, and balance handling during profit calculation is now correct. *Internal references:* [IB-2029](https://mambucom.jira.com/browse/IB-2029), [IB-2009](https://mambucom.jira.com/browse/IB-2009), [IB-1998](https://mambucom.jira.com/browse/IB-1998), [IB-1978](https://mambucom.jira.com/browse/IB-1978) #### End-of-day profit sharing job can now be triggered correctly via the Run Job button The **Run Job** button now correctly triggers the full IPS (Islamic Profit Sharing) end-of-day calculation, resolving an issue where the job was not being initiated. *Internal references:* [IB-2015](https://mambucom.jira.com/browse/IB-2015) #### IPS configuration and account management issues resolved Several issues with Islamic Profit Sharing setup and account management have been fixed: the capped rate rule is no longer incorrectly required when **Use the calculated rate** is selected, deposit transactions can now be posted to approved Islamic accounts, IPS Savings Products can now be created, income/expense pool percentage allocations can now be edited, and the IPS accounts list now correctly reflects all account statuses. *Internal references:* [IB-1996](https://mambucom.jira.com/browse/IB-1996), [IB-1972](https://mambucom.jira.com/browse/IB-1972), [IB-1942](https://mambucom.jira.com/browse/IB-1942), [IB-1933](https://mambucom.jira.com/browse/IB-1933), [IB-1879](https://mambucom.jira.com/browse/IB-1879) --- ### Accounting #### Exchange rate errors now return a specific error code An explicit return code is now provided when an `ExchangeRateException` occurs, making it easier to identify and handle exchange rate errors programmatically. *Internal references:* [ADM-3804](https://mambucom.jira.com/browse/ADM-3804) #### Journal entries can no longer be posted against deactivated branches Attempting to `POST` journal entries to a deactivated branch is now correctly rejected, preventing invalid accounting entries. *Internal references:* [LED-2376](https://mambucom.jira.com/browse/LED-2376) #### Additional work - Non-customer-facing internal maintenance. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.169 cycle. ## v9.169.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Mortgages #### Payment holidays now apply correctly for Mutual Vision Payment holidays failed to take effect under certain conditions; this has been resolved so that payment holiday configurations are honoured as expected. *Internal references:* [MTGE-1073](https://mambucom.jira.com/browse/MTGE-1073) #### Additional work - Non-customer-facing internal maintenance. --- ## v9.169.2 **Release Date**: 03.06.2026 --- ## Bug fixes ### Lending #### Custom repayments now correctly process fees not yet due The allocation check during repayment processing has been corrected to allow fees to be repaid even when they are not yet due in the schedule, resolving failures in custom repayment flows involving principal and fee combinations. *Internal references:* [REV-4187](https://mambucom.jira.com/browse/REV-4187) --- ## v9.169.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data maintenance. --- ## Bug fixes ### Mortgages #### Predefined fee configuration no longer gets stuck during product setup Fixed an issue where predefined fee configuration would become unresponsive or stuck when setting up a mortgage product. *Internal references:* [MTGE-1029](https://mambucom.jira.com/browse/MTGE-1029) ### Lending #### Interest rate no longer resets to 0% on the disbursement date Fixed an issue where a new interest rate change caused the interest rate to incorrectly revert to 0% on the loan disbursement date. *Internal references:* [LPRC-2911](https://mambucom.jira.com/browse/LPRC-2911) ---

    Database changes

    | Table | Changes | |---|---| | `ips_cash_flow_calculation_cycle` | • Added column `PROPOSAL_ID` | | `ips_customer_share_tier` | • Renamed from `ips_bank_share_tier` | | `ips_customer_share_tier_cycle` | • Renamed from `ips_bank_share_tier_cycle` | | `ips_pool_calculation_cycle` | • Added column `PROPOSAL_ID` | | `ips_product_calculation_cycle` | • Added column `PRODUCT_PAYMENT_POINT`
    • Added column `PROFIT_APPLICATION_POINT` | | `ips_product_settings` | • Added column `PRODUCT_PAYMENT_POINT`
    • Added column `PROFIT_APPLICATION_POINT` | | `loan_account_balance` | • New table
    • Added index `loan_account_balance_unique_id`
    • Added column `version` | | `predefinedfee` | • Added column `schedule_allocation_method`
    • Added column `interest_bearing`
    • Added column `schedule_allocation_method`
    • Added column `interest_bearing` | | `scheduleversion` | • Added column `SCHEDULE`
    • Added column `VERSION`
    • Added column `FINGERPRINT` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.170 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.170/ This page contains the following releases for v9.170: * [v9.170](#v9170) * [v9.170.4](#v91704) * [v9.170.3](#v91703) * [v9.170.2](#v91702) * [v9.170.1](#v91701) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.170 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### New API endpoint for loan account balances A new V2 API endpoint at `/loans//balances` returns loan account balances, including fees not yet allocated to a scheduled installment. The response structure mirrors existing balance fields in loan account results; see the [Loan account balance API migration guide](https://community.mambu.com/t/loan-account-balance-api-migration-guide/) for details. *Internal references:* [MTGE-808](https://mambucom.jira.com/browse/MTGE-808) #### Additional work - Non-customer-facing mortgage backend changes. ### Lending #### Additional work - Non-customer-facing lending backend changes. ### Islamic Banking #### Profit distribution calculation corrected Resolved an issue where `calculatedProfit` and `payableProfit` were handled incorrectly in the profit distribution service for account payment cycles. *Internal references:* [IB-2057](https://mambucom.jira.com/browse/IB-2057) #### Profit sharing job now returns accurate rate and balance values Fixed a bug where the IPS job completed successfully but reported a profit rate and average balance of zero in its results. *Internal references:* [IB-2050](https://mambucom.jira.com/browse/IB-2050) #### Customer share percentage configuration now initialises correctly Corrected the starting point for customer share percentage configuration, which was incorrectly defaulting to the bank share value instead of the customer share value. *Internal references:* [IB-2048](https://mambucom.jira.com/browse/IB-2048) #### Pool list display corrected when no pools exist Fixed incorrect information being shown in the pool list when no pools had been created. *Internal references:* [IB-1809](https://mambucom.jira.com/browse/IB-1809) #### Groundwork for upcoming features - Building out the Islamic Profit Sharing proposal creation workflow, including automatic proposal approval, default proposal generation, and integration of proposal details into the UI. - Extending the IPS end-of-day jobs with configuration validation prior to the manage cycles job execution. - Implementing the overpayment principal development feature toggle in preparation for non-scheduled overpayment allocation. #### Additional work - Non-customer-facing Islamic Banking backend changes. ### Developer #### Additional work - Internal backend performance and caching improvements. --- ## Improvements ### Data #### Additional work - Internal data and backend-only maintenance changes. ### Notifications #### Strengthened access controls prevent unauthorised template exposure A security vulnerability has been resolved where users with **Manage Streaming** permissions could access non-streaming notification templates by manipulating the URL; permissions are now strictly enforced to prevent unauthorised configuration exposure. *Internal references:* [NTF-3191](https://mambucom.jira.com/browse/NTF-3191) #### Groundwork for upcoming features - Building the activity logging infrastructure to support client and group notification subscription tracking. - Laying the groundwork for transfer account ownership functionality, including the owner selection pop-up UI. #### Additional work - Internal notifications monitoring, alerting, and maintenance work. --- ## Bug fixes ### Mortgages #### Correct interest rate displayed on loan account details Fixed an issue where an incorrect value was being displayed on the interest rates widget on the loan account details form. *Internal references:* [MTGE-1030](https://mambucom.jira.com/browse/MTGE-1030) #### Apply Interest button now visible for accounts with interest on a custom date Fixed an issue where the **Apply Interest** button was not visible for loan accounts configured to apply interest on a custom date. *Internal references:* [MTGE-1033](https://mambucom.jira.com/browse/MTGE-1033) #### Non-allocated fee repayments no longer incorrectly applied to fee balances Fixed an issue where non-allocated fee repayments were being incorrectly allocated against fee balances. *Internal references:* [MTGE-1023](https://mambucom.jira.com/browse/MTGE-1023) #### Additional work - Internal mortgage configuration and API fixes. --- ### Lending #### Custom repayments now correctly process fees not yet due Fixed an issue in repayment processing where the allocation check was failing for fees not yet due in the schedule; fees can now be repaid even when they have not yet reached their due date within custom repayments. *Internal references:* [REV-4187](https://mambucom.jira.com/browse/REV-4187) #### Interest rate no longer incorrectly reset to 0% on disbursement date Fixed an issue where the interest rate was being changed to 0% on the disbursement date when using the new interest rate change functionality. *Internal references:* [LPRC-2911](https://mambucom.jira.com/browse/LPRC-2911) #### Additional work - Internal lending configuration and interest rate change fixes. --- ### Deposits #### Search results no longer empty due to time zone conversion error Fixed a bug where the `useDateOffsetInsteadOfOrganizationOffset` toggle caused the `+00:00` time zone offset in payloads to be incorrectly converted to `Z` instead of `UTC`, which MySQL's `CONVERT_TZ` method does not recognise as a valid value, resulting in empty search results. *Internal references:* [DO-654](https://mambucom.jira.com/browse/DO-654) --- ### Access Control #### Additional work - Internal identity and access management fixes. --- ### Accounting #### Additional work - Internal accounting API fixes. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.170 cycle. ## v9.170.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Data #### Fee details now returned correctly in repayment API responses Fixed an issue where the Fees object was returned empty in the `makeRepayment` API response. The response now correctly includes detailed fee information associated with the repayment transaction. *Internal references:* [LPRC-3072](https://mambucom.jira.com/browse/LPRC-3072) #### Smarter input splitting in Magic Search Improved the input parsing logic in **Magic Search** to more accurately interpret and split search terms, reducing mismatches and returning more relevant results. *Internal references:* [CDO-4255](https://mambucom.jira.com/browse/CDO-4255) #### Additional work - Internal data revert with no customer-facing impact. --- ## v9.170.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing environment and configuration updates. --- ## v9.170.2 **Release Date**: 03.06.2026 --- ## Improvements ### Lending #### Holiday schedule updates now correctly recalculate repayment schedules When general holidays are added, affected loan repayment schedules are now updated as expected, preventing accounts from being left in an inconsistent state. *Internal references:* [LPRC-3769](https://mambucom.jira.com/browse/LPRC-3769) #### Allocation flow bug resolved A bug affecting allocation flows has been fixed, ensuring correct processing behaviour. *Internal references:* [REV-4237](https://mambucom.jira.com/browse/REV-4237) #### Additional work - Internal lending test and maintenance tasks. --- ## Bug fixes ### Data #### Interest no longer accrues on zero-balance revolving accounts When the `OPTIMIZE_INTEREST_RATE_PROVIDER_FOR_REVOLVING` setting is enabled, interest was incorrectly calculated on accounts with a zero balance; this has been resolved. *Internal references:* [REV-4205](https://mambucom.jira.com/browse/REV-4205) #### Adding or removing holidays no longer drops grace installments from the schedule A bug where modifying holidays caused grace installments to be removed from the loan repayment schedule has been fixed. *Internal references:* [LPRC-3763](https://mambucom.jira.com/browse/LPRC-3763) #### Excel export now reflects the same sort order as custom views Exported Excel files now match the column sort order displayed in custom views, ensuring consistency between on-screen data and downloaded reports. *Internal references:* [CDO-4271](https://mambucom.jira.com/browse/CDO-4271) --- ## v9.170.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data caching improvements. --- ## Bug fixes ### Mortgages #### Transaction queries correctly handle repayment as a filter value Filtering API transaction queries by repayment type now returns accurate results. *Internal references:* [MTGE-1079](https://mambucom.jira.com/browse/MTGE-1079) #### Additional work - Non-customer-facing data maintenance. ---

    Database changes

    | Table | Changes | |---|---| | `savings_transactions_daily_summary_offset` | • Renamed column `LAST_TRANSACTION_ID` → `BATCH_END_ID`
    • Added column `STATUS`
    • Added column `RETRIES`
    • Added column `BATCH_START_ID`
    • Added unique constraint on `BATCH_START_ID, BATCH_END_ID` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.171 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.171/ This page contains the following releases for v9.171: * [v9.171](#v9171) * [v9.171.4](#v91714) * [v9.171.3](#v91713) * [v9.171.2](#v91712) * [v9.171.1](#v91711) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.171 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Apply principal overpayments without allocating them to scheduled instalments Lenders can now apply non-scheduled principal overpayments directly to a loan balance without redistributing the amount across future scheduled instalments. A new **Principal Overpayment** menu option is available in the UI, and a corresponding API endpoint enables the same action programmatically. *Internal references:* [MTGE-977](https://mambucom.jira.com/browse/MTGE-977), [MTGE-978](https://mambucom.jira.com/browse/MTGE-978), [MTGE-979](https://mambucom.jira.com/browse/MTGE-979), [MTGE-1107](https://mambucom.jira.com/browse/MTGE-1107) #### Fees with no allocation method are now handled consistently across the loan lifecycle When a loan product uses the **No Allocation** fee method, fee capitalisation is now blocked at both the UI and API layers, and loan products configured this way must also permit custom payments. Balance-only fee balances are displayed correctly on the reschedule, refinance, payoff, and write-off screens, giving operations teams an accurate view of outstanding fee obligations at every stage. *Internal references:* [MTGE-783](https://mambucom.jira.com/browse/MTGE-783), [MTGE-782](https://mambucom.jira.com/browse/MTGE-782), [MTGE-1002](https://mambucom.jira.com/browse/MTGE-1002), [MTGE-1053](https://mambucom.jira.com/browse/MTGE-1053), [MTGE-1056](https://mambucom.jira.com/browse/MTGE-1056), [MTGE-1100](https://mambucom.jira.com/browse/MTGE-1100) --- ### Lending #### `CHANGE_INTEREST_RATE` placeholder now returns the correct pre-change rate Fixed an issue where the `CHANGE_INTEREST_RATE` placeholder in `INTEREST_RATE_CHANGE` event notification templates was returning a null value; it now correctly returns the original interest rate value prior to the rate-change transaction. *Internal references:* [LL-5131](https://mambucom.jira.com/browse/LL-5131) #### Streaming responses now available for loan transaction search APIs (Beta) When the `Accept` header is sent together with the `cursor=_` parameter, all matching data is streamed back in a single file and the connection remains open until the client disconnects or all records have been retrieved. Requests made without the `cursor` parameter continue to return only the first page as an octet stream. This capability is released in **Beta**. *Internal references:* [BKE-197](https://mambucom.jira.com/browse/BKE-197) #### Groundwork for upcoming features - Schedule calculation work for equal instalments across longer first periods under simple interest, covering loan creation, interest application, and prepayment scenarios. #### Additional work - Internal lending maintenance and tooling improvements. --- ### Islamic Banking #### Proposal visibility and account details accuracy restored Fixed multiple issues affecting the Islamic Profit Sharing proposal workflow: approved proposals are now visible in the UI, the **Get Proposal Account Details** API no longer returns an empty list after EOD jobs run, account details are correctly filtered by product, and displayed figures are accurate. *Internal references:* [IB-2069](https://mambucom.jira.com/browse/IB-2069), [IB-2071](https://mambucom.jira.com/browse/IB-2071), [IB-2079](https://mambucom.jira.com/browse/IB-2079), [IB-2107](https://mambucom.jira.com/browse/IB-2107), [IB-2111](https://mambucom.jira.com/browse/IB-2111) #### Proposal list now shows status information The proposal list view now displays the status of each proposal, giving users immediate visibility into where each proposal stands in the workflow. *Internal references:* [IB-2031](https://mambucom.jira.com/browse/IB-2031) #### Configurable column display for proposal account details Users can now choose which columns to display in the account details view and set the order in which they appear, enabling teams to tailor the layout to their operational needs. *Internal references:* [IB-1892](https://mambucom.jira.com/browse/IB-1892) #### Income and expenses details and graph An income and expenses breakdown with an accompanying graph is now available within the proposal workflow, providing a visual summary of financial flows. *Internal references:* [IB-1883](https://mambucom.jira.com/browse/IB-1883) #### Profit sharing calculation and cycle accuracy improved Resolved several issues in the Islamic Profit Sharing engine: cash flow cycles were being created using incorrect pool settings, pool cycles were generated for the wrong period, balance summaries were not created on the activation date or on the entry date of the first transaction, inactive accounts and non-financial transactions are now correctly excluded from calculations, and minimum and total balance calculations in internal cycles now produce accurate results. *Internal references:* [IB-2045](https://mambucom.jira.com/browse/IB-2045), [IB-2056](https://mambucom.jira.com/browse/IB-2056), [IB-2085](https://mambucom.jira.com/browse/IB-2085), [IB-2088](https://mambucom.jira.com/browse/IB-2088), [IB-2016](https://mambucom.jira.com/browse/IB-2016) #### Additional work - Internal Islamic Banking configuration and job processing fixes. --- ## Improvements ### Data #### Improved auto-recovery for message streaming Optimised the logic for reusing the message bus producer, reducing the time needed to automatically recover the application's streaming capabilities after an interruption. *Internal references:* [NTF-3207](https://mambucom.jira.com/browse/NTF-3207) #### Warning added when updating interest payment point for existing accounts A warning message is now displayed in the product settings **Confirm Changes** dialog when the interest payment point is updated for a product and applied to both new and existing accounts. *Internal references:* [DO-732](https://mambucom.jira.com/browse/DO-732) #### Groundwork for upcoming features - Improvements to the revolving recalculation API, including `cutOffDate` support and keep-alive handling for long-running recalculation processes, to support account repair workflows. - Enhancements to profit accrual calculation logic and payment cycle aggregation fields in preparation for profit proposal detail reporting in Islamic Banking. - Fixes to internal cycle creation logic to prevent runaway cycle generation when account and pool cycles are misaligned, as part of ongoing Islamic Banking stability work. - Schedule regeneration support and observability improvements for the Flexible Schedule Engine. - Groundwork for upcoming data migration import strategy improvements, including freeze operation handling. #### Additional work - Non-customer-facing internal maintenance, including feature toggle removals, module renames, logging adjustments, internal contract refactors, metric and alerting additions, code ownership updates, environment-specific configuration enablements, and build-level changes. --- ## Bug fixes ### Data #### Cursor pagination performance improvement Resolved an issue causing poor performance when using cursor-based pagination on large datasets. *Internal references:* [SCAL-1009](https://mambucom.jira.com/browse/SCAL-1009) #### Refund processed with mismatched linked disbursement key Fixed an issue where a refund was processed with an incorrect `linkedDisbursementKey`, which could result in mislinked refund records. *Internal references:* [REV-4196](https://mambucom.jira.com/browse/REV-4196) #### Revolving loan schedule not updated after disbursement fee adjustment The schedule of a revolving loan without billing cycles and with repayment scheduling versioning enabled was not correctly updated after the adjustment of a disbursement with disbursement fees. This release fixes the issue. *Internal references:* [REV-4085](https://mambucom.jira.com/browse/REV-4085) #### Transfer transaction custom fields lost after backdated adjustments Resolved an issue where, in any backdated transaction performed on an account and a transfer is reapplied, it had missing custom field values. *Internal references:* [DO-646](https://mambucom.jira.com/browse/DO-646) #### Missing card external reference ID in reapplied transaction notifications Resolved an issue where, in any backdated transaction performed on an account, the `External_Reference_ID` value was not set in the streaming template. *Internal references:* [DO-552](https://mambucom.jira.com/browse/DO-552) #### Accounting rules now load correctly when currency changes during product creation When the UI is used to define a new savings product, the **Accounting Rules** block now loads the correct rules if the currency changes. *Internal references:* [DO-235](https://mambucom.jira.com/browse/DO-235) #### Removing past holidays no longer breaks loan schedules or penalty application Fixed an issue where the removal of past holidays caused loan schedules to break and prevented penalties from being applied correctly. *Internal references:* [LPRC-3817](https://mambucom.jira.com/browse/LPRC-3817) #### Planned fee entry date now correctly recorded at midnight Fixed an issue where the entry date for planned fees was recorded using the exact instant time rather than midnight, causing inconsistencies in fee scheduling. *Internal references:* [LPRC-3201](https://mambucom.jira.com/browse/LPRC-3201) #### PATCH endpoint now works for active fixed-term loans with a payment plan The `PATCH /api/loans/` endpoint for loan accounts was not working for active fixed loan accounts with a payment plan. This issue has been resolved. *Internal references:* [LL-5257](https://mambucom.jira.com/browse/LL-5257) #### Repayment period unit can now be modified via API v2 PUT call Resolved an issue where, when trying to modify the repayment period unit via the PUT API call in API v2 — for example from months to weeks — the change was not performed. *Internal references:* [LL-3985](https://mambucom.jira.com/browse/LL-3985) #### Duplicate entries no longer appear in repayment schedule editing with RAI pre-payment recalculation Fixed an issue where editing the repayment schedule displayed duplicate entries when pre-payment recalculation was set to **Reduce Amount of Installments (RAI)**. *Internal references:* [LL-5183](https://mambucom.jira.com/browse/LL-5183) #### Due date field now retains state correctly Fixed an issue where the due date field did not maintain its state correctly, which could result in inconsistent behaviour when working with installment data. *Internal references:* [FSE-566](https://mambucom.jira.com/browse/FSE-566) #### Currency formatting corrected in custom view totals Fixed an issue where totals displayed in custom views were not formatted correctly according to the account currency. *Internal references:* [CDO-4277](https://mambucom.jira.com/browse/CDO-4277) #### Smarter input splitting improves magic search accuracy Improved the search input splitting logic so that magic search more accurately interprets and matches complex or multi-part search terms. *Internal references:* [CDO-4255](https://mambucom.jira.com/browse/CDO-4255) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.171 cycle. ## v9.171.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing internal maintenance and configuration changes. --- ## Bug fixes ### Deposits #### Deposit interest application no longer affected by daylight saving time changes Applying interest via the deposits API now produces correct results across daylight saving time transitions, preventing miscalculated interest postings during clock-change periods. *Internal references:* [DO-972](https://mambucom.jira.com/browse/DO-972) --- ## v9.171.3 **Release Date**: 03.06.2026 --- ## Features ### Deposits #### Interest applied before transfer on deposit account transfers When a transfer transaction is posted on the interest application date, interest is now applied before the transfer is processed, ensuring accurate balance handling for deposit accounts via the `POST /deposits//transfer-transactions` endpoint and UI. *Internal references:* [DIF-2016](https://mambucom.jira.com/browse/DIF-2016) --- ## Improvements ### Data #### Additional work - Internal data and configuration maintenance. --- ## v9.171.2 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to data integrity and identifier generation within the core banking engine. ## v9.171.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Patching loan products with Fixed Days of Months payment interval restored A regression that prevented `PATCH` requests to Loan Products when the **Payment Interval Method** is set to **Fixed Days of Months** has been resolved. *Internal references:* [LL-5350](https://mambucom.jira.com/browse/LL-5350) #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Transactions and Interest #### Interest schedule correctly reflects advance payments on billed products Fixed the schedule in cases where certain interest payments are made before the instalment is generated on products configured with a billing cycle, ensuring transactions are correctly reflected on the schedule. *Internal references:* [REV-4239](https://mambucom.jira.com/browse/REV-4239) #### Withholding tax journal entries now posted correctly for overdrawn accounts When applying withholding taxes to an account in overdraft, journal entries were not being posted for the transaction. This has been fixed. *Internal references:* [DO-589](https://mambucom.jira.com/browse/DO-589) ---

    Database changes

    | Table | Changes | |---|---| | `ips_product_calculation_cycle` | • Added column `AGGREGATED_ACCOUNT_BALANCES_PROFIT`
    • Added column `TOTAL_BANK_SHARE_AMOUNT_PROFIT`
    • Added column `TOTAL_ACCRUED_PROFIT_AMOUNT`
    • Added column `TOTAL_MUDARIB_SHARE_AMOUNT_PROFIT`
    • Added column `AGGREGATED_ACCOUNT_BALANCES_PAYMENT`
    • Added column `TOTAL_BANK_SHARE_AMOUNT_PAYMENT`
    • Added column `TOTAL_FINAL_SHARE_AMOUNT`
    • Added column `TOTAL_MUDARIB_SHARE_AMOUNT_PAYMENT` | | `notificationbrokerqueue` | • Removed index `NOTIFICATIONBROKERQUEUE_KEY_STATE_CREATIONDATE_IDX`
    • Changed data type of column `CREATIONDATE`
    • Added index `NOTIFICATIONBROKERQUEUE_KEY_STATE_CREATIONDATE_IDX`
    • Changed data type of column `CREATIONDATE` | | `savingstransactioncustomfieldvalue` | • Removed index `TRANSACTIONID_VALUEDATE_IDX`
    • Removed column `TRANSACTIONID`
    • Added column `TRANSACTIONKEY`
    • Column `TRANSACTIONKEY` marked NOT NULL
    • Added index `TRANSACTIONKEY_VALUEDATE_IDX` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.172 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.172/ This page contains the following releases for v9.172: * [v9.172](#v9172) * [v9.172.4](#v91724) * [v9.172.3](#v91723) * [v9.172.2](#v91722) * [v9.172.1](#v91721) ## v9.172 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Improvements ### Accounting #### Faster and more reliable Accounting Summaries processing A redesigned algorithm for the daily Accounting Summaries job simplifies the computation logic and reduces run time, while resolving previous limitations around daylight savings time handling, accounting cut-off behaviour, and the **Allow EOD Time** feature toggle. *Internal references:* [LED-2469](https://mambucom.jira.com/browse/LED-2469) #### Additional work - Internal configuration and flag-enablement changes. --- ## v9.172.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data configuration changes. --- ## v9.172.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Detect and recalculate broken revolving accounts outside standard categories A new API endpoint at `POST /recalculaterevolvingzeroprincipaldueschedule` enables detection of revolving broken accounts that fall outside the six standard categories and triggers recalculation to restore them to a valid state. The `RecalculateRevolvingSchedule` API now returns a meaningful response, giving callers actionable feedback on the outcome of each recalculation request. *Internal references:* [REV-4221](https://mambucom.jira.com/browse/REV-4221), [REV-4125](https://mambucom.jira.com/browse/REV-4125) --- ## v9.172.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration and maintenance changes. --- ## v9.172.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data and configuration maintenance. --- ## Bug fixes ### Deposits #### Daylight saving time no longer disrupts interest application Applying interest via the deposits API now handles daylight saving time transitions correctly, preventing miscalculations that could occur when clocks change. *Internal references:* [DO-972](https://mambucom.jira.com/browse/DO-972) --- For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.173 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.173/ This page contains the following releases for v9.173: * [v9.173](#v9173) * [v9.173.2](#v91732) * [v9.173.1](#v91731) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.173 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Non-scheduled fees fields renamed when feature is enabled When the `ALLOW_NON_SCHEDULED_FEES` feature toggle is on, three fields in the New Balance API response are renamed to reflect their scheduled-only scope: `feesDue` becomes `scheduledFeesDue`, `feesBalance` becomes `scheduledFeesBalance`, and `feesPaid` becomes `scheduledFeesPaid`. *Internal references:* [MTGE-1238](https://mambucom.jira.com/browse/MTGE-1238) #### Non-allocated fees paid now visible in the UI and API Users can now view non-allocated fees paid directly in the loan account interface, and the same data is surfaced through the API, giving both operators and integrations a complete picture of fee activity. *Internal references:* [MTGE-1118](https://mambucom.jira.com/browse/MTGE-1118) #### Custom payments for non-allocated fees now available in the UI Loan officers can now submit custom payments against non-allocated fees directly from the UI, removing the need for API-only workarounds. *Internal references:* [MTGE-1109](https://mambucom.jira.com/browse/MTGE-1109) #### Repayment validation prevents over-payment of a balance A new validation ensures that repayment amounts cannot exceed the balance they are intended to reduce, preventing erroneous over-payment entries. *Internal references:* [MTGE-1104](https://mambucom.jira.com/browse/MTGE-1104) #### Clear error message when loan product configuration is incomplete When a loan product has no allocation fees and the custom repayment option is not enabled, users now see an explicit error message rather than a silent failure. *Internal references:* [MTGE-1196](https://mambucom.jira.com/browse/MTGE-1196) #### New Dynamic Term Mortgage product type simplifies product management A new **Dynamic Term Mortgage** product type consolidates mortgage-specific features into a single, streamlined configuration, eliminating complex feature-flag checks and reducing the overhead of creating and managing mortgage products. This product type is available to customers with the Mambu Feature enabled. *Internal references:* [MTGE-1040](https://mambucom.jira.com/browse/MTGE-1040) #### Non-scheduled principal overpayment balance now included in schedule API response `nonScheduledPrincipalBalanceOverpayment` is now returned in the response body of `GET /loans//schedule` when the `PRINCIPAL_OVERPAYMENT` feature flag is enabled, giving integrations direct access to overpayment balance data. *Internal references:* [MTGE-1044](https://mambucom.jira.com/browse/MTGE-1044) #### Loan account termination no longer blocked by capitalised fees Fixed an issue where the presence of capitalised fees prevented loan account termination from completing; termination now works correctly regardless of the fee type applied. *Internal references:* [LL-5361](https://mambucom.jira.com/browse/LL-5361) #### Groundwork for upcoming features - Building out broken interest support for capital repayment loans, including a new feature toggle, updated loan product API parameters, UI configuration options, and first-instalment calculation logic. - Laying the foundation for carry-forward balances at reschedule and refinance, covering principal, interest, arrears state, and related fields. - Expanding principal overpayment handling to calculate and apply Early Repayment Charges (ERC) on non-scheduled overpayments and adjustments. - Enabling a custom interest application date on Interest Only Equal Instalment loans, including disbursement handling and repayment scheduling when the due date precedes the interest application date. - Extending equal-instalment support for longer first periods on simple interest loans, including carry-forward interest in the preview schedule API, late repayment options, and penalty behaviour. - Progressing the decommission of Pricing V1 endpoints by mapping missing entities to the V2 repayments API. - Extending automated transfer handling for transactions posted after midnight and on the interest application date. #### Additional work - Internal mortgage and lending backend changes including EOD performance rollouts, schedule regeneration fixes, caching improvements, and other non-customer-facing maintenance. --- ### Accounting #### Groundwork for upcoming features - Redesigning ledger reporting summaries to use an improved accounting summary algorithm, covering both the P&L report in the UI and the underlying common services layer. --- ### Islamic Banking #### Proposal details display accuracy and consistency improvements Multiple display issues in the **Proposal** screens have been resolved: the total final profit amount now calculates correctly, product names and account IDs sort in ascending order, decimal precision is consistent between customer profit rate and adjusted rate fields, percentage value display is uniform throughout proposal details, and the average account balance figure is accurate. *Internal references:* [IB-2167](https://mambucom.jira.com/browse/IB-2167), [IB-2153](https://mambucom.jira.com/browse/IB-2153), [IB-2139](https://mambucom.jira.com/browse/IB-2139), [IB-2138](https://mambucom.jira.com/browse/IB-2138), [IB-2128](https://mambucom.jira.com/browse/IB-2128), [IB-2124](https://mambucom.jira.com/browse/IB-2124) #### Currency support added to the IPS UI The Islamic Profit Sharing UI now supports currency display, ensuring monetary values are presented with the correct currency context throughout the interface. *Internal references:* [IB-2105](https://mambucom.jira.com/browse/IB-2105) #### Cash flow balance calculation in pool cycles corrected Fixed an incorrect cash flow balance calculation occurring within pool cycles during scheduled jobs, ensuring profit-sharing computations reflect accurate balances. *Internal references:* [IB-2052](https://mambucom.jira.com/browse/IB-2052) #### Income and Expenses allocation method corrected Fixed an issue with the allocation method used in Income and Expenses calculations where the number of accounts was being computed incorrectly. *Internal references:* [IB-2025](https://mambucom.jira.com/browse/IB-2025) #### Linked Income and Expenses names now shown in pool information Pool details now display the names of linked Income and Expenses entries, giving users the context they need without navigating away from the pool view. *Internal references:* [IB-2022](https://mambucom.jira.com/browse/IB-2022) #### Groundwork for upcoming features - Advancing IPS Proposal Creation (Milestone 5) with Income & Expenses detail views in the UI and updated product and pool accumulated account data fields on the Proposal Search endpoint. - Enabling eligible balance configuration in the IPS product configuration screen as part of ongoing configuration consistency work. - Continuing IPS profit-sharing job validation and test automation for Milestone 4 use cases. - Progressing in-cycle proposal handling for proposals raised mid-calculation cycle. - Renaming UI fields to align with updated terminology across the IPS interface. #### Additional work - Internal IPS backend and test infrastructure maintenance. --- ### Developer #### Groundwork for upcoming features - Migrating FSE schedule functions to functionless fields, including a schedule comparison algorithm and an extracted rounding service. - Designing and implementing the `PrincipalService` component, including the `CurrentPrincipalBalance` building block. - Defining the `CrudRepository` interface as part of core backend infrastructure work. #### Additional work - Internal developer tooling changes including a private API for adjusting first interest applied transactions and non-customer-facing backend maintenance. --- ## Improvements ### Lending #### Patching loan products with Fixed Days of Months payment interval restored A regression that prevented `PATCH` requests on loan products when the **Payment Interval Method** is set to **Fixed Days of Months** has been resolved. *Internal references:* [LL-5350](https://mambucom.jira.com/browse/LL-5350) #### Pay-off performance improved for loans with large numbers of fees The pay-off loan endpoint has been optimised to handle accounts with a high volume of applied fees more efficiently, reducing processing time. *Internal references:* [LL-5309](https://mambucom.jira.com/browse/LL-5309) #### Interest applied before disbursement when targeting a linked deposit account When a loan disbursement targets a linked deposit account via `POST /loans//disbursement-transactions`, interest is now applied before the disbursement is processed, ensuring correct balance handling. *Internal references:* [DIF-2110](https://mambucom.jira.com/browse/DIF-2110) #### Groundwork for upcoming features - Building the database and infrastructure changes required for the Phase 1 MVP implementation of upcoming lending schedule enhancements. - Improvements to the internal SCT Schedule Comparison Tool to support high-level categorisation of schedule differences. - Enhancements to the proposal account details API to use updated internal cycle boundaries for profit accrual calculations in Islamic Banking. #### Additional work - Internal lending configuration and environment-level changes. --- ### Deposits #### Accounting Summaries redesigned for improved reliability and performance The Accounting Summaries job has been re-engineered with a simplified computation algorithm that reduces run time and resolves known limitations including daylight savings time handling, accounting cut-off behaviour, and **Allow EOD Time** feature toggle interactions. *Internal references:* [LED-2469](https://mambucom.jira.com/browse/LED-2469) #### Groundwork for upcoming features - Building the Update Internal Cycles Balance job for Islamic Banking, including batch processing and range-list retrieval for internal cycles. - Laying the groundwork for backdated `AccountPaymentCycles` creation in Islamic Banking. - Propagating execution context through deposits end-of-day jobs to support improved observability and processing control. #### Additional work - Internal deposits end-of-day and environment configuration changes. --- ### Islamic Banking #### Groundwork for upcoming features - Removing the **Active** status from **CashFlow** and product-related configuration settings as part of a broader configuration simplification initiative. --- ### Cards #### Additional work - Internal cards logging and transaction adjustments. --- ### Access Control #### Reporting authorisation vulnerabilities resolved Two access control gaps in the reporting feature have been fixed: low-permission users could previously add new column presets, and a missing permission check allowed generation of organisation-wide reports without appropriate authorisation. *Internal references:* [CDO-4172](https://mambucom.jira.com/browse/CDO-4172), [CDO-4121](https://mambucom.jira.com/browse/CDO-4121) #### Additional work - Internal support-user lifecycle automation. --- ### Data #### Broken revolving accounts detected and recalculated via new API A new private endpoint at `POST /recalculaterevolvingzeroprincipaldueschedule` enables detection and recalculation of revolving broken accounts that fall outside the six standard categories, and now returns a meaningful response to confirm the outcome. *Internal references:* [REV-4221](https://mambucom.jira.com/browse/REV-4221), [REV-4125](https://mambucom.jira.com/browse/REV-4125) #### Additional work - Internal data migration, cache, and configuration changes. --- ### Developer #### Additional work - Internal framework and infrastructure maintenance, including local cache configuration and asynchronous notification adjustments. --- ## Bug fixes ### Mortgages #### Adjust Total Due option now visible for Dynamic Mortgages with Compound Interest The **Adjust the total due for first repayment** option is now correctly displayed in the UI for Dynamic Mortgages configured with Compound Interest. *Internal references:* [MTGE-1272](https://mambucom.jira.com/browse/MTGE-1272) #### Spurious interest-from-arrears transactions no longer logged when no late interest exists An interest-from-arrears transaction was incorrectly being recorded even when no late interest was present; this has been resolved. *Internal references:* [MTGE-1255](https://mambucom.jira.com/browse/MTGE-1255) #### Excess payment error resolved for custom repayments on Interest Only Loans Posting a custom repayment in interest on an Interest Only Loan no longer incorrectly returns an "Excess payment" error. *Internal references:* [MTGE-1254](https://mambucom.jira.com/browse/MTGE-1254) #### Lock account function correctly disabled for Mortgage accounts The lock account function is now properly disabled for Mortgage accounts, preventing it from being applied where it is not supported. *Internal references:* [MTGE-1243](https://mambucom.jira.com/browse/MTGE-1243) #### `PrepaymentRecalculationMethod` now correctly populated on product edit The `PrepaymentRecalculationMethod` field was not being populated correctly when editing a product; this is now resolved. *Internal references:* [MTGE-1172](https://mambucom.jira.com/browse/MTGE-1172) #### Schedule preview on loan creation now displays correctly The schedule preview shown during loan creation was not rendering correctly; this has been fixed to display accurate schedule information. *Internal references:* [MTGE-1154](https://mambucom.jira.com/browse/MTGE-1154) #### Incorrect accounting bookings for Interest Only Loans with principal overpayments resolved Accounting bookings for Interest Only Loans are now correct when an overpayment against the principal balance is posted. *Internal references:* [MTGE-1153](https://mambucom.jira.com/browse/MTGE-1153) #### Reschedule now works correctly when Flexible Terms is enabled without non-scheduled fees A UI issue preventing rescheduling from working when Flexible Terms was enabled but no non-scheduled fees were present has been resolved. *Internal references:* [MTGE-1252](https://mambucom.jira.com/browse/MTGE-1252) #### Backdated fee application now produces the correct balance change application date Applying a backdated fee no longer results in an incorrect balance change application date. *Internal references:* [MTGE-1245](https://mambucom.jira.com/browse/MTGE-1245) #### Schedule calculation corrected when a full due is paid and an instalment is partially paid An incorrect schedule calculation that occurred when `FullDueIsPaid` was set and an instalment was only partially paid has been fixed. *Internal references:* [MTGE-1249](https://mambucom.jira.com/browse/MTGE-1249) #### Principal overpayment bulk adjustment failure resolved A failure occurring during bulk adjustment of principal overpayments has been corrected. *Internal references:* [MTGE-1248](https://mambucom.jira.com/browse/MTGE-1248) #### UI issues on Principal Overpayment resolved Several UI bugs affecting the Principal Overpayment workflow have been fixed. *Internal references:* [MTGE-1149](https://mambucom.jira.com/browse/MTGE-1149) #### Interest accrual between repayments now functioning correctly Interest was not being accrued between repayments in certain configurations; this has been resolved. *Internal references:* [MTGE-1141](https://mambucom.jira.com/browse/MTGE-1141) --- ### Lending #### Fixed-term loans with holiday periods no longer throw an exception during schedule generation A `NegativePrincipalForRepaymentException` that occurred when generating a schedule for a fixed-term loan configured with a holiday period has been resolved. *Internal references:* [LPRC-4051](https://mambucom.jira.com/browse/LPRC-4051) #### Tax on penalty calculation corrected for Fixed Term Loan accounts `taxOnPenalty` at the instalment level was previously calculated as the sum of `taxOnPenalty` from individual penalty transactions rather than being derived from the overall `penaltyDue` amount, causing rounding discrepancies; this is now resolved and delivered under the feature toggle `fixInstallmentTaxOnPenalty`. *Internal references:* [LPRC-3623](https://mambucom.jira.com/browse/LPRC-3623) #### Validation error when adjusting a repayment transaction resolved A validation error that prevented repayment transactions from being adjusted has been fixed. *Internal references:* [LPRC-2975](https://mambucom.jira.com/browse/LPRC-2975) #### Consistent response bodies across loan search and get endpoints A custom field from disbursement details was present in the `POST /loans:search` response but absent from `GET /loans/`; both endpoints now return consistent response bodies. *Internal references:* [LL-5389](https://mambucom.jira.com/browse/LL-5389) #### Non-zero principal instalments can now be deleted via the Schedule Edit V2 API The Schedule Edit V2 API now allows instalments with a principal amount greater than zero to be deleted, bringing API behaviour in line with the UI. *Internal references:* [LL-5130](https://mambucom.jira.com/browse/LL-5130) #### Custom fields on active Tranche Loan accounts can now be updated via API v2 A `PATCH` request to update custom fields on an active Tranche Loan account via API v2 was failing; this has been resolved. *Internal references:* [LL-5333](https://mambucom.jira.com/browse/LL-5333) --- ### Accounting #### Date offset calculation corrected near Daylight Saving Time transitions `DateUtils.toDateWithOrgOffsetAdjust` was returning an incorrect date when a Daylight Saving Time boundary was near; this has been fixed. *Internal references:* [LED-2688](https://mambucom.jira.com/browse/LED-2688), [LED-2559](https://mambucom.jira.com/browse/LED-2559) --- ### Islamic Banking #### Account details results corrected for IPS account detail reports Certain account detail results returned by IPS reports were incorrect; this has been resolved. *Internal references:* [IB-2135](https://mambucom.jira.com/browse/IB-2135) --- ### Clients and Groups #### Search no longer enforces minimum length for IDs that are not the first search term The minimum search length restriction for ID fields is no longer applied when the ID is not the first term in the search query, improving search flexibility. *Internal references:* [CDO-4307](https://mambucom.jira.com/browse/CDO-4307) #### Custom field patching errors resolved for groups Errors occurring when patching a group custom field with an invalid group index, and when handling free-text custom field responses, have been fixed. *Internal references:* [ADM-3778](https://mambucom.jira.com/browse/ADM-3778), [ADM-3036](https://mambucom.jira.com/browse/ADM-3036) --- ### Deposits #### Notes now saved when changing the overdraft interest rate on a deposit account When adjusting overdraft terms and updating only the interest rate with a note, the note is now correctly attached to the resulting **Overdraft Interest Rate Changed** transaction. *Internal references:* [DO-454](https://mambucom.jira.com/browse/DO-454) #### Accounts linked to inactive products now processed by the Interest Accrual Breakdown job The Interest Accrual Breakdown job was skipping accounts linked to inactive products; the validation requiring an active product has been removed so all eligible accounts are processed correctly. *Internal references:* [DO-752](https://mambucom.jira.com/browse/DO-752) #### Additional work - Internal fix for GSON parsing following a JDK 17 upgrade. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.173 cycle. ## v9.173.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Accurate schedule calculations for fee-activated accounts with changed loan terms Previously, accounts activated with a fee did not contain `LoanTransactionTerms` details within the loan transaction history for the first transaction, causing inaccurate schedule calculations when loan terms were altered throughout the account's history. This has been resolved. *Internal references:* [REV-4319](https://mambucom.jira.com/browse/REV-4319) #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Data #### Adjusting a fee no longer incorrectly invalidates the full reserve Correcting a fee adjustment that was causing the associated reserve to be fully invalidated. *Internal references:* [REV-4354](https://mambucom.jira.com/browse/REV-4354) --- ## v9.173.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Groundwork for upcoming features - Groundwork for custom field optimisation for savings transactions, enabling improved search and custom view performance. --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and configuration changes. --- ## Bug fixes ### Mortgages #### Payment holiday interest now correctly reflected on the repayment schedule Fixed an issue where interest applied during a payment holiday was not shown on the loan repayment schedule. *Internal references:* [MTGE-1256](https://mambucom.jira.com/browse/MTGE-1256) #### IFA decoupling setting preserved when updating other product-level options Fixed an issue where the **IFA decoupling** flag was unintentionally reset to false on loan products with active accounts when other product-level settings were modified. *Internal references:* [MTGE-1223](https://mambucom.jira.com/browse/MTGE-1223) #### Corrected interest calculation on IFA-decoupled loans after prepayment Fixed schedule interest calculation after prepayments on dynamic mortgage accounts, where the system was using an incorrect value for the loan account schedule **Interest Expected** / **Interest Due** date. *Internal references:* [MTGE-1222](https://mambucom.jira.com/browse/MTGE-1222) ### Developer #### Improved resiliency for long-running idempotent API requests Improved error handling for cases where the API takes several minutes to process idempotent requests, preventing the monitoring thread from stalling unexpectedly. *Internal references:* [BKE-553](https://mambucom.jira.com/browse/BKE-553) ---

    Database changes

    | Table | Changes | |---|---| | `SAVINGS_TRANSACTIONS_DAILY_SUMMARY` | • Table removed | | `fse_scheduleversion` | • Added column `EVENT`
    • Removed column `FINGERPRINT` | | `ips_account_payment_cycle` | • Changed data type of column `START_DATE`
    • Changed data type of column `END_DATE` | | `ips_cash_flow` | • Removed column `STATUS` | | `ips_cash_flow_calculation_cycle` | • Removed column `STATUS` | | `ips_internal_cycle` | • Changed data type of column `START_DATE`
    • Changed data type of column `END_DATE`
    • Added column `BALANCE_PRODUCT_CALCULATION_CYCLE_ID`
    • Added index `idx_ic_balance_pcc_id` | | `ips_pool_calculation_cycle` | • Changed data type of column `START_DATE`
    • Changed data type of column `END_DATE` | | `ips_pool_settings` | • Renamed column `BANK_INVESTMENT_PL_ACCOUNT_ENCODEDKEY` → `BANK_PL_ACCOUNT_ENCODEDKEY`
    • Added column `PROFIT_SUSPENSE_ACCOUNT_ENCODEDKEY`
    • Added column `RESERVE_ACCOUNT_ENCODEDKEY`
    • Added column `MUDARIB_SHARE_ACCOUNT_ENCODEDKEY` | | `ips_product_calculation_cycle` | • Changed data type of column `START_DATE`
    • Changed data type of column `END_DATE` | | `ips_proposal` | • Changed data type of column `START_DATE`
    • Changed data type of column `END_DATE` | | `loan_account_balance_change` | • New table
    • Added index `labc_idx_loanAccountBalanceAndDate`
    • Added index `labc_idx_loanTransaction`
    • Added index `labc_idx_loanAccountBalance` | | `loanaccount` | • Added column `ADDITION`
    • Added column `ADDITION` | | `loanproduct` | • Added column `ADDITION`
    • Added column `ADDITION` | | `predefinedfee` | • Added column `ADDITION`
    • Added column `ADDITION` | | `repayment` | • Added column `ADDITIONS` | | `scheduleversion` | • Table removed | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.174 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.174/ This page contains the following releases for v9.174: * [v9.174](#v9174) * [v9.174.6](#v91746) * [v9.174.5](#v91745) * [v9.174.4](#v91744) * [v9.174.3](#v91743) * [v9.174.2](#v91742) * [v9.174.1](#v91741) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.174 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Carry-forward interest displayed on loan schedule The loan account **Schedule** page and schedule preview now show carried-forward interest, giving users a clear, accurate view of how prior-period interest balances flow into the repayment schedule. *Internal references:* [LL-5425](https://mambucom.jira.com/browse/LL-5425), [LL-5149](https://mambucom.jira.com/browse/LL-5149) #### Non-scheduled fees balance visible on pay-off and reduce-balance screens The pay-off screen now includes the non-scheduled fees balance, and the reduce-balance screen surfaces the balance-only fee balance, ensuring users have complete fee visibility when closing or reducing a loan. *Internal references:* [MTGE-1258](https://mambucom.jira.com/browse/MTGE-1258), [MTGE-1054](https://mambucom.jira.com/browse/MTGE-1054) #### Loan transaction detail view uses clearer fee balance label The fees balance field in the loan transaction detail view has been renamed to **Scheduled Fees Balance**, reducing ambiguity between scheduled and non-scheduled fee balances. *Internal references:* [MTGE-1276](https://mambucom.jira.com/browse/MTGE-1276) #### Loan account balances endpoint returns values rounded to two decimal places The loan account balances API now limits returned values to two decimal places, ensuring consistent and predictable numeric precision for downstream integrations. *Internal references:* [MTGE-1275](https://mambucom.jira.com/browse/MTGE-1275) #### Fee schedule allocation method locked for products with active accounts Modifying the fee schedule allocation method is now prevented for loan products that already have accounts, and a **Confirm Changes** dialog is presented when editing such products, protecting the integrity of existing account data. *Internal references:* [MTGE-1062](https://mambucom.jira.com/browse/MTGE-1062), [MTGE-1271](https://mambucom.jira.com/browse/MTGE-1271) #### Non-scheduled fee product configuration errors resolved An error that occurred when opening a loan product containing a non-scheduled fee with active accounts has been fixed, and the amortization profile option is now correctly disabled for non-schedule-allocated fees. *Internal references:* [MTGE-1340](https://mambucom.jira.com/browse/MTGE-1340), [MTGE-1303](https://mambucom.jira.com/browse/MTGE-1303) #### Non-scheduled fees balance calculations and UI updated Balance calculation values and UI display for non-scheduled fees have been updated to reflect accurate balances across relevant loan account screens. *Internal references:* [MTGE-1278](https://mambucom.jira.com/browse/MTGE-1278) #### Future value of interest from arrears returned in preview pay-off API The preview pay-off API now returns the future value of **Interest from Arrears (IFA)**, enabling integrations to present a more accurate projected pay-off amount. *Internal references:* [MTGE-741](https://mambucom.jira.com/browse/MTGE-741) #### Interest-bearing fees configurable and applied independently of the repayment schedule Loan products can now be configured with interest-bearing fees that are decoupled from the repayment schedule, and the five associated loan account balances are exposed via the UI and API, giving lenders greater flexibility in fee structuring. *Internal references:* [MTGE-1309](https://mambucom.jira.com/browse/MTGE-1309), [MTGE-1308](https://mambucom.jira.com/browse/MTGE-1308), [MTGE-1307](https://mambucom.jira.com/browse/MTGE-1307) #### Carry-forward or capitalise income balances at reschedule or refinance Lenders can now choose whether to capitalise income balances or carry them forward when rescheduling or refinancing a loan, providing greater control over how outstanding balances are handled at restructure. *Internal references:* [MTGE-1089](https://mambucom.jira.com/browse/MTGE-1089) #### Groundwork for upcoming features - Broken interest logic for capital repayment loans (DBEI/FSE), including fixed-day-of-month support, edit-schedule integration, and product/account configuration forwarding to the FSE contract. - Prepayment schedule computation with remaining accrued interest for equal-instalment simple-interest loans. - Islamic Profit Sharing (IPS) cycle management, status updates, and average balance calculation corrections ahead of full profit-sharing accounting delivery. - IPS end-of-day jobs adapted to process lists of profit-sharing proposals. - Deposits-to-ledger accrual reporting and post-midnight transaction balance handling for deposits. - Flexible Schedule Engine regeneration process, due-date component extraction, and installment index exposure to division functions. #### Additional work - Internal backend changes across EOD architecture, ledger module structure, repository interfaces, and schedule tooling. --- ## Improvements ### Data #### Additional work - Non-customer-facing internal data and infrastructure changes. --- ### Analytics #### Faster computation of savings indicators with reduced timeout risk A processing window has been introduced to compute a subset of savings indicators — including active accounts, total deposits, overdraft, and active account holders by segment — significantly reducing the probability of timeouts during indicator calculation. *Internal references:* [DO-765](https://mambucom.jira.com/browse/DO-765) #### Additional work - Non-customer-facing environment configuration and feature-flag changes. --- ### Mortgages #### Fees display renamed to Scheduled Fee in the UI The **Fees** label in the mortgage product UI has been renamed to **Scheduled Fee**, providing clearer terminology that distinguishes scheduled fees from other fee types. *Internal references:* [MTGE-1304](https://mambucom.jira.com/browse/MTGE-1304) #### Groundwork for upcoming features - Building support for applying non-scheduled overpayments without allocating them to scheduled instalments as part of the dynamic mortgage product. --- ### Lending #### Groundwork for upcoming features - Laying the groundwork for Phase 1 MVP implementation of updated loan account setup and product configuration, including amortisation profile management. --- ### Deposits #### Groundwork for upcoming features - Building bulk authorisation holds API for cards, including new deposits modules, endpoint exposure, and supporting data layer work. - Preparing asynchronous notifications support on deposit-related endpoints, including deposit edit and deposit transactions. - Implementing aggressive caching of general settings configuration data to improve performance. --- ### Accounting #### Additional work - Non-customer-facing accounting fixes to prevent duplicate accounting rules. --- ### Islamic Banking #### Groundwork for upcoming features - Building batch processing infrastructure for applying profit and splitting payment cycles, in preparation for scalable Islamic Banking accounting operations. --- ### Developer #### Groundwork for upcoming features - Migrating installment fields (`INTEREST_PAID`, `PRINCIPAL_PAID`, `PENALTY_PAID`, `FEE_PAID`, `FEE_DUE`, `STATE`) to functionless fields as part of the FSE functions migration initiative. - Enriching the execution context with organisation time, currency, and overdraft interest EOD balance method switch date to support downstream processing improvements. - Integrating the Loan Transactions Custom Methods flow (API V2) with the Revolving submodule as part of the revolving code separation initiative. --- ## Bug fixes ### Deposits #### Withholding tax can now be applied to accounts in arrears When an account was in the **In Arrears** state, withholding taxes could not be applied. This has now been fixed. *Internal references:* [DO-998](https://mambucom.jira.com/browse/DO-998) #### Interest accrual reporting job correctly handles products with default accrual configuration Resolved an issue where the `DEPOSITS_ACCRUED_AMOUNTS_PROVISIONING` job would not send ledger information for accounts belonging to products that had not been updated after the `ENABLE_DEPOSITS_INTEREST_ACCRUAL_REPORTING` feature toggle was enabled. Products whose `interestAccrualCalculation` remained at the default value of `NONE` are now handled correctly. *Internal references:* [DO-983](https://mambucom.jira.com/browse/DO-983) #### Overdraft limit correctly determined for backdated transactions in arrears scenarios Resolved an issue where the system failed to accurately determine the applicable overdraft limit for backdated transactions in specific arrears account balance scenarios. *Internal references:* [DO-491](https://mambucom.jira.com/browse/DO-491) #### Booking date now reflects the correct accounting period when cut-off time is enabled Fixed an issue where the booking date was not correctly adjusted when the **Accounting Cut-Off** time feature was enabled and a transaction fell within the cut-off period. The booking date now reflects the intended accounting period, aligned with the configured cut-off time. *Internal references:* [DO-476](https://mambucom.jira.com/browse/DO-476) --- ### Lending #### `GET /loans` v2 now correctly returns loans with written-off or rejected closed states Fixed an issue where filtering by `accountState=CLOSED_WRITTEN_OFF` or `accountState=CLOSED_REJECTED` in the `GET /loans` v2 API returned an `INVALID_ACCOUNT_STATE` error. The endpoint now returns a `200 OK` response with the matching loan accounts as expected. *Internal references:* [LL-5435](https://mambucom.jira.com/browse/LL-5435) #### Loan schedule is now recomputed when terms are updated via PATCH v2 Resolved an issue in the `PATCH` v2 API where updating loan terms for fixed-term loans in **Partial Application** or **Pending Approval** status did not trigger a recalculation of the repayment schedule. This fix also applies to the `PUT /loans/` endpoint, bringing v2 behaviour in line with v1. *Internal references:* [LL-5320](https://mambucom.jira.com/browse/LL-5320) #### `GET /loanproducts` v2 no longer misapplies dynamic-product enhancements to fixed loan products Fixed an issue where fixed loan products were incorrectly processed through enhancement steps intended only for dynamic loan products — such as payment holiday options and amortization period fields — causing errors in the `GET /loanproducts` v2 API. *Internal references:* [LL-5411](https://mambucom.jira.com/browse/LL-5411) #### Payoff preview now accounts for redraw balance The `/loans/:previewPayOffAmounts` endpoint now correctly includes the redraw balance when calculating the total amount due for loan payoff. *Internal references:* [LL-5358](https://mambucom.jira.com/browse/LL-5358) #### Locking an already-locked account no longer returns an error The `loans//lock-transactions` endpoint no longer throws the `CANT_EDIT_LOCKED_ACCOUNT_DUE_AMOUNT_TYPE` error when an account is locked more than once or when `lockedAccountDueAmountType` is not set. *Internal references:* [LL-4668](https://mambucom.jira.com/browse/LL-4668) #### Additional work - Non-customer-facing lending fixes and internal maintenance. --- ### Mortgages #### PMT threshold can now be saved on Interest Only Equal Instalments products Resolved an issue that prevented the PMT threshold from being saved on **IOEI** products. *Internal references:* [MTGE-1356](https://mambucom.jira.com/browse/MTGE-1356) #### Journal entries for overpayments on Interest Only loans are now correctly recorded Fixed incorrect journal entries being logged for overpayments on Interest Only loans. *Internal references:* [MTGE-1355](https://mambucom.jira.com/browse/MTGE-1355) #### Dynamic mortgage products can now be created successfully Resolved an issue that prevented dynamic mortgage products from being created. *Internal references:* [MTGE-1335](https://mambucom.jira.com/browse/MTGE-1335) #### Future interest calculation corrected for loans with AIR and compounding interest Fixed an incorrect future interest calculation affecting loans that use an Annual Interest Rate with compounding interest. *Internal references:* [MTGE-1289](https://mambucom.jira.com/browse/MTGE-1289) #### Interest applied amount corrected for IO and DBEI loans with late instalments Fixed an issue where an incorrect interest applied amount was recorded on Interest Only and DBEI loans when a late instalment was present and **Accrue Late Interest** was set to false. *Internal references:* [MTGE-1288](https://mambucom.jira.com/browse/MTGE-1288) #### Broken interest no longer incorrectly triggered on IOEI loans Resolved an issue where broken interest logic was being invoked on Interest Only Equal Instalments loans in scenarios where it should not apply. *Internal references:* [MTGE-1273](https://mambucom.jira.com/browse/MTGE-1273) #### Broken interest now correctly invoked on the next instalment when no First Repayment Date is set Fixed an issue where broken interest was not triggered on the next instalment for FSE loans when no First Repayment Date had been configured. *Internal references:* [MTGE-1298](https://mambucom.jira.com/browse/MTGE-1298) #### Fee reduction no longer fails when refinancing or rescheduling a loan Resolved an issue where reducing a fee amount during a loan refinance or reschedule operation caused the process to fail. *Internal references:* [MTGE-1025](https://mambucom.jira.com/browse/MTGE-1025) #### Closing balance on interest applied transactions corrected for Interest Only loans Fixed an incorrect closing balance being recorded on interest applied transactions for Interest Only loans. *Internal references:* [MTGE-662](https://mambucom.jira.com/browse/MTGE-662) --- ### Accounting #### Manual journal entries can now be posted across branches when one entry has no branch assigned Fixed an issue where posting manual journal entries failed when one entry was assigned to a specific branch and another had no branch assigned. *Internal references:* [LED-2726](https://mambucom.jira.com/browse/LED-2726), [LED-2555](https://mambucom.jira.com/browse/LED-2555) --- ### Islamic Banking #### Internal cycle balances no longer calculated over more days than the cycle period Fixed an issue where internal cycle balances were being calculated across a greater number of days than the defined cycle period. *Internal references:* [IB-2213](https://mambucom.jira.com/browse/IB-2213) #### Aggregated product balances now correct for shifted payment cycles Resolved an issue where aggregated product balances for the previous month were incorrect in shifted payment cycle scenarios. *Internal references:* [IB-2212](https://mambucom.jira.com/browse/IB-2212) #### Profit rates of 10% or greater can now be stored in pool and product cycles Fixed an issue that prevented profit rates greater than or equal to 10% from being saved in pool and product cycles. *Internal references:* [IB-2187](https://mambucom.jira.com/browse/IB-2187) #### Current Account products can now be created successfully Resolved an issue that prevented Current Account products from being created. *Internal references:* [IB-2087](https://mambucom.jira.com/browse/IB-2087) --- ### Developer #### Custom field configuration changes for transaction channels now take effect immediately Fixed a caching issue that could prevent an updated custom field definition for a transaction channel from being reflected straight away. *Internal references:* [ADM-3895](https://mambucom.jira.com/browse/ADM-3895) #### Additional work - Non-customer-facing developer tooling and API fixes. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.174 cycle. ## v9.174.6 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Groundwork for upcoming features - Ongoing separation and consolidation of revolving credit logic to support a cleaner, more maintainable product architecture. #### Additional work - Internal refactoring of loan account method integrations with no customer-observable changes. --- ## v9.174.5 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and internal refactoring. --- ## v9.174.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and internal test fixes. --- ## Bug fixes ### Mortgages #### Corrected interest applied amount on interest-only loans with late instalments Fixed an issue where an incorrect interest applied amount was calculated on interest-only loans when an instalment was paid late. *Internal references:* [MTGE-1397](https://mambucom.jira.com/browse/MTGE-1397) #### Corrected GL entries when reversing or adjusting repayments that include arrears interest Fixed incorrect general ledger entries generated during the reversal or adjustment of repayments that settled interest from arrears. *Internal references:* [MTGE-1396](https://mambucom.jira.com/browse/MTGE-1396) #### Corrected interest calculation on declining balance loans with multiple partial prepayments Fixed an issue where interest was calculated incorrectly on declining balance equal instalment loans when multiple partial prepayments had been made and interest was applied or paid alongside those prepayments. *Internal references:* [MTGE-1390](https://mambucom.jira.com/browse/MTGE-1390) #### Corrected schedule recalculation after backdated overpayments on interest-only loans Fixed schedule interest calculation after overpayments made before the due date on dynamic mortgage accounts, where the system was previously applying an incorrect calculation to the loan account schedule. *Internal references:* [MTGE-1385](https://mambucom.jira.com/browse/MTGE-1385) #### Corrected interest and payment computation after multiple overpayments on compound loans Fixed an issue where interest and payment amounts were computed incorrectly following a second overpayment on a loan using new compound interest. *Internal references:* [MTGE-1305](https://mambucom.jira.com/browse/MTGE-1305) #### Additional work - Non-customer-facing release preparation changes. --- ## v9.174.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal backend integration work across loan account API subflows. --- ## v9.174.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Groundwork for upcoming features - Ongoing integration of loan account API v2 subflows with the Reload and Revolving submodules, advancing the separation of product-specific logic in preparation for future lending capabilities. #### Additional work - Internal loan account subflow and module integration work. --- ## Bug fixes ### Mortgages #### Fixed loan account creation and editing restored A regression that prevented creating or editing loan accounts for fixed loan products has been resolved. *Internal references:* [MTGE-1436](https://mambucom.jira.com/browse/MTGE-1436) --- ## v9.174.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Early Repayment Charge reset now honours the configured end date The ERC reset cron job now correctly resets the Early Repayment Charge value to zero on the end date specified in the custom field, preventing stale charges from persisting beyond their intended period. *Internal references:* [MTGE-1376](https://mambucom.jira.com/browse/MTGE-1376) #### Additional work - Non-customer-facing data fixes. --- ## Bug fixes ### Deposits #### Deposit account custom field values now visible in transaction views Custom field values associated with deposit accounts were missing from deposit transaction views and are now correctly displayed. *Internal references:* [ADM-3955](https://mambucom.jira.com/browse/ADM-3955) ---

    Database changes

    | Table | Changes | |---|---| | `fse_account` | • Added column `REGENERATED` | | `ips_account_payment_cycle` | • Changed data type of column `STATUS`
    • Changed data type of column `STATUS` | | `ips_cash_flow_settings` | • Removed foreign key `FK_IPS_CASH_FLOW_SETTINGS_GL_ACCOUNT_ENCODEDKEY` | | `ips_deduction_settings` | • Removed foreign key `FK_IPS_DEDUCTION_SETTINGS_GL_ACCOUNT_ENCODEDKEY` | | `ips_pool_calculation_cycle` | • Changed data type of column `PROFIT_RATE` | | `ips_pool_settings` | • Removed foreign key `FK_IPS_POOL_BANK_INVESTMENT_PL_ACCOUNT_ENCODEDKEY_KEY` | | `ips_product_calculation_cycle` | • Changed data type of column `PROFIT_RATE` | | `ips_product_settings` | • Removed foreign key `FK_IPS_PRODUCT_SETTINGS_SAVINGS_PRODUCT_ENCODEDKEY` | | `ips_system_options` | • Removed foreign key `FK_IPS_SYSTEM_OPTIONS_PROFIT_SUSPENSE_ACCOUNT_ENCODEDKEY`
    • Removed foreign key `FK_IPS_SYSTEM_OPTIONS_RESERVE_ACCOUNT_ENCODEDKEY` | | `loantransaction` | • Added column `ADDITION`
    • Added column `ADDITION`
    • Added column `ADDITION`
    • Added column `ADDITION` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.175 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.175/ This page contains the following releases for v9.175: * [v9.175](#v9175) * [v9.175.3](#v91753) * [v9.175.2](#v91752) * [v9.175.1](#v91751) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.175 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Carried-forward balances displayed on rescheduled and refinanced accounts When a loan is rescheduled or refinanced, the account details screen now shows the balances carried forward from the previous arrangement — including principal, interest, arrears state, days in arrears, and the date the account entered arrears — giving staff a complete picture of the account's history at a glance. *Internal references:* [MTGE-1474](https://mambucom.jira.com/browse/MTGE-1474), [MTGE-1348](https://mambucom.jira.com/browse/MTGE-1348), [MTGE-1091](https://mambucom.jira.com/browse/MTGE-1091) #### Broken interest option visible on loan account details The **Broken Interest** option is now displayed on the loan account details screen for capital repayment loans, making it easier to review and confirm the interest configuration applied to an account. *Internal references:* [MTGE-1435](https://mambucom.jira.com/browse/MTGE-1435) #### Interest on interest-bearing fees now accrues, applies, and displays correctly Simple interest now accrues on interest-bearing fee balances via scheduled processing, repayments against those balances are validated to prevent overpayment, and the resulting interest balance is visible in the loan account summary — closing a gap where this balance was previously hidden from view. *Internal references:* [MTGE-1377](https://mambucom.jira.com/browse/MTGE-1377), [MTGE-1319](https://mambucom.jira.com/browse/MTGE-1319), [MTGE-1315](https://mambucom.jira.com/browse/MTGE-1315), [MTGE-1314](https://mambucom.jira.com/browse/MTGE-1314), [MTGE-1311](https://mambucom.jira.com/browse/MTGE-1311), [MTGE-1310](https://mambucom.jira.com/browse/MTGE-1310) #### Prepayment recalculation method selectable at repayment time for additional product configurations Users can now choose the prepayment recalculation method at the point of repayment for a broader set of mortgage product configurations, with the **Prepayment Method** dropdown now available in the payment pop-up and the supporting validation extended accordingly. *Internal references:* [MTGE-1176](https://mambucom.jira.com/browse/MTGE-1176), [MTGE-1164](https://mambucom.jira.com/browse/MTGE-1164), [MTGE-1162](https://mambucom.jira.com/browse/MTGE-1162) #### Groundwork for upcoming features - Groundwork for phase-2 balance handling for transactions posted after midnight and on the interest application date, covering card settlement, post-seizure, and fee-posting scenarios. #### Additional work - Internal mortgage performance and schedule-computation improvements. --- ### Credit Arrangements #### Credit arrangement search extended to support encoded key lookup The credit arrangements search now accepts `encodedKey` as a search parameter, enabling more precise and direct lookups. *Internal references:* [LL-5533](https://mambucom.jira.com/browse/LL-5533) #### Additional work - Internal schedule-calculation test tooling updates. --- ### Islamic Banking #### Withholding tax fields surfaced in the UI for profit application Withholding tax fields are now included in the UI data model and displayed on the relevant screens, supporting the configuration and visibility of withholding tax during profit application. *Internal references:* [IB-2300](https://mambucom.jira.com/browse/IB-2300) #### Groundwork for upcoming features - Groundwork for the Investment Pool Sharing (IPS) profit-sharing accounting cycle, including batch processing, payment cycle status updates, and product-level accounting rules. - Groundwork for IPS proposal configuration, adding fields at account, pool, and product levels. --- ### Data #### Additional work - Non-customer-facing internal refactoring of installment field computation and fee capitalisation logic. - Backend-only EOD execution context and metrics improvements. - Internal EOD feature-flag cleanup, retaining pagination and repayment fetch improvements as permanent defaults. - Internal repository and infrastructure maintenance. --- ## Improvements ### Data #### Additional work - Non-customer-facing internal data and infrastructure changes. ### Access Control #### Additional work - Internal access control maintenance. ### Lending #### Additional work - Non-customer-facing internal lending maintenance. ### Deposits #### Additional work - Non-customer-facing internal deposits maintenance. ### Credit Arrangements #### Additional work - Non-customer-facing internal credit arrangement changes. ### Cards #### Bulk authorization hold management via API A new bulk API endpoint for authorization holds enables card processors to submit multiple authorization hold requests in a single call, with balance validation performed before each update to ensure only holds with sufficient funds are applied. *Internal references:* [BKE-603](https://mambucom.jira.com/browse/BKE-603), [BKE-576](https://mambucom.jira.com/browse/BKE-576), [BKE-571](https://mambucom.jira.com/browse/BKE-571) ### Payments #### Additional work - Non-customer-facing internal payments maintenance. ### Islamic Banking #### Additional work - Non-customer-facing Islamic Banking internal maintenance. ### Developer #### Resilient idempotency key handling A null-pointer error that could occur when extending the time-to-live of an idempotent request entry is now resolved, improving reliability for integrations that rely on idempotency guarantees. *Internal references:* [BKE-662](https://mambucom.jira.com/browse/BKE-662) #### Groundwork for upcoming features - Asynchronous notification support is being extended to additional CBE endpoints, including deposit creation, loan editing, loan disbursement transactions, credit arrangement patching, and authorization hold creation. #### Additional work - Non-customer-facing developer tooling changes. --- ## Bug fixes ### Mortgages #### Overpayment no longer causes incorrect principal balance during a Payment Holiday Making a payment during a Payment Holiday period previously caused the principal balance to be calculated incorrectly on interest-only with equal instalments accounts; this has now been resolved. *Internal references:* [MTGE-1399](https://mambucom.jira.com/browse/MTGE-1399) #### Schedule interest recalculated correctly after overpayments before due date Fixed schedule interest calculation after overpayments before due date on dynamic mortgage accounts; previously the system used an incorrect calculation for the loan account schedule. *Internal references:* [MTGE-1383](https://mambucom.jira.com/browse/MTGE-1383) #### Journal reversal now correctly mirrors accounting bookings Fixed an issue where journal reversals were not mirroring their corresponding accounting bookings, ensuring accounting entries remain consistent. *Internal references:* [MTGE-1488](https://mambucom.jira.com/browse/MTGE-1488) #### Fee schedule no longer generated when no fees are present Resolved an issue where a fee schedule was being created for accounts that had no fees configured, preventing unnecessary schedule entries. *Internal references:* [MTGE-1459](https://mambucom.jira.com/browse/MTGE-1459) #### Interest accrued correctly excluded from PMT recalculation for compound interest loans Fixed an issue where accrued interest was incorrectly included in the payment (PMT) recalculation for loans using new compound interest when an interest rate change transaction was posted before the threshold. *Internal references:* [MTGE-1449](https://mambucom.jira.com/browse/MTGE-1449) #### IFA balance can now be settled when all other loan balances are fully paid Resolved an issue where the Interest Fee Account (IFA) balance could not be paid once all other balances on the loan had been cleared. *Internal references:* [MTGE-1191](https://mambucom.jira.com/browse/MTGE-1191) #### Journal entries now created for non-scheduled fee applications Fixed an issue where applying a non-scheduled fee failed to generate the corresponding journal entries, ensuring all fee activity is correctly recorded in accounting. *Internal references:* [MTGE-1378](https://mambucom.jira.com/browse/MTGE-1378) --- ### Deposits #### Reopening a closed-rejected account now correctly enforces account transition rules Fixed an issue where the reopen account endpoint bypassed required account transition validations for accounts in `CLOSED_REJECTED` state. *Internal references:* [DO-825](https://mambucom.jira.com/browse/DO-825) #### Overdraft index interest rate calculated correctly when activation transaction is adjusted Resolved an issue where the system failed to calculate the overdraft index interest rate when the activation transaction was adjusted, which previously caused a null pointer error during appraisal. *Internal references:* [DO-592](https://mambucom.jira.com/browse/DO-592) #### Deposits with a booking date after account closure date now processed correctly When making a deposit after the accounting closure with a booking date, the system now performs the deposit while correctly applying the account closure logic. *Internal references:* [DO-455](https://mambucom.jira.com/browse/DO-455) #### End-of-day jobs no longer fail when importing savings accounts with Interest Rate Management Enhancements enabled Resolved an issue where end-of-day jobs would fail if the Interest Rate Management Enhancements feature was enabled and savings accounts were imported using the Excel template. *Internal references:* [DIF-2092](https://mambucom.jira.com/browse/DIF-2092) --- ### Lending #### Instalments now correctly marked as paid after an overpayment on the due date Fixed an issue where an instalment was not being marked as **Paid** after an overpayment was made on the due date. *Internal references:* [LL-5508](https://mambucom.jira.com/browse/LL-5508) #### Interest split preserved after editing a loan account Resolved an issue where editing a loan account caused the interest to no longer be split correctly across the schedule. *Internal references:* [LL-5507](https://mambucom.jira.com/browse/LL-5507) #### Loan accounts with custom schedules can now be edited via API in Approved or Closed state Fixed an issue where editing a loan account via API v2 with a custom schedule in **Approved** or **Closed** state would not work properly. *Internal references:* [LL-4259](https://mambucom.jira.com/browse/LL-4259) --- ### Islamic Banking #### Mudarib share no longer displays a negative value when it should be zero Fixed an issue where the Mudarib share was incorrectly shown with a minus sign instead of zero. *Internal references:* [IB-2260](https://mambucom.jira.com/browse/IB-2260) #### Expected return percentage now displayed correctly in proposal details Resolved a UI issue where the expected return (ER) was not presented as a percentage in the proposal details screen. *Internal references:* [IB-2259](https://mambucom.jira.com/browse/IB-2259) #### Proposal job no longer picks up pools with a future start date Fixed an issue where the proposal job was incorrectly selecting pools whose start date had not yet been reached. *Internal references:* [IB-2255](https://mambucom.jira.com/browse/IB-2255) #### Payment cycle end date calculated correctly when activation date falls on the last day of the month Resolved an issue where the payment cycle `endDate` was calculated incorrectly when the account activation date was the last day of the month. *Internal references:* [IB-2252](https://mambucom.jira.com/browse/IB-2252) --- ### Data #### Transaction custom field values can no longer be edited by view-only users Fixed an issue where users with view-only access to custom fields were able to create new transactions and populate those field values; permissions are now correctly enforced. *Internal references:* [ADM-3968](https://mambucom.jira.com/browse/ADM-3968) #### Loan transaction data import now returns accurate validation error messages Corrected an inaccurate validation error message returned during spreadsheet import of loan transactions. *Internal references:* [ADM-3923](https://mambucom.jira.com/browse/ADM-3923) #### Exceeding custom field limits on deposit account requests now returns the correct error code Fixed an issue where exceeding the custom field limit when creating or updating a deposit account via `POST` or `PATCH` returned a `500` error instead of the correct `400` response. *Internal references:* [ADM-3893](https://mambucom.jira.com/browse/ADM-3893) #### Custom field selection ordering now applied correctly Resolved an issue where the configured ordering of custom field selections was not being respected in the UI. *Internal references:* [ADM-3389](https://mambucom.jira.com/browse/ADM-3389) #### Additional work - Internal schedule engine data fix. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.175 cycle. ## v9.175.3 **Release Date**: 03.06.2026 --- ## Improvements ### Lending #### Groundwork for upcoming features - Ongoing separation and refinement of revolving credit logic in preparation for cleaner product boundaries and future feature work. --- ## v9.175.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and internal refactoring. --- ## v9.175.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Groundwork for upcoming features - Ongoing separation and consolidation of revolving credit logic to support a cleaner, more maintainable product architecture. #### Additional work - Internal refactoring of loan account method integrations with no customer-facing changes. ---

    Database changes

    | Table | Changes | |---|---| | `fse_account` | • Added column `LATEST_SCHEDULEVERSION_ENCODEDKEY` | | `fse_scheduleversion` | • Added column `VERSION_INDEX` | | `ips_product_calculation_cycle` | • Added column `WITHHOLDING_TAX_ENABLED`
    • Added column `WITHHOLDING_TAX_SOURCE_KEY` | | `ips_product_settings` | • Added column `WITHHOLDING_TAX_ENABLED`
    • Added column `WITHHOLDING_TAX_SOURCE_KEY` | | `loan_account_carry_forward_log` | • New table
    • Added index `labc_idx_newLoanAccountEncodedKey`
    • Added index `labc_idx_oldLoanAccountEncodedKey` | | `savings_transactions_daily_summary` | • Changed data type of column `avg_balance`
    • Changed data type of column `total_balance`
    • Changed data type of column `min_balance` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.176 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.176/ This page contains the following releases for v9.176: * [v9.176](#v9176) * [v9.176.1](#v91761) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.176 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Redraw support on Dynamic Mortgage products The redraw flag is now forwarded to the contract and displayed in the UI for Dynamic Mortgage products, giving clients visibility and control over redraw availability directly on the account. *Internal references:* [MTGE-1534](https://mambucom.jira.com/browse/MTGE-1534), [MTGE-1480](https://mambucom.jira.com/browse/MTGE-1480) #### Interest-bearing fees decoupled from the repayment schedule Interest-bearing fees can now accrue and compound independently of the repayment schedule, with manual interest application available via both the API and UI; repaid interest is validated to prevent excessive repayment, and applied interest transactions are visible in the account view. *Internal references:* [MTGE-1323](https://mambucom.jira.com/browse/MTGE-1323), [MTGE-1321](https://mambucom.jira.com/browse/MTGE-1321), [MTGE-1320](https://mambucom.jira.com/browse/MTGE-1320), [MTGE-1318](https://mambucom.jira.com/browse/MTGE-1318), [MTGE-1317](https://mambucom.jira.com/browse/MTGE-1317), [MTGE-1316](https://mambucom.jira.com/browse/MTGE-1316), [MTGE-1523](https://mambucom.jira.com/browse/MTGE-1523), [MTGE-1517](https://mambucom.jira.com/browse/MTGE-1517), [MTGE-1513](https://mambucom.jira.com/browse/MTGE-1513), [MTGE-1512](https://mambucom.jira.com/browse/MTGE-1512), [MTGE-1490](https://mambucom.jira.com/browse/MTGE-1490) #### Custom contractual monthly payment on Dynamic Mortgage accounts Dynamic Mortgage accounts now support a custom **Contractual Monthly Payment (CMP)**, enabling lenders to maintain a fixed payment amount independently of schedule recalculations. *Internal references:* [MTGE-1401](https://mambucom.jira.com/browse/MTGE-1401) #### Groundwork for upcoming features - Carry-forward balance handling at reschedule and refinance is being extended to cover principal in arrears, late principal splitting, and write-off scenarios. #### Additional work - Internal mortgage service and schedule engine maintenance. --- ### Lending #### Equal installments for extended first periods on simple interest loans Interest splitting logic for payment holidays is now supported in schedule calculations for simple interest loans using optimised payments, with the feature automatically disabled based on **Prepayment Allocation** and **Mark Installment As Paid When** configuration options. *Internal references:* [LL-2405](https://mambucom.jira.com/browse/LL-2405), [LL-2403](https://mambucom.jira.com/browse/LL-2403) #### Additional work - Internal lending performance and validation fixes. --- ### Accounting #### Upgraded trial balance reporting via the accounting reports API The **Get accounting reports** API now delivers an upgraded trial balance report, improving the accuracy and scalability of accounting summary data returned to clients. *Internal references:* [LED-2596](https://mambucom.jira.com/browse/LED-2596) #### Additional work - Internal GL accounts balance computation logging improvements. --- ### Islamic Banking #### Groundwork for upcoming features - Profit-sharing accounting and payment cycle integration is being prepared for general availability, including profit application transactions, configuration consistency validation, and feature-toggled API endpoints. #### Additional work - Internal Islamic Banking UI dependency updates and operational readiness maintenance. --- ### Data #### GET APIs for fetching product features New GET endpoints are available to retrieve product features, enabling clients to programmatically query product feature configurations as part of the overdraft product independence initiative. *Internal references:* [DIF-2195](https://mambucom.jira.com/browse/DIF-2195) #### Groundwork for upcoming features - Balance handling for transactions posted after midnight and on the interest application date is being extended to cover bulk deposit and card settlement reversal scenarios. - Flexible Schedule Engine installment fields are being migrated to a functionless field model to support next-generation schedule computation. #### Additional work - Internal search, observability, and schedule engine maintenance. --- ## Improvements ### Lending #### Cross-site scripting vulnerability resolved in index rate configuration Fixed a stored cross-site scripting (XSS) vulnerability that occurred when adding a new index rate source, ensuring user input is properly sanitised to prevent malicious script injection and enhance overall application security. *Internal references:* [LPRC-1899](https://mambucom.jira.com/browse/LPRC-1899) #### Groundwork for upcoming features - Ongoing work to isolate and modularise revolving credit logic, integrating scheduled jobs, orchestrators, UI flows, and private APIs into a dedicated revolving submodule. #### Additional work - Internal lending lifecycle maintenance and backend-only changes. --- ### Deposits #### Dormant account state correctly restored after unlock Fixed an issue where a deposit account in a **Dormant** state that was locked and then unlocked would incorrectly transition to **Active**, with the dormant state only being re-established at the next End of Day (EOD) run; unlocked accounts now immediately reflect the correct dormant state if conditions are met. *Internal references:* [DO-1154](https://mambucom.jira.com/browse/DO-1154) #### Groundwork for upcoming features - Foundational work on the deposits EOD transitional architecture to support JDBI-based persistence. #### Additional work - Internal deposits logging and backend-only changes. --- ### Access Control #### Unauthorised access to teller and loan product data prevented Resolved improper access control vulnerabilities that allowed unauthorised retrieval of teller till data and loan product summaries, ensuring these endpoints now enforce correct permission checks. *Internal references:* [LL-5325](https://mambucom.jira.com/browse/LL-5325), [LL-5324](https://mambucom.jira.com/browse/LL-5324), [LL-5323](https://mambucom.jira.com/browse/LL-5323) --- ### Notifications #### Document preview and template management access properly restricted Editing access to product document templates is now restricted to users with the `EDIT_PRODUCT_DOCUMENT_TEMPLATES`, `CREATE_PRODUCT_DOCUMENT_TEMPLATES`, and `DELETE_PRODUCT_DOCUMENT_TEMPLATES` permissions, and the UI backend endpoint for document previews in the Savings module now requires the **Document View** permission. *Internal references:* [NTF-3311](https://mambucom.jira.com/browse/NTF-3311), [NTF-3197](https://mambucom.jira.com/browse/NTF-3197) #### Additional work - Internal notifications dependency and security maintenance. --- ### Accounting #### Balance computation improved for mixed journal entry types Improved the accuracy of balance calculations when a mix of summarised and unsummarised journal entries is present, ensuring consistent and correct reporting outcomes. *Internal references:* [LED-2693](https://mambucom.jira.com/browse/LED-2693), [LED-2529](https://mambucom.jira.com/browse/LED-2529) #### Groundwork for upcoming features - Continued improvements to the accounting summary algorithm to support enhanced ledger reporting. --- ### Islamic Banking #### Configuration errors surfaced directly in the settings panel Islamic profit sharing (IPS) configuration errors are now displayed inline within the configuration settings panel, giving users immediate visibility of issues without needing to navigate away. *Internal references:* [IB-2362](https://mambucom.jira.com/browse/IB-2362), [IB-2360](https://mambucom.jira.com/browse/IB-2360) #### Groundwork for upcoming features - Internal service and data-retrieval work to support profit applied transaction adjustments, withholding tax journal entries, and payment cycle filtering improvements. --- ### Cards #### Groundwork for upcoming features - Building bulk authorisation hold API capabilities for cards, including balance management, partial authorisation handling, and account state validation. --- ### Mortgages #### Additional work - Internal mortgage development configuration changes. --- ### Developer #### Additional work - Backend-only internal changes including obfuscation, build tooling, and configuration updates. --- ## Bug fixes ### Deposits #### Deposit product configuration update now surfaces all validation errors Previously, updating a deposit product via configuration could silently suppress certain errors, such as those related to custom fields. All validation errors are now correctly returned during the update process. *Internal references:* [DO-170](https://mambucom.jira.com/browse/DO-170) #### Correct account creation date shown on deposit account overview Resolved an issue where `creationDate` was displayed with a different value on the **Deposit Account Overview** page compared with the **Deposit Accounts** tab. *Internal references:* [DO-74](https://mambucom.jira.com/browse/DO-74) #### Accurate transaction timestamp in deposit account activation notifications Resolved an issue where the `TRANSACTION_DATE` notifications placeholder was returning an incorrect transaction time for the **Deposit Account Activated** event. *Internal references:* [DO-159](https://mambucom.jira.com/browse/DO-159) #### Additional work - Non-customer-facing deposit configuration fixes. --- ### Lending #### Repayment history preserved correctly during loan schedule adjustments Fixed an issue where previously paid dues could lose their payment records when the due amount increased, ensuring repayment history is correctly maintained across rescheduled loans. *Internal references:* [REV-4372](https://mambucom.jira.com/browse/REV-4372) #### Interest correctly restored after undoing a payoff transaction Fixed an issue where, after undoing the payoff of a fixed-term loan with interest applied at the repayment moment, the interest from the schedule was missing; interest is now correctly visible on the schedule after the payoff transaction is adjusted. *Internal references:* [LPRC-4113](https://mambucom.jira.com/browse/LPRC-4113) #### Loan arrears status no longer incorrectly triggered when no amount is due Fixed an issue where an account was sometimes shown as in arrears when there was no total due amount outstanding. *Internal references:* [LPRC-3809](https://mambucom.jira.com/browse/LPRC-3809) #### `feesDue` calculated correctly when IOF fee and `FEE_INCLUDED_IN_PMT` are used together Fixed an incorrect `feesDue` calculation that occurred when an IOF fee and `FEE_INCLUDED_IN_PMT` were applied simultaneously. *Internal references:* [LPRC-4420](https://mambucom.jira.com/browse/LPRC-4420) #### Validation added for `FEE_INCLUDED_IN_PMT` product-level configuration A validation error is now raised when `useFeeIncludedInPMT` is set to `true` at the product level but the corresponding `FEE_INCLUDED_IN_PMT` fee does not exist, preventing silent misconfiguration. *Internal references:* [LPRC-4418](https://mambucom.jira.com/browse/LPRC-4418) --- ### Mortgages #### ERC fee allowance amounts rounded to the configured repayment currency Fixed an issue where Early Repayment Charge fee allowance amounts were not being rounded according to the repayment currency defined in **Administration**. *Internal references:* [MTGE-1521](https://mambucom.jira.com/browse/MTGE-1521) #### Principal overpayment no longer returns an error Resolved an error that occurred when performing a principal overpayment on a mortgage account. *Internal references:* [MTGE-1509](https://mambucom.jira.com/browse/MTGE-1509) #### Future interest calculation corrected for accounts with AIR and compounding interest Fixed an incorrect future interest calculation on the preview schedule for loans using an Annual Interest Rate with compounding interest. *Internal references:* [MTGE-1508](https://mambucom.jira.com/browse/MTGE-1508) #### Loan accounts correctly return to good standing after late installments are marked as payment holiday Fixed an issue where a loan account previously in arrears was not being set back to good standing when its late installments were marked as a payment holiday. *Internal references:* [MTGE-1078](https://mambucom.jira.com/browse/MTGE-1078) --- ### Islamic Banking #### Profit application transactions now correctly linked to withholding tax Fixed an issue where profit applied transactions were not being associated with the corresponding withholding tax entries. *Internal references:* [IB-2364](https://mambucom.jira.com/browse/IB-2364) #### Profit correctly applied for accounts with adjusted transactions after the profit application entry date Resolved an issue where profit was not being applied to accounts that had adjusted transactions dated after the profit application entry date. *Internal references:* [IB-2355](https://mambucom.jira.com/browse/IB-2355) #### Transaction list accessible in the UI after profit application Fixed an issue that prevented users from accessing the transactions list in the UI after applying profit to an account. *Internal references:* [IB-2351](https://mambucom.jira.com/browse/IB-2351) #### Customer share percentage per tier now updates correctly when balance changes Fixed an issue where the customer share percentage per tier was not being recalculated when the account balance was updated. *Internal references:* [IB-2276](https://mambucom.jira.com/browse/IB-2276) --- ### Data #### Additional work - Non-customer-facing data and logging fixes. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.176 cycle. ## v9.176.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data and infrastructure maintenance. ---

    Database changes

    | Table | Changes | |---|---| | `ips_payment_cycle_transaction` | • New table | | `savingstransactioncustomfieldvalue` | • Changed data type of column `transactionkey`
    • Removed unique constraint `TRANSACTIONKEY_VALUEDATE_IDX`
    • Changed data type of column `VALUEDATE`
    • Added primary key on `TRANSACTIONKEY,VALUEDATE` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.177 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.177/ This page contains the following releases for v9.177: * [v9.177](#v9177) * [v9.177.4](#v91774) * [v9.177.3](#v91773) * [v9.177.2](#v91772) * [v9.177.1](#v91771) ## v9.177 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Notes can now be added when manually applying fee interest When manually applying fee interest, users can now include a note to provide context or record the reason for the action. *Internal references:* [MTGE-1542](https://mambucom.jira.com/browse/MTGE-1542) #### Fee interest application reversal dialog restored A broken dialog for reversing fee interest applications has been fixed, restoring the ability to complete this action from the UI. *Internal references:* [MTGE-1566](https://mambucom.jira.com/browse/MTGE-1566) #### Pay-off calculations now account for carried-forward amounts Pay-off processing correctly incorporates carried-forward balances, and multiple reschedule or refinance operations now preserve any existing carried-forward amounts rather than discarding them. *Internal references:* [MTGE-1528](https://mambucom.jira.com/browse/MTGE-1528), [MTGE-1495](https://mambucom.jira.com/browse/MTGE-1495) #### New penalty calculation option includes fees in overdue balance A new penalty calculation method, `OVERDUE_BALANCE_INTEREST_AND_FEE`, is available on loan products and accounts, allowing fees due to be factored into penalty calculations alongside interest; this option is controlled by the `includeFeeInPenalty` feature toggle. *Internal references:* [LPRC-4345](https://mambucom.jira.com/browse/LPRC-4345) #### Schedule fix migration tool produces more consistent results The schedule fix migration tool now ignores single-field differences limited to the Last Paid Date, and runs account appraisal before enabling the fix, resolving inconsistencies in report output. *Internal references:* [LPRC-4145](https://mambucom.jira.com/browse/LPRC-4145) #### Groundwork for upcoming features - Building support for redraw functionality on the DynamicMortgage product, including product and account creation, event handling, schedule updates, and reporting fields. - Expanding Islamic Banking profit-sharing proposals with additional account details. #### Additional work - Internal field migration and package reorganisation work across the formula scripting engine. --- ## Improvements ### Lending #### Auto-healing skips locked accounts and reduces database load Autohealing now skips locked accounts and consolidates database calls from seven to one, significantly improving performance during automated recovery processing. *Internal references:* [REV-4449](https://mambucom.jira.com/browse/REV-4449) #### End-of-day exclusion extended to revolving accounts The existing mechanism for excluding broken accounts from End of Day processing has been extended to also support revolving accounts, improving processing reliability across account types. *Internal references:* [REV-4419](https://mambucom.jira.com/browse/REV-4419) #### Stored XSS vulnerability fixed when adding fees Fixed a stored cross-site scripting (XSS) vulnerability that occurred when adding a fee under a loan product, ensuring user input is properly sanitised to prevent malicious script injection. *Internal references:* [LPRC-4132](https://mambucom.jira.com/browse/LPRC-4132) #### Groundwork for upcoming features - Ongoing work to modularise revolving credit logic by separating it from shared product code, integrating UI flows for penalty, schedule, and interest management, and consolidating revolving acceptance tests into a dedicated module. - Foundational implementation work for a lending pricing engine, including fee accrual fields on the loan account API response, a fee adjustment mechanism, and an updated normal repayment flow. #### Additional work - Internal lending maintenance and technical debt cleanup, including feature toggle removals and schedule engine versioning updates. --- ### Deposits #### Groundwork for upcoming features - Infrastructure work to support handling of fees and overdraft limit expiry dates when updating account balances. #### Additional work - Internal deposits maintenance, including feature toggle removals and internal configuration changes. --- ### Notifications #### Webhook and template notification settings manageable via API New `GET /notificationsettings` and `PUT /notificationsettings/webhook` API endpoints allow notification settings to be retrieved by template type and updated programmatically, supporting configuration-as-code workflows. *Internal references:* [MYM-4733](https://mambucom.jira.com/browse/MYM-4733), [MYM-4731](https://mambucom.jira.com/browse/MYM-4731), [MYM-4747](https://mambucom.jira.com/browse/MYM-4747) #### Destination URL validation enforced for notification endpoints Notification configuration now validates that the destination is a properly formed URL, preventing misconfigured delivery targets from being saved. *Internal references:* [NTF-3381](https://mambucom.jira.com/browse/NTF-3381) --- ### Islamic Banking #### Configuration errors surfaced in the UI for IPS settings Errors encountered during IPS configuration are now translated and displayed directly in the UI, giving operators clear, actionable feedback without needing to inspect backend logs. *Internal references:* [IB-2361](https://mambucom.jira.com/browse/IB-2361) #### Additional work - Internal security improvement to prevent sensitive or personally identifiable data from appearing in logs. --- ### Data #### Additional work - Non-customer-facing infrastructure and configuration work, including EOD horizontal scaling investigations and internal job routing changes. --- ## Bug fixes ### Mortgages #### Overpayments no longer trigger incorrect interest recalculations on dynamic mortgage accounts On dynamic mortgage loan accounts created with RAI where Principal Expected has been paid, overpayments were incorrectly generating a Recalculate Next Installment (RNI) recalculation — including cases where the overpayment was posted after a regular prepayment allocated to an upcoming pending installment. This has been fixed. *Internal references:* [MTGE-1578](https://mambucom.jira.com/browse/MTGE-1578), [MTGE-1529](https://mambucom.jira.com/browse/MTGE-1529) ### Lending #### Penalty allocations from custom repayments now target the correct installment The system would sometimes not allocate penalties from a custom repayment on the installment that had the penalty due. This has been fixed. *Internal references:* [LPRC-1333](https://mambucom.jira.com/browse/LPRC-1333) #### Fee transactions now reinsert correctly after adjustment and cron job re-execution A fee transaction was not being inserted after it was adjusted and the cron job executed again. This has been fixed. *Internal references:* [LPRC-4461](https://mambucom.jira.com/browse/LPRC-4461) #### Additional work - Non-customer-facing lending data fix. ### Transactions and Interest #### Interest accrual batch completion dates now record the correct timestamp When marking an interest accrual batch as complete in the decoupled flow, the `completionDate` was not correctly considering the timestamp at the time of storage. This has been fixed. *Internal references:* [LED-2575](https://mambucom.jira.com/browse/LED-2575) ### Islamic Banking #### Profit application entry dates now correct when using payment cycle end date When the profit application point was set to `PAYMENT_CYCLE_END_DATE`, an incorrect entry date was being recorded. This has been fixed. *Internal references:* [IB-2392](https://mambucom.jira.com/browse/IB-2392) #### Taxes payable accounting rules can now be configured for IPS products A configuration restriction was preventing taxes payable accounting rules from being applied to Islamic Profit Sharing (IPS) products. This has been resolved. *Internal references:* [IB-2375](https://mambucom.jira.com/browse/IB-2375) #### Pool configuration no longer incorrectly blocked An issue was preventing pool configuration from being saved or updated. This has been fixed. *Internal references:* [IB-2387](https://mambucom.jira.com/browse/IB-2387) #### IPS proposal product detail labels corrected Incorrect text labels in the **Proposal Product Details** screen for IPS have been updated to accurately reflect the relevant fields. *Internal references:* [IB-2386](https://mambucom.jira.com/browse/IB-2386) ### Data #### Custom and native fields with the same name are now distinguished in filters When a custom field shared the same name as a native field, duplicate filter options appeared and the selected filter value was silently overridden. Filter options for custom fields now display a **(Custom Fields)** suffix, ensuring the correct field is always applied. *Internal references:* [CDO-4280](https://mambucom.jira.com/browse/CDO-4280) #### Transaction custom fields now save correctly on PATCH requests An issue prevented transaction custom field values from being persisted when updated via a `PATCH` request. This has been fixed. *Internal references:* [ADM-3998](https://mambucom.jira.com/browse/ADM-3998) --- ## v9.177.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data processing and infrastructure maintenance. --- ## v9.177.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data processing and backend optimisation changes. --- ## v9.177.2 **Release Date**: 03.06.2026 --- ## Improvements ### Additional work - Non-customer-facing internal configuration and infrastructure changes. --- ## v9.177.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data processing and end-of-day job optimisations. --- ## Bug fixes ### Lending #### Planned fees date no longer shifted by customer time zone The `POST /loans//plannedfees:apply` endpoint was incorrectly converting the `applyOnDate` response field to the customer's time zone instead of returning midnight UTC. This has been fixed. *Internal references:* [LPRC-3631](https://mambucom.jira.com/browse/LPRC-3631) --- For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.178 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.178/ This page contains the following releases for v9.178: * [v9.178](#v9178) * [v9.178.7](#v91787) * [v9.178.6](#v91786) * [v9.178.5](#v91785) * [v9.178.4](#v91784) * [v9.178.3](#v91783) * [v9.178.2](#v91782) * [v9.178.1](#v91781) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.178 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Carry forward balances at reschedule and refinance When a loan is rescheduled or refinanced, principal, interest, interest-from-arrears balances, loan state, days in arrears, and days late are now carried forward into the new arrangement, with daily accruals applied to those carried-forward balances in the ledger. *Internal references:* [MTGE-1637](https://mambucom.jira.com/browse/MTGE-1637), [MTGE-1626](https://mambucom.jira.com/browse/MTGE-1626), [MTGE-1618](https://mambucom.jira.com/browse/MTGE-1618), [MTGE-1520](https://mambucom.jira.com/browse/MTGE-1520) #### Interest-bearing fees decoupled from the repayment schedule Lenders can now configure dedicated GL accounts for fee interest, validate accounting settings for interest-bearing fees, and process loan pay-offs that include interest-bearing fee balances, with negative journal entries prevented for adjusted non-scheduled or interest-bearing fees. *Internal references:* [MTGE-1603](https://mambucom.jira.com/browse/MTGE-1603), [MTGE-1570](https://mambucom.jira.com/browse/MTGE-1570), [MTGE-1567](https://mambucom.jira.com/browse/MTGE-1567), [MTGE-1415](https://mambucom.jira.com/browse/MTGE-1415) #### Principal overpayment captured and linked during repayment Users can now specify a principal overpayment amount at the time of repayment; the overpayment is processed and logged together with the repayment transaction, and adjusting the overpayment in isolation is restricted when it is linked to a repayment. *Internal references:* [MTGE-1575](https://mambucom.jira.com/browse/MTGE-1575), [MTGE-1574](https://mambucom.jira.com/browse/MTGE-1574), [MTGE-1573](https://mambucom.jira.com/browse/MTGE-1573), [MTGE-1572](https://mambucom.jira.com/browse/MTGE-1572) --- ### Lending #### Fee amounts surfaced in loan transaction API responses The loan transaction API response now includes `feeIncludedInPmt` and `lateFeeIncludedInPmt` fields, giving integrators direct visibility into the fee portions of optimised payment amounts. *Internal references:* [LPRC-4607](https://mambucom.jira.com/browse/LPRC-4607) #### Credit arrangement search extended by owner Credit arrangement searches can now be filtered by `ownerKey`, making it easier to retrieve all arrangements belonging to a specific owner. *Internal references:* [LL-5630](https://mambucom.jira.com/browse/LL-5630) --- ### Islamic Banking #### Profit application corrected for non-end-of-month payment cycles Profit application now works correctly for accounts whose payment cycle end date does not fall at the end of the month, resolving a calculation failure in those configurations. *Internal references:* [IB-2455](https://mambucom.jira.com/browse/IB-2455) #### GL entries generated from Mudarib share after profit application General ledger entries are now produced from the product-level Mudarib share following profit application, and a dedicated **Mudarib Share** accounting category is available at the product level in the UI. *Internal references:* [IB-2411](https://mambucom.jira.com/browse/IB-2411), [IB-2407](https://mambucom.jira.com/browse/IB-2407) #### Withholding tax amounts visible on the proposal page A **Withholding Tax** column is now displayed on the proposal page, showing indicative withholding tax amounts for each entry. *Internal references:* [IB-2248](https://mambucom.jira.com/browse/IB-2248) #### End-of-day profit-sharing job status visible in the UI Operators can now monitor the status of end-of-day profit-sharing jobs directly from the UI, reducing the need to query backend systems for job progress. *Internal references:* [IB-1987](https://mambucom.jira.com/browse/IB-1987) #### IPS public API endpoints available The Proposals, Proposal Account Details, and Product Search endpoints are now exposed in the public API, enabling external integrations with the Islamic Profit Sharing module. *Internal references:* [IB-2348](https://mambucom.jira.com/browse/IB-2348) #### Groundwork for upcoming features - Configuration service extended to structure pool data by the proposal each pool belongs to, in preparation for full IPS configuration consistency. - IPS API documentation prepared and OpenAPI specification migrated from v2 to v3, supporting operational readiness for general availability. --- ### Data #### Groundwork for upcoming features - Installment fields `CURRENT_INTEREST_BALANCE`, `PMT_INTEREST_RATE`, `PMT_ANNUAL_NOMINAL_INTEREST_RATE`, and `FEE_EVENT_DETAILS` migrated to functionless fields as part of the ongoing FSE functions migration. - Schedule serialisation refactored using Avro for FSEValue classes and their corresponding serializers. - Deposits end-of-day transitional architecture extended with batched persistence for savings account changes. - Backdating transactions logic implemented as part of accrual data migration groundwork. - Foundation work for independence of temporary overdraft from overdraft, covering account feature creation and linking capabilities. #### Additional work - Internal architectural guidelines and code-to-capability mapping updates. --- ## Improvements ### Access Control #### Data import endpoints now enforce proper authorization Fixed a security vulnerability where a non-privileged user could access sensitive information related to administrative data import tasks via the `GetBackgroundTaskProgress` endpoint. Access is now restricted by the `VIEW_BACKGROUND_TASKS` permission, and the `GET /admin/errorfile` endpoint is now restricted to administrators only, preventing unauthorized users from downloading files containing Personally Identifiable Information. *Internal references:* [ADM-3880](https://mambucom.jira.com/browse/ADM-3880), [ADM-3879](https://mambucom.jira.com/browse/ADM-3879) #### Custom field access now requires an explicit administration permission UI users must now hold at least one permission under **Administration** > **Custom Fields** to access custom fields in any UI flow — such as deposits or loans. This change may require a review and update of existing user permissions. *Internal references:* [ADM-3858](https://mambucom.jira.com/browse/ADM-3858) #### Additional work - Internal access control and administration maintenance. --- ### Notifications #### Webhook and streaming template previews are now protected against HTML injection The content of the request body is now sanitized before being rendered in the **Preview** action when creating a Webhook or Streaming template, preventing stored HTML injection attacks. *Internal references:* [NTF-3336](https://mambucom.jira.com/browse/NTF-3336) #### Notification request endpoint now enforces access control The UI backend endpoint used to retrieve notification requests now requires either the `VIEW_CLIENT_DETAILS` or `VIEW_GROUP_DETAILS` permission before returning data. *Internal references:* [NTF-3312](https://mambucom.jira.com/browse/NTF-3312) #### Additional work - Internal notifications maintenance. --- ### Deposits #### Savings product endpoint now enforces access control The UI backend endpoint used to retrieve savings product summaries now requires the `VIEW_SAVINGS_PRODUCT_DETAILS` permission. *Internal references:* [DO-809](https://mambucom.jira.com/browse/DO-809) #### Additional work - Internal deposits configuration and backend-only changes. --- ### Lending #### Repayment Period Unit changes via API v2 now apply correctly Resolved an issue where modifying the Repayment Period Unit via the `PUT` API v2 call — for example, changing from months to weeks — was silently ignored and the change was not applied. *Internal references:* [LL-5349](https://mambucom.jira.com/browse/LL-5349) #### Additional work - Internal lending backend maintenance. --- ### Mortgages #### `AMORTIZATION_PERIOD_DIFFERENT_THAN_LOAN_LENGTH` compatibility extended Enhanced compatibility of the `AMORTIZATION_PERIOD_DIFFERENT_THAN_LOAN_LENGTH` feature toggle with Dynamic Mortgage and interest-only products. *Internal references:* [MTGE-1393](https://mambucom.jira.com/browse/MTGE-1393) #### Groundwork for upcoming features - Building toward OSB overpayment and repayment API enhancements, including feature-toggle protection for new repayment functionality. - Laying the groundwork for write-off loan support within the interest-bearing fees and repayment schedule decoupling initiative. - Removing the interest-on-custom-date implementation across services, calculators, contracts, helpers, validators, providers, and API/UI layers in preparation for a cleaner Mutual Vision integration. - Addressing an infinite loop risk in the flexible schedule contract to support upcoming schedule reliability improvements. - Restricting **Edit Principal** and **Add/Remove Installments** actions for mortgage products in preparation for controlled rollout. #### Additional work - Internal mortgage backend maintenance. --- ### Transactions and Interest #### Groundwork for upcoming features - Building toward payment holiday support by logging payment holiday interest type in interest accrual breakdowns for the decoupled flow. - Performance improvements to the accrual deposit batching query to support the decoupled accrual process. - Optimising EOD processing by skipping late and early interest accrual jobs for tenants without products using daily or monthly accrual methods. - Inserting GL journal entries using batch insert statements as part of the deposits EOD transitional architecture. #### Additional work - Internal transactions and interest backend changes. --- ### Islamic Banking #### Monthly profit accrual now runs exactly once per month Fixed an issue where the monthly profit accrual job could run more than once in a single month, ensuring accurate and consistent profit accrual behaviour. *Internal references:* [IB-2451](https://mambucom.jira.com/browse/IB-2451) #### Profit accrual now uses the correct GL accounts and excludes settled cycles Profit accrual calculations now correctly use the GL accounts configured for the product, and paid payment cycles are excluded when computing accrued profit, preventing double-counting. *Internal references:* [IB-2446](https://mambucom.jira.com/browse/IB-2446), [IB-2440](https://mambucom.jira.com/browse/IB-2440) #### Users can now configure the profit accrual method The UI now allows users to set the profit accrual method directly on a product, giving institutions greater control over how profit is accrued. *Internal references:* [IB-2441](https://mambucom.jira.com/browse/IB-2441) #### Groundwork for upcoming features - Building toward correct product-level profit summaries at end-of-payment-cycle by implementing aggregation of account payment cycle values at the product cycle level. --- ### Accounting #### Groundwork for upcoming features - Logging the ID of the last journal entry summarised at EOD to support auditability and traceability improvements. #### Additional work - Internal accounting backend changes. --- ### Developer #### Groundwork for upcoming features - Groundwork for sunsetting API v1, including a feature toggle to disable API v1 access in phase 1. - Preparing the flexible schedule engine for the next supported regeneration version. #### Additional work - Internal developer tooling and infrastructure maintenance. --- ### Data #### Groundwork for upcoming features - Integrating the UI flows for Payoff, Loan Transaction, and Loan Account Closure with the Revolving submodule as part of the broader effort to separate Revolving logic from other product areas. - Implementing late fee on current late installments, and updating repayment flows for pre-payment and over-payment scenarios, as part of the lending pricing MVP. - Aggregating account payment cycle values at the product cycle level to support accurate end-of-cycle product summaries. - Defining the business capabilities of Config Mambu in preparation for future configuration management features. #### Additional work - Internal data and configuration maintenance. --- ## Bug fixes ### Clients and Groups #### Clearing all address fields now reliably removes client address data Resolved an issue where clearing all address fields for a client did not correctly delete the corresponding address data in the database. Users can now reliably remove all address information from a client record, and the changes will be accurately reflected in the system. *Internal references:* [NTF-3456](https://mambucom.jira.com/browse/NTF-3456) --- ### Notifications #### `filterConstraints` validation enforced when creating Webhook Templates via API API requests to create a Webhook Template now correctly validate the `filterConstraints` field, preventing malformed configurations from being persisted silently. *Internal references:* [MYM-4765](https://mambucom.jira.com/browse/MYM-4765) --- ### Mortgages #### Transaction order preserved correctly during pay-off with balance reductions Resolved an issue where paying off a mortgage with balance reductions caused transactions to be recorded in an incorrect order, ensuring accurate repayment sequencing. *Internal references:* [MTGE-1624](https://mambucom.jira.com/browse/MTGE-1624) #### Overpayments on interest-only loans no longer produce a negative total due Fixed a bug where making an overpayment on an interest-only loan resulted in a negative total due amount being displayed, ensuring balances are calculated and presented correctly. *Internal references:* [MTGE-1595](https://mambucom.jira.com/browse/MTGE-1595) #### Prepayment recalculation method now correctly defaults to reduce amount per instalment Resolved an issue where overpayments were incorrectly triggering a reduce number of instalments (RNI) recalculation instead of the configured reduce amount per instalment (RAI) method. *Internal references:* [MTGE-1617](https://mambucom.jira.com/browse/MTGE-1617) #### Prepayment recalculation method selector no longer appears when the feature is disabled Fixed a UI issue where the option to choose a prepayment recalculation method at repayment time remained visible even when the corresponding toggle was disabled in the product configuration. *Internal references:* [MTGE-1594](https://mambucom.jira.com/browse/MTGE-1594) --- ### Lending #### Repayment flow no longer generates a spurious zero-amount fee transaction Fixed an issue where processing a repayment incorrectly created an additional fee applied transaction with an amount of zero, keeping transaction histories clean and accurate. *Internal references:* [LPRC-4564](https://mambucom.jira.com/browse/LPRC-4564) #### Adjusting the first interest transaction no longer produces zero expected interest Resolved a bug where adjusting the first interest applied transaction on an account with the new interest rate configuration enabled incorrectly generated a zero expected interest value. *Internal references:* [LPRC-4170](https://mambucom.jira.com/browse/LPRC-4170) #### Branch updates via PATCH no longer incorrectly require disbursement permissions The PATCH endpoint for loan accounts was incorrectly requiring the `SET_DISBURSEMENT_CONDITIONS` permission when updating branch assignments, even when no transaction channel changes were made. The validation has been corrected so that users with standard association permissions such as `MANAGE_LOAN_ASSOCIATION` can perform branch updates without being blocked. *Internal references:* [LL-5244](https://mambucom.jira.com/browse/LL-5244) #### Custom fields now included in disbursement and transaction channel API specifications The OpenAPI specification for the disbursement endpoint now correctly includes custom fields, and custom field details have been added to the transaction channels API v2, ensuring API consumers have accurate and complete schema documentation. *Internal references:* [ADM-3983](https://mambucom.jira.com/browse/ADM-3983), [ADM-3843](https://mambucom.jira.com/browse/ADM-3843) --- ### Deposits #### Unicode characters in account notes now return a proper validation error Entering a unicode character in the **Notes** field when creating a savings account now returns a `400` validation error instead of an unhandled `500` exception. *Internal references:* [DO-165](https://mambucom.jira.com/browse/DO-165) #### `bookingDate` timestamp preserved correctly on deposit and withdrawal adjustments When posting a deposit or withdrawal adjustment via API, the `bookingDate` parameter now retains the exact date and time provided, rather than resetting the time component to midnight. *Internal references:* [DO-95](https://mambucom.jira.com/browse/DO-95) --- ### Accounting #### Copying a savings product no longer triggers an accounting rule validation error Resolved an issue where duplicating a savings product caused an accounting rule validation error, allowing users to copy savings products without interruption. *Internal references:* [LED-2683](https://mambucom.jira.com/browse/LED-2683), [LED-2603](https://mambucom.jira.com/browse/LED-2603) --- ### Islamic Banking #### Profit accrual calculations corrected for Islamic profit-sharing accounts Resolved an issue where profit accrual amounts were computed incorrectly for Islamic profit-sharing accounts, ensuring accurate accrual figures are applied. *Internal references:* [IB-2456](https://mambucom.jira.com/browse/IB-2456) #### Zero-profit transactions no longer generated at end of payment cycle Fixed a bug where a transaction was incorrectly created when the calculated profit amount was zero, preventing unnecessary zero-value entries in account histories. *Internal references:* [IB-2410](https://mambucom.jira.com/browse/IB-2410) #### Minimum eligible balance calculation corrected for complex scenarios Resolved an issue where the minimum eligible balance was not computed correctly in complex multi-condition scenarios, ensuring profit eligibility is assessed accurately. *Internal references:* [IB-2413](https://mambucom.jira.com/browse/IB-2413) #### End-of-payment-cycle summary now consistent with detailed breakdown Fixed a discrepancy where the summary figures shown at the end of a payment cycle did not match the corresponding detailed line items. *Internal references:* [IB-2397](https://mambucom.jira.com/browse/IB-2397) #### Profit accrual GL entries now correctly appear under Shariah-based accounts Resolved a UI configuration issue where profit accrual entries were not being displayed under the correct Shariah-based GL accounts. *Internal references:* [IB-2385](https://mambucom.jira.com/browse/IB-2385) #### Mudarib Share GL account type now fully displayed in product configuration Fixed an incomplete rendering of the Mudarib Share GL account type within the product configuration screen, ensuring all account type options are visible and selectable. *Internal references:* [IB-2453](https://mambucom.jira.com/browse/IB-2453) #### Job search page now returns the correct most-recent job result Resolved a UI issue where the job search page returned an incorrect result instead of the most recently executed job, giving operators accurate visibility into job execution status. *Internal references:* [IB-2447](https://mambucom.jira.com/browse/IB-2447) #### Invalid configuration no longer persisted when moving income cashflow between pools Fixed a bug where moving an income cashflow from an active pool to another pool could result in an invalid configuration being saved, protecting the integrity of pool settings. *Internal references:* [IB-2391](https://mambucom.jira.com/browse/IB-2391) #### System now prevents creation of an active pool without required settings Resolved an issue where it was possible to create an active profit-sharing pool without completing the mandatory configuration settings, enforcing configuration completeness before activation. *Internal references:* [IB-2390](https://mambucom.jira.com/browse/IB-2390) #### Accounting rules for withholding tax on Islamic profit-sharing products now configurable Resolved an issue where it was not possible to define an accounting rule for taxes on Islamic profit-sharing products that had withholding tax enabled. *Internal references:* [IB-2388](https://mambucom.jira.com/browse/IB-2388) #### Additional work - Non-customer-facing Islamic Banking configuration and infrastructure fixes. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.178 cycle. ## v9.178.7 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance. --- ## v9.178.6 **Release Date**: 03.06.2026 --- ## Improvements I cannot produce release notes for this section. The single ticket (`ADM-4209`) is a cherry-pick administrative task with no `existingNote` and a summary that contains only an internal branch/version reference. There is no customer-observable change, no product area context, and no content from which to derive a benefit-oriented description or even a meaningful non-customer-facing acknowledgement. **To proceed, please provide at least one of the following for this ticket:** - An `existingNote` describing what the original change (`ADM-4121`) actually does. - The summary or release note from the source ticket (`ADM-4121`). - A `productArea` value and a brief description of the underlying change. --- ## v9.178.5 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data layer maintenance. --- ## v9.178.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data and infrastructure maintenance. --- ## Bug fixes ### Data #### Revolving interest calculation correctly applied when no interest is present The revolving calculator now correctly selects the account-specific calculation path when an account has no interest configured, preventing incorrect calculation behaviour in these scenarios. *Internal references:* [REV-4655](https://mambucom.jira.com/browse/REV-4655) --- ## v9.178.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing infrastructure and configuration changes. --- ## v9.178.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data and infrastructure maintenance. --- ## Bug fixes ### Data #### Last-modified date no longer updated when no changes are made to a savings account The last-modified date on a savings account is no longer incorrectly updated when no actual changes have been made. *Internal references:* [DO-501](https://mambucom.jira.com/browse/DO-501) --- ## v9.178.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Security fix: unauthorized access to data import file information prevented Access to the `GetBackgroundTaskProgress` endpoint is now restricted by the `VIEW_BACKGROUND_TASKS` permission, closing a vulnerability where an authenticated non-privileged user could inspect filenames of data import files initiated by other users. *Internal references:* [ADM-3880](https://mambucom.jira.com/browse/ADM-3880) #### Additional work - Internal data infrastructure and configuration changes. ---

    Database changes

    | Table | Changes | |---|---| | `gljournalentryinterestaccruallog` | • Added column `TYPE`
    • Removed index `INTERESTACCRUALLOG_PRODUCTTYPE_ACCRUALMETHOD_LASTEXECUTION_INDEX`
    • Added index `ACCRUALLOG_PRODUCTTYPE_TYPE_ACCRUALMETHOD_LASTEXECUTION_IDX` | | `ips_product_calculation_cycle` | • Added column `TOTAL_WITHHOLDING_TAX_AMOUNT` | | `loan_account_balance` | • Added column `component`
    • Removed index `loan_account_balance_unique_id`
    • Added index `loan_account_balance_unique_id` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.179 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.179/ This page contains the following releases for v9.179: * [v9.179](#v9179) * [v9.179.4](#v91794) * [v9.179.3](#v91793) * [v9.179.2](#v91792) * [v9.179.1](#v91791) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.179 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### More descriptive errors for invalid custom field entity assignments When an `INVALID_CUSTOM_FIELD_ENTITY_KEY` error occurs, the `errorSource` field now includes both the custom field name and the entity for which it is not available — for example, `custom field is not marked as available for entity ` — making it faster to diagnose misconfigured custom field assignments. *Internal references:* [ADM-3940](https://mambucom.jira.com/browse/ADM-3940) #### Groundwork for upcoming features - Building the mechanism to process repayments into the schedule as part of performance optimisation for schedule storing and processing. - Laying the groundwork for daily breakdown accrual accounting of interest from arrears in a decoupled flow. - Implementing accounting entries for carry-forward principal in arrears during transfer, in support of carry-forward balances at reschedule and refinance. - Advancing interest-bearing fees decoupled from the repayments schedule, including accounting, UI, and API support for refinance/reschedule and fee balance reduction. - Extending the product creation UI with an **Interest Calculation Option** dropdown to support fee capitalisation during late status. - Adding interest-splitting logic for taxes in schedule calculation, in support of equal instalments for longer first periods on optimised payments. - Extending the GL Account definition UI to support revaluation setup. - Advancing daily profit accruals for Islamic Banking, including initial exchange rate configuration at pool level and its use in daily accruals calculations. - Building pool accounting for Islamic Banking, including the profit section in the product configuration and streamlining the Mudarib account setting. - Implementing asynchronous execution of the full IPS calculation job and related configuration and EOD enhancements. - Defining the CBE package and module structure in preparation for the rewrite of the Repayment API for fixed-term loans. - Migrating FSE schedule serialisation to use Avro for parameters, including serialisation and deserialisation processes. - Splitting **Interest Due** and **Payment Holiday Interest Applied** fields as part of the FSE installments migration to functionless fields. - Implementing EOD account exclusion from set-based micro-batches as part of the deposits EOD transitional architecture. - Adding OAS v3 annotations to new hidden endpoints in preparation for upcoming API exposure. - Supporting manual interest application as a temporary migration workaround for accrual data. - Building synthetic API health checks, including a private ping endpoint and authentication key. - Enabling early EOD triggering via both UI and API. #### Additional work - Non-customer-facing internal maintenance, refactoring, and tooling changes across data and backend services. --- ## Improvements ### Lending #### Accurate interest calculations for revolving credit accounts with billing cycles Resolved an issue where revolving credit accounts configured with both Billing Cycles and the **Accrue Interest Since Disbursement** setting did not select the correct principal balance calculator, leading to inaccurate interest amounts after a due date had passed. The logic has been corrected to ensure accurate manual and automatic interest applications for all affected accounts. *Internal references:* [REV-4625](https://mambucom.jira.com/browse/REV-4625) #### Pay-off and preview pay-off for loan accounts Pay-off and preview pay-off functionality is now available, enabling users to calculate and execute full loan settlements directly. *Internal references:* [LPRC-4096](https://mambucom.jira.com/browse/LPRC-4096) #### Groundwork for upcoming features - Groundwork to support repayment allocation order within the new Loan Repayment API module, including horizontal repayment allocation logic and instalment change persistence. - Groundwork to split revolving credit module code and remove cross-product logic, including integration of card transaction flows with the revolving submodule. - Groundwork to extend the `JournalEntry` to allow overwriting the GL accounting rule, in support of moving product profit amounts and bank share from a pool suspense. - Groundwork to support scaling capabilities for the lending platform. #### Additional work - Internal lending and revolving module maintenance, including refactoring of account health-check services and internal test improvements. --- ### Deposits #### Rate sheets for fixed-type regular interest on deposit accounts Rate sheets can now be used to configure fixed-type regular interest for deposit accounts and are integrated into the interest accrual and application process through the `RATE_SHEETS_FOR_DEPOSIT_ACCOUNTS` feature. *Internal references:* [BE-77](https://mambucom.jira.com/browse/BE-77) #### Groundwork for upcoming features - Groundwork to implement a withdrawal counter rule for deposit accounts, including a custom interest application service and product feature configuration. - Groundwork to implement a rate provider with caching support for deposit account interest calculations. - Groundwork to support early manual EOD rescheduling and background process endpoint updates for deposit accounts. - Groundwork to allow creating a Product Feature for products with no accounts via API v2, in support of compound interest for credit interest. #### Additional work - Internal deposits maintenance, including consolidation of daily deposit account update jobs and internal test coverage improvements. --- ### Accounting #### More reliable accounting summary report generation API report generation for accounting summaries now uses `lastEntryId` instead of creation date when processing unsummarised general ledger journal entries, improving accuracy and consistency of generated reports. *Internal references:* [LED-2743](https://mambucom.jira.com/browse/LED-2743) #### Groundwork for upcoming features - Groundwork to ensure accounting rate storage respects currency and end-date uniqueness constraints. #### Additional work - Internal accounting maintenance and test infrastructure improvements. --- ### Islamic Banking #### Groundwork for upcoming features - Groundwork to create the **Product Profit** section in the CBE product UI, supporting the move of product profit amounts and bank share from a pool suspense account. --- ### Notifications #### Groundwork for upcoming features - Groundwork to deliver Configuration-as-Code APIs for Notification Templates, including validation fixes and API consistency improvements across the Templates API. #### Additional work - Internal notifications maintenance, including view definition updates and CRM test and production code migration. --- ### Developer #### Groundwork for upcoming features - Groundwork to support OpenAPI v3 via API v2, including public documentation with required permissions. #### Additional work - Internal tooling and process work, including capability tagging, team handovers, and internal configuration changes. --- ## Bug fixes ### Mortgages #### Carried-forward interest balance correctly restored after undoing a reschedule Undoing a rescheduling operation now properly restores the `carriedForwardInterestAccrued` balance to its previous state, preventing incorrect outstanding amounts on the account. *Internal references:* [MTGE-1763](https://mambucom.jira.com/browse/MTGE-1763) #### Carry-forward warning icons no longer appear when the carry-forward toggle is disabled A UI fix removes the spurious warning images that were displayed on carry-forward fields when the carry-forward toggle was turned off, keeping the interface clean and unambiguous. *Internal references:* [MTGE-1706](https://mambucom.jira.com/browse/MTGE-1706) #### Ledger entries for carried-forward amounts now use the correct transaction type Carried-forward balance ledger entries are no longer incorrectly recorded as write-offs, ensuring accurate accounting classification and cleaner audit trails. *Internal references:* [MTGE-1604](https://mambucom.jira.com/browse/MTGE-1604) #### Interest calculation after a redraw overpayment now accounts for the redraw balance When an overpayment is made on a loan with a redraw facility, the subsequent interest calculation correctly incorporates the redraw balance, preventing understated interest charges. *Internal references:* [MTGE-1750](https://mambucom.jira.com/browse/MTGE-1750) #### Compounding rest methodology now accrues interest on the first instalment An issue where interest was not accrued on the first instalment period under the compounding rest methodology has been resolved, ensuring accurate interest from the start of the loan. *Internal references:* [MTGE-1710](https://mambucom.jira.com/browse/MTGE-1710) #### Adjusting a payment transaction now correctly updates the account schedule Posting an **Adjust Payment Made** transaction now triggers a proper recalculation of the account repayment schedule, eliminating stale or inconsistent schedule data. *Internal references:* [MTGE-1680](https://mambucom.jira.com/browse/MTGE-1680) #### Total amount due is now accurate after a partial payment made on the due date A calculation error that caused an incorrect **Total Due** figure following a partial payment on the due date has been corrected. *Internal references:* [MTGE-1562](https://mambucom.jira.com/browse/MTGE-1562) #### Deprecated interest application method `FIXED_DAYS_OF_MONTH` restored for backward compatibility The `FIXED_DAYS_OF_MONTH` interest application method has been reinstated as a deprecated option, ensuring existing loan products that rely on this method continue to function correctly. *Internal references:* [MTGE-1735](https://mambucom.jira.com/browse/MTGE-1735) #### Payment holiday is no longer ignored after an overpayment A bug where a configured payment holiday was bypassed following an overpayment has been fixed, ensuring holiday periods are honoured regardless of prior payment activity. *Internal references:* [MTGE-1690](https://mambucom.jira.com/browse/MTGE-1690) #### API 2.0 now returns correct principal expected and principal paid amounts for interest-only loans Incorrect `principalExpected` and `principalPaid` values returned by the API for interest-only loan accounts have been corrected, ensuring downstream integrations receive accurate data. *Internal references:* [MTGE-1642](https://mambucom.jira.com/browse/MTGE-1642) #### Interest-only accounts no longer incorrectly transition to a late state after a paid instalment An issue where a fully paid interest-only instalment was subsequently reclassified as late has been resolved, preventing erroneous arrears status and associated downstream effects. *Internal references:* [MTGE-1631](https://mambucom.jira.com/browse/MTGE-1631) #### PMT threshold now correctly applied to the first month when broken interest is present The payment threshold was not being considered during the first month's calculation on a Dynamic Mortgage when broken interest existed; this has been corrected to ensure consistent instalment amounts from the outset. *Internal references:* [MTGE-1623](https://mambucom.jira.com/browse/MTGE-1623) #### PMT for the next instalment is no longer incorrectly recalculated on overpayment within the threshold period for interest-only loans When an overpayment is posted within the threshold period on an interest-only loan with a configured PMT threshold, the next instalment amount is no longer erroneously recalculated. *Internal references:* [MTGE-559](https://mambucom.jira.com/browse/MTGE-559) --- ### Lending #### Fees due are no longer retained in the schedule after an account is closed before the due date Closing a loan account prior to a fee due date now correctly removes the pending fee from the repayment schedule, preventing phantom obligations on closed accounts. *Internal references:* [LPRC-4752](https://mambucom.jira.com/browse/LPRC-4752) #### Manual fee application for custom payments now works correctly A missing mapping for the `FEE_INCLUDED_IN_PMT` trigger has been restored, ensuring that manually applied fees on accounts using custom payment methods are processed correctly. *Internal references:* [LPRC-4739](https://mambucom.jira.com/browse/LPRC-4739) #### Schedule preview now reflects the fee rate configured on the account, not the product default The schedule preview was always rendering instalments based on the product-level default fee rate rather than the rate configured on the individual account; this has been corrected. *Internal references:* [LPRC-4707](https://mambucom.jira.com/browse/LPRC-4707) #### Interest from arrears accrual now aligns with loan product settings The interest-from-arrears accrued calculation now correctly respects the accrual configuration defined on the loan product, eliminating discrepancies between expected and actual accrued amounts. *Internal references:* [LPRC-4631](https://mambucom.jira.com/browse/LPRC-4631) #### Interest is no longer applied twice on the same day during prepayment Interest is now correctly skipped during the prepayment process if it has already been applied through the end-of-day interest application run, preventing duplicate interest transactions on the same day. *Internal references:* [LPRC-4270](https://mambucom.jira.com/browse/LPRC-4270) #### Schedule recalculation no longer produces a broken schedule or negative final instalment when a transaction precedes a scheduled event The system was occasionally miscalculating the repayment schedule when a transaction was applied before a scheduled event, sometimes resulting in negative interest; this has been resolved. *Internal references:* [LPRC-3919](https://mambucom.jira.com/browse/LPRC-3919) #### Repayment schedules are now reliably updated when a new holiday is added In some cases, adding a general holiday did not trigger a schedule update for all affected accounts; this fix ensures due dates are correctly recalculated across all applicable accounts. *Internal references:* [LPRC-3715](https://mambucom.jira.com/browse/LPRC-3715) #### Decimal separator is now applied consistently across repayment screens The comma decimal mark setting is now correctly honoured on the **Edit Repayment** and **Apply a Repayment** screens, eliminating mixed use of dots and commas in numeric fields. *Internal references:* [LL-4752](https://mambucom.jira.com/browse/LL-4752) --- ### Islamic Banking #### Profit accrual reversals are now correctly linked to their originating accrual log Reversal transactions for profit accruals are now properly associated with the corresponding accrual log entry, ensuring complete and traceable profit accrual records. *Internal references:* [IB-2516](https://mambucom.jira.com/browse/IB-2516) #### Daily accrual cycles are now generated correctly by the profit-sharing engine An issue where the next cycle's daily accrual was not being generated has been resolved, ensuring uninterrupted profit accrual processing. *Internal references:* [IB-2514](https://mambucom.jira.com/browse/IB-2514) #### Accrued profit general ledger entries now carry the correct amount A calculation error that caused accrued profit GL entries to reflect an incorrect monetary amount has been corrected. *Internal references:* [IB-2502](https://mambucom.jira.com/browse/IB-2502) #### Mudarib accounting entries are now booked on the correct date Mudarib accounting entries now follow the configured **Profit Application Point** rule when determining the booking date, ensuring entries are recorded in the correct accounting period. *Internal references:* [IB-2477](https://mambucom.jira.com/browse/IB-2477) #### Applied profit amount now matches the generated proposal A discrepancy between the profit amount in the generated proposal and the amount actually applied to the account has been corrected. *Internal references:* [IB-2464](https://mambucom.jira.com/browse/IB-2464) #### Mudarib entries are now posted to the correct configured GL accounts Mudarib accounting entries were being generated against incorrect general ledger accounts; they are now correctly directed to the GL accounts configured on the product. *Internal references:* [IB-2463](https://mambucom.jira.com/browse/IB-2463) #### Profit accrual calculation now uses the last approved expected rate The profit accrual calculation has been corrected to reference the most recently approved expected rate, preventing accrual amounts based on outdated rate values. *Internal references:* [IB-2461](https://mambucom.jira.com/browse/IB-2461) #### Average balance used in expected rate calculation is now correct An incorrect account average balance was being used during expected rate calculations; this has been resolved to ensure accurate rate determination. *Internal references:* [IB-2454](https://mambucom.jira.com/browse/IB-2454) #### Additional work - Non-customer-facing API contract corrections for Islamic Banking. --- ### Data #### Dropdown selection custom fields now render correctly A UI issue causing **Selection** type custom field dropdowns to malfunction has been fixed, ensuring users can reliably select values from these fields. *Internal references:* [CDO-4381](https://mambucom.jira.com/browse/CDO-4381) --- ### Deposits #### Patching a deposit transaction with a custom field value over the limit now returns the correct error response The API now returns an `HTTP 400` error with an appropriate message when a `PATCH` on a deposit transaction includes a custom field value that exceeds its configured limit, rather than an unhelpful `500` server error. *Internal references:* [ADM-4089](https://mambucom.jira.com/browse/ADM-4089) #### Duplicate custom fields no longer appear when double-clicking a tab A UI bug that caused custom fields to be rendered twice when a tab was double-clicked has been resolved, preventing confusion and potential duplicate data entry. *Internal references:* [ADM-3057](https://mambucom.jira.com/browse/ADM-3057) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.179 cycle. ## v9.179.4 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to custom field data purging processes for better overall platform performance and reliability. ## v9.179.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and security patching. --- ## v9.179.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration and infrastructure changes. --- ## Bug fixes ### Notifications #### Additional work - Internal notifications maintenance. --- ## v9.179.1 **Release Date**: 03.06.2026 --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data maintenance. ---

    Database changes

    | Table | Changes | |---|---| | `accountsinterestaccrualamounts` | • Added column `INTEREST_FROM_ARREARS_AMOUNT` | | `brokenaccountoverview` | • Changed data type of column `BROKEN_REASON_CODE` | | `glaccount` | • Added column `ISREVALUATIONENABLED`
    • Added column `REVALUATIONCREDITGLACCOUNTKEY`
    • Added column `REVALUATIONDEBITGLACCOUNTKEY`
    • Added column `REVALUATIONOFFSETGLACCOUNTKEY` | | `ips_payment_calculation` | • Changed data type of column `CALCULATION_TYPE` | | `ips_pool_settings` | • Added column `INITIAL_EQUIVALENT_RATE`
    • Removed column `MUDARIB_SHARE_ACCOUNT_ENCODEDKEY` | | `ips_product_settings` | • Removed column `WITHHOLDING_TAX_ENABLED` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.180 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.180/ This page contains the following releases for v9.180: * [v9.180](#v9180) * [v9.180.1](#v91801) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.180 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Choose a prepayment recalculation method when making principal overpayments When submitting a non-allocated principal overpayment, you can now specify the prepayment recalculation method directly at repayment time — both via the API and in the UI — giving you greater control over how the loan schedule is adjusted after an overpayment. *Internal references:* [MTGE-1823](https://mambucom.jira.com/browse/MTGE-1823), [MTGE-1822](https://mambucom.jira.com/browse/MTGE-1822) #### Actual/Actual interest calculation now available for mortgage products The **Actual/Actual** days-in-year convention can now be selected for interest calculation on mortgage products, accessible through both the API and the product configuration UI. *Internal references:* [MTGE-1804](https://mambucom.jira.com/browse/MTGE-1804), [MTGE-1803](https://mambucom.jira.com/browse/MTGE-1803) #### UI restrictions removed for Dynamic Term Loans Previously introduced UI restrictions on Dynamic Term Loans have been lifted, restoring full configuration access for these products. *Internal references:* [MTGE-1785](https://mambucom.jira.com/browse/MTGE-1785) #### Groundwork for upcoming features - Building support for redraw functionality on Dynamic Mortgage products, including backdated schedule retrieval. #### Additional work - Internal mortgage architecture and query mapping improvements. --- ### Lending #### Filter loan searches by assigned branch In the `POST /loans:search` endpoint, `assignedBranchKey` can now be included in `filterCriteria`, closing a gap between API v2 and API v1 where branch-based filtering was previously only available via the legacy `/loans` endpoint. *Internal references:* [LL-5746](https://mambucom.jira.com/browse/LL-5746) #### Groundwork for upcoming features - Extending interest splitting logic to support equal installments for longer first periods on simple interest Optimised Payment loans. #### Additional work - Internal lending EOD architecture and schedule computation improvements. --- ### Deposits #### Improved search filtering for deposit account balance summaries Deposit account balance summary searches now support a broader set of filter operators, enabling more precise and flexible queries against account balance data. *Internal references:* [BE-114](https://mambucom.jira.com/browse/BE-114) #### Additional work - Internal deposit product feature cache and code-linking maintenance. --- ### Islamic Banking #### Greater control over daily profit accrual calculation and timing Two new configuration options are available for Shari'ah-compliant deposit products: `accruedProfitAmountCalculationMethod` controls how the daily profit amount is calculated (choosing from `CUSTOMER_PROFIT_RATE_AFTER_ADJUSTMENT`, `CUSTOMER_PROFIT_RATE`, or `CUSTOMER_PROFIT_RATE_WITH_CAPPED_RATE`), and `profitAccrualPoint` defines whether accrued profit is posted on the `CURRENT_ACCRUAL_DATE` or `NEXT_ACCRUAL_DATE`. Both settings are configurable via the Profit Sharing Service API and the deposit product settings UI, and are available to all customers with the Islamic Banking module enabled. *Internal references:* [IB-2488](https://mambucom.jira.com/browse/IB-2488), [IB-2487](https://mambucom.jira.com/browse/IB-2487) #### Groundwork for upcoming features - Laying the groundwork for pool-level accounting, including Mudarib share handling and profit-applied adjustment support. --- ### Transactions and Interest #### Additional work - Non-customer-facing data fix to prevent corruption when concurrent API v1 and v2 calls write to savings transaction custom field value tables. --- ### Data #### Additional work - Internal financial schedule engine refactoring and logging fixes. --- ## Improvements ### Data #### Broken account consistency detected after repayment When a repayment breaks the consistency of a revolving credit account, the inconsistency is now automatically detected and recorded in the new `BrokenAccountOverview` and `BrokenAccountHistory` tables, enabling faster diagnosis and remediation. *Internal references:* [REV-4585](https://mambucom.jira.com/browse/REV-4585) #### Compound accrued interest daily for deposit accounts A new **Deposits Credit Interest Compounding** product feature (available as Early Access) enables daily compounding of accrued credit interest on deposit accounts, with safeguards that prevent incompatible product updates and control which user permissions can create the feature — even when active accounts exist. *Internal references:* [DIF-2307](https://mambucom.jira.com/browse/DIF-2307), [DIF-2305](https://mambucom.jira.com/browse/DIF-2305), [DIF-2299](https://mambucom.jira.com/browse/DIF-2299), [DIF-2269](https://mambucom.jira.com/browse/DIF-2269), [DIF-2268](https://mambucom.jira.com/browse/DIF-2268) #### Trial balance report now uses `lastEntryId` for unsummarised journal entries The **Trial Balance** UI report now uses `lastEntryId` instead of creation date when processing unsummarised general ledger journal entries, improving accuracy and consistency of accounting summaries. *Internal references:* [LED-2754](https://mambucom.jira.com/browse/LED-2754) #### Groundwork for upcoming features - Caching support for currency and transaction channel lookups is being introduced to underpin the Bulk Withdrawal Transactions API. - Internal routing for card transaction creation and reversal steps is being migrated to the Orchestrator in preparation for a cleaner separation of revolving credit logic. - Groundwork for daily accrual enhancements in Islamic Banking, including a new `daily_accrual_amount` field and adjusted GL postings for the updated accrual calculation point. - Repository and balance-flow methods are being built to support a high-throughput fixed-term loan repayment API and configurable repayment allocation order. - Flexible Schedule Engine improvements are in progress, covering configuration state isolation across versions, regeneration version increments, and latest-schedule retrieval. - Groundwork for planned fees configuration on Dynamic Mortgage products. - Feature toggle infrastructure for the Actual/Actual days-in-year interest calculation method for mortgage products. - Feature toggle for prepayment recalculation method selection on principal overpayments. #### Additional work - Internal maintenance across lending, mortgages, deposits, Islamic banking, accounting, and platform configuration, including toggle enablements, internal refactors, performance improvements, and architecture compliance fixes. --- ### Mortgages #### Configure planned fees on Dynamic Mortgage products Administrators can now configure planned fees for **Dynamic Mortgage** products via both the UI and API, bringing Dynamic Mortgages to parity with other mortgage product types for fee management. *Internal references:* [MTGE-1797](https://mambucom.jira.com/browse/MTGE-1797) #### Groundwork for upcoming features - The **Interest Only Equal Instalments** payoff preview calculation is being aligned with actual repayment behaviour for mortgage accounts. - Support for the Actual/Actual days-in-year interest calculation method is being prepared for mortgage products. - Redraw support for the Dynamic Mortgage product is progressing, including hiding the IOI option on product configuration. #### Additional work - Internal mortgage maintenance, including toggle investigations, exception handling fixes, test cleanup, and architecture documentation. --- ### Deposits #### Groundwork for upcoming features - Performance instrumentation is being extended to the deposit accounts search endpoint to support ongoing cursor-based pagination investigations. #### Additional work - Internal deposits configuration changes, including feature state adjustments. --- ### Accounting #### Additional work - Internal accounting architecture fixes and compliance updates. --- ### Islamic Banking #### Additional work - Internal Islamic Banking maintenance, including unit test fixes and daily accrual GL posting adjustments. --- ### Developer #### Additional work - Internal developer tooling updates, including OpenAPI breaking-change detection and permission-denied logging improvements. --- ## Bug fixes ### Lending #### Payoff transactions now apply the correct interest amount Addressed a calculation error where payoff transactions used a lower interest amount than the repayment schedule, ensuring the correct interest is applied during settlement and preventing cases where a closed account still shows a balance due. *Internal references:* [REV-4707](https://mambucom.jira.com/browse/REV-4707) #### Interest no longer accrues on accounts with a zero outstanding balance In edge cases where an account was fully paid off, interest could still be calculated based on an incorrect principal amount from the schedule. The calculation now correctly uses the actual transaction-based principal, ensuring no interest is accrued when the true outstanding balance is zero or less. *Internal references:* [REV-4690](https://mambucom.jira.com/browse/REV-4690) #### Interest calculation corrected after new disbursements within a billing cycle Previously, after a new disbursement within a billing cycle, the interest due for an installment could sometimes be incorrectly inflated. The calculation now considers only the principal balance applicable to that specific billing period. *Internal references:* [REV-4662](https://mambucom.jira.com/browse/REV-4662) #### Reschedule action no longer fails on accounts with redraw enabled Fixes an error that occurred when performing the reschedule action on accounts with the redraw feature enabled. *Internal references:* [LPRC-3091](https://mambucom.jira.com/browse/LPRC-3091) #### Loan transaction search now handles custom field filters correctly Fixed an issue where the `/api/loans/transactions:search` API returned internal errors when filtering by custom fields such as `_lendingAccount`. The system now correctly processes search requests that include custom field filters. *Internal references:* [LL-5755](https://mambucom.jira.com/browse/LL-5755) #### Paid-off loans no longer show a remaining interest balance Fixed a bug where interest reductions from a loan payoff were not correctly reflected in the repayment schedule, which previously caused the final payment to incorrectly show a remaining interest balance even after the loan was fully paid off. *Internal references:* [LL-5739](https://mambucom.jira.com/browse/LL-5739) #### Loan account PATCH requests no longer fail due to unrelated field validation Fixed an issue where PATCH requests to update loan accounts incorrectly triggered validation against current loan product constraints for fields not included in the request. Validation is now applied only to fields explicitly modified in the API payload. *Internal references:* [LL-5567](https://mambucom.jira.com/browse/LL-5567) #### Additional work - Internal lending performance and memory fixes. --- ### Mortgages #### Repaying fees no longer generates an unexpected additional interest transaction Resolved an issue where repaying fees on a mortgage account incorrectly triggered an additional transaction that applied interest. *Internal references:* [MTGE-1857](https://mambucom.jira.com/browse/MTGE-1857) #### Pay-off screen now shows the correct interest balance for interest-only equal installment accounts with broken interest Fixed a calculation discrepancy where the interest balance displayed in the pay-off screen for interest-only equal installment accounts with broken interest did not match expected values. *Internal references:* [MTGE-1853](https://mambucom.jira.com/browse/MTGE-1853) #### Principal overpayment in the first installment after the threshold no longer alters the installment amount Resolved an issue with dynamic mortgages where a principal overpayment in the first installment after the overpayment threshold incorrectly caused the installment amount to be recalculated. *Internal references:* [MTGE-1845](https://mambucom.jira.com/browse/MTGE-1845) #### Carry-forward fields are now visible in the UI Carry-forward balance elements are now correctly displayed in the account UI, giving users visibility into carried-forward amounts. *Internal references:* [MTGE-1844](https://mambucom.jira.com/browse/MTGE-1844) #### Interest calculation corrected for dynamic mortgages with prepayments and principal overpayments Fixed an issue where interest was incorrectly calculated for a dynamic mortgage when a prepayment was allocated to the upcoming pending installment and an overpayment existed in the principal balance. *Internal references:* [MTGE-1820](https://mambucom.jira.com/browse/MTGE-1820) #### Total balance is now correct after a scheduled fee is applied Resolved an issue where applying a scheduled fee resulted in an incorrect total balance on the account. *Internal references:* [MTGE-1819](https://mambucom.jira.com/browse/MTGE-1819) #### Carry-forward now returns a meaningful error when no balances are present When attempting to carry forward state on an account with no applicable balances, the system now returns a clear, descriptive error message instead of a generic failure. *Internal references:* [MTGE-1795](https://mambucom.jira.com/browse/MTGE-1795) #### Same-day interest application no longer results in a zero-balance transaction Fixed an issue where applying interest on the same day as another operation produced a transaction with a zero balance under carry-forward configurations. *Internal references:* [MTGE-1793](https://mambucom.jira.com/browse/MTGE-1793) #### Carry-forward fields are no longer shown when rescheduling to a non-mortgage loan Carry-forward fields are now correctly hidden when a loan is rescheduled to a product that is not a mortgage, preventing irrelevant fields from appearing in the UI. *Internal references:* [MTGE-1791](https://mambucom.jira.com/browse/MTGE-1791) #### Preview schedule now shows correct principal balance and interest capitalisation under carry-forward Fixed multiple issues in the preview schedule for carry-forward accounts: the principal balance is now accurate, interest is correctly carried forward rather than capitalised, and the interest for the first installment is computed correctly. *Internal references:* [MTGE-1787](https://mambucom.jira.com/browse/MTGE-1787) #### Reschedule now works correctly for products with non-scheduled fees configured Resolved an issue where the reschedule action failed for loan products that had non-scheduled fees configured. *Internal references:* [MTGE-1784](https://mambucom.jira.com/browse/MTGE-1784) #### Adjusting applied interest now correctly reverses carried-forward interest Fixed an issue where the **Adjust Interest Applied** transaction did not reverse the carried-forward interest component, leaving an incorrect balance on the account. *Internal references:* [MTGE-1781](https://mambucom.jira.com/browse/MTGE-1781) #### Repayments with mandatory custom fields no longer produce an error Resolved an error that occurred when submitting a repayment on accounts where a mandatory custom field was configured, preventing the transaction from completing. *Internal references:* [MTGE-1739](https://mambucom.jira.com/browse/MTGE-1739) #### PMT is now correctly recalculated after a principal custom repayment during a broken interest installment Fixed an issue where the periodic payment amount (PMT) for interest-only loans was not correctly recalculated after a principal custom repayment was made during a broken interest installment period. *Internal references:* [MTGE-1644](https://mambucom.jira.com/browse/MTGE-1644) #### Multiple RNI overpayments no longer inflate the current installment total due Resolved an issue where making multiple repayments-not-in-installment (RNI) overpayments incorrectly increased the total due amount on the current installment. *Internal references:* [MTGE-1607](https://mambucom.jira.com/browse/MTGE-1607) #### Enter Repayment button is no longer disabled when funds remain in IFA Fixed an issue where the **Enter Repayment** button was incorrectly disabled when an account still had an amount in the Interest-Free Amount (IFA) balance, blocking users from submitting repayments. *Internal references:* [MTGE-1525](https://mambucom.jira.com/browse/MTGE-1525) #### Withdrawing the full redraw balance now correctly creates a division Resolved an issue where withdrawing the entire available redraw balance did not generate the expected division record on the account. *Internal references:* [MTGE-1854](https://mambucom.jira.com/browse/MTGE-1854) #### Make Principal Overpayment option now appears for products with redraw enabled Fixed an issue where the **Make Principal Overpayment** option was not displayed for loan products configured with the redraw feature. *Internal references:* [MTGE-1847](https://mambucom.jira.com/browse/MTGE-1847) #### Interest on redraw balance changes made on the same day is now calculated correctly Resolved an issue where multiple changes to the redraw balance on the same day resulted in incorrect interest calculations. *Internal references:* [MTGE-1729](https://mambucom.jira.com/browse/MTGE-1729) #### RecalculateSchedule API now returns populated differences Fixed an issue where the private `RecalculateSchedule` loan account API returned empty differences, providing no actionable output to callers. *Internal references:* [LPRC-4883](https://mambucom.jira.com/browse/LPRC-4883) --- ### Deposits #### Overdraft terms can no longer be modified while a savings account is locked Previously, it was possible to change overdraft terms (such as the overdraft limit) on a savings account while it was in a locked state, which did not correctly log a corresponding transaction and could cause 500 Internal Server Errors during subsequent operations. Overdraft terms can now only be modified when the account is unlocked, and the API now correctly returns the `INVALID_DEPOSIT_ACCOUNT_STATE (407)` error when an operation is attempted on a deposit account that is not in a valid state. *Internal references:* [DO-1285](https://mambucom.jira.com/browse/DO-1285) #### Additional work - Non-customer-facing deposit account maintenance. --- ### Islamic Banking #### Taxes Payable accounting category now appears in product configuration Fixed an issue where the **Taxes Payable** accounting category was not visible in the product configuration UI, preventing it from being assigned during product setup. *Internal references:* [IB-2538](https://mambucom.jira.com/browse/IB-2538) #### Profit amount is now calculated correctly on apply Resolved an issue where the profit amount applied to certain accounts was incorrect, ensuring profit calculations reflect the expected values. *Internal references:* [IB-2521](https://mambucom.jira.com/browse/IB-2521) --- ### Cards #### Financial transactions endpoint handles missing authorization hold references gracefully Improved the `financialtransactions` endpoint to handle cases where a reference to an authorization hold is missing, preventing errors and ensuring the request is processed correctly. *Internal references:* [CARDS-2491](https://mambucom.jira.com/browse/CARDS-2491) --- ### Data #### Custom field updates via the v1 API now work correctly for linked entities Fixed an issue where PATCH requests to update a single custom field on a linked entity via the v1 API did not apply the change as expected. *Internal references:* [ADM-3944](https://mambucom.jira.com/browse/ADM-3944) #### Storing a date value in a datetime custom field no longer breaks the UI Resolved an issue where saving a date value into a datetime custom field caused the UI to malfunction during subsequent single custom field update operations. *Internal references:* [ADM-3943](https://mambucom.jira.com/browse/ADM-3943) #### Additional work - Non-customer-facing fix to the archive deposit transactions custom fields resource endpoint. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.180 cycle. ## v9.180.1 **Release Date**: 03.06.2026 --- ## Bug fixes ### Mortgages #### Reduce event now processed correctly across different instalments Fixed an issue where the Financial Schedule Engine failed to process a reduce event correctly when the reduction was applied to a different instalment. *Internal references:* [MTGE-1987](https://mambucom.jira.com/browse/MTGE-1987) #### Get Schedule API returns results reliably Resolved an error that caused the Get Schedule API to fail under certain conditions. *Internal references:* [MTGE-1877](https://mambucom.jira.com/browse/MTGE-1877) #### PMT threshold correctly validated on broken interest during redraw repayment Fixed an issue where the PMT threshold was not being validated against broken interest when a redraw repayment was posted. *Internal references:* [MTGE-1896](https://mambucom.jira.com/browse/MTGE-1896) #### Principal overpayment adjustment notification now triggered correctly Resolved an issue where the notification for a principal overpayment adjustment was not being raised as expected. *Internal references:* [MTGE-1859](https://mambucom.jira.com/browse/MTGE-1859) #### Schedule calculation corrected for API redraw repayment transactions Fixed an incorrect schedule calculation that occurred when a redraw repayment was posted via the API. *Internal references:* [MTGE-1884](https://mambucom.jira.com/browse/MTGE-1884) ### Lending #### Prepayment schedule no longer incorrectly includes fee due Resolved an issue where a prepayment entry on the schedule incorrectly showed a fee due amount. *Internal references:* [LPRC-4975](https://mambucom.jira.com/browse/LPRC-4975) ---

    Database changes

    | Table | Changes | |---|---| | `accountsinterestaccrualamounts` | • Added column `INTEREST_FROM_FEES_AMOUNT` | | `fse_account` | • Added column `SOURCE_CODE_VERSION`
    • Added column `LAST_REGENERATED_AT`
    • Added column `SKIP_SCHEDULES_COMPARISON` | | `fse_scheduleversion` | • Added index `FSE_SCHEDULEVERSION_EVENTDATE_INDEX`
    • Added column `CONFIGURATION_COMPONENTS` | | `ips_account_payment_cycle` | • Added column `DAILY_ACCRUAL_AMOUNT` | | `ips_pool_calculation_cycle` | • Added column `INITIAL_EQUIVALENT_RATE`
    • Added column `BANK_PL_ACCOUNT_ENCODEDKEY`
    • Added column `PROFIT_SUSPENSE_ACCOUNT_ENCODEDKEY`
    • Added column `RESERVE_ACCOUNT_ENCODEDKEY` | | `ips_product_calculation_cycle` | • Added column `PROFIT_ACCRUAL_POINT`
    • Added column `ACCRUED_PROFIT_AMOUNT_CALCULATION_METHOD` | | `ips_product_settings` | • Added column `PROFIT_ACCRUAL_POINT`
    • Added column `ACCRUED_PROFIT_AMOUNT_CALCULATION_METHOD` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.181 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.181/ This page contains the following releases for v9.181: * [v9.181](#v9181) * [v9.181.1](#v91811) ## v9.181 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Islamic Banking #### Additional work - Internal operational configuration changes. --- ## Improvements ### Transactions and Interest #### Interest accrual breakdown now available Detailed interest accrual breakdown is now activated, giving clients visibility into how interest is calculated and accumulated across their accounts. *Internal references:* [DO-1330](https://mambucom.jira.com/browse/DO-1330) ### Lending #### Additional work - Internal lending module maintenance and logging updates. --- ## v9.181.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Bug fixes ### Mortgages #### Consistent interest applied and interest accrued values Resolved an inconsistency where interest applied and interest accrued values were reported incorrectly, ensuring accurate interest figures are reflected on mortgage accounts. *Internal references:* [MTGE-2128](https://mambucom.jira.com/browse/MTGE-2128) --- For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.182 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.182/ This page contains the following releases for v9.182: * [v9.182](#v9182) * [v9.182.2](#v91822) * [v9.182.1](#v91821) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.182 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing internal maintenance, refactoring, and infrastructure work across multiple areas. --- ### Notifications #### Additional work - Internal notifications maintenance and reconciliation work. --- ### Lending #### Additional work - Backend-only lending EOD architecture and internal maintenance changes. --- ### Mortgages #### Redraw now available on Interest Only Equal Instalment products The redraw facility can now be enabled on **Interest Only Equal Instalment (IOEI)** products, giving borrowers the ability to access funds they have paid ahead of schedule on this product type. *Internal references:* [MTGE-1932](https://mambucom.jira.com/browse/MTGE-1932) #### Additional work - Non-customer-facing mortgage architecture and internal maintenance work. --- ### Deposits #### Technical Overdraft interest rates now sourced from linked rate sheets When a rate sheet is linked at the product or account level, the Technical Overdraft rate fetching logic will use the rate defined in that rate sheet, ensuring consistent and centralised rate management across overdraft products. *Internal references:* [DIF-2162](https://mambucom.jira.com/browse/DIF-2162) #### Groundwork for upcoming features - Building support for tiered rate terms handling within rate sheets, enabling more flexible interest rate structures in future releases. --- ### Cards #### Additional work - Non-customer-facing cards architecture alignment work. --- ### Developer #### Additional work - Internal architecture design and documentation work across the platform. --- ## Improvements ### Data #### Automated recovery for broken revolving account schedules A new hourly job automatically recalculates broken revolving accounts and attempts to fix inconsistencies in their schedules. If an account cannot be resolved on the first attempt, the system waits for a cooling period to pass before retrying, rather than reattempting every hour. *Internal references:* [REV-4810](https://mambucom.jira.com/browse/REV-4810), [REV-4555](https://mambucom.jira.com/browse/REV-4555) #### `PATCH deposit-account` no longer fails during Daylight Saving Time transitions Resolved an issue where the `PATCH deposit-account` endpoint rejected requests due to an invalid date format when accounts were modified during Daylight Saving Time (DST) changes. *Internal references:* [DO-1438](https://mambucom.jira.com/browse/DO-1438) #### Groundwork for upcoming features - Groundwork for a new API endpoint to retrieve account withdrawal counter information and enforce interest accrual rules based on withdrawal activity. - Groundwork for bulk withdrawal transaction APIs, including extraction of organisation integration tests into a dedicated module. - Groundwork for improved transaction adjustment performance by reusing computed values when applying rounding adjustments for interest. - Groundwork for editing principal instalments on dynamic mortgages. - Groundwork for the Actual/Actual days-in-year interest calculation method for loans, including payment calculation accuracy on leap years. - Groundwork for account locking functionality, including a UI option to specify a fee rate when creating a loan account. - Groundwork for updated loan account overview details displaying new fields. - Groundwork for flexible schedule engine reliability, including a mechanism to store schedule differences during regeneration. - Groundwork for Islamic Banking pool accounting corrections, including extending the delete-cycles tool to clean pool-level GL journal entries. - Groundwork for deposits EOD transitional architecture using JDBI persistence. - Groundwork for generate-summary job observability improvements via updated metrics. #### Additional work - Internal configuration, feature-toggle removals, test additions, and backend-only maintenance across deposits, mortgages, lending, notifications, and infrastructure. --- ## Bug fixes ### Notifications #### Deletion of in-use notification templates is now prevented The Mambu UI now blocks deletion of notification templates that are actively in use, preventing accidental removal of templates tied to live processes. *Internal references:* [NTF-3529](https://mambucom.jira.com/browse/NTF-3529) --- ### Data #### Holiday save button no longer re-enables after a timeout The **Save** button on the holiday configuration screen correctly remains disabled after a request timeout, preventing duplicate submissions. *Internal references:* [MYM-4826](https://mambucom.jira.com/browse/MYM-4826) #### Search input now accepts period characters Search fields now accept the period (`.`) character as valid input, resolving failures when searching for values that include decimal points or domain-style strings. *Internal references:* [CDO-4358](https://mambucom.jira.com/browse/CDO-4358) #### Deposit transaction search now returns consistent results for date-time custom fields Searching deposit transactions using a date-time type custom field value now returns accurate, consistent results. *Internal references:* [ADM-4216](https://mambucom.jira.com/browse/ADM-4216) --- ### Mortgages #### Capitalised fees now correctly accrue interest when Decoupled IFA is enabled Fixed a bug where capitalised fees on mortgage loan accounts failed to accrue interest when the Decoupled Interest From Arrears feature was enabled. *Internal references:* [MTGE-2078](https://mambucom.jira.com/browse/MTGE-2078) #### Interest-bearing fee calculations corrected for accounts with more than two divisions Fixed an incorrect interest-bearing fee calculation that occurred when more than two divisions were present on a loan account. *Internal references:* [MTGE-2070](https://mambucom.jira.com/browse/MTGE-2070) #### Custom field data is now retained on Principal Overpayment transactions after adjustment Principal Overpayment **Entered** transactions now correctly carry custom field data after the transaction has been adjusted. *Internal references:* [MTGE-2050](https://mambucom.jira.com/browse/MTGE-2050) #### Instalment count in schedule calculations corrected for Principal Overpayment Fixed an incorrect number of instalments being generated in schedule calculations following a Principal Overpayment. *Internal references:* [MTGE-2045](https://mambucom.jira.com/browse/MTGE-2045) #### Interest due calculated correctly after RNI Principal Overpayment Fixed a bug where interest due was incorrectly calculated following a Reduce Number of Instalments (RNI) Principal Overpayment. *Internal references:* [MTGE-2040](https://mambucom.jira.com/browse/MTGE-2040) #### Loan product edit form loads reliably for all repayment frequency configurations Fixed a null pointer error that could prevent the loan product edit form from loading when certain repayment frequency unit values were present. *Internal references:* [MTGE-2039](https://mambucom.jira.com/browse/MTGE-2039) #### Excess payment error on mortgage pay-off resolved Fixed an erroneous excess payment validation error that blocked users from completing a pay-off on a mortgage account. *Internal references:* [MTGE-2037](https://mambucom.jira.com/browse/MTGE-2037) #### Carried-forward interest accrual now shown correctly on the first instalment after reschedule with product change Fixed a bug where interest accrued prior to reschedule was not represented on the first instalment of the rescheduled account when the product was changed at the point of reschedule. *Internal references:* [MTGE-2035](https://mambucom.jira.com/browse/MTGE-2035) #### Arrears accrual balance correctly cleared from original account on carry-forward Fixed a bug where the interest-from-arrears accrued balance was not removed from the original account when carried forward to the rescheduled account. *Internal references:* [MTGE-2028](https://mambucom.jira.com/browse/MTGE-2028) #### Improved error messaging for Carry Forward operations Error messages returned during Carry Forward operations are now clearer and more actionable, helping users identify and resolve issues faster. *Internal references:* [MTGE-2021](https://mambucom.jira.com/browse/MTGE-2021) #### Pay-off screen no longer retains values from a previous pay-off action Fixed a bug where the pay-off screen could display stale values from a prior pay-off action, causing incorrect figures and spurious validation errors. *Internal references:* [MTGE-1963](https://mambucom.jira.com/browse/MTGE-1963) #### Interest calculation corrected after adding a new interest rate period on Dynamic Mortgage accounts Fixed an incorrect interest calculation that occurred when a new interest rate period was added to a Dynamic Mortgage loan account. *Internal references:* [MTGE-1962](https://mambucom.jira.com/browse/MTGE-1962) #### Interest rate backdating now correctly restricted to after the last interest application Fixed a bug that allowed an interest rate to be backdated to a date before the last interest application, which could produce incorrect interest calculations. *Internal references:* [MTGE-1882](https://mambucom.jira.com/browse/MTGE-1882) #### Interest from Arrears within pay-off figure now rounds correctly Fixed a rounding error affecting the Interest from Arrears component of the pay-off figure on loan accounts. *Internal references:* [MTGE-1852](https://mambucom.jira.com/browse/MTGE-1852) #### Instalments now transition correctly past their due date Fixed a bug where instalments remained in a **Pending** status even after their due date had passed. *Internal references:* [MTGE-1786](https://mambucom.jira.com/browse/MTGE-1786) #### Accrue interest option for non-scheduled fees restricted to Manual fees only The **Accrue Interest** option for non-scheduled fees is now correctly restricted to Manual fee types in both the UI and API, preventing misconfiguration on other fee types. *Internal references:* [MTGE-1661](https://mambucom.jira.com/browse/MTGE-1661) #### Prepayment recalculation method now correctly propagated for Principal Overpayment Fixed a bug where the selected prepayment recalculation method was not propagated when processing a Principal Overpayment, ensuring the correct method is applied consistently. *Internal references:* [MTGE-2022](https://mambucom.jira.com/browse/MTGE-2022) #### Additional work - Internal mortgage revert and guardianship maintenance. --- ### Lending #### Repayment UI issue caused by serialisation change resolved Fixed a UI issue triggered by a change in the repayment class serialisation that affected repayment display and interaction. *Internal references:* [LPRC-5092](https://mambucom.jira.com/browse/LPRC-5092) #### Tax calculation on payment due fees now accurate for dynamic loan accounts Fixed a rounding issue that caused slight discrepancies in the tax amount calculated on payment due fees for dynamic loan accounts, ensuring all such calculations are now accurate. *Internal references:* [LPRC-3976](https://mambucom.jira.com/browse/LPRC-3976) #### Negative principal balance on RNI overpayment and prepayment scenarios resolved Fixed a bug where a `NegativePrincipalForRepaymentException` was thrown due to an incorrect `principalDue` amount during RNI overpayment and prepayment scenarios, caused by a miscalculation of the recalculation sub-schedule end index. *Internal references:* [LPRC-2677](https://mambucom.jira.com/browse/LPRC-2677) #### Loan account update API now works correctly for blacklisted clients with Predefined Fees Disbursement details, including fees, are now correctly validated when modifying fields on a loan account with Predefined Fees belonging to a blacklisted client. *Internal references:* [LL-5458](https://mambucom.jira.com/browse/LL-5458) --- ### Deposits #### Interest rate applied correctly when an account is unlocked on the same day its settings are updated Fixed a bug where unlocking an account on the same day its interest settings were updated caused the system to apply the previous day's interest rate, leading to inaccurate accruals. *Internal references:* [DO-382](https://mambucom.jira.com/browse/DO-382) #### Unicode characters in the Notes field now return a clear validation error Entering a unicode character in the **Notes** field during savings account creation now returns a `400` validation error instead of an unhandled `500` server error. *Internal references:* [DO-1553](https://mambucom.jira.com/browse/DO-1553) #### Additional work - Internal deposits cache and deposit limit fixes. --- ### Islamic Banking #### Invalid accounting setup error on IPS product edit resolved Fixed a bug that incorrectly raised an "invalid accounting setup" error when attempting to edit an Investment Product Suite (IPS) product that had both accounting and withholding taxes enabled. *Internal references:* [IB-2615](https://mambucom.jira.com/browse/IB-2615) #### Daily accrual calculation corrected for monthly IPS products Fixed an inconsistency in the daily accrual calculation that produced different results for two days within the same monthly IPS product cycle. *Internal references:* [IB-2610](https://mambucom.jira.com/browse/IB-2610) #### Profit distribution now uses the correct rate for the current cycle Fixed a bug where the profit distribution process incorrectly applied the profit rate from a future cycle instead of the current one. *Internal references:* [IB-2607](https://mambucom.jira.com/browse/IB-2607) #### Cashflow GL journal entries now logged at the correct time on end-of-cycle day Fixed a timing issue where cashflow GL journal entries were not being logged one second before midnight on the final day of a profit cycle, ensuring correct end-of-day ordering. *Internal references:* [IB-2605](https://mambucom.jira.com/browse/IB-2605) #### Profit calculation corrected when minimum and maximum rate ranges are defined Fixed an incorrect profit calculation that occurred when both minimum and maximum rate ranges were configured on an IPS product. *Internal references:* [IB-2571](https://mambucom.jira.com/browse/IB-2571) #### Profit accrual journal entries now include amounts for accounts paid on the accrual day Fixed a bug where profit accrual journal entries for a profit payment day did not include the accrued amount for accounts whose profit was paid on that same day. *Internal references:* [IB-2564](https://mambucom.jira.com/browse/IB-2564) #### Average balance for End of Payment Cycles now excludes post-profit balance Fixed a bug where the average balance displayed in Proposal Account Details for the **End of Payment Cycles** period incorrectly included the balance recorded after profit was applied. *Internal references:* [IB-2561](https://mambucom.jira.com/browse/IB-2561) #### Mudarib accounting entries no longer carry a linked transaction ID Fixed a minor issue where Mudarib accounting entries were incorrectly associated with a linked transaction ID. *Internal references:* [IB-2497](https://mambucom.jira.com/browse/IB-2497) #### Proposal account details no longer time out Resolved a timeout issue affecting the loading of proposal account details, ensuring the page loads reliably. *Internal references:* [IB-2289](https://mambucom.jira.com/browse/IB-2289) --- ### Transactions and Interest #### Interest accrual now posted correctly for Fixed Term Loans via the Decoupled flow Fixed a bug where interest accrual entries were not being posted for Fixed Term Loans processed through the Decoupled flow. *Internal references:* [GRAB-157](https://mambucom.jira.com/browse/GRAB-157) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.182 cycle. ## v9.182.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and configuration work. --- ## Bug fixes ### Lending #### Reposted `lateFeeIncludedInPmt` transactions now post with the correct value Reposted transactions that include a late fee in the payment amount were being recorded with an incorrect value; this has been resolved to ensure accurate transaction posting. *Internal references:* [LPRC-5147](https://mambucom.jira.com/browse/LPRC-5147) #### Balloon Payment recompute logic no longer affects non-Balloon accounts The `IRC_RECOMPUTE_GRACED_INSTALMENTS_FOR_BALLOON_ACCOUNTS` feature toggle was incorrectly applied to all loan accounts, including those not using the Balloon Payments amortization method; the logic has been corrected so the recompute process applies only to true Balloon Payment accounts, preventing errors during end-of-day execution and repayment or interest application. *Internal references:* [LPRC-5146](https://mambucom.jira.com/browse/LPRC-5146) --- ## v9.182.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data maintenance. --- ## Improvements ### Data #### Additional work - Non-customer-facing internal configuration and maintenance changes. --- ## Bug fixes ### Mortgages #### Consistent interest applied and interest accrued values Resolved an inconsistency where interest applied and interest accrued values were misaligned, ensuring accurate and reliable interest calculations. *Internal references:* [MTGE-2128](https://mambucom.jira.com/browse/MTGE-2128) ---

    Database changes

    | Table | Changes | |---|---| | `deposit_account_extensions` | • New table | | `fse_account` | • Added column `FAILED_SCHEDULE_COMPARISON` | | `ips_database_locks` | • Added column `LOCK_TYPE`
    • Added column `OWNER_ID`
    • Added column `ACQUIRED_AT` | | `loantransactioncustomfieldvalue` | • Added column `version` | | `notificationbrokerqueue` | • Removed index `NOTIFICATIONBROKERQUEUE_KEY_STATE_CREATIONDATE_IDX`
    • Added index `IDX_NOTIFICATIONBROKERQUEUE_NOTIFICATIONMESSAGEKEY`
    • Added index `IDX_NOTIFICATIONBROKERQUEUE_CREATION_DATE_STATE` | | `notificationevent` | • Added index `IDX_NOTIFICATIONEVENT_STATE_CREATION_DATE` | | `transactionchannel` | • Added column `ATTRIBUTES` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.183 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.183/ This page contains the following releases for v9.183: * [v9.183](#v9183) * [v9.183.6](#v91836) * [v9.183.5](#v91835) * [v9.183.4](#v91834) * [v9.183.3](#v91833) * [v9.183.2](#v91832) * [v9.183.1](#v91831) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.183 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Carry-forward fees and redraw balances preserved at reschedule and refinance When a mortgage is rescheduled or refinanced, outstanding fees and redraw balances are now carried forward to the new arrangement, ensuring no balances are lost during the transition. Both the API and UI expose the carried-forward values, and the `carriedForwardRedrawnBalance` is included in the activation event for downstream processing. *Internal references:* [MTGE-2156](https://mambucom.jira.com/browse/MTGE-2156), [MTGE-2102](https://mambucom.jira.com/browse/MTGE-2102), [MTGE-2101](https://mambucom.jira.com/browse/MTGE-2101), [MTGE-2052](https://mambucom.jira.com/browse/MTGE-2052) #### Auto-exclusion from end-of-day processing extended to Fixed Term Loans The auto-exclusion tool, which detects broken accounts and removes them from end-of-day (EOD) processing, now supports **Fixed Term Loan** product types in addition to Dynamic Term Loans, reducing the risk of EOD failures caused by problematic accounts. *Internal references:* [LPRC-5148](https://mambucom.jira.com/browse/LPRC-5148) #### Repayment schedule versioning can now be enabled for new accounts only A new **Repayment Schedule Versioning for New Accounts** feature toggle allows repayment schedule versioning (RSV) to be activated exclusively for newly created accounts, giving institutions a controlled, low-risk path to adopting RSV without affecting existing loan portfolios. *Internal references:* [LL-5815](https://mambucom.jira.com/browse/LL-5815) #### Groundwork for upcoming features - Building toward advance payment allocation for LATAM markets, enabling loan prepayments to be applied to future instalments without reducing interest (Phase 1 data model). - Building toward fee capitalisation during late status so that interest can be calculated on principal plus fees for standard payment loans. - Building toward enhanced EOD auto-exclusion monitoring capabilities. #### Additional work - Internal lending EOD architecture improvements, serialisation refactors, and backend-only maintenance. --- ### Deposits #### Fixed Term and Savings Plan products now supported for Profit Sharing deposits **Fixed Term** and **Savings Plan** product types can now be configured for profit-sharing deposits, with **On Account Maturity** and **On Fixed Date** payment frequencies available in product settings and a **Day of Month** field displayed when the **On Fixed Dates** frequency is selected. *Internal references:* [IB-2598](https://mambucom.jira.com/browse/IB-2598), [IB-2597](https://mambucom.jira.com/browse/IB-2597), [IB-2570](https://mambucom.jira.com/browse/IB-2570), [IB-1820](https://mambucom.jira.com/browse/IB-1820) --- ### Accounting #### Amortisation job no longer logs GL journal entries for locked accounts The EOD `AMOUNTS_AMORTIZATION` job now skips GL journal entry logging when an account is locked, preventing erroneous entries from being recorded during income recognition pauses for deferred fees. *Internal references:* [GRAB-147](https://mambucom.jira.com/browse/GRAB-147) #### Groundwork for upcoming features - Building toward GL account revaluation, enabling foreign-currency balances on GL accounts to be revalued when revaluation is configured. - Building toward independence of Term Overdraft from Overdraft for interest accrual and application, with product feature configuration now read from JSON with validated property values. #### Additional work - Backend-only accounting maintenance. --- ### Developer #### Additional work - Internal architectural diagrams, README documentation, and library dependency upgrades. - Non-customer-facing framework and infrastructure work. --- ## Improvements ### Data #### Additional work - Non-customer-facing internal maintenance, configuration, and test fixes. ### Analytics *(No tickets in this section.)* --- *(Skipping empty areas and restarting with populated ones only.)* --- ### Notifications #### Additional work - Internal notifications maintenance. ### Transactions and Interest #### Transaction channel `overdraftAllowed` attribute now returned on create and update The `overdraftAllowed` attribute on a `TransactionChannel` object is now validated and correctly mapped, so create and update calls return the full attributes field in the response. *Internal references:* [NCU-49](https://mambucom.jira.com/browse/NCU-49), [NCU-48](https://mambucom.jira.com/browse/NCU-48) ### Access Control #### Additional work - Non-customer-facing access control fixes. ### Mortgages #### Negative spread now supported for Actual Interest Rate on mortgage products Validation has been updated to allow mortgage products to be configured with a negative spread for the Actual Interest Rate (AIR), giving product managers greater flexibility when modelling below-benchmark rate structures. *Internal references:* [MTGE-2112](https://mambucom.jira.com/browse/MTGE-2112) #### Edit all instalment due dates in a single action Users can now bulk-edit due dates across all instalments at once from the UI, reducing manual effort when adjusting repayment schedules. *Internal references:* [MTGE-2098](https://mambucom.jira.com/browse/MTGE-2098), [MTGE-2096](https://mambucom.jira.com/browse/MTGE-2096), [MTGE-2095](https://mambucom.jira.com/browse/MTGE-2095) #### Improved Actual/Actual interest day-count calculation The Actual/Actual days-in-year interest calculation for mortgage loans has been refined, improving accuracy of interest computations for products using this day-count convention. *Internal references:* [MTGE-2068](https://mambucom.jira.com/browse/MTGE-2068) #### Additional work - Internal mortgage test and UI test maintenance. ### Lending #### Fee rate changes can now be scheduled with a future effective date A new date-selection control in the fee rate change dialog prevents backdated rate changes and lets users set a forward-looking effective date, with full integration between the UI and the backend fee rate change service. *Internal references:* [LPRC-5195](https://mambucom.jira.com/browse/LPRC-5195), [LPRC-5177](https://mambucom.jira.com/browse/LPRC-5177), [LPRC-4858](https://mambucom.jira.com/browse/LPRC-4858), [LPRC-4845](https://mambucom.jira.com/browse/LPRC-4845) #### Payment holidays blocked for Fee-Included-in-Payment products Validation has been added at both the API and UI levels to prevent payment holidays from being configured on accounts using the **FeeIncludedInPmt** functionality, avoiding unsupported schedule combinations. *Internal references:* [LPRC-5134](https://mambucom.jira.com/browse/LPRC-5134) #### Reschedule action no longer errors on accounts with redraw enabled An error that occurred when performing a reschedule on accounts with the redraw feature enabled has been resolved, ensuring the action completes successfully. *Internal references:* [LPRC-4971](https://mambucom.jira.com/browse/LPRC-4971) #### Fee rate changes handled correctly when an instalment is fee-unlocked Fee rate change processing now correctly handles the instalment for which an account has been fee-unlocked under the **FeeIncludedInPmt** configuration, ensuring accurate recalculation at unlock boundaries. *Internal references:* [LPRC-4928](https://mambucom.jira.com/browse/LPRC-4928) #### Closed account reserve entries cleaned up automatically Reserve (RSV) entries for closed accounts are now deleted, preventing stale data from accumulating and keeping account records clean after closure. *Internal references:* [LL-5863](https://mambucom.jira.com/browse/LL-5863) #### Groundwork for upcoming features - Foundational work to support Principal, Interest, and Fee computation of interest in arrears. - Groundwork for the new Loan Repayment transaction API 2.0 module, including handling of custom repayment and predefined fee settings. #### Additional work - Internal lending performance improvements, refactoring, and test fixes. ### Accounting #### Hourly journal entry summarisation reduces End-of-Day processing load A new hourly job now summarises total debits and credits journal entries throughout the day, distributing the summarisation workload evenly and reducing the processing burden at End-of-Day. *Internal references:* [LED-2766](https://mambucom.jira.com/browse/LED-2766) #### Additional work - Internal accounting logging additions and test fixes. ### Islamic Banking #### Groundwork for upcoming features - Parallel batch processing architecture for the **ManagePaymentCycle** job to support Fixed Term and Savings Plan payment cycle creation at scale. #### Additional work - Internal Islamic Banking data fixes. ### Cards #### Notifications sent for bulk authorisation holds Notifications are now dispatched when a bulk authorisation hold is created, keeping cardholders and downstream systems informed of hold activity. *Internal references:* [BKE-771](https://mambucom.jira.com/browse/BKE-771) ### Deposits #### Additional work - Internal deposits configuration and migration fixes. ### Transactions and Interest #### Current date used as entry date for all manual and backdated interest application paths When applying accrued interest manually — whether via the UI, API, early manual End-of-Day processing, or during backdated account activation — the current date is now consistently used as the entry date, ensuring correct transaction dating across all paths. *Internal references:* [BE-135](https://mambucom.jira.com/browse/BE-135), [BE-134](https://mambucom.jira.com/browse/BE-134), [BE-133](https://mambucom.jira.com/browse/BE-133), [BE-132](https://mambucom.jira.com/browse/BE-132) --- ## Bug fixes ### Lending #### Bulk reversal correctly handles future-dated terms changes Updated bulk reversal logic now correctly identifies and reverses future-dated `TERMS_CHANGED` transactions, aligning their behaviour with existing logic for future-dated `INTEREST_RATE_CHANGED` transactions. When a core transaction is reversed, any dependent scheduled loan term changes are also correctly reversed. *Internal references:* [REV-4772](https://mambucom.jira.com/browse/REV-4772) #### Manual fees can now be applied via the UI for fixed-term loans Resolved an issue that prevented manual fees from being applied through the UI on fixed-term loan accounts. *Internal references:* [LPRC-5214](https://mambucom.jira.com/browse/LPRC-5214) #### Balloon payment toggle no longer affects non-balloon loan accounts The `IRC_RECOMPUTE_GRACED_INSTALMENTS_FOR_BALLOON_ACCOUNTS` feature toggle was incorrectly applied to all accounts regardless of amortization method, causing failures during end-of-day execution and repayment or interest application. The logic now restricts the recompute process to true Balloon Payment accounts only. *Internal references:* [LPRC-5146](https://mambucom.jira.com/browse/LPRC-5146) #### RAI overpayments on fully paid instalments now processed correctly Resolved an issue where RAI overpayments on fully paid instalments were not recognised due to zero principal allocation; the logic now correctly identifies and processes these overpayments. *Internal references:* [LPRC-4908](https://mambucom.jira.com/browse/LPRC-4908) #### Custom field unique validation no longer blocks adjusted transactions on fixed-term loans Fixed an issue where adjusting transactions on fixed-term loans with interest pre-payments enabled incorrectly triggered duplicate custom field value errors; custom field values are now handled correctly during transaction adjustments. *Internal references:* [LPRC-4781](https://mambucom.jira.com/browse/LPRC-4781) #### Interest correctly restored on schedule after undoing a backdated fixed-term loan payoff Fixed an issue where undoing the payoff of a backdated fixed-term loan with interest applied at the repayment moment caused interest to disappear from the schedule; interest is now correctly visible after the payoff transaction is adjusted. *Internal references:* [LPRC-4424](https://mambucom.jira.com/browse/LPRC-4424) #### Schedule and Details tabs remain consistent after penalty rate changes Fixed a bug where changing the penalty rate and adjusting loan transactions caused a data mismatch between the **Schedule** and **Details** tabs when some principal had been paid. *Internal references:* [LL-5786](https://mambucom.jira.com/browse/LL-5786) #### Holiday data processing made more reliable Implemented backend enhancements to improve the reliability and stability of how holiday data is processed, reducing the risk of internal service failures. *Internal references:* [LL-5851](https://mambucom.jira.com/browse/LL-5851) #### Additional work - Non-customer-facing lending fixes and internal maintenance. --- ### Mortgages #### Reverting a fee no longer leaves a residual accrued fee balance Fixed an issue where reverting a `FeeApplied` transaction failed to remove the associated accrued fee balance, leaving accounts in an inconsistent state. *Internal references:* [MTGE-2155](https://mambucom.jira.com/browse/MTGE-2155) #### Interest type now visible on product creation, product details, and loan account details Resolved a display issue where the interest type field was missing from the product creation form, product details page, and loan account details view. *Internal references:* [MTGE-2147](https://mambucom.jira.com/browse/MTGE-2147) #### Interest on IBF Accrued correctly cleared after backdated repayment Fixed an issue where interest on IBF Accrued was retained even after a backdated repayment was made to cover the IBF balance and its associated interest. *Internal references:* [MTGE-2094](https://mambucom.jira.com/browse/MTGE-2094) #### Repaying interest from arrears no longer incorrectly affects Interest from Arrears Accrued Resolved an issue where repaying the interest from an arrears balance had unintended side effects on the **Interest from Arrears Accrued** field. *Internal references:* [MTGE-2085](https://mambucom.jira.com/browse/MTGE-2085) --- ### Deposits #### `GET /api/depositproducts` now returns complete template lists for all products Previously, calling `GET /api/depositproducts` returned an empty `templates` list for each product despite templates being correctly associated; the endpoint now returns the complete and correct list of associated templates for every product, consistent with the individual product endpoint. *Internal references:* [DO-1677](https://mambucom.jira.com/browse/DO-1677) #### Base currency validation for linked loan and deposit products corrected Fixed validation for linked loan and deposit products so that base currency checks are only triggered when the organisation's base currency is actually removed from a savings product, preventing false validation errors. *Internal references:* [DO-573](https://mambucom.jira.com/browse/DO-573) #### Additional work - Non-customer-facing deposit fixes and internal maintenance. --- ### Islamic Banking #### Islamic accounts no longer display interest accrual fields Fixed an issue where Islamic accounts incorrectly displayed **Interest Accrued** and **Negative Interest Accrued** fields, which are not applicable to Islamic banking products. *Internal references:* [IB-2776](https://mambucom.jira.com/browse/IB-2776), [IB-2567](https://mambucom.jira.com/browse/IB-2567) #### Profit applied transactions now respect currency decimal settings Resolved an issue where profit applied transactions did not honour the configured number of digits after the decimal point for the account's currency. *Internal references:* [IB-2697](https://mambucom.jira.com/browse/IB-2697) #### Accounting header no longer appears as a selectable option in pool accounting settings Fixed a UI issue where an accounting header was incorrectly displayed as a selectable option when configuring pool accounting settings. *Internal references:* [IB-2696](https://mambucom.jira.com/browse/IB-2696) #### GL accounts can no longer be linked to multiple income categories Added the missing restriction that prevents a single GL account from being associated with more than one income category, ensuring correct accounting configuration. *Internal references:* [IB-2616](https://mambucom.jira.com/browse/IB-2616) #### All GL accounts now visible in pool settings drop-down Fixed a pagination issue that caused the GL account drop-down list on pool settings to display an incomplete set of available accounts. *Internal references:* [IB-2580](https://mambucom.jira.com/browse/IB-2580) --- ### Cards #### Credit limit calculated correctly when disbursement exceeds available balance Fixed an issue where an incorrect credit limit was calculated when a disbursement amount exceeded the available account balance. *Internal references:* [CARDS-2495](https://mambucom.jira.com/browse/CARDS-2495) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.183 cycle. ## v9.183.6 **Release Date**: 03.06.2026 --- ## Bug fixes ### Lending #### Loan account status correctly reflects late installments after manual interest or fee application When an interest or fee action was performed before the scheduled cron job ran, installments were incorrectly marked as late without the loan account itself reflecting the same status; this has been resolved so the account-level status stays consistent with its installments. *Internal references:* [LL-5949](https://mambucom.jira.com/browse/LL-5949) --- ## v9.183.5 **Release Date**: 03.06.2026 --- ## Bug fixes ### Mortgages #### Interest rate changes on loan accounts restored Resolved an issue that prevented users from modifying the interest rate on a loan account. *Internal references:* [MTGE-2286](https://mambucom.jira.com/browse/MTGE-2286) --- ## v9.183.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data maintenance and test coverage improvements. --- ## v9.183.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data maintenance and test coverage improvements. --- ## Bug fixes ### Mortgages #### End-of-day processing failure resolved for affected tenants An issue causing end-of-day processing to fail in certain tenant environments has been resolved, restoring reliable batch execution. *Internal references:* [MTGE-2237](https://mambucom.jira.com/browse/MTGE-2237) #### Dynamic mortgage accounts can now be created with Actual ISDA and broken interest A defect preventing the creation of dynamic mortgage accounts when using the Actual ISDA convention with broken interest has been fixed. *Internal references:* [MTGE-2186](https://mambucom.jira.com/browse/MTGE-2186) --- ## v9.183.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and configuration work. --- ## v9.183.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and internal configuration changes. --- ## Bug fixes ### Lending #### Manual fees can now be applied through the UI for fixed-term loans Fixed-term loans no longer block manual fee application through the user interface, restoring expected fee management behaviour. *Internal references:* [LPRC-5214](https://mambucom.jira.com/browse/LPRC-5214) ---

    Database changes

    | Table | Changes | |---|---| | `fse_account` | • Removed column `REGENERATED` | | `generalsettings` | • Added column `CONFIGURATIONDATA` | | `glaccountsummaryprocess` | • Added column `MINENTRYDATE`
    • Added column `MAXENTRYDATE`
    • Added index `IDX_GLACCOUNTSUMMARYPROCESS_FROMENTRY_TOENTRY` | | `ips_account_payment_cycle` | • Added column `ACTIVATION_DATE`
    • Added column `MATURITY_DATE` | | `ips_internal_cycle` | • Added column `SETTINGS_PRODUCT_CYCLE_ID` | | `ips_product_calculation_cycle` | • Added column `DAY_OF_MONTH` | | `ips_product_settings` | • Added column `DAY_OF_MONTH` | | `savings_account_balance` | • New table
    • Added index `idx_savings_account_balance_unique` | | `savings_account_balance_change` | • New table
    • Added index `idx_savings_account_balance_change_balance_id`
    • Added index `idx_savings_account_balance_change_balance_value_date`
    • Added index `idx_savings_account_balance_change_transaction_id` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.184 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.184/ This page contains the following releases for v9.184: * [v9.184](#v9184) * [v9.184.3](#v91843) * [v9.184.2](#v91842) * [v9.184.1](#v91841) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.184 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Mortgages #### Set a first repayment date during mortgage migration Lenders can now specify a first repayment date when migrating mortgage accounts, giving greater control over repayment schedule alignment at the point of migration. *Internal references:* [MTGE-2295](https://mambucom.jira.com/browse/MTGE-2295) #### View carry-forward balances in the mortgage UI Carry-forward balances are now visible directly in the mortgage account interface, making it easier for users to review outstanding amounts carried over from a reschedule or refinance. *Internal references:* [MTGE-1776](https://mambucom.jira.com/browse/MTGE-1776) #### New API endpoint for external mortgage account migration A new API endpoint is available to support the migration of external mortgage accounts into the platform, enabling integrations to programmatically submit migration data. *Internal references:* [MTGE-1775](https://mambucom.jira.com/browse/MTGE-1775) #### Carry-forward fees now included in reschedule and refinance calculations Scheduled fees, non-scheduled fees, and interest-bearing fees are now correctly carried forward when a mortgage account is rescheduled or refinanced, ensuring fee balances are accurately reflected in the updated schedule. *Internal references:* [MTGE-2109](https://mambucom.jira.com/browse/MTGE-2109), [MTGE-2051](https://mambucom.jira.com/browse/MTGE-2051) #### Clearer tooltips for carry-forward and IBF interest accrued values New tooltips on the reschedule and refinance screens explain carry-forward amounts and interest-bearing fee (IBF) interest accrued figures, reducing ambiguity for operations staff reviewing rescheduled accounts. *Internal references:* [MTGE-2097](https://mambucom.jira.com/browse/MTGE-2097), [MTGE-2266](https://mambucom.jira.com/browse/MTGE-2266) --- ### Lending #### Selectively include fees in penalty calculations A new **Include in penalty calculation** checkbox in the **Product Fees** section of the loan creation and product overview screens lets users choose which fees are factored into penalty calculations, with the penalty calculator updated to apply only the selected fees. *Internal references:* [LPRC-5253](https://mambucom.jira.com/browse/LPRC-5253), [LPRC-5049](https://mambucom.jira.com/browse/LPRC-5049), [LPRC-4349](https://mambucom.jira.com/browse/LPRC-4349) #### Configure advance payment allocation for loan pre-payments Loan products and accounts can now be configured to allocate pre-payments to the next scheduled installments without reducing interest, supporting advance payment behaviour required for certain lending markets. The API contracts for loan products and accounts have been updated accordingly, and the advance payment transaction schedule computation is in place. *Internal references:* [LPRC-5110](https://mambucom.jira.com/browse/LPRC-5110), [LPRC-5102](https://mambucom.jira.com/browse/LPRC-5102) #### Groundwork for upcoming features - Building toward a Rate Sheet 2.0 capability; Rate Sheet-related features are intentionally hidden from the Admin console until the feature is ready for release. #### Additional work - Internal lending UI and calculator maintenance. --- ### Islamic Banking #### Display end-of-maturity period details for fixed-term deposit accounts The proposal page for fixed-term deposit accounts now shows the **End of Maturity Period** section, giving users visibility of maturity terms before confirming a deposit proposal. *Internal references:* [IB-2599](https://mambucom.jira.com/browse/IB-2599) #### Groundwork for upcoming features - Building toward profit-sharing support for term and savings plan deposits, including correct internal cycle splitting for on-account-maturity frequency. - Building toward cash-flow distribution between assets and liabilities, including EOD balance calculation on internal cycles, asset amount computation, liability checks in pool settings, and asset-liability parameter display and editing in the UI. #### Additional work - Internal Islamic Banking test coverage and operational maintenance. --- ### Deposits #### Groundwork for upcoming features - Building toward next-generation transaction processing, including dynamic balance framework enhancements to expose shadow and standard balance updates via the Deposits API. - Building toward tiered rate terms handling, updating the rate provider to use rates from a linked rate sheet at product and account level for tiered-balance interest. --- ### Data #### Additional work - Internal OIDC provider initialisation fix (non-customer-facing configuration correction). --- ### Accounting #### Groundwork for upcoming features - Building toward the ability to pause income recognition for deferred fees on locked loan portfolios. --- ## Improvements ### Data #### Additional work - Non-customer-facing internal maintenance, infrastructure, and backend-only changes. ### Mortgages #### Adjust the number of installments at the end of a mortgage loan term Lenders can now extend or shorten a mortgage loan term by adding or removing installments at the end of the schedule, with a new API endpoint to preview the impact before committing the change and a second endpoint to apply it. *Internal references:* [MTGE-2163](https://mambucom.jira.com/browse/MTGE-2163), [MTGE-2169](https://mambucom.jira.com/browse/MTGE-2169), [MTGE-2165](https://mambucom.jira.com/browse/MTGE-2165), [MTGE-2164](https://mambucom.jira.com/browse/MTGE-2164), [MTGE-2170](https://mambucom.jira.com/browse/MTGE-2170), [MTGE-2236](https://mambucom.jira.com/browse/MTGE-2236), [MTGE-2247](https://mambucom.jira.com/browse/MTGE-2247), [MTGE-2252](https://mambucom.jira.com/browse/MTGE-2252), [MTGE-2287](https://mambucom.jira.com/browse/MTGE-2287), [MTGE-2162](https://mambucom.jira.com/browse/MTGE-2162) #### Groundwork for upcoming features - Ongoing refactoring of the mortgage financial simulation engine to improve reliability and maintainability of scheduled job execution. #### Additional work - Internal mortgage backend maintenance and test fixes. ### Accounting #### Additional work - Backend-only accounting summary and test maintenance changes. ### Deposits #### Additional work - Internal deposits backend fixes and EOD processing improvements. --- ## Bug fixes ### Notifications #### Deposit interest notification templates now correctly exported via Configuration as Code Templates created using the `DEPOSIT_INTEREST_APPLIED` and `DEPOSIT_INTEREST_APPLIED_ADJUSTMENTS` event types are now correctly available via Configuration as Code (CasC) when the functionality is enabled. *Internal references:* [NTF-3638](https://mambucom.jira.com/browse/NTF-3638), [NTF-3594](https://mambucom.jira.com/browse/NTF-3594) --- ### Mortgages #### Interest rate changes no longer produce rounded principal due figures Rounded principal due figures that appeared incorrectly following interest rate changes are now resolved, ensuring accurate installment amounts are displayed. *Internal references:* [MTGE-2288](https://mambucom.jira.com/browse/MTGE-2288) #### Carried forward days in arrears now counted accurately An off-by-one error that caused carried forward days in arrears to lose one day has been corrected, ensuring arrears tracking remains precise across rescheduling and refinancing operations. *Internal references:* [MTGE-2253](https://mambucom.jira.com/browse/MTGE-2253) #### Accrued interest on interest-bearing fees now correctly calculated after fee reduction or partial repayment Returned accrued interest on interest-bearing fees is now accurately recalculated following a fee reduction or partial repayment, preventing incorrect interest figures from appearing on affected accounts. *Internal references:* [MTGE-2194](https://mambucom.jira.com/browse/MTGE-2194) #### Fee capitalisation with broken interest now respects the configured threshold Fee capitalisation no longer ignores the configured threshold when broken interest is involved, ensuring capitalisation behaviour remains consistent with product settings. *Internal references:* [MTGE-2159](https://mambucom.jira.com/browse/MTGE-2159) #### Interest due value now calculated correctly An issue causing incorrect interest due values on certain accounts has been resolved, ensuring the displayed and applied interest due figures are accurate. *Internal references:* [MTGE-2130](https://mambucom.jira.com/browse/MTGE-2130) #### Principal overpayment no longer causes incorrect interest calculation for compound interest products Interest applied is now correctly calculated for dynamic mortgage products configured with compound interest when a principal overpayment has been made, preventing inaccurate interest amounts from being posted. *Internal references:* [MTGE-2143](https://mambucom.jira.com/browse/MTGE-2143) #### Excess repayment validation now works correctly with new loan account balances Validation of excess repayments no longer fails incorrectly when new loan account balance fields are in use, allowing repayments to be processed without erroneous errors. *Internal references:* [MTGE-2099](https://mambucom.jira.com/browse/MTGE-2099) #### Make overpayment action now validates payment amount correctly The **Make Overpayment** action now enforces correct payment amount validation, preventing invalid overpayment submissions from being accepted. *Internal references:* [MTGE-1991](https://mambucom.jira.com/browse/MTGE-1991) #### Interest accrual now recalculated correctly after backdated fee capitalisation Interest accrued is now correctly recalculated when a fee capitalisation is posted with a backdated value date, ensuring the accrual figures reflect the true state of the account. *Internal references:* [MTGE-1444](https://mambucom.jira.com/browse/MTGE-1444) #### Custom repayment option now includes non-scheduled fees after carry forward restructure Non-scheduled fees are now correctly available as a custom repayment option following a carry forward scheduled fees restructure, restoring expected repayment flexibility. *Internal references:* [MTGE-2257](https://mambucom.jira.com/browse/MTGE-2257) #### Redraw repayment accounting corrected for interest-only equal instalment products when payment exceeds interest balance Accounting entries for redraw repayments on interest-only equal instalment products are now posted correctly when the payment amount is larger than the deferred interest balance. *Internal references:* [MTGE-2210](https://mambucom.jira.com/browse/MTGE-2210) #### Bulk due date update no longer assigns duplicate due dates when holidays are configured When holidays are configured and a bulk due date update is performed, the system now correctly avoids assigning the same due date to multiple instalments. *Internal references:* [MTGE-2185](https://mambucom.jira.com/browse/MTGE-2185) #### Rescheduling a loan with both redraw and outstanding interest balance now completes successfully Fixed an issue where rescheduling a loan account with both an available redraw balance and an outstanding interest balance would fail. The system now correctly updates its record of the interest balance after the redraw balance is used to pay it down, but before validations are run, preventing an incorrect validation error and allowing the reschedule to complete successfully. *Internal references:* [LL-5779](https://mambucom.jira.com/browse/LL-5779) #### Interest due no longer incorrectly zeroed after a principal-only prepayment followed by an interest rate change When an interest rate change occurs shortly after a custom principal repayment on loans configured with the "Principal expected is paid before/on due date" rule, the system no longer incorrectly marks installments as fully paid by setting interest due to zero. The fix ensures interest due remains correctly open until its actual due date, improving amortisation accuracy and payment amounts. *Internal references:* [LPRC-5096](https://mambucom.jira.com/browse/LPRC-5096) #### Additional work - Internal mortgage backend fixes and maintenance. --- ### Deposits #### EOD process now completes successfully when monthly fee exceeds available balance The End of Day (EOD) process previously failed when attempting to apply a monthly fee to a savings account with an insufficient balance when the German fee model was enabled and overdraft was disabled. The fee is now correctly applied in full, the account moves to **In Arrears** if the balance is insufficient, and the EOD process completes successfully. *Internal references:* [DO-1017](https://mambucom.jira.com/browse/DO-1017) #### Accounting rules no longer incorrectly dropped or duplicated on deposit product update via Configuration as Code Fixed an issue where refreshing product accounting rules via CasC could incorrectly drop existing rules or mishandle updated ones. Updates now result in stable, consistent rule persistence without unintended deletions. *Internal references:* [DO-1715](https://mambucom.jira.com/browse/DO-1715) #### Unicode characters in account notes field now return a 400 response instead of a 500 error Setting a unicode character in the **Notes** field for savings accounts no longer causes an unhandled server error; the system now returns a `400` status code with an appropriate error response. *Internal references:* [DO-1749](https://mambucom.jira.com/browse/DO-1749) #### Additional work - Internal deposits backend fixes and maintenance. --- ### Islamic Banking #### Account status no longer changed incorrectly when a profit cycle is closed An issue causing an account's status to change unexpectedly when closing a profit cycle has been resolved, ensuring account status remains stable throughout the profit cycle closure process. *Internal references:* [IB-2758](https://mambucom.jira.com/browse/IB-2758) #### Average balance calculation corrected for affected profit cycles An incorrect average balance calculation affecting certain profit cycles has been fixed, ensuring profit distribution is based on accurate balance figures. *Internal references:* [IB-2725](https://mambucom.jira.com/browse/IB-2725) #### Interest fields now correctly hidden when a Sharīʿah product category is selected After selecting a Sharīʿah product category in the UI, interest-related fields are now correctly hidden, preventing misleading configuration options from being displayed. *Internal references:* [IB-2724](https://mambucom.jira.com/browse/IB-2724) #### Closing an IPS account now displays correct wording in the confirmation dialog The confirmation popup shown when closing an Islamic Profit Sharing account now displays accurate and appropriate wording. *Internal references:* [IB-2711](https://mambucom.jira.com/browse/IB-2711) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.184 cycle. ## v9.184.3 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data fixes. --- ## v9.184.2 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data maintenance. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## v9.184.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Interest accrual breakdown now available Detailed interest accrual breakdown data is now available, giving clients greater visibility into how interest is calculated and accrued across accounts. *Internal references:* [LED-2956](https://mambucom.jira.com/browse/LED-2956) #### Additional work - Non-customer-facing data and query maintenance. ---

    Database changes

    | Table | Changes | |---|---| | `ips_account_payment_cycle` | • Added column `ACCOUNT_STATE` | | `ips_cash_flow_calculation_cycle` | • Added column `ASSET_GL_ACCOUNT_ENCODEDKEY`
    • Added column `ASSET_AMOUNT` | | `ips_internal_cycle` | • Added column `EOD_BALANCE` | | `ips_pool_calculation_cycle` | • Added column `LIABILITY_CHECK` | | `ips_pool_settings` | • Added column `LIABILITY_CHECK` | | `loan_account_carry_forward_log` | • Added column `fee_amount`
    • Column `last_set_to_arrears_date` now allows NULL | | `rate_sheet_schema` | • New table
    • Added index `idx_rate_sheet_schema_code` | | `ratesheet` | • New table
    • Added index `uq_ratesheet_code_valid_from` | | `savings_account_balance` | • Added index `idx_savings_account_balance_savings_account_encoded_key_type` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.185 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.185/ This page contains the following releases for v9.185: * [v9.185](#v9185) * [v9.185.4](#v91854) * [v9.185.3](#v91853) * [v9.185.2](#v91852) * [v9.185.1](#v91851) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.185 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Withholding Tax now supported on index (variable) rate deposit products Withholding tax (WHT) can now be applied to deposit products that use an index (variable) rate, extending existing WHT support to this product type. *Internal references:* [DO-1849](https://mambucom.jira.com/browse/DO-1849) #### New `INVALID_ACCOUNT_FEATURE_CONFIGURATION` return code A new `INVALID_ACCOUNT_FEATURE_CONFIGURATION` return code has been introduced to provide clearer, more specific error signalling when an account feature is misconfigured. *Internal references:* [NCU-126](https://mambucom.jira.com/browse/NCU-126) #### Groundwork for upcoming features - Groundwork for enabling credit (negative) balance on revolving loan accounts, including API storage and liability GL posting support. - Groundwork for Courtesy Pay product and account limit configuration. - Groundwork for restricting redraw balance when carrying forward balances during loan restructure. - Groundwork for redraw balance migration support within mortgage migration tooling. - Groundwork for advance payment transaction posting to support allocation of loan prepayments to next instalments without interest reduction. - Groundwork for applying profit across new payment frequencies on Islamic term and savings plan deposits. - Groundwork for cashflow distribution between assets and liabilities, including EOD average balance calculations and asset GL account configuration in the UI. - Groundwork for improving fixed-term loan repayment API throughput, including organisation time service integration and expanded unsupported configuration coverage. - Groundwork for next-generation transaction processing with backdate support. - Groundwork for credit card product definition, including a feature toggle to enable creation of new credit card products. - Groundwork for credit account data structures to support credit account flows, statements, dynamic balances, and transactions. - Groundwork for back-dating remediation requirements. #### Additional work - Internal data layer changes for product feature storage normalisation and API/implementation module restructuring. --- ## Improvements ### Data #### Improved range API performance for parallel file downloads Optimised performance on the range API used for parallel file downloads across deposit and loan accounts. *Internal references:* [SCAL-1238](https://mambucom.jira.com/browse/SCAL-1238) ### Analytics #### Historical balances API contract A new API contract is now available for retrieving historical balances, enabling clients to query balance data over time. *Internal references:* [DIF-2433](https://mambucom.jira.com/browse/DIF-2433) #### Daily accrued interest exposed via API New API endpoints expose daily accrued interest amounts from savings account accrual data, giving clients programmatic access to interest calculation details. *Internal references:* [BE-201](https://mambucom.jira.com/browse/BE-201) #### Groundwork for upcoming features - Building the v2 Rate Sheet data model, domain repositories, and caching layer in preparation for full Rate Sheet API delivery. ### Lending #### Emoji characters supported in loan repayment transaction notes Emoji characters are now allowed in loan repayment transaction notes when the `ALLOW_EMOJI` feature toggle is enabled; when the toggle is disabled, emojis continue to be removed from notes to preserve existing behaviour. *Internal references:* [LL-5964](https://mambucom.jira.com/browse/LL-5964) #### Groundwork for upcoming features - Building the loan repayment transaction flow in the new API 2.0 module, including response construction and consistency validation, for fixed-term loans. #### Additional work - Internal lending configuration and backend-only changes. ### Mortgages #### Change Loan Term now accessible for all eligible mortgage accounts The **Change Loan Term** flow is now available to all eligible mortgage accounts, with a streamlined path that does not require a preview step. *Internal references:* [MTGE-2167](https://mambucom.jira.com/browse/MTGE-2167), [MTGE-2166](https://mambucom.jira.com/browse/MTGE-2166) #### Groundwork for upcoming features - Carry-forward accrued balance display behaviour is being refined as part of the reschedule and refinance carry-forward balances initiative. - Advancing the Change Loan Term feature to support adding and removing instalments at the end of the loan term. #### Additional work - Internal mortgage test coverage, migration validation, and feature toggle removal. ### Deposits #### Additional work - Internal deposit configuration changes. ### Islamic Banking #### Asset GL account selection restricted to ASSET-type accounts The **Cashflow Settings** UI now limits asset GL account selection to accounts of type **ASSET**, preventing misconfiguration. *Internal references:* [IB-2808](https://mambucom.jira.com/browse/IB-2808) #### Profit distribution now uses the correct exchange rate for each internal cycle Fixed a bug where profit distribution always applied the exchange rate from the first internal cycle rather than the rate corresponding to each respective cycle. *Internal references:* [IB-2792](https://mambucom.jira.com/browse/IB-2792) #### Internal cycles created with correct end dates Fixed a bug where internal cycles were being created with an incorrect end date. *Internal references:* [IB-2790](https://mambucom.jira.com/browse/IB-2790) #### Null product cycle ID no longer causes errors when creating internal cycles Fixed two related bugs where a null product cycle ID could cause failures when creating internal cycles or combining cycle data. *Internal references:* [IB-2793](https://mambucom.jira.com/browse/IB-2793), [IB-2775](https://mambucom.jira.com/browse/IB-2775) ### Notifications #### Additional work - Internal notifications maintenance. ### Accounting #### Additional work - Backend-only accounting changes. --- ## Bug fixes ### Notifications #### Amount-based notification conditions now evaluate correctly Notification rules using **Amount** as a condition now trigger as expected, resolving an issue where the condition was not being evaluated properly. *Internal references:* [NTF-2049](https://mambucom.jira.com/browse/NTF-2049) --- ### Mortgages #### Interest accrual restored on rescheduled accounts after carry-forward Fixed an issue where the interest accrued balance stopped accruing interest on a mortgage account after a carry-forward operation at reschedule, ensuring interest continues to accrue correctly on the rescheduled account. *Internal references:* [MTGE-2354](https://mambucom.jira.com/browse/MTGE-2354) #### Repaying a non-scheduled fee no longer disrupts the repayment schedule Resolved a bug where repaying a non-scheduled fee incorrectly altered the loan repayment schedule, ensuring the schedule remains unaffected after such repayments. *Internal references:* [MTGE-2298](https://mambucom.jira.com/browse/MTGE-2298) #### Fee capitalisation now correctly updates the schedule when no threshold is configured Fixed an issue where fee capitalisation on a mortgage loan without a capitalisation threshold configured left the repayment schedule unchanged, ensuring the schedule is properly updated after capitalisation. *Internal references:* [MTGE-1662](https://mambucom.jira.com/browse/MTGE-1662) #### Carry-forward of non-scheduled fees now works correctly via API Resolved an issue preventing non-scheduled fees from being carried forward through the API, and corrected the associated accounting entries for non-scheduled, interest-bearing fees during carry-forward operations. *Internal references:* [MTGE-2334](https://mambucom.jira.com/browse/MTGE-2334), [MTGE-2332](https://mambucom.jira.com/browse/MTGE-2332) #### Loan schedule remains consistent when editing the principal amount Fixed an inconsistency where editing the principal amount on a loan could produce an unpredictable repayment schedule. *Internal references:* [MTGE-2305](https://mambucom.jira.com/browse/MTGE-2305) #### Planned fees no longer missing from the loan schedule Resolved an issue where planned fees were absent from the loan schedule under certain conditions. *Internal references:* [MTGE-2303](https://mambucom.jira.com/browse/MTGE-2303) #### Additional work - Internal mortgage maintenance and implementation changes. --- ### Lending #### Dynamic term loan accounts now correctly reflect late status when interest or fees are applied before end-of-day processing Fixed an issue where, if an interest or fee apply action was performed before the scheduled end-of-day job, individual installments were marked as late but the parent loan account status was not updated accordingly. *Internal references:* [LPRC-5275](https://mambucom.jira.com/browse/LPRC-5275) #### Booking dates are now correctly converted to organisation time when posted to Accounting Resolved an issue where booking dates were not being converted to the organisation's local time zone before being logged in Accounting, ensuring consistent and accurate date records. *Internal references:* [LPRC-4809](https://mambucom.jira.com/browse/LPRC-4809) #### Rescheduling multiple loans in the same session now shows the correct outstanding principal Fixed an issue where the **Reschedule Loan Account** form displayed the previous loan's **Current Outstanding Principal** when rescheduling multiple loan accounts consecutively in the same browser tab or session; the form now correctly reflects the outstanding principal for the loan being rescheduled. *Internal references:* [LL-5980](https://mambucom.jira.com/browse/LL-5980) #### Interest splitting for payment holidays now calculated correctly Resolved an issue in schedule calculation where interest was not being split correctly across payment holiday periods. *Internal references:* [LL-5918](https://mambucom.jira.com/browse/LL-5918) --- ### Islamic Banking #### Duplicate profit calculation cycles no longer created when effective date differs from profit calculation start date Fixed an issue where duplicate pool and product cycles were generated when the effective date did not match the profit calculation start date, preventing duplicate internal cycle errors. *Internal references:* [IB-2780](https://mambucom.jira.com/browse/IB-2780), [IB-2771](https://mambucom.jira.com/browse/IB-2771) #### Terminology in savings product descriptions updated to reflect Islamic Banking context Removed inappropriate use of the term "interest" from Islamic Profit Sharing savings product descriptions to ensure correct and compliant terminology is displayed. *Internal references:* [IB-2767](https://mambucom.jira.com/browse/IB-2767) #### Additional work - Internal Islamic Banking front-end maintenance. --- ### Deposits #### Closed savings accounts no longer affected by interest rate availability end-of-day job When an interest rate value changes as a result of the interest availabilities end-of-day job, accounts with a **Closed** status are no longer incorrectly updated. *Internal references:* [DO-453](https://mambucom.jira.com/browse/DO-453) #### Branch now correctly assigned to auto-created linked settlement accounts Resolved an issue where the branch was not being set on a linked settlement account that was automatically created alongside a deposit account. *Internal references:* [DO-1262](https://mambucom.jira.com/browse/DO-1262) #### Additional work - Internal deposits query and test maintenance. --- ### Cards #### Available balance check correctly applied when an authorisation hold is present Fixed an issue where the available balance was not being checked against an existing authorisation hold during transaction processing, ensuring balance validation behaves correctly. *Internal references:* [CARDS-2517](https://mambucom.jira.com/browse/CARDS-2517) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.185 cycle. ## v9.185.4 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data layer fixes. --- ## v9.185.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing configuration changes. --- ## v9.185.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration and maintenance changes. --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data fixes. --- ## v9.185.1 **Release Date**: 03.06.2026 --- ## Features ### Data #### Groundwork for upcoming features - Groundwork to extend instalment recomputation feature toggle support for balloon accounts at the point of account creation. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. ---

    Database changes

    | Table | Changes | |---|---| | `ips_pool_calculation_cycle` | • Added column `AVERAGE_EOD_BALANCE`
    • Added index `IPS_POOL_CALCULATION_CYCLE_POOL_ID_START_END_DATE_UNIQUE_IDX` | | `ips_product_calculation_cycle` | • Added column `AVERAGE_EOD_BALANCE` | | `loan_account_carry_forward_log` | • Added column `redraw_balance` | | `rate_sheet_schema` | • Renamed column `modified_by` → `last_modified_by`
    • Changed data type of column `creation_date`
    • Changed data type of column `last_modified_date` | | `savingsaccountdailyaccruedinterest` | • Added column `ACCOUNT_BALANCE`
    • Added column `CREDIT_INTEREST_RATE` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.186 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.186/ This page contains the following releases for v9.186: * [v9.186](#v9186) * [v9.186.2](#v91862) * [v9.186.1](#v91861) ## v9.186 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data fixes. --- ## Improvements ### Data #### Additional work - Internal tenant and sandbox configuration updates. --- ## v9.186.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## v9.186.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data fixes. --- For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.187 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.187/ This page contains the following releases for v9.187: * [v9.187](#v9187) * [v9.187.4](#v91874) * [v9.187.3](#v91873) * [v9.187.2](#v91872) * [v9.187.1](#v91871) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.187 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Lending #### `feeDetails` now returned in schedule preview responses The `/loans/schedule:preview` endpoint now correctly returns `feeDetails` in its response, giving integrators full visibility into fee breakdowns when previewing loan schedules. *Internal references:* [LL-5756](https://mambucom.jira.com/browse/LL-5756) #### Groundwork for upcoming features - Building support for advance repayment allocation, enabling loan prepayments to be applied to next instalments without reducing interest (LATAM). - Laying the groundwork for credit (negative) balance support on revolving loan accounts. - Expanding carry-forward balance handling at reschedule and refinance to cover interest accrued under IFA non-decoupled configurations, including UI improvements to hide zero-value carry-forward fields. - Implementing ledger entries to support mortgage account migration. - Introducing initial payment and interest calculation changes for LBS mortgages. - Improving arrears position calculation on loan transactions to support higher-throughput repayment processing. #### Additional work - Internal lending maintenance, refactoring, and tooling improvements. --- ### Islamic Banking #### Broken-period profit and withholding tax visible on proposal details Proposals for term and savings plan deposits with profit sharing now calculate broken-period profit and withholding tax, with the results displayed directly on the proposal details screen at end-of-maturity cycle. *Internal references:* [IB-2816](https://mambucom.jira.com/browse/IB-2816), [IB-2815](https://mambucom.jira.com/browse/IB-2815) #### Groundwork for upcoming features - Building asset/liability cashflow distribution support, including restricting asset GL account selection to ASSET-type accounts. #### Additional work - Internal Islamic Banking maintenance and test infrastructure updates. --- ### Data #### Additional work - Internal data modelling and backend structural work. --- ### Developer #### Additional work - Internal build, module restructuring, and CI tooling changes. --- ## Improvements ### Data #### Parallel file download now supported for deposit accounts The Deposits Accounts download API now supports a `detailsLevel` parameter, enabling parallel file downloads and giving callers control over whether basic or full account details are retrieved — improving throughput for large data exports. *Internal references:* [SCAL-1281](https://mambucom.jira.com/browse/SCAL-1281), [SCAL-1277](https://mambucom.jira.com/browse/SCAL-1277), [SCAL-1244](https://mambucom.jira.com/browse/SCAL-1244) #### Holiday configuration no longer triggers unnecessary account recalculations The `/configuration/holidays.yaml` endpoint now checks whether submitted holiday entries are new before recalculating affected accounts, preventing redundant processing when no new holidays have been added. *Internal references:* [LPRC-5296](https://mambucom.jira.com/browse/LPRC-5296) #### Rate Sheet management APIs now available under v2 New v2 endpoints allow clients to create, retrieve, update, and delete Rate Sheets, and create, get, update, and delete operations are now captured in the activity feed for full auditability. *Internal references:* [DIF-2404](https://mambucom.jira.com/browse/DIF-2404), [DIF-2372](https://mambucom.jira.com/browse/DIF-2372) #### Groundwork for upcoming features - Building the calculation layer for accrued, applied, and advance-payment interest to support interest-applied transaction posting. - Implementing historical balance calculation methods to support an upcoming Historical Balances feature. - Improving Fixed Term Loan repayment throughput with account locking and transaction management, targeting up to 10× TPS capacity. - Laying the groundwork for next-generation transaction processing, including a fix to `TOTAL_BALANCE` delta calculations sourced from savings transaction funds amounts. - Introducing a UI preview step for the upcoming Change Loan Term (add/remove installments) feature. #### Additional work - Internal maintenance covering EOD infrastructure fixes, code ownership assignments, module restructuring, test coverage improvements, feature toggle removals, and other non-customer-facing changes across lending, mortgages, deposits, and cards components. --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data infrastructure maintenance. ### Deposits #### Invalid branch ID now returns a correct error when creating a savings product When creating a new savings product via the API using an ID of a non-existing branch, the system now returns a descriptive HTTP 400 error instead of an HTTP 500 Internal Server Error. *Internal references:* [DO-1657](https://mambucom.jira.com/browse/DO-1657) #### Tier balance bounds can now be set correctly for products with non-standard currency precision Resolved an issue that prevented tier balance bounds from being saved correctly when a deposit product's currency had a different decimal precision than the organisation's base currency. *Internal references:* [DO-1398](https://mambucom.jira.com/browse/DO-1398) #### Current-day transactions no longer fail after a back-dated business date correction Fixed an issue where transactions submitted on the current business day would fail following a back-to-future date adjustment, ensuring uninterrupted processing after date corrections. *Internal references:* [BE-207](https://mambucom.jira.com/browse/BE-207) ### Lending #### Payments on locked accounts now correctly cover all amounts due Resolved an issue where a repayment made while a loan account was locked would not fully cover the outstanding due amount. *Internal references:* [LL-5982](https://mambucom.jira.com/browse/LL-5982) #### Payment holidays no longer break when manual interest is applied Fixed an issue where applying manual interest to a loan account caused payment holidays to fail unexpectedly. *Internal references:* [LL-5975](https://mambucom.jira.com/browse/LL-5975) #### Custom fields on closed loan accounts can now be updated after product availability changes Resolved an issue where updating a custom field on a closed loan account failed if the associated product's availability had changed since the account was closed. *Internal references:* [LL-5799](https://mambucom.jira.com/browse/LL-5799) #### Loan accounts can now be terminated after the repayment schedule has been edited Loan accounts can now be terminated even if the repayment schedule was previously edited with custom due dates. *Internal references:* [LL-4931](https://mambucom.jira.com/browse/LL-4931) #### Ledger batching errors during accrued interest transfer are resolved Fixed cases where a `BATCH_NOT_FOUND_EXCEPTION` or `AccruedAmountsBatchException` was returned during the transfer of accrued interest amounts to the ledger, ensuring daily interest accrual batches complete successfully. *Internal references:* [LPRC-5453](https://mambucom.jira.com/browse/LPRC-5453), [LPRC-5355](https://mambucom.jira.com/browse/LPRC-5355) #### Installment status is now correct after a principal reduction followed by a future rate change Resolved an issue where an installment's status was calculated incorrectly when a principal reduction repayment was followed by a future interest rate change transaction. *Internal references:* [LPRC-5335](https://mambucom.jira.com/browse/LPRC-5335) #### Dynamic Term Loan schedule now recalculates correctly after a Change Terms transaction with an overpayment Fixed a calculation issue affecting Dynamic Term Loan accounts configured with Balloon Payments where the periodic payment had been modified via a **Change Terms** transaction; previously, an overpayment on an installment with zero Principal Due caused the future schedule to use an incorrect periodic payment value. *Internal references:* [LPRC-4654](https://mambucom.jira.com/browse/LPRC-4654) #### Applied payments can now be made on accounts where the amount is not yet due Resolved an issue that prevented a custom applied payment from being processed when the payment amount was not yet due on the account. *Internal references:* [REV-4793](https://mambucom.jira.com/browse/REV-4793) ### Mortgages #### Product cloning is restored Fixed a regression that caused the copy-product (clone) function to fail, allowing mortgage products to be duplicated as expected. *Internal references:* [MTGE-2504](https://mambucom.jira.com/browse/MTGE-2504) #### Interest and fee accrual now calculates correctly after a rate change Resolved an issue where accrued interest and interest on interest-bearing fees were calculated incorrectly following an interest rate change on a mortgage account. *Internal references:* [MTGE-2447](https://mambucom.jira.com/browse/MTGE-2447) #### Total balance on migrated loan accounts is now calculated correctly Fixed an issue where the loan transaction total balance was not computed correctly on accounts that had been migrated into the system. *Internal references:* [MTGE-2389](https://mambucom.jira.com/browse/MTGE-2389) #### Redraw balance is now correctly factored into interest calculations on migrated accounts Resolved an issue where migrated accounts did not account for the redraw balance when calculating interest, leading to incorrect interest amounts. *Internal references:* [MTGE-2383](https://mambucom.jira.com/browse/MTGE-2383) #### Payments toward carried-forward balances no longer incorrectly reduce interest from arrears accrued Fixed an issue where making a payment toward carried-forward balances unexpectedly reduced the **Interest from Arrears Accrued** balance. *Internal references:* [MTGE-2375](https://mambucom.jira.com/browse/MTGE-2375) #### Preview schedule now correctly reflects the redraw balance to be carried forward Resolved an issue where the preview schedule did not include the redraw balance in the carry-forward calculation, causing the displayed schedule to differ from the actual post-reschedule outcome. *Internal references:* [MTGE-2362](https://mambucom.jira.com/browse/MTGE-2362) ### Notifications #### Notification templates using `TRANSACTION` entity filters can now be created and updated via the API Resolved an issue where creating or updating notification templates via the API failed when using `TRANSACTION` entity filters, ensuring that templates created in the UI can be successfully managed through CasC workflows. *Internal references:* [MYM-5045](https://mambucom.jira.com/browse/MYM-5045) ### Islamic Banking #### Broken period cycles are no longer included in previous product cycle aggregations Fixed an issue where a broken period cycle was incorrectly included in the aggregation of a previous product cycle, resulting in inaccurate profit-sharing calculations. *Internal references:* [IB-2836](https://mambucom.jira.com/browse/IB-2836) #### Deposit product configuration is now applied correctly Resolved an issue where deposit product configuration was not being applied correctly in the system, ensuring product settings take effect as intended. *Internal references:* [IB-2740](https://mambucom.jira.com/browse/IB-2740) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.187 cycle. ## v9.187.4 **Release Date**: 03.06.2026 --- ## Bug fixes ### Mortgages #### Transfer transactions correctly excluded from redraw calculations Transfer transactions are no longer incorrectly treated as redraw-type transactions, ensuring redraw balances and eligibility are calculated accurately. *Internal references:* [MTGE-2583](https://mambucom.jira.com/browse/MTGE-2583) --- ## v9.187.3 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to data integrity and deletion handling within the core banking engine. ## v9.187.2 **Release Date**: 03.06.2026 --- ## Bug fixes ### Islamic Banking #### Deposit product configuration now applies correctly in CBE Fixed an issue where deposit product configuration was not being applied correctly in the CBE environment. *Internal references:* [IB-2740](https://mambucom.jira.com/browse/IB-2740) ### Deposits #### Accrued amounts provisioning job now clears data correctly between runs Fixed an issue where the accrued amounts provisioning job retained stale data between successive runs, ensuring accurate provisioning calculations on each execution. *Internal references:* [DO-2093](https://mambucom.jira.com/browse/DO-2093) --- ## v9.187.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data fixes. --- ## Bug fixes ### Mortgages #### Product cloning restored Copying an existing mortgage product now completes successfully. *Internal references:* [MTGE-2504](https://mambucom.jira.com/browse/MTGE-2504) ---

    Database changes

    | Table | Changes | |---|---| | `credit_account` | • Changed data type of column `loan_product_encoded_key` | | `credit_account_history` | • Changed data type of column `loan_product_encoded_key` | | `fse_scheduleversion` | • Added column `VIRTUAL_EVENTS` | | `loan_account_carry_forward_log` | • Added column `migrated_pmt` | | `loan_account_payment_arrangements` | • New table
    • Added index `IDX_LOAN_ACCOUNT_PAYMENT_ARRANGEMENTS_LOAN_ACCOUNT` | | `streaming_subscription` | • New table
    • Added index `idx_streaming_subscription_subscription_id` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.188 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.188/ This page contains the following releases for v9.188: * [v9.188](#v9188) * [v9.188.3](#v91883) * [v9.188.2](#v91882) * [v9.188.1](#v91881) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. ## v9.188 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Improvements ### Data #### Groundwork for upcoming features - Building out the Parallel File Download API for deposit and loan accounts and transactions across sandbox and production environments. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.188 cycle. ## v9.188.3 **Release Date**: 03.06.2026 --- ## Bug fixes ### Lending #### Redraw product repayment schedule recalculation corrected Repayment schedule recalculation now functions correctly for Redraw products, ensuring accurate schedule generation following redraw activity. *Internal references:* [LPRC-5648](https://mambucom.jira.com/browse/LPRC-5648) --- ## v9.188.2 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to the core banking engine's stability and reliability. ## v9.188.1 **Release Date**: 03.06.2026 --- ## Bug fixes ### Mortgages #### Transfer transactions correctly excluded from redraw calculations Transfer transactions are no longer incorrectly treated as redraw-type transactions, ensuring redraw balances and eligibility are calculated accurately. *Internal references:* [MTGE-2583](https://mambucom.jira.com/browse/MTGE-2583) ---

    Database changes

    | Table | Changes | |---|---| | `fse_account` | • Added column `EVENTS` | | `gljournalentry` | • Removed foreign key `GLJOURNALENTRY_FK1`
    • Removed foreign key `GLJOURNALENTRY_FK2`
    • Removed foreign key `GLJOURNALENTRY_IBFK_1`
    • Removed foreign key `USERKEY_FK2` | | `gljournalentryforeignamount` | • Removed foreign key `FK_GLJOURNALENTRYFOREIGNAMOUNT_ACCOUNTINGRATE_ENCODEDKEY`
    • Removed foreign key `FK_GLJOURNALENTRYFOREIGNAMOUNT_GLJOUNALENTRY_ENCODEDKEY` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.189 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.189/ This page contains the following releases for v9.189: * [v9.189](#v9189) * [v9.189.8](#v91898) * [v9.189.7](#v91897) * [v9.189.6](#v91896) * [v9.189.5](#v91895) * [v9.189.4](#v91894) * [v9.189.3](#v91893) * [v9.189.2](#v91892) * [v9.189.1](#v91891) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.191 cycle. ## v9.189 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Lending #### Disbursements beyond the loan limit using Credit Balance When a revolving account has an available **Credit Balance**, users can now disburse amounts exceeding the standard loan limit, unlocking greater flexibility for revolving credit management. *Internal references:* [REV-4920](https://mambucom.jira.com/browse/REV-4920) #### Credit Balance settings surfaced on the Loan Product page When the **Credit Balance** feature is enabled, the Loan Product page now displays Credit Balance settings under the **Repayment Scheduling** section, making configuration more discoverable when updating a revolving account. *Internal references:* [REV-5082](https://mambucom.jira.com/browse/REV-5082) #### Detailed fee and tax tracking per instalment on loan schedules The `/loans/schedule` endpoint now returns `feeDetails` for fixed-term loans, enabling granular tracking of specific fee types and inclusive/exclusive tax amounts per instalment. *Internal references:* [LL-5812](https://mambucom.jira.com/browse/LL-5812) #### Groundwork for upcoming features - Building support for distributing accrued payment holiday interest across future instalments. - Building the advance payment feature for LATAM, covering accounting rules, transaction adjustments, interest-paid postings on reschedule/refinance, and tax handling. - Building short-term payment arrangements (temporary interest-only instalments) for mortgage products. - Building interest rollover configuration to maintain equal instalments when accrued interest exceeds the instalment's total due. - Building payment holiday interest capitalisation, including schedule adjustments and event publishing. - Improving Fixed Term Loan repayment throughput to support higher transaction volumes. #### Additional work - Internal lending refactoring, tooling, and performance improvements. --- ### Mortgages #### Groundwork for upcoming features - Implementing a new PMT calculation formula based on daily periods for Interest-Only Equal Instalment (IOEI) loans, including UI and API updates for loan products and accounts, and restricting repayment periods to monthly. - Enabling PMT formula migration support for Interest Only loans. - Building LBS initial payment and interest calculation changes, including a new boolean parameter on the loan product endpoint and corresponding UI and service-layer enhancements. --- ### Deposits #### Courtesy Pay wallet access via Simple API Deposits and withdrawals via the Simple API can now access the Courtesy Pay wallet, and the READ Deposit API exposes balance details including CourtesyPay-related fields. *Internal references:* [NCU-14](https://mambucom.jira.com/browse/NCU-14), [NCU-822](https://mambucom.jira.com/browse/NCU-822), [NCU-823](https://mambucom.jira.com/browse/NCU-823), [NCU-824](https://mambucom.jira.com/browse/NCU-824) #### Groundwork for upcoming features - Building dynamic balance support for deposit accounts, covering backdated transactions, fee application balance changes, and overdraft handling, all gated behind the `SAVINGS_ACCOUNT_DYNAMIC_BALANCES` feature toggle. - Building Rate Sheet 2.0 with complex marker-based rate lookup and validation. - Building bulk update API support for deposit accounts and credit-interest product feature configuration. - Building Product Feature 2.0 availability controls for deposit products. #### Additional work - Internal deposits modularisation and code compliance work. --- ### Islamic Banking #### Configurable profit approval workflows A new API endpoint enables manual approval of profit proposals, complementing automatic approval for proposals in the `READY_FOR_APPROVAL` state, with profit distribution and pool/product/cashflow cycle closure handled on approval. *Internal references:* [IB-2878](https://mambucom.jira.com/browse/IB-2878), [IB-2875](https://mambucom.jira.com/browse/IB-2875), [IB-2877](https://mambucom.jira.com/browse/IB-2877), [IB-2880](https://mambucom.jira.com/browse/IB-2880), [IB-2906](https://mambucom.jira.com/browse/IB-2906) #### Sharīʿah-compliant profit terminology across the UI The Dashboard, Operations, and Reversals screens now use consistent profit terminology aligned with Sharīʿah-compliant labelling standards. *Internal references:* [IB-2799](https://mambucom.jira.com/browse/IB-2799) --- ### Notifications #### Groundwork for upcoming features - Improving reliability of the Notifications V2 unhappy-path flows on AWS. #### Additional work - Internal notifications maintenance. --- ### Developer #### Groundwork for upcoming features - Building a process orchestration framework, including APIs to upload process definitions, expose and map extension points, and a feature flag to control availability. - Building subscription limit enforcement for the consumer framework. #### Additional work - Internal platform modularisation, enum and datatype restructuring, and code architecture compliance work. - Internal data search and reporting code mapping. --- ### Data #### Search assignment filter restored for Magic Search The Magic Search REST API now correctly applies the assignment filter, restoring expected search behaviour. *Internal references:* [CDO-4420](https://mambucom.jira.com/browse/CDO-4420) --- ## Improvements ### Data #### Filter deposit transactions by account holder When searching deposit transactions via `/deposits/transactions:search`, you can now specify `accountHolderKey` as a filter field using the `EQUALS` or `EQUALS_CASE_SENSITIVE` operators. *Internal references:* [DO-1264](https://mambucom.jira.com/browse/DO-1264) #### Correct JSON response body for 409 and 429 errors The response body for 409 and 429 errors now correctly returns JSON objects across all deposit transaction endpoints, the deposits apply interest endpoint, the deposits and loans accounts search file download endpoints, and all endpoints where an idempotency key is used. *Internal references:* [CFM-150](https://mambucom.jira.com/browse/CFM-150) #### Groundwork for upcoming features - Building the parallel file download API for deposit and loan transactions, including enabling v2 endpoints in development environments and aligning response formats with the existing search API. - Improving the parallel file download API for deposit and loan accounts, including response alignment and query optimisation for loan account key boundary calculations. - Implementing a Deposit Limit Tracking Service to support dynamic balance management for deposit accounts. - Introducing a feature-controlled rounding mechanism for interest applied amounts on deposit accounts. - Updating the Historical Balance API to reflect available balance and implementing the underlying historical balances endpoint. - Laying the groundwork for RateSheet 2.0 by supporting rate sheet account markers in the account execution context. - Advancing the advance payment (pre-payment allocation to next instalments without interest reduction) feature through schedule correctness and code optimisation work. - Introducing a new loan computation module as part of the loan computation framework optimisation initiative. - Extending pool settings with a `manualApprovalEnabled` field to support profit approval configuration. - Adjusting the notifications v2 flow to create notification messages earlier, embedding the notification encoded key in destination settings and archival updates, to enable resend with the original idempotency key. - Adding template filter condition evaluation before outbox insertion to prevent missed or incorrect notifications during asynchronous processing. - Progressing the Revolving module separation (RELOAD Phase 2.1 and 2.2) by integrating multiple loan lifecycle handlers and services with the Revolving submodule. - Optimising Repayments Schedule Versioning (RSV) storage with performance benchmarking for the new serialisation/deserialisation implementation. - Improving the fixed-term loan repayment module by resolving account database locking concurrency limitations to support higher throughput. - Advancing the shadow-run framework with additional logging for skipped scenarios. - Progressing the Deposits EOD transitional architecture to JDBI persistence, including scenario fixes for withholding taxes, multiple fees, overdraft interest, and manual EOD balance correctness. - Applying the **Profit** terminology label across the Islamic Banking dashboard, operations, and reversals UI. #### Additional work - Internal maintenance covering build configuration, code ownership annotations, feature toggle removals, SonarQube remediation, internal class restructuring, test infrastructure updates, logging improvements, API key TTL management, and other non-customer-facing changes across lending, deposits, mortgages, notifications, and platform modules. --- ## Bug fixes ### Lending #### Loan accounts no longer remain in arrears after full repayment Once a loan account balance reaches zero through custom repayments, the account state now correctly transitions out of **In Arrears** immediately. *Internal references:* [LPRC-3925](https://mambucom.jira.com/browse/LPRC-3925) #### Interest rate start dates now display correctly across all regions Corrected a logic error that caused interest rate records to show incorrect dates for users in certain regions, ensuring rate records consistently align with the local calendar date. *Internal references:* [LPRC-1377](https://mambucom.jira.com/browse/LPRC-1377) #### Interest due calculations are now consistent across all months Resolved a calculation error affecting accounts with payments due on the 28th or 29th of the month, ensuring interest and payment amounts remain consistent across all months, including February, and preventing unexpected changes to previously settled installments. *Internal references:* [LPRC-4316](https://mambucom.jira.com/browse/LPRC-4316) #### Eligible new accounts now benefit from corrected interest balance calculation The `COMPUTE_PRINCIPAL_BALANCE_FROM_TRANSACTIONS` fix is now applied at account creation, ensuring all newly created eligible accounts are free from the incorrect interest balance issues previously observed. *Internal references:* [LPRC-5420](https://mambucom.jira.com/browse/LPRC-5420) #### PATCH requests no longer fail due to unrelated product constraint validation Fixed an issue where PATCH requests to update loan accounts incorrectly triggered validation against current loan product constraints for fields not included in the request; validation is now applied only to fields explicitly modified in the API payload. *Internal references:* [LL-5938](https://mambucom.jira.com/browse/LL-5938) #### Arrears settings are now fully replaced when patching a loan account Resolved an issue where the Patch Loan Account API was not correctly updating all fields within `accountArrearsSettings`, such as `toleranceFloorAmount` and `nonWorkingDaysMethod`, ensuring all arrears settings fields are properly replaced during a patch operation. *Internal references:* [LL-5680](https://mambucom.jira.com/browse/LL-5680) #### Interest due is now calculated correctly after payment holidays are reversed Resolved an issue where interest due could be miscalculated after applying payment holidays with RSV enabled, particularly when backdated repayments were present; event ordering and schedule updates are now handled correctly to keep due and paid amounts consistent. *Internal references:* [LL-6015](https://mambucom.jira.com/browse/LL-6015) #### Split interest calculations no longer produce negative interest or incorrect repayment additions Corrected the split interest calculation logic to prevent negative interest values and erroneous repayment addition amounts from being generated. *Internal references:* [LL-6032](https://mambucom.jira.com/browse/LL-6032) #### Additional work - Internal lending test and calculation fixes. --- ### Mortgages #### Custom repayments can now be entered on loans that do not accept prepayments Resolved an issue that prevented users from entering custom repayment amounts on loan accounts configured to not accept prepayments. *Internal references:* [MTGE-2519](https://mambucom.jira.com/browse/MTGE-2519) #### Changing the product during reschedule no longer reduces the outstanding principal Fixed a carry-forward issue where switching the product in the reschedule form incorrectly decreased the displayed current outstanding principal balance. *Internal references:* [MTGE-2502](https://mambucom.jira.com/browse/MTGE-2502) #### Loan accounts no longer accept negative interest rates Resolved an issue where accounts could be configured with negative rate values, ensuring rate inputs are correctly validated. *Internal references:* [MTGE-2501](https://mambucom.jira.com/browse/MTGE-2501) #### Restructured account state values are now correctly formatted in the UI Fixed a display issue where the account state value for restructured accounts was shown unformatted in the user interface. *Internal references:* [MTGE-2495](https://mambucom.jira.com/browse/MTGE-2495) #### Carry Forward Redraw balance field now behaves correctly when controlled by another balance Resolved a UI issue where the **Carry Forward Redraw** balance field remained enabled and read-only when it should have been fully controlled by a linked carry-forward balance setting. *Internal references:* [MTGE-2429](https://mambucom.jira.com/browse/MTGE-2429) #### Accrued interest is no longer duplicated in carry-forward scenarios Fixed an issue where accrued interest was being duplicated during carry-forward processing, ensuring accurate interest balances are maintained. *Internal references:* [MTGE-2376](https://mambucom.jira.com/browse/MTGE-2376) #### Principal balance is now carried forward correctly on subsequent reschedule operations Resolved an issue where the incorrect principal balance was being carried forward during a second reschedule operation, ensuring accurate balances are maintained throughout the reschedule workflow. *Internal references:* [MTGE-2279](https://mambucom.jira.com/browse/MTGE-2279) --- ### Deposits #### Activity tab no longer shows false custom field changes during ownership transfer In the **Activity** tab of a savings account's audit trail, ownership transfers previously displayed misleading messages indicating custom field values had been set to null; this fix ensures those incorrect messages no longer appear. *Internal references:* [DO-2132](https://mambucom.jira.com/browse/DO-2132) #### Unlock account modal now shows the correct post-unlock state Updated the **Unlock Deposit Account** confirmation modal to display the correct new state — **Active** or **Dormant** — based on backend evaluation, fixing cases where dormant accounts incorrectly showed **Active** before being unlocked. *Internal references:* [DO-2060](https://mambucom.jira.com/browse/DO-2060) --- ### Transactions and Interest #### `creditBalanceChangeAmount` is now returned in loan transaction responses The `GET /loans//transactions` response now includes `creditBalanceChangeAmount` within the `affectedAmounts` object for Credit Balance Deposit and Disbursement transactions. *Internal references:* [REV-5203](https://mambucom.jira.com/browse/REV-5203) #### Stamped account balance now reflects the correct balance for backdated transactions Resolved an issue where the stamped account balance displayed an incorrect value when backdated transactions were present. *Internal references:* [BE-211](https://mambucom.jira.com/browse/BE-211) --- ### Notifications #### Custom SMS gateway URLs are now correctly transmitted to the external dispatcher Resolved an issue where custom SMS gateway configurations were not being sent to the microservice during external dispatching, causing notifications to fall back to a hardcoded endpoint and bypass user-defined regional or custom URLs. *Internal references:* [NTF-3717](https://mambucom.jira.com/browse/NTF-3717) #### Streaming notifications now consistently route to the correct Kafka topic Updated the notification streaming service to use a single authoritative destination per template, ensuring consistent message delivery across all streaming notification templates. *Internal references:* [NTF-3654](https://mambucom.jira.com/browse/NTF-3654) --- ### Islamic Banking #### IPS deleteAll API now succeeds for matured accounts Resolved an issue where the IPS `deleteAll` API call failed when the account state was **Matured**. *Internal references:* [IB-2902](https://mambucom.jira.com/browse/IB-2902) #### Effective date entered via the UI is now correctly recognised by the system Fixed an issue where the effective date field populated through the UI was not being recognised during processing. *Internal references:* [IB-2905](https://mambucom.jira.com/browse/IB-2905) #### Asset GL account is now visible in the cash flow settings UI Resolved an issue where the Asset GL account was missing from the **View Cash Flow Settings** screen. *Internal references:* [IB-2892](https://mambucom.jira.com/browse/IB-2892) #### Profit sharing settings changes can now be saved correctly in the savings product UI Fixed a configuration issue that prevented profit sharing settings changes from being applied and saved in the savings product UI. *Internal references:* [IB-2891](https://mambucom.jira.com/browse/IB-2891) #### Product filter by assigned pool is now available in configuration Added a filter allowing products to be listed by the specific pool they are assigned under, improving navigation in configuration screens. *Internal references:* [IB-2869](https://mambucom.jira.com/browse/IB-2869) #### Total asset per income category now uses average daily balance for profit calculation Corrected the profit calculation logic so that total assets per income category are computed using the average daily asset balance over the profit calculation cycle period, in line with IK45 requirements. *Internal references:* [IB-2852](https://mambucom.jira.com/browse/IB-2852) --- ### Cards #### Hold balance settlement logic no longer allows negative balances Resolved a corruption issue in hold balance settlement where the settlement logic could produce negative hold balances, ensuring balance integrity is maintained throughout the settlement process. *Internal references:* [CARDS-2548](https://mambucom.jira.com/browse/CARDS-2548) --- ### Payments #### Idempotency cache no longer stores error responses Fixed an issue where failed or error responses were being cached by the idempotency layer, which could cause subsequent valid requests to incorrectly receive a cached error. *Internal references:* [CFM-290](https://mambucom.jira.com/browse/CFM-290) --- ### Developer #### `creationDate` in Fixed Term Loan API responses now includes timezone information Resolved an issue where the `creationDate` field returned in the Fixed Term Loan API response was missing timezone information, ensuring timestamps are fully ISO-compliant. *Internal references:* [GRAB-232](https://mambucom.jira.com/browse/GRAB-232) #### Reporting menu links no longer trigger a "Feature Unavailable" error Fixed an issue where navigating to reporting menu links incorrectly displayed a **Feature Unavailable** message. *Internal references:* [CDO-4435](https://mambucom.jira.com/browse/CDO-4435) --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.189 cycle. ## v9.189.8 **Release Date**: 03.06.2026 --- ## Features ### Deposits #### Courtesy Pay balance details now visible via the Deposits API Simple API deposits and withdrawals can now access the Courtesy Pay wallet, and the Read Deposit API response includes Courtesy Pay-related balance detail fields. *Internal references:* [NCU-822](https://mambucom.jira.com/browse/NCU-822) --- ## v9.189.7 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data maintenance and configuration fixes. --- ## v9.189.6 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Internal sandbox configuration changes. --- ## Improvements ### Data #### Additional work - Internal data performance and scaling optimisations. --- ## v9.189.5 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to the data access layer of the Cards module, enhancing the platform's overall stability and long-term maintainability. ## v9.189.4 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to platform stability and backwards compatibility of core product configuration data structures. ## v9.189.3 **Release Date**: 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data configuration changes. --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration fixes. --- ## v9.189.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration and infrastructure changes. --- ## Bug fixes ### Data #### Redraw product repayment schedule values now calculate correctly Repayment schedule values (RSV) for Redraw products now function correctly, ensuring accurate schedule calculations for these product types. *Internal references:* [LPRC-5648](https://mambucom.jira.com/browse/LPRC-5648) #### Event application now correctly populates event columns The events column is now properly populated when applying events, preventing missing data in event records. *Internal references:* [FSE-920](https://mambucom.jira.com/browse/FSE-920) --- ## v9.189.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data configuration and infrastructure changes. ---

    Database changes

    | Table | Changes | |---|---| | `MESSAGEQUEUEITEMINTENT` | • New table
    • Added index `IDX_MSG_QUEUE_INTENT_TENANT_CREATED` | | `credit_account` | • Column `statement_date` now allows NULL | | `extension_point_process` | • New table
    • Added index `uq_extension_point_process_proc_def_id_ext_pt_name` | | `ips_pool_calculation_cycle` | • Added column `MANUAL_APPROVAL_ENABLED` | | `ips_pool_settings` | • Added column `MANUAL_APPROVAL_ENABLED` | | `loan_account_payment_arrangements` | • Added column `instalment_index_start`
    • Added column `instalment_index_end`
    • Removed column `instalment_ids` | | `ratesheet` | • Added index `idx_rate_sheet_schema_id` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.190 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.190/ This page contains the following releases for v9.190: * [v9.190](#v9190) * [v9.190.4](#v91904) * [v9.190.3](#v91903) * [v9.190.2](#v91902) * [v9.190.1](#v91901) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.191 cycle. ## v9.190 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Data #### Additional work - Non-customer-facing data maintenance and internal code changes. --- ### Mortgages #### Edit the principal of the current installment on Dynamic Mortgages Users can now edit the principal amount of the current installment on Dynamic Mortgage accounts, providing greater flexibility to manage repayment schedules in real time. *Internal references:* [MTGE-2657](https://mambucom.jira.com/browse/MTGE-2657) #### Payment holiday term settings visible at account level The account details view now displays whether a payment holiday is configured to extend the loan term or keep the term the same, giving users clear visibility into how payment holidays affect the schedule. *Internal references:* [MTGE-2150](https://mambucom.jira.com/browse/MTGE-2150) #### Interest rollover displayed accurately on Dynamic Mortgage accounts The **Interest Rollover** field is now shown only on Dynamic Mortgage accounts and only when the rollover amount is non-zero, eliminating irrelevant data from other account types and improving clarity in the UI. *Internal references:* [MTGE-2611](https://mambucom.jira.com/browse/MTGE-2611), [MTGE-2189](https://mambucom.jira.com/browse/MTGE-2189) #### Maintained payment amount setting visible in loan account details The **MaintainPMTOnFirstInstallment** selection is now surfaced in loan account details, so users can confirm at a glance whether the original payment amount is being preserved following a reschedule or refinance. *Internal references:* [MTGE-2619](https://mambucom.jira.com/browse/MTGE-2619) #### Groundwork for upcoming features - Building API paths to support Short Term Payment Arrangements (temporary interest-only instalments) for mortgages. - Laying the groundwork for capitalised payment holiday interest handling, including accounting treatment for interest accrued during a payment holiday. --- ### Deposits #### Groundwork for upcoming features - Advancing next-generation backdated transaction processing, including handling of backdated withdrawals with subsequent transactions and insufficient-funds rejection logic. - Building the repository and foundation for a Generic Interest Product Feature (V2). - Integrating an internal process orchestrator (Flowable BPM) to handle complex business rules — such as Mexican Deposit Limit Validation — dynamically without code redeploys. #### Additional work - Internal deposits module restructuring and non-customer-facing maintenance. --- ### Cards #### Groundwork for upcoming features - Updating the Cards API to use the new available balance service for revolving loan accounts, and building core account-opening skeleton and credit limit product feature for credit card products. --- ### Islamic Banking #### Profit terminology applied consistently across the UI Shari'ah-compliant **Profit** terminology is now used consistently across account opening, overdraft terms, product configuration, accounting rules, the account transactions tab, and the product change confirmation popup, ensuring a fully compliant and coherent experience for Islamic Banking users. *Internal references:* [IB-2911](https://mambucom.jira.com/browse/IB-2911), [IB-2910](https://mambucom.jira.com/browse/IB-2910), [IB-2798](https://mambucom.jira.com/browse/IB-2798), [IB-2797](https://mambucom.jira.com/browse/IB-2797) #### Profit accrual paused when the latest exchange rate is unapproved The system no longer accrues profit when the most recent exchange rate has not been approved, preventing inaccurate profit calculations from flowing through to accounts. *Internal references:* [IB-2881](https://mambucom.jira.com/browse/IB-2881) #### Groundwork for upcoming features - Scoping and limiting UI configuration options to those required for the first delivery of common deposit functions for Islamic products and accounts. --- ### Developer #### Selected client-specific API endpoints removed from public documentation Four deposit-related endpoints specific to a single institution are no longer listed on the public API documentation site, keeping the published API surface accurate and relevant for all developers. *Internal references:* [BE-214](https://mambucom.jira.com/browse/BE-214) #### Groundwork for upcoming features - Building offset validation for the Streaming API consumer cursor-commit flow under the new AWS architecture. #### Additional work - Internal code-ownership annotations and activity log fixes. --- ## Improvements ### Data #### `detailsLevel` support added to the Loan Accounts download API The Loan Accounts download API now supports the `detailsLevel` parameter, giving clients control over the verbosity of data returned in file downloads. *Internal references:* [SCAL-1247](https://mambucom.jira.com/browse/SCAL-1247) #### Rounding type now visible in the deposit product UI The product overview screen now displays the rounding type configured for withholding tax application and interest application, making rounding policy settings directly visible without requiring API inspection. *Internal references:* [DIF-2601](https://mambucom.jira.com/browse/DIF-2601) #### Deposit rounding policy configurable per product A dedicated rounding policy feature has been implemented for deposit products, enabling institutions to configure interest calculation rounding behaviour (including round-down) at the product level. *Internal references:* [DIF-2587](https://mambucom.jira.com/browse/DIF-2587) #### Decommissioned API V1 now returns the correct HTTP status code The decommissioned API V1 endpoint now returns HTTP `410 Gone` instead of `500 Internal Server Error`, giving integrators a clear and standards-compliant signal that the resource has been permanently removed. *Internal references:* [CFM-512](https://mambucom.jira.com/browse/CFM-512) #### Renamed carried-forward interest accrued fields for terminology consistency The fields `carriedForwardInterestAccruedBalance` and `carriedForwardInterestFromArrearsAccruedBalance` have been renamed to `carriedForwardInterestAccrued` and `carriedForwardInterestFromArrearsAccrued` respectively, aligning API terminology for carry-forward balances used during refinance and reschedule operations on Dynamic Mortgage and Interest Only Equal Instalment products. *Internal references:* [MTGE-2516](https://mambucom.jira.com/browse/MTGE-2516) #### Groundwork for upcoming features - Optimised loan account queries and standardised endpoint paths to support the parallel file download API for deposit and loan accounts. - Implementing core engine state and session management for incremental loan computation. - Extending dynamic balances for Mexican deposits with Month-To-Date calculation repository queries and account execution context exposure. - Building out the new Streaming API architecture on AWS, including a `/stats` publisher endpoint. - Groundwork to support repayment fee details in the new repayment flow. - Implementing PMT calculation logic with `maintainPmtOnFirstInstalment` support for mortgage reschedule and refinance operations. - Extending Islamic product settings with a weightage parameter. - Advancing advance payment compatibility verification and display/validation fixes for the LATAM pre-payment allocation feature. - Improving SSO branch behaviour in the configuration service. - Preparing skills and commands for AI-assisted loan schedule analysis tooling. - Migrating big tenants to horizontal EOD workers and introducing execution context improvements to reduce SQL load during lending end-of-day processing. - Modularising the EOD domain with new module structure and enum migrations. #### Additional work - Internal backend refactoring, modularisation, annotation, and test coverage work across lending, deposits, cards, EOD, and core platform modules. --- ### Notifications #### Additional work - Internal notifications logging maintenance. --- ### Lending #### Groundwork for upcoming features - Revolving credit product maintenance, including removal of unimplemented features carried over from Dynamic Term Loans and fee performance optimisation enablement. - Refining available loan balance retrieval to use the lending available balance facade in support of partial and full refund flows. #### Additional work - Internal revolving credit serialisation improvements and test additions. --- ### Mortgages #### Additional work - Internal mortgage architecture work, including migration of product enums to the lending-common module. --- ### Cards #### `transactionType` added to cards financial transaction responses The cards financial transaction DTO now includes the `transactionType` field, giving integrators richer context on each transaction returned through the Cards API. *Internal references:* [CARDS-2555](https://mambucom.jira.com/browse/CARDS-2555) #### Additional work - Internal Cards codebase ownership and configuration maintenance. --- ## Bug fixes ### Deposits #### Transfer Account Ownership permission now enforced consistently in the UI Users without the `MANAGE_DEPOSIT_ACCOUNT_RECIPIENT` permission can no longer access the **Transfer account ownership** menu item in the UI, bringing the interface into alignment with the existing API-level permission check. *Internal references:* [DO-2094](https://mambucom.jira.com/browse/DO-2094) #### Authorization Hold API response corrected The `balances` property is now consistently returned in Authorization Hold API responses, resolving an omission that caused incomplete data to be surfaced. *Internal references:* [DO-1297](https://mambucom.jira.com/browse/DO-1297) #### Savings Product description field protected against XSS User-provided content in the Savings Product description field is now properly HTML-encoded using industry-standard OWASP techniques, preventing potential Cross-Site Scripting (XSS) attacks. *Internal references:* [DO-1217](https://mambucom.jira.com/browse/DO-1217) #### Overdraft interest rate change behaviour made consistent Resolved an inconsistency in how overdraft interest rate changes were applied, ensuring predictable and uniform behaviour across affected accounts. *Internal references:* [DO-471](https://mambucom.jira.com/browse/DO-471) #### Additional work - Non-customer-facing deposits maintenance. --- ### Lending #### Loan search by settlement account now returns accurate results Resolved an issue where the `settlementAccountKey` filter on `POST /api/loans:search` was incorrectly matching any loan with a settlement account rather than filtering by the specific key provided; results now precisely match the supplied account key. *Internal references:* [CFM-294](https://mambucom.jira.com/browse/CFM-294) #### New `hasSettlementAccount` filter for loan searches A new boolean filter field, `hasSettlementAccount`, is available on `POST /api/loans:search`, allowing you to quickly segment your loan portfolio by whether a settlement account is linked (`true`) or not (`false`). *Internal references:* [CFM-294](https://mambucom.jira.com/browse/CFM-294) #### DateTime BETWEEN filter for custom fields now works correctly Resolved an issue where `BETWEEN` date-time filters applied to custom fields returned incorrect or unexpected results. *Internal references:* [CFM-44](https://mambucom.jira.com/browse/CFM-44) #### Redraw-enabled loans now include custom principal in interest rate calculations Fixed an issue where the Interest Rate Calculation (IRC) did not account for custom principal amounts when the redraw feature was enabled, resulting in incorrect rate computations. *Internal references:* [LPRC-5591](https://mambucom.jira.com/browse/LPRC-5591) #### Split interest calculation corrected for edge-case conditions Resolved an issue where split interest was calculated incorrectly under certain loan conditions, ensuring accurate interest amounts are applied. *Internal references:* [LL-6095](https://mambucom.jira.com/browse/LL-6095) --- ### Mortgages #### Accrued interest calculated correctly on Interest Only loans with carried-forward amounts during external migration Fixed an issue where accrued interest was not correctly computed for Interest Only loans that carried forward amounts during external migration, ensuring accurate interest balances post-migration. *Internal references:* [MTGE-2520](https://mambucom.jira.com/browse/MTGE-2520) #### AIR loan accounts can no longer be created with a custom `validFrom` timestamp A validation has been added to prevent users from creating Adjustable Interest Rate (AIR) loan accounts with a custom `validFrom` timestamp, avoiding potential data integrity issues. *Internal references:* [MTGE-2487](https://mambucom.jira.com/browse/MTGE-2487) #### Interest from arrears correctly reset to zero on backdated repayments with payment holidays Fixed an issue where interest accrued from arrears was not being set to zero on loans with a principal and interest (PH) installment schedule when a backdated repayment was made after the late installment due date. *Internal references:* [MTGE-2480](https://mambucom.jira.com/browse/MTGE-2480) #### Carried-forward and migrated interest accrued now correctly considered during payment holidays Resolved an issue where carried-forward or migrated interest accrued amounts were not factored into calculations during payment holiday periods, leading to incorrect outstanding balances. *Internal references:* [MTGE-2370](https://mambucom.jira.com/browse/MTGE-2370) #### Payment holiday can no longer be incorrectly removed after holiday interest has been applied Fixed an issue where a keep-same-term loan payment holiday could be removed after payment holiday interest had already been applied, which could result in inconsistent schedule and interest data. *Internal references:* [MTGE-562](https://mambucom.jira.com/browse/MTGE-562) #### Additional work - Internal mortgage interest computation fixes. --- ### Notifications #### Notification template creation with unconstrained event filters no longer fails Resolved an issue where creating notification templates containing events without filter constraints incorrectly triggered a validation error, preventing template creation. *Internal references:* [MYM-5130](https://mambucom.jira.com/browse/MYM-5130) --- ### Credit Arrangements #### `PATCH /principalPaymentSettings/amount` no longer returns error 460 on revolving accounts Fixed an issue where patching the principal payment settings amount on a revolving credit arrangement incorrectly returned error code `460` (`INVALID_REVOLVING_SETTINGS`). *Internal references:* [REV-5321](https://mambucom.jira.com/browse/REV-5321) --- ### Accounting #### Accounting Interest Accrual Search now handles `creationDate` offset correctly Resolved an issue where the `creationDate` offset was handled incorrectly when searching Accounting Interest Accrual records by creation date, ensuring search results reflect the intended date range. *Internal references:* [LED-2791](https://mambucom.jira.com/browse/LED-2791) --- ### Islamic Banking #### Profit sharing calculation corrections across multiple scenarios Resolved multiple issues affecting profit sharing calculations, including: incorrect effective rate computations; incorrect unpaid profit amounts on maturity for fixed deposit accounts with payment on maturity; accounts activated within the current pool cycle no longer incorrectly receiving profit; maturity date no longer included in profit calculations; broken-period profit now correctly paid on the maturity date rather than the last profit payment date; and fixed day-of-month values now correctly used as the profit payment cycle start date. *Internal references:* [IB-2922](https://mambucom.jira.com/browse/IB-2922), [IB-2921](https://mambucom.jira.com/browse/IB-2921), [IB-2920](https://mambucom.jira.com/browse/IB-2920), [IB-2918](https://mambucom.jira.com/browse/IB-2918), [IB-2913](https://mambucom.jira.com/browse/IB-2913), [IB-2853](https://mambucom.jira.com/browse/IB-2853) #### Profit sharing products page error resolved Fixed an issue that caused a "Something went wrong" error to appear on the profit sharing products page. *Internal references:* [IB-2912](https://mambucom.jira.com/browse/IB-2912) #### Internal API error on profit sharing requests resolved Resolved an issue where certain API requests returned a `6-internal_error` response, restoring reliable API behaviour for affected operations. *Internal references:* [IB-2903](https://mambucom.jira.com/browse/IB-2903) #### `Use calculated rate` can now be configured without a fixed rate percentage Fixed an issue where attempting to configure the **Use calculated rate** option via the API failed when no fixed rate percentage was provided, allowing the option to be set as intended. *Internal references:* [IB-2888](https://mambucom.jira.com/browse/IB-2888) #### Cashflow creation via API now validates data correctly Resolved an issue where creating cashflows through the API allowed malformed or inconsistent data to be persisted, ensuring only valid cashflow configurations are accepted. *Internal references:* [IB-2846](https://mambucom.jira.com/browse/IB-2846) #### Cashflow editing no longer blocked when no Cashflow Settings exist Fixed an issue where editing a cashflow was not possible when no Cashflow Settings had been configured, restoring the ability to manage cashflows in this state. *Internal references:* [IB-2845](https://mambucom.jira.com/browse/IB-2845) --- ### Developer #### Additional work - Non-customer-facing loan batch metric and internal DTO maintenance. --- ## v9.190.4 **Release Date**: 03.06.2026 --- ## Features ### Deposits #### Courtesy Pay balance details now visible via the Deposits API Simple API deposits and withdrawals can now access the Courtesy Pay wallet, and the Read Deposit API response includes Courtesy Pay-related balance detail fields. *Internal references:* [NCU-823](https://mambucom.jira.com/browse/NCU-823) --- ## v9.190.3 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data configuration fixes. --- ## v9.190.2 **Release Date**: 03.06.2026 --- This release contains the following: * Internal maintenance improvements to cloud storage upload reliability and stability for large-scale database operations. ## v9.190.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing infrastructure maintenance. --- ## Bug fixes ### Lending #### Overpayment handling corrected for balloon payment accounts Resolved an issue affecting overpayment scenarios on deferred balloon payment accounts with RNI and ILI interest configurations. *Internal references:* [LPRC-5592](https://mambucom.jira.com/browse/LPRC-5592) --- For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.191 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.191/ This page contains the following releases for v9.191: * [v9.191](#v9191) * [v9.191.6](#v91916) * [v9.191.5](#v91915) * [v9.191.4](#v91914) * [v9.191.3](#v91913) * [v9.191.2](#v91912) * [v9.191.1](#v91911) **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications. [Database changes](#database-changes) ## v9.191 **Release Dates** * **Sandbox:** 03.06.2026 --- ## Features ### Deposits #### Rounding configuration for deposit product interest calculation The deposit product UI now includes a rounding configuration option, allowing institutions to define how interest calculations are rounded — supporting requirements such as round-down behaviour for Japanese markets. *Internal references:* [DIF-2540](https://mambucom.jira.com/browse/DIF-2540) #### Groundwork for upcoming features - Building next-generation transaction processing with backdating support, including `PROFIT_APPLIED` batch handling and `TRANSFER` transaction validation during backdating. - Laying the foundation for a Generic Interest Product feature, including caching improvements and multi-tenant cache integrity verification. ### Cards #### Retrieve credit account information by ID A new GET API endpoint enables retrieval of credit account details by account ID, giving integrators direct programmatic access to credit account data. *Internal references:* [CCD-123](https://mambucom.jira.com/browse/CCD-123) #### Dynamic balances created on new credit account opening Dynamic balances are now automatically created at the account level when a new credit account is opened, ensuring accurate balance tracking from account inception. *Internal references:* [CCD-119](https://mambucom.jira.com/browse/CCD-119) #### Credit limit configuration at the account level Credit limits can now be configured individually at the credit account level, providing greater flexibility in managing per-account exposure within a credit card product. *Internal references:* [CCD-60](https://mambucom.jira.com/browse/CCD-60) #### Groundwork for upcoming features - Building the ability to activate loan products via API as part of the revolving credit account infrastructure. ### Payments #### Advance Payment support for Interest Rate Change transactions Loan accounts using **Optimised Payments** now correctly handle **Interest Rate Change** transactions made after an advance payment has been processed. *Internal references:* [LPRC-5752](https://mambucom.jira.com/browse/LPRC-5752) #### Regular RNI transaction posting after advance payment processing Regular **RNI** (Repayment of Next Instalment) transactions are now correctly posted following the processing of an advance payment, ensuring payment sequencing remains accurate. *Internal references:* [LPRC-5578](https://mambucom.jira.com/browse/LPRC-5578) #### Groundwork for upcoming features - Continuing Phase 2 of the Advance Payment feature, adding support for split interest, planned fees, PMT fees, and UI changes to complete the advance payment workflow. #### Additional work - Internal removal of a deprecated feature toggle from the payments codebase. ### Mortgages #### Enable or disable payment arrangements at the product level Lenders can now configure whether payment arrangements are permitted on a mortgage product, with a new UI and API option to enable or disable this capability at the product level. *Internal references:* [MTGE-2395](https://mambucom.jira.com/browse/MTGE-2395) #### Custom payment amount per instalment in flexible schedule engine The flexible schedule engine now supports configuring a custom PMT (payment amount) per instalment, enabling more granular control over repayment schedules. *Internal references:* [MTGE-2696](https://mambucom.jira.com/browse/MTGE-2696) #### Improved error handling during restructure with Maintain PMT When a restructure operation with **Maintain PMT** results in a minimum instalment count error, the UI now surfaces a clear, actionable error message rather than failing silently. *Internal references:* [MTGE-2688](https://mambucom.jira.com/browse/MTGE-2688) #### Configure and enable unapplied funds on loan products Lenders can now enable unapplied funds on a loan product and configure the associated accounting treatment, supporting end-of-term redemption scenarios where the payment received exceeds the outstanding balance. *Internal references:* [MTGE-2663](https://mambucom.jira.com/browse/MTGE-2663), [MTGE-2662](https://mambucom.jira.com/browse/MTGE-2662) #### Preview schedule API now supported on mortgage products The Preview Schedule API is now available for mortgage products, allowing lenders and integrators to simulate repayment schedules before committing to a loan structure. *Internal references:* [MTGE-2716](https://mambucom.jira.com/browse/MTGE-2716) #### Groundwork for upcoming features - Registering the `FLEXIBLE_REPAYMENT_MORTGAGE` feature in preparation for the Payment Schedule MVP for Australia and New Zealand. - Implementing interest rollover logic — including rate change threshold handling and schedule preview computation — to keep instalments equal when accrued interest exceeds the instalment's total due. - Introducing the unapplied funds feature toggle as the enabling mechanism for the unapplied funds configuration. #### Additional work - Internal modularisation work moving lending interfaces, enums, and types from the monolith to shared lending-common modules. ### Islamic Banking #### Profit terminology applied to Line of Credit transactions **Profit**-based terminology is now consistently applied across Line of Credit transactions, aligning the product display with Shari'ah-compliant labelling standards. *Internal references:* [IB-2943](https://mambucom.jira.com/browse/IB-2943) #### Weightage-based profit rate used in product profit distribution Profit distribution at the account level now uses the product profit rate derived from weightage settings, ensuring that profit sharing calculations correctly reflect the configured product weightage parameters. *Internal references:* [IB-2935](https://mambucom.jira.com/browse/IB-2935), [IB-2934](https://mambucom.jira.com/browse/IB-2934) ### Notifications #### EOD completion notifications now include result details End-of-day completion notification templates have been updated to include EOD result details, giving operations teams richer context directly within the notification. *Internal references:* [EOD-693](https://mambucom.jira.com/browse/EOD-693) ### Deposits (Courtesy Pay) #### Courtesy Pay account limit override enforcement The **Courtesy Pay** account limit now starts at $0 and can only be set above the product-level limit when the designated override flag is enabled, preventing unintended limit breaches. *Internal references:* [NCU-136](https://mambucom.jira.com/browse/NCU-136) #### Courtesy Pay settings visible in account details **Courtesy Pay** account settings are now displayed at the account level, giving staff immediate visibility of Courtesy Pay configuration without navigating away from the account. *Internal references:* [NCU-122](https://mambucom.jira.com/browse/NCU-122) #### Additional work - Internal refactoring and legacy cleanup within the flexible schedule engine, including threshold removal and interest accrual field updates. --- ## Improvements ### Data #### Holiday rescheduling now handles non-disbursed loans with past repayment dates Resolved an issue where adding an organisational holiday would fail if a non-disbursed loan account had a first repayment date in the past. The system now falls back to using the account creation date to successfully reschedule these loans without interrupting the batch process; this behaviour is controlled by the `USE_ACCOUNT_CREATION_DATE_AS_ACTIVATION_DATE_FALLBACK_FOR_PREACTIVE_LOANS` feature toggle. *Internal references:* [LL-6099](https://mambucom.jira.com/browse/LL-6099) #### Additional work - Internal maintenance, infrastructure, and non-customer-facing technical improvements across data and platform services. --- ## Bug fixes ### Mortgages #### Carry-forward interest accrual corrected for dynamic and interest-only loans Accrued interest from arrears is now correctly calculated for both dynamic mortgage loans and interest-only loans that use carried-forward balances, preventing understated arrears figures on affected accounts. *Internal references:* [MTGE-2706](https://mambucom.jira.com/browse/MTGE-2706), [MTGE-2523](https://mambucom.jira.com/browse/MTGE-2523) #### Capitalized interest now correctly reflected in accounting for carry-forward loans Capitalized interest on loans using carried-forward balances is now properly posted to accounting, ensuring the general ledger accurately reflects all capitalized amounts. *Internal references:* [MTGE-2648](https://mambucom.jira.com/browse/MTGE-2648) #### Correct interest applied after a prepayment on a payment holiday installment due date An incorrect interest applied transaction that appeared after a prepayment was made on the due date of a payment holiday installment has been resolved, ensuring accurate interest distribution on the repayment schedule. *Internal references:* [MTGE-2477](https://mambucom.jira.com/browse/MTGE-2477) #### Prepayment calculation method now respected for repayments with custom values and principal overpayment Repayments that include custom values alongside a principal overpayment now correctly honour the selected prepayment calculation method, preventing miscalculated schedules on affected mortgage accounts. *Internal references:* [MTGE-2741](https://mambucom.jira.com/browse/MTGE-2741) --- ### Lending #### Interest rate changes no longer affect already-paid installments When an interest rate change is applied with an effective date before a paid installment, the recalculation now correctly targets only pending or partially paid installments, preventing unintended modifications to installments already settled through multiple **Reduce Amount per Installment** overpayments. *Internal references:* [LPRC-5629](https://mambucom.jira.com/browse/LPRC-5629) #### Installment status no longer reverts after a custom principal repayment Installments marked as **Paid** under the **Principal Expected is Paid** setting no longer revert to **Partially Paid** after a custom principal repayment is posted, ensuring installment statuses remain stable once the payment obligation for a period is met. *Internal references:* [LPRC-5620](https://mambucom.jira.com/browse/LPRC-5620) #### Interest rate adjustments no longer recalculate installments settled via advance payments Resolved an issue where interest rate adjustments incorrectly recalculated installments already settled via advance payments, ensuring accurate loan schedules and consistent repayment tracking for accounts using optimized payment configurations. *Internal references:* [LPRC-5820](https://mambucom.jira.com/browse/LPRC-5820) #### Planned fees now included in total expected schedule amount When generating loan account documents, planned fees were incorrectly excluded from the `SCHEDULE_TOTAL_EXPECTED` amount; they are now included, ensuring the displayed total accurately reflects all amounts owed. *Internal references:* [LPRC-5432](https://mambucom.jira.com/browse/LPRC-5432) #### Editing and deleting loan accounts with planned fees no longer fails Editing or deleting a loan account that had planned fees associated with it failed unexpectedly due to planned fees not being properly handled before the operation completed; this has now been resolved. *Internal references:* [LPRC-4506](https://mambucom.jira.com/browse/LPRC-4506) #### Repayment posting no longer fails due to already-applied planned fees Posting a repayment to certain accounts failed because planned fees that had already been applied were being incorrectly reapplied during repayment processing; this has now been corrected. *Internal references:* [LPRC-4267](https://mambucom.jira.com/browse/LPRC-4267) #### Late repayment fees now correctly reflected in the repayment schedule For certain loan accounts, late repayment fees applied to installments were not correctly reflected in the repayment schedule, causing end-of-day jobs to fail; this has been resolved. *Internal references:* [LPRC-5075](https://mambucom.jira.com/browse/LPRC-5075) #### Incorrect first installment date corrected for schedules using last day of month The first installment date is now calculated correctly for loan schedules configured to fall on the last day of the month, preventing off-by-one date errors on new accounts. *Internal references:* [REV-5242](https://mambucom.jira.com/browse/REV-5242) #### Refinance API now returns the correct error when a duplicate loan account ID is submitted The Refinance API V2 now returns a `DUPLICATE_LOAN_ACCOUNT_ID` error instead of a generic `INTERNAL_ERROR` when a loan account ID that already exists is provided, making integration error handling more precise. *Internal references:* [LL-6140](https://mambucom.jira.com/browse/LL-6140) #### Loan account ID generation failures now return a clear error When loan account ID generation fails, the system now returns a specific, actionable error rather than a generic message, improving diagnostic clarity for integrations. *Internal references:* [LL-6079](https://mambucom.jira.com/browse/LL-6079) #### Incorrect tax source value for loan product fees no longer displayed in the UI The UI now correctly displays the tax source value for loan product fees, resolving a mismatch between the stored configuration and what was shown on screen. *Internal references:* [LL-5795](https://mambucom.jira.com/browse/LL-5795) #### "Terminate Loan Accounts" permission now visible and assignable for API-only roles Administrators can now grant the **Terminate Loan Accounts** permission to API-only roles, enabling secure, granular access control for integrations without requiring unnecessary UI access. *Internal references:* [LL-5791](https://mambucom.jira.com/browse/LL-5791) #### `GET /installments` now correctly enforces branch permissions for API consumers The `GET /installments` endpoint previously ignored branch-level permissions for API consumers; it now correctly applies those restrictions, ensuring consistent access control across UI and API. *Internal references:* [LL-5685](https://mambucom.jira.com/browse/LL-5685) #### Calling `previewPayOffAmounts` with the wrong HTTP method now returns the correct error Calling `GET /loans/:previewPayOffAmounts` previously returned a misleading `INVALID_LOAN_ACCOUNT_ID` error; it now correctly returns `405 Method Not Allowed` when the endpoint is called with an unsupported HTTP method. *Internal references:* [LL-5085](https://mambucom.jira.com/browse/LL-5085) #### Loan search with multiple sub-states now returns repaid accounts correctly When searching for loans using the `accountSubState` filter with multiple values, loans in the `REPAID` sub-state were previously omitted from results; this has been fixed so all matching sub-states are returned as expected. *Internal references:* [LL-4548](https://mambucom.jira.com/browse/LL-4548) #### Refinancing now validates that top-up amount matches currency settings Attempting to refinance a loan with a `topUpAmount` that does not conform to the account's currency precision settings is now correctly rejected, preventing invalid refinancing operations. *Internal references:* [LL-4860](https://mambucom.jira.com/browse/LL-4860) #### Document visibility for loan products now correctly respects user permissions Users without permission to view, edit, or delete documents for loan products can no longer access those documents via the loan account **Documents** menu, closing an unintended permission bypass. *Internal references:* [LL-2856](https://mambucom.jira.com/browse/LL-2856) #### `PATCH` loan no longer triggers an incorrect securities permission check on unrelated field updates Updating loan fields unrelated to securities no longer incorrectly triggers a securities permission check, preventing spurious permission errors for users who do not hold securities-related permissions. *Internal references:* [LL-6017](https://mambucom.jira.com/browse/LL-6017) #### Fixed-term loans now correctly transition to `ACTIVE_IN_ARREARS` with manual interest application on due date Fixed-term loan accounts configured with **Manual Interest Application on Due Date** now correctly transition to the `ACTIVE_IN_ARREARS` state when a payment is missed, ensuring arrears processing behaves as expected. *Internal references:* [LL-5957](https://mambucom.jira.com/browse/LL-5957) #### `POST /creditArrangements:search` now supports filtering by last modified date A `lastModifiedDate` filter has been added to `POST /creditArrangements:search`, allowing API consumers to retrieve only credit arrangements modified within a specified date range. *Internal references:* [LL-5852](https://mambucom.jira.com/browse/LL-5852) #### `/loanproducts` V2 API now returns all expected fields A previously missing field has been added to the `/loanproducts` V2 API response, ensuring integrations receive complete product configuration data. *Internal references:* [LL-5718](https://mambucom.jira.com/browse/LL-5718) #### Prepayment schedules now calculated correctly when using `INCREASE_LAST_INSTALLMENT` Making prepayments on loans configured with the `INCREASE_LAST_INSTALLMENT` late payment calculation setting no longer produces an incorrect repayment schedule or an inflated total repayment amount, ensuring accurate loan balances and payment projections. *Internal references:* [LL-5747](https://mambucom.jira.com/browse/LL-5747) #### Additional work - Non-customer-facing lending maintenance. --- ### Islamic Banking #### Broken-period profit calculation on the proposal page now uses the correct average balance The proposal page now uses the correct account average balance when calculating broken-period profit, preventing inaccurate profit estimates from being shown before account activation. *Internal references:* [IB-2916](https://mambucom.jira.com/browse/IB-2916) #### Extra payment cycles no longer created when cycle alignment differs from product cycle An issue where an additional account payment cycle was incorrectly created when the payment cycle was not aligned with the product cycle has been resolved, ensuring cycle counts remain accurate. *Internal references:* [IB-2889](https://mambucom.jira.com/browse/IB-2889) #### Accrued profit for the last day of a cycle is now correctly adjusted Accrued profit applied for the final day of a profit cycle is now correctly adjusted during end-of-day processing, preventing over- or under-accrual on closing entries. *Internal references:* [IB-2698](https://mambucom.jira.com/browse/IB-2698) #### Additional work - Non-customer-facing Islamic Banking fixes. --- ### Deposits #### Manual interest application no longer generates interest for periods with a zero-rate tier Manually applying interest on an account that had a zero interest rate tier for an extended period no longer incorrectly generates interest applications covering that entire period, ensuring only the applicable rate periods are processed. *Internal references:* [DO-742](https://mambucom.jira.com/browse/DO-742) --- ### Data #### Deleting multiple grouped custom fields via API V2 no longer disrupts ordering or removes incorrect data Deleting multiple grouped custom fields in a single API V2 call now correctly preserves the ordering sequence of remaining fields and removes only the intended records, preventing data loss on bulk delete operations. *Internal references:* [CFM-43](https://mambucom.jira.com/browse/CFM-43) #### Transaction channel creation now validates `usageRights` Validation has been added for the `usageRights` field when creating a transaction channel, ensuring only permitted values are accepted and preventing misconfigured channels from being saved. *Internal references:* [CFM-42](https://mambucom.jira.com/browse/CFM-42) --- ### Clients and Groups #### **View Client Details** permission now enforced on the UI search bar The **View Client Details** permission is now correctly enforced when using the UI search bar, preventing users without this permission from retrieving client information through search. *Internal references:* [CDO-4440](https://mambucom.jira.com/browse/CDO-4440) #### Additional work - Non-customer-facing backend maintenance. --- **Database changes** — see the [table at the bottom of the page](#database-changes) for the full list of schema modifications during the v9.191 cycle. ## v9.191.6 **Release Date**: 17.06.2026 --- ## Bug fixes ### Data #### End-of-Day processing reliability for loan accounts Resolved an issue where End-of-Day processing could fail with an error for certain loan accounts after the enableOptimizedRsvPayloadSerialization feature toggle was enabled, due to the read path falling back to the old deserialization. Affected accounts will now process through EOD successfully without requiring a workaround. *Internal references:* [REV-5455](https://mambucom.jira.com/browse/REV-5455) --- ## v9.191.5 **Release Date**: 05.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing configuration changes. --- ## v9.191.4 **Release Date**: 03.06.2026 --- ## Improvements ### Mortgages #### Deferred interest balance correctly reflects repayment transaction adjustments When a repayment transaction is adjusted, the deferred interest paid amount is now recalculated accurately, preventing balance discrepancies on offset savings mortgage accounts. *Internal references:* [MTGE-2868](https://mambucom.jira.com/browse/MTGE-2868) ### Notifications #### Additional work - Internal notifications infrastructure updates. --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data fixes. --- ## v9.191.3 **Release Date**: 03.06.2026 --- ## Features ### Deposits #### Courtesy Pay balance details now visible via the Deposits API Simple API deposits and withdrawals can now access the Courtesy Pay wallet, and the Read Deposit API response includes Courtesy Pay-related fields in the balance details. *Internal references:* [NCU-824](https://mambucom.jira.com/browse/NCU-824) --- ## Improvements ### Notifications #### Groundwork for upcoming features - Ongoing migration of notification delivery to the next-generation outbox-based dispatcher, progressively activated across sandbox and production environments. #### Additional work - Internal notifications infrastructure and activation work. --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data maintenance. --- ## v9.191.2 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Non-customer-facing data fixes and internal configuration changes. --- ## Bug fixes ### Data #### Additional work - Non-customer-facing data maintenance. --- ## v9.191.1 **Release Date**: 03.06.2026 --- ## Improvements ### Data #### Additional work - Internal data maintenance and configuration fixes. --- ## Bug fixes ### Notifications #### Webhook authentication corrected for non-ordinary notification events Webhook notifications using non-standard authentication methods now authenticate correctly, preventing delivery failures for affected notification types. *Internal references:* [EXT-93](https://mambucom.jira.com/browse/EXT-93) ### Data #### Additional work - Internal data-layer maintenance. ---

    Database changes

    | Table | Changes | |---|---| | `ips_product_calculation_cycle` | • Added column `WEIGHTAGE` | | `ips_product_settings` | • Added column `WEIGHTAGE`
    • Removed column `BALANCE_ELIGIBILITY_TYPE` | | `loan_account_carry_forward_log` | • Added column `capitalized_carry_forward_interest_amount`
    • Added column `capitalized_carry_forward_interest_from_arrears_amount` | For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Cbe - v9.192 URL: https://docs.mambu.com/release-notes/cbe/v9/v9.192/ This page contains the following releases for v9.192: * [v9.192](#v9192) * [v9.192.1](#v91921) ## v9.192 **Release Dates** * **Sandbox:** 12.06.2026 --- ## Features ### Developer #### Enhanced process instance recovery and management We have introduced new operational endpoints and granular permissions to recover stalled process instances without direct database access. These tools enable administrators to resolve blocked workflows by terminating instances or repairing variables directly via the API, with new endpoints for canceling instances and updating process variables. *Internal references:* [PROC-211](https://mambucom.jira.com/browse/PROC-211) #### Granular access control for Process Orchestration APIs We have introduced seven new specific permissions for Process Orchestration APIs, enabling granular access control and strict maker-checker separation of duties for the process-definition lifecycle. **Breaking Change**: Access is no longer automatically granted via the general **ADMIN** permission — you must explicitly assign the relevant new Orchestration permissions to maintain integration continuity. *Internal references:* [PROC-56](https://mambucom.jira.com/browse/PROC-56) #### Process context loading optimization Improved performance by avoiding context loading when no process is configured for extension points, with enhanced afterExecution method support. *Internal references:* [PROC-53](https://mambucom.jira.com/browse/PROC-53) ### Lending #### Enhanced fee tracking for existing fixed term loans Introduced detailed tracking of specific fee types and tax amounts (Inclusive/Exclusive) per installment for existing loans, extending the fee details capability previously available only for new loans. *Internal references:* [LL-6084](https://mambucom.jira.com/browse/LL-6084) ### Notifications #### Holiday synchronization completion webhooks Introduced a new `HOLIDAY_SYNC_COMPLETED` webhook event under the Administrative target type, allowing system administrators to receive automated alerts after global or branch-specific holiday updates are processed. Webhook payloads include detailed synchronization metadata, process status, and machine-readable failure information for improved integration reliability. *Internal references:* [EXT-50](https://mambucom.jira.com/browse/EXT-50) ### Deposits #### Next-generation backdating framework We have introduced a dual-layered gating framework to safely control and deploy next-generation backdating capabilities across deposit products and accounts. This includes a tenant-level master gate (`DEPOSITS_NEXT_GEN_BACKDATING`) and product-level opt-in configuration (`deposits_next_gen_backdating`) that ensures precise operational control and eliminates partial activation risks. *Internal references:* [DIF-2771](https://mambucom.jira.com/browse/DIF-2771) --- ## Improvements ### Data #### Shadow balance tracking for Mexican deposit limits Verified that shadow balance tracking for Mexican deposit limits in MXV/UDIS correctly utilizes historical exchange rates for backdated transactions, with a fallback strategy of using the latest available rate on or before the transaction date. *Internal references:* [DIF-2682](https://mambucom.jira.com/browse/DIF-2682) #### Additional work - Internal data structure changes. --- ## Bug fixes ### Lending #### End-of-Day processing failures resolved for optimized serialization Resolved an issue where End-of-Day processing could fail with an error for certain loan accounts after the enableOptimizedRsvPayloadSerialization feature toggle was enabled, due to the read path falling back to the old deserialization. Affected accounts will now process through EOD successfully without requiring a workaround. *Internal references:* [REV-5455](https://mambucom.jira.com/browse/REV-5455) #### Human task completion reliability improved Resolved a defect to ensure human-task completion is invoked exactly once, standardizing data propagation via task reply variables, and improved the Tasks inbox interface by resolving missing names for linked accounts and journal entries. *Internal references:* [PROC-241](https://mambucom.jira.com/browse/PROC-241) #### Interest rounding errors eliminated on Dynamic Term Loans with prepayments Resolved an issue where posting a repayment mid-installment on Dynamic Term Loans using Declining Balance Equal Instalment (DBEI) caused subsequent repayments to fail. The system now accumulates all intervals before executing a single-pass tax calculation, aligning it with the standard interest application mechanism. *Internal references:* [LPRC-5831](https://mambucom.jira.com/browse/LPRC-5831) #### Negative interest calculations corrected for offset savings accounts Resolved an issue on loan accounts linked with an offset savings account where interest due on future installments was incorrectly calculated as a negative value when the savings account balance exceeded the outstanding loan principal. The system now correctly clamps the minimum effective principal to zero under these conditions. *Internal references:* [LPRC-5800](https://mambucom.jira.com/browse/LPRC-5800) #### Fee prepayment allocation fixed for zero grace principal installments A fee prepayment made for an installment with zero grace principal amount is now corrected to allocate the payment properly on the installment marking it as PAID. *Internal references:* [LPRC-5696](https://mambucom.jira.com/browse/LPRC-5696) #### Repayment allocation errors resolved for accounts with multiple fee types Resolved an allocation defect that caused repayments to fail on Dynamic Term Loans when an account carried both a capitalized disbursement fee and a post-maturity manual fee. The updated allocation logic calculates unlinked fee states directly from the outstanding fee balance rather than historical payments. *Internal references:* [LPRC-5501](https://mambucom.jira.com/browse/LPRC-5501) #### Concurrent repayment race conditions eliminated Resolved a class of concurrency issues where multiple API transactions processed on the same loan account within milliseconds of each other could cause race conditions. The system now acquires a pessimistic lock on the loan account database row during key orchestration events to ensure overlapping transactions serialize cleanly. *Internal references:* [LPRC-5269](https://mambucom.jira.com/browse/LPRC-5269) #### Interest application on payment holidays corrected Resolved an issue where a small amount of regular interest could be applied on a due date marked as a payment holiday for Dynamic Term Loan accounts. Interest application on payment holiday dates is now correctly skipped. *Internal references:* [LPRC-4643](https://mambucom.jira.com/browse/LPRC-4643) #### Overpayment allocation to planned fees corrected When making an overpayment on a loan account that had planned fees configured, the excess amount was incorrectly allocated to fees on the next installment instead of being fully applied to the current installment being paid. *Internal references:* [LPRC-4562](https://mambucom.jira.com/browse/LPRC-4562) #### Large prepayment calculations improved for RNI accounts Resolved an edge case where large prepayments on loan accounts configured with Reduce Number of Installments (RNI) caused incorrect due amounts to appear during grace periods. This fix has been extended to broader Dynamic Term Loan configurations using Declining Balance Equal Instalment loans. *Internal references:* [LPRC-4102](https://mambucom.jira.com/browse/LPRC-4102) #### Custom repayment penalty allocation aligned with standard repayments When a repayment combined an interest amount and a penalty amount across different months, the penalty portion of a combined custom repayment is now allocated to the oldest installment with an outstanding penalty first, matching the order used for standard repayments. *Internal references:* [LPRC-3741](https://mambucom.jira.com/browse/LPRC-3741) #### Undo Close and Undo Write Off operations fixed in UI Resolved an issue where the Undo Close and Undo Write Off actions on loan accounts failed with an unexpected error when performed through the UI. These operations now complete successfully via the UI. *Internal references:* [LL-6175](https://mambucom.jira.com/browse/LL-6175) #### Credit arrangement account filtering enhanced Added an optional `accountState` query parameter to the `GET /creditarrangements//accounts` endpoint. Clients can now filter linked loan and deposit accounts by state (e.g. ACTIVE, CLOSED). *Internal references:* [LL-6114](https://mambucom.jira.com/browse/LL-6114) #### Inter-branch transfer journal entries corrected for tax on fees Resolved an issue where changing a loan's branch resulted in negative journal entry amounts for exclusive taxes applied to fees. The system now correctly logs these inter-branch transfer entries with positive amounts and the appropriate Credit or Debit entry type. *Internal references:* [LL-5983](https://mambucom.jira.com/browse/LL-5983) #### Fee prepayments enabled for locked accounts Resolved an issue on Fixed Term Loan accounts with Horizontal payment allocation and Payment-Due fees applied on due dates, where prepayments were rejected with an excess-payment error after interest was locked. Prepayments are now accepted and the relevant payment-due fees are applied to the targeted future installments. *Internal references:* [LL-4778](https://mambucom.jira.com/browse/LL-4778) ### Deposits #### Product description display corrected for special characters The savings product overview page now correctly displays descriptions containing special characters, HTML markup, or JSON content. Previously, characters such as quotes and angle brackets were shown as HTML entities, making JSON-formatted descriptions unreadable. *Internal references:* [DO-2329](https://mambucom.jira.com/browse/DO-2329) #### Account validation improved for maximum withdrawal limits Resolved a validation issue where editing unrelated fields on an existing deposit account would fail if the account's maximum withdrawal limit was higher than the product's current limit. The system now only enforces product-level maximum withdrawal constraints when the account's maximum withdrawal limit field itself is explicitly modified. *Internal references:* [DO-2147](https://mambucom.jira.com/browse/DO-2147) #### Account ID validation strengthened for API compatibility Deposit account IDs and product ID patterns now enforce strict validation to reject characters that are unsafe in URL paths. Allowed characters are alphanumeric characters, hyphens, and underscores. *Internal references:* [DO-2123](https://mambucom.jira.com/browse/DO-2123) #### Zero interest application validation enhanced Resolved an issue where manually applying interest to a deposit account with a net-zero accrued amount incorrectly returned a success response without generating a transaction. The API now correctly validates the request and returns a dedicated error when the rounded net of all accrued interest components is zero. *Internal references:* [DO-2056](https://mambucom.jira.com/browse/DO-2056) #### Date range searches fixed across DST transitions Resolved an issue where search queries using a `BETWEEN` filter on core date fields returned an HTTP 500 error when the requested date range spanned a Daylight Saving Time transition. The conversion logic has been corrected to handle timezone offset changes properly. *Internal references:* [DO-1843](https://mambucom.jira.com/browse/DO-1843) #### Interest calculation corrected for product propagation with rate history When interest payment dates of a savings product were updated and propagated to existing accounts, the end-of-day process now correctly calculates interest based on the account's rate history rather than applying the current rate retrospectively from the account's activation date. *Internal references:* [DO-1750](https://mambucom.jira.com/browse/DO-1750) #### Interest accrual validation strengthened for imported amounts Resolved an issue where invalid values within the imported interest accrual custom field caused End-of-Day processing to fail. Strict data validation is now enforced at write time, blocking malformed or negative inputs before they can disrupt downstream batch jobs. *Internal references:* [DO-1673](https://mambucom.jira.com/browse/DO-1673) #### Integer overflow protection added for ID pattern configuration Resolved an integer overflow issue where configuring an `INCREMENTAL_NUMBER` identifier pattern on a deposit product with a value greater than 2,147,483,647 would silently overflow to zero. The validation engine now strictly enforces the operational range of [0, 2,000,000,000]. *Internal references:* [DO-936](https://mambucom.jira.com/browse/DO-936) #### Indexed overdraft interest account updates enabled in UI Resolved an issue in the user interface where updating a deposit account configured with indexed overdraft interest rate settings would fail with a validation error after the underlying product's interest rate review period parameters were modified. *Internal references:* [DO-931](https://mambucom.jira.com/browse/DO-931) #### Auto-settlement balance calculation improved for overdraft accounts When the 'USE_OVERDRAFT_ON_LINKED_TRANSFER' feature toggle is enabled, auto-settlements from linked deposit accounts now correctly consider the authorised overdraft limit as part of the available balance rather than failing for accounts with a debit balance within the authorised limit. *Internal references:* [DO-480](https://mambucom.jira.com/browse/DO-480) ### Clients and Groups #### Client branch updates preserve group memberships An issue in the client management interface has been resolved to ensure that updating a client's assigned branch no longer inadvertently clears their existing group memberships. The UI now correctly preserves all group assignments when a branch change is saved. *Internal references:* [CFM-40](https://mambucom.jira.com/browse/CFM-40) --- ## v9.192.1 **Release Date**: 22.06.2026 --- This release contains the following: * Internal maintenance improvements to platform stability and security within the loan account interface. For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Connectors - v1.0.0 URL: https://docs.mambu.com/release-notes/connectors/v1.0.0/ ## v1.0.0 **Release Dates** * **Sandbox:** 30.03.2026 --- This release does not contain any customer-facing changes. For more information about the release, please reach out to [Mambu Support](/docs/mambu-support). For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Connectors - v1.1.0 URL: https://docs.mambu.com/release-notes/connectors/v1.1.0/ ## v1.1.0 **Release Dates** * **Sandbox:** 30.03.2026 --- This release does not contain any customer-facing changes. For more information about the release, please reach out to [Mambu Support](/docs/mambu-support). For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Connectors - v1.2.0 URL: https://docs.mambu.com/release-notes/connectors/v1.2.0/ ## v1.2.0 **Release Dates** * **Sandbox:** 10.12.2024 --- ## Features ### Enhanced Transaction Reversal Data Capture The Cards platform now captures comprehensive transaction metadata for all card transaction reversals. When reversals are processed, the system automatically includes visa transaction IDs, settlement information, currency conversion details, fee breakdowns, and issuer-specific data fields for authorization clearing reversals, chargeback reversals, declined transactions, and both credit and debit transaction reversals across all supported transaction types. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Connectors - v1.2.1 URL: https://docs.mambu.com/release-notes/connectors/v1.2.1/ ## v1.2.1 **Release Dates** * **Sandbox:** 23.01.2025 --- ## Improvements ### Cards Security Updates - Updated security dependencies to address identified vulnerabilities --- ## Bug fixes ### Credit Authorization Processing - Fixed performance issues in credit authorization clearing operations by optimizing transaction lookup mechanisms. - Replaced timeout-prone search operations with direct retrieval methods. - Enhanced error messaging for credit authorization reversal transactions when required payment objects are missing. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Connectors - v1.2.4 URL: https://docs.mambu.com/release-notes/connectors/v1.2.4/ ## v1.2.4 **Release Dates** * **Sandbox:** 30.03.2026 --- This release does not contain any customer-facing changes. For more information about the release, please reach out to [Mambu Support](/docs/mambu-support). For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Release notes URL: https://docs.mambu.com/release-notes/ Welcome to the Release Notes section! This section will contain detailed information about new features, improvements, and bug fixes in our latest releases. For more information about our release management process, please see [Mambu Release Cycle](/docs/mambu-release-cycle). Do you want to stay updated on all the latest news from across Mambu? See [What's new in the Mambu platform](https://mambu.com/en/whats-new-in-the-mambu-platform). --- ## Subscribe to Release Note Updates Stay informed about the latest releases:

    RSS Feed

    Subscribe to our RSS feed to get the latest release notes directly in your reader.

    RSS --- See below for the list of all available release notes: ## CBE (Mambu Core Banking Engine) ### V9 * **[v9.192](/release-notes/cbe/v9/v9-192)** * [v9.192.1](/release-notes/cbe/v9/v9-192#v91921) * **[v9.191](/release-notes/cbe/v9/v9-191)** * [v9.191.6](/release-notes/cbe/v9/v9-191#v91916) * [v9.191.5](/release-notes/cbe/v9/v9-191#v91915) * [v9.191.4](/release-notes/cbe/v9/v9-191#v91914) * [v9.191.3](/release-notes/cbe/v9/v9-191#v91913) * [v9.191.2](/release-notes/cbe/v9/v9-191#v91912) * [v9.191.1](/release-notes/cbe/v9/v9-191#v91911) * **[v9.190](/release-notes/cbe/v9/v9-190)** * [v9.190.4](/release-notes/cbe/v9/v9-190#v91904) * [v9.190.3](/release-notes/cbe/v9/v9-190#v91903) * [v9.190.2](/release-notes/cbe/v9/v9-190#v91902) * [v9.190.1](/release-notes/cbe/v9/v9-190#v91901) * **[v9.189](/release-notes/cbe/v9/v9-189)** * [v9.189.8](/release-notes/cbe/v9/v9-189#v91898) * [v9.189.5](/release-notes/cbe/v9/v9-189#v91895) * [v9.189.7](/release-notes/cbe/v9/v9-189#v91897) * [v9.189.6](/release-notes/cbe/v9/v9-189#v91896) * [v9.189.4](/release-notes/cbe/v9/v9-189#v91894) * [v9.189.3](/release-notes/cbe/v9/v9-189#v91893) * [v9.189.2](/release-notes/cbe/v9/v9-189#v91892) * [v9.189.1](/release-notes/cbe/v9/v9-189#v91891) * **[v9.188](/release-notes/cbe/v9/v9-188)** * [v9.188.3](/release-notes/cbe/v9/v9-188#v91883) * [v9.188.2](/release-notes/cbe/v9/v9-188#v91882) * [v9.188.1](/release-notes/cbe/v9/v9-188#v91881) * **[v9.187](/release-notes/cbe/v9/v9-187)** * [v9.187.4](/release-notes/cbe/v9/v9-187#v91874) * [v9.187.3](/release-notes/cbe/v9/v9-187#v91873) * [v9.187.2](/release-notes/cbe/v9/v9-187#v91872) * [v9.187.1](/release-notes/cbe/v9/v9-187#v91871) * **[v9.186](/release-notes/cbe/v9/v9-186)** * [v9.186.2](/release-notes/cbe/v9/v9-186#v91862) * [v9.186.1](/release-notes/cbe/v9/v9-186#v91861) * **[v9.185](/release-notes/cbe/v9/v9-185)** * [v9.185.4](/release-notes/cbe/v9/v9-185#v91854) * [v9.185.3](/release-notes/cbe/v9/v9-185#v91853) * [v9.185.2](/release-notes/cbe/v9/v9-185#v91852) * [v9.185.1](/release-notes/cbe/v9/v9-185#v91851) * **[v9.184](/release-notes/cbe/v9/v9-184)** * [v9.184.3](/release-notes/cbe/v9/v9-184#v91843) * [v9.184.2](/release-notes/cbe/v9/v9-184#v91842) * [v9.184.1](/release-notes/cbe/v9/v9-184#v91841) * **[v9.183](/release-notes/cbe/v9/v9-183)** * [v9.183.6](/release-notes/cbe/v9/v9-183#v91836) * [v9.183.5](/release-notes/cbe/v9/v9-183#v91835) * [v9.183.4](/release-notes/cbe/v9/v9-183#v91834) * [v9.183.3](/release-notes/cbe/v9/v9-183#v91833) * [v9.183.2](/release-notes/cbe/v9/v9-183#v91832) * [v9.183.1](/release-notes/cbe/v9/v9-183#v91831) * **[v9.182](/release-notes/cbe/v9/v9-182)** * [v9.182.2](/release-notes/cbe/v9/v9-182#v91822) * [v9.182.1](/release-notes/cbe/v9/v9-182#v91821) * **[v9.181](/release-notes/cbe/v9/v9-181)** * [v9.181.1](/release-notes/cbe/v9/v9-181#v91811) * **[v9.180](/release-notes/cbe/v9/v9-180)** * [v9.180.1](/release-notes/cbe/v9/v9-180#v91801) * **[v9.179](/release-notes/cbe/v9/v9-179)** * [v9.179.4](/release-notes/cbe/v9/v9-179#v91794) * [v9.179.3](/release-notes/cbe/v9/v9-179#v91793) * [v9.179.2](/release-notes/cbe/v9/v9-179#v91792) * [v9.179.1](/release-notes/cbe/v9/v9-179#v91791) * **[v9.178](/release-notes/cbe/v9/v9-178)** * [v9.178.7](/release-notes/cbe/v9/v9-178#v91787) * [v9.178.6](/release-notes/cbe/v9/v9-178#v91786) * [v9.178.5](/release-notes/cbe/v9/v9-178#v91785) * [v9.178.4](/release-notes/cbe/v9/v9-178#v91784) * [v9.178.3](/release-notes/cbe/v9/v9-178#v91783) * [v9.178.2](/release-notes/cbe/v9/v9-178#v91782) * [v9.178.1](/release-notes/cbe/v9/v9-178#v91781) * **[v9.177](/release-notes/cbe/v9/v9-177)** * [v9.177.4](/release-notes/cbe/v9/v9-177#v91774) * [v9.177.3](/release-notes/cbe/v9/v9-177#v91773) * [v9.177.2](/release-notes/cbe/v9/v9-177#v91772) * [v9.177.1](/release-notes/cbe/v9/v9-177#v91771) * **[v9.176](/release-notes/cbe/v9/v9-176)** * [v9.176.1](/release-notes/cbe/v9/v9-176#v91761) * **[v9.175](/release-notes/cbe/v9/v9-175)** * [v9.175.3](/release-notes/cbe/v9/v9-175#v91753) * [v9.175.2](/release-notes/cbe/v9/v9-175#v91752) * [v9.175.1](/release-notes/cbe/v9/v9-175#v91751) * **[v9.174](/release-notes/cbe/v9/v9-174)** * [v9.174.6](/release-notes/cbe/v9/v9-174#v91746) * [v9.174.5](/release-notes/cbe/v9/v9-174#v91745) * [v9.174.4](/release-notes/cbe/v9/v9-174#v91744) * [v9.174.3](/release-notes/cbe/v9/v9-174#v91743) * [v9.174.2](/release-notes/cbe/v9/v9-174#v91742) * [v9.174.1](/release-notes/cbe/v9/v9-174#v91741) * **[v9.173](/release-notes/cbe/v9/v9-173)** * [v9.173.2](/release-notes/cbe/v9/v9-173#v91732) * [v9.173.1](/release-notes/cbe/v9/v9-173#v91731) * **[v9.172](/release-notes/cbe/v9/v9-172)** * [v9.172.4](/release-notes/cbe/v9/v9-172#v91724) * [v9.172.3](/release-notes/cbe/v9/v9-172#v91723) * [v9.172.2](/release-notes/cbe/v9/v9-172#v91722) * [v9.172.1](/release-notes/cbe/v9/v9-172#v91721) * **[v9.171](/release-notes/cbe/v9/v9-171)** * [v9.171.4](/release-notes/cbe/v9/v9-171#v91714) * [v9.171.3](/release-notes/cbe/v9/v9-171#v91713) * [v9.171.2](/release-notes/cbe/v9/v9-171#v91712) * [v9.171.1](/release-notes/cbe/v9/v9-171#v91711) * **[v9.170](/release-notes/cbe/v9/v9-170)** * [v9.170.4](/release-notes/cbe/v9/v9-170#v91704) * [v9.170.3](/release-notes/cbe/v9/v9-170#v91703) * [v9.170.2](/release-notes/cbe/v9/v9-170#v91702) * [v9.170.1](/release-notes/cbe/v9/v9-170#v91701) * **[v9.169](/release-notes/cbe/v9/v9-169)** * [v9.169.3](/release-notes/cbe/v9/v9-169#v91693) * [v9.169.2](/release-notes/cbe/v9/v9-169#v91692) * [v9.169.1](/release-notes/cbe/v9/v9-169#v91691) * **[v9.168](/release-notes/cbe/v9/v9-168)** * [v9.168.6](/release-notes/cbe/v9/v9-168#v91686) * [v9.168.5](/release-notes/cbe/v9/v9-168#v91685) * [v9.168.4](/release-notes/cbe/v9/v9-168#v91684) * [v9.168.3](/release-notes/cbe/v9/v9-168#v91683) * [v9.168.2](/release-notes/cbe/v9/v9-168#v91682) * [v9.168.1](/release-notes/cbe/v9/v9-168#v91681) * **[v9.167](/release-notes/cbe/v9/v9-167)** * [v9.167.10](/release-notes/cbe/v9/v9-167#v916710) * [v9.167.9](/release-notes/cbe/v9/v9-167#v91679) * [v9.167.8](/release-notes/cbe/v9/v9-167#v91678) * [v9.167.7](/release-notes/cbe/v9/v9-167#v91677) * [v9.167.6](/release-notes/cbe/v9/v9-167#v91676) * [v9.167.5](/release-notes/cbe/v9/v9-167#v91675) * [v9.167.4](/release-notes/cbe/v9/v9-167#v91674) * [v9.167.3](/release-notes/cbe/v9/v9-167#v91673) * [v9.167.2](/release-notes/cbe/v9/v9-167#v91672) * [v9.167.1](/release-notes/cbe/v9/v9-167#v91671) * **[v9.166](/release-notes/cbe/v9/v9-166)** * [v9.166.7](/release-notes/cbe/v9/v9-166#v91667) * [v9.166.6](/release-notes/cbe/v9/v9-166#v91666) * [v9.166.5](/release-notes/cbe/v9/v9-166#v91665) * [v9.166.4](/release-notes/cbe/v9/v9-166#v91664) * [v9.166.3](/release-notes/cbe/v9/v9-166#v91663) * [v9.166.2](/release-notes/cbe/v9/v9-166#v91662) * [v9.166.1](/release-notes/cbe/v9/v9-166#v91661) * **[v9.165](/release-notes/cbe/v9/v9-165)** * [v9.165.7](/release-notes/cbe/v9/v9-165#v91657) * [v9.165.6](/release-notes/cbe/v9/v9-165#v91656) * [v9.165.5](/release-notes/cbe/v9/v9-165#v91655) * [v9.165.4](/release-notes/cbe/v9/v9-165#v91654) * [v9.165.3](/release-notes/cbe/v9/v9-165#v91653) * [v9.165.2](/release-notes/cbe/v9/v9-165#v91652) * [v9.165.1](/release-notes/cbe/v9/v9-165#v91651) ### Connectors * **[v1.2.4](/release-notes/connectors/v1-2-4)** * **[v1.2.1](/release-notes/connectors/v1-2-1)** * **[v1.2.0](/release-notes/connectors/v1-2-0)** * **[v1.1.0](/release-notes/connectors/v1-1-0)** * **[v1.0.0](/release-notes/connectors/v1-0-0)** ### Notifications * **[Notifications v1.77](/release-notes/notifications/Notifications v1-77)** * **[v1.77](/release-notes/notifications/v1-77)** * **[v1.75](/release-notes/notifications/v1-75-0)** * **[v1.73](/release-notes/notifications/v1-73-0)** * **[v1.69](/release-notes/notifications/v1-69-0)** * **[v1.68](/release-notes/notifications/v1-68-0)** * **[v1.63](/release-notes/notifications/v1-63-0)** ## Payments * **[v1.44.97](/release-notes/payments/v1-44-97)** * **[v1.44.96](/release-notes/payments/v1-44-96)** * **[v1.44.91](/release-notes/payments/v1-44-91)** * **[v1.44.87](/release-notes/payments/v1-44-87)** * **[v1.44.86](/release-notes/payments/v1-44-86)** * **[v1.44.85](/release-notes/payments/v1-44-85)** --- # Notifications - v1.63.0 URL: https://docs.mambu.com/release-notes/notifications/v1.63.0/ ## v1.63.0 **Release Dates** * **Sandbox:** 27.03.2026 --- ## Improvements ### Notifications #### Enhanced Notification Service Reliability Improved the notification service startup process to ensure consistent performance and eliminate configuration-related interruptions that could impact message delivery. ### General #### Enhanced Monitoring and Diagnostics Improved system monitoring capabilities to provide better visibility into platform operations, enabling faster issue identification and resolution for enhanced service reliability. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Notifications - v1.68.0 URL: https://docs.mambu.com/release-notes/notifications/v1.68.0/ ## v1.68.0 **Release Dates** * **Sandbox:** 27.03.2026 --- ## Improvements ### Notifications #### Enhanced Webhook Notification Configuration Organizations can now programmatically enable or disable webhook notifications by template type. The new configuration includes comprehensive validation to ensure reliable delivery and proper setup. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Notifications - v1.69.0 URL: https://docs.mambu.com/release-notes/notifications/v1.69.0/ ## v1.69.0 **Release Dates** * **Sandbox:** 27.03.2026 --- ## Bug fixes ### Notifications #### Improved Notification Delivery Reliability Enhanced the notification system's handling of messages in pending states to ensure consistent delivery across all channels including webhooks, SMS, and email communications. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Notifications - v1.73.0 URL: https://docs.mambu.com/release-notes/notifications/v1.73.0/ ## v1.73.0 **Release Dates** * **Sandbox:** 27.03.2026 --- ## Improvements ### Enhanced Event Streaming Diagnostics Improved diagnostic capabilities for event streaming operations to ensure more reliable notification delivery and faster issue resolution. This enhancement provides better visibility into system operations, enabling our support team to proactively monitor and maintain optimal streaming performance for your integrations. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). Note that if a database backup was in progress during the release process, it has to be requested again. --- # Notifications - v1.75.0 URL: https://docs.mambu.com/release-notes/notifications/v1.75.0/ ## v1.75.0 **Release Dates** * **Sandbox:** 31.03.2026 --- ## Features ### Circuit Breaker Poller for Notifications Dispatcher Introduces automated recovery testing for notification templates that have been temporarily disabled due to failures. The system now performs controlled dispatch tests on templates in HALF_OPEN state, automatically transitioning them back to normal operation once they pass the configured number of test messages (max_half_open_tests). Failed recovery attempts extend the cooldown period and revert templates to OPEN state. Includes comprehensive logging of all state transitions with tenant and template context, plus Prometheus metrics for monitoring circuit recovery rates and open circuit counts. ### Retry Poller for Notifications Dispatcher Implements intelligent retry processing for failed notification messages through a dedicated background poller. Messages marked as ON_RETRY are reprocessed using configurable batch sizes and pacing controls to prevent downstream system overload. The system increments retry_count on each failure and automatically marks messages as FAILED when they exceed MAX_RETRIES threshold. All retry attempts update the failure_aggregate table for corresponding tenant_id and template_id combinations, with full support for concurrent execution across multiple pods using row-level locking. ### Circuit Breaker Evaluator Job and Failure Aggregate Tracking Establishes core circuit breaker decision engine with new failure_aggregate table for tracking per-template failure metrics by (tenant_id, template_id). The Evaluator Job runs periodically to analyze failure patterns and automatically opens circuits by inserting entries into on_hold_templates when FAIL_THRESHOLD is exceeded. Key parameters including FAIL_THRESHOLD, COOLDOWN_SEC, and MAX_HALF_OPEN_TESTS are externally configurable. The system preserves cumulative failure data for observability and uses fail_count_snapshot deltas to detect new failure incidents without duplicate circuit opens. --- ## Improvements ### AWS Secret Manager Integration for Encrypted Message Processing The Notifications service now supports AWS Secrets Manager for retrieving AEAD keysets required for decrypting MessageQueueItem payloads. The implementation includes a 24-hour cache using Caffeine to minimize AWS API calls and reduce latency. The system fetches the complete Tink keyset JSON in a single operation and leverages AWS SDK v2's built-in retry mechanisms for resilience. Failed decryption attempts are tracked via `notifications.secret.decrypt.failure` metrics and logged with AWS secret version IDs for debugging. ### Local Tink Decryption Support for Development Environments Local development environments can now decrypt MessageQueueItem payloads using mock Tink keysets configured in config.YAML. The implementation supports both plaintext legacy messages (tinkKeyId=NULL) and encrypted messages using the Header Detachment pattern. Decryption failures automatically mark messages as FAILED state and increment the `notifications.decryption.failure` metric. The LocalSecretFetcher reads keyset configuration directly from the YAML file, while SubscriberApplication handles environment-specific wiring based on the ENVIRONMENT_VENDOR system property. --- ## Bug fixes ### Fixed NullPointerException in SMS notification dispatch causing notification failures Resolved a critical null pointer exception that was preventing SMS notifications from being dispatched through the Infobip SMS gateway. The error occurred during HTTP client initialization when the executor service parameter was unexpectedly null, causing the entire notification dispatch process to fail. This fix ensures SMS notifications are processed reliably without interruption. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Notifications - v1.77 URL: https://docs.mambu.com/release-notes/notifications/v1.77/ This page contains the following releases for v1.77: * [v1.77](#v177) ## v1.77 **Release Dates** * **Sandbox:** 26.05.2026 --- ## Bug fixes ### Notifications #### Webhook delivery reliability improvements We fixed a bug where outbound webhook notifications intermittently failed with a 60-second timeout caused by stale network connections. A proactive connection rotation mechanism now refreshes the internal connection pool every 5 minutes, ensuring webhooks are dispatched using fresh connections and improving overall delivery reliability. --- For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.85 URL: https://docs.mambu.com/release-notes/payments/v1.44.85/ ## v1.44.85 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Features ### Feature flag implementation for SEPA 2025 rulebook changes Feature flag added to control the rollout of SEPA 2025 rulebook compliance updates. The flag is initially disabled, allowing controlled activation of the new payment processing capabilities. ### Enhanced camt.056 processing for SEPA 2025 naming conventions Incoming camt.056 payment cancellation messages now support shortened naming convention references. The system processes camt.056 messages where OrgnlMsgNmId references "pacs.008" instead of the full version format "pacs.008.001.0X", while maintaining backward compatibility with existing full version references. ### Enhanced pacs.004 processing for SEPA 2025 naming conventions Incoming pacs.004 payment return messages now support shortened naming convention references. The system processes pacs.004 messages where OrgnlMsgNmId contains "pacs.008" instead of the full version format, enabling proper reconciliation with original payments while maintaining backward compatibility. ### Enhanced pacs.002 processing for SEPA 2025 naming conventions Incoming pacs.002 payment status messages now support shortened naming convention references. The system processes pacs.002 messages where OrgnlMsgNmId contains "pacs.008" instead of the full version format "pacs.008.001.08" or "pacs.008.001.09", enabling correct linking to original payment instructions while maintaining backward compatibility. ### Relaxed validation for incoming pacs.009 debtor account requirements Incoming pacs.009 FI-to-FI transfer messages no longer require debtor account ID validation. The system now processes incoming pacs.009 payments and books them in CBE even when the debtor account ID field is missing, while maintaining all other existing validations. Creditor account ID remains mandatory for successful processing. --- ## Improvements ### Enhanced Kafka Event Handling for SEPA Credit Transfer Processing Implemented comprehensive logging and duplicate mitigation measures for SEPA CT outgoing payments (pacs.008) processing. Added detailed logging to InitiateSettlementHandler for complete event tracking and introduced unique indexing on (aggregate_id, type) in the event table to prevent duplicate Kafka event consumption that could result in duplicate XML messages to customers. ### Default Configuration for Incoming Direct Debit Retry Processing Resolved NullPointerException in AML processing for incoming SEPA Direct Debit (SDD) transactions. The system now handles missing incomingDirectDebitRetryDays system property configuration by implementing appropriate default values or alerts, ensuring uninterrupted AML result processing flow. ### Updated IBAN Plus Directory Integration Retrieved and integrated the latest IBAN Plus file from SWIFT network (swift.com) in XML format. This update ensures current IBAN validation data is available for payment processing and compliance verification. ### Enhanced Exception Logging for Outgoing Direct Debit Scheduler Improved diagnostic capabilities for OutgoingDDScheduler by adding complete stack trace logging. This enhancement facilitates faster issue resolution and reduces alert noise by providing detailed context for exception handling. --- ## Bug fixes ### Fixed SQL query error in SEPA block header retrieval The SQL query in SepaRepository for retrieving SEPA block headers has been corrected. The query now properly includes the missing parameter binding for INSTGAGT_GEN field, ensuring accurate retrieval of SEPA block header sequence numbers based on message ID, message name ID, input/output block type, and instructing agent generation parameters. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.86 URL: https://docs.mambu.com/release-notes/payments/v1.44.86/ ## v1.44.86 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Features ### Enhanced pacs.007 Message Processing with SEPA 2025 Shortened Naming Convention MPG now processes incoming pacs.007 return messages that reference original pacs.003 transactions using the shortened naming convention "pacs.003" in the OrgnlMsgNmId field. This update ensures compliance with SEPA 2025 rulebook requirements while maintaining backward compatibility with full version naming (pacs.003.001.0X). The system correctly reconciles returns with original SEPA Credit Transfer transactions and handles unlinked returns through established procedures. ### Enhanced pacs.004 Message Processing with SEPA 2025 Shortened Naming Convention MPG now processes incoming pacs.004 return messages that reference original pacs.003 transactions using the shortened naming convention "pacs.003" in the OrgnlMsgNmId field. This enhancement supports SEPA 2025 compliance for SEPA Direct Debit returns while preserving backward compatibility with existing full version references. The system maintains proper reconciliation with original transactions and applies standard handling for unlinked returns. ### Enhanced pacs.002 Status Report Processing with SEPA 2025 Shortened Naming Convention MPG now processes incoming pacs.002 status report messages that reference original pacs.003 transactions using the shortened naming convention "pacs.003" in the OrgnlMsgNmId field. This update enables proper linking of status reports to original SEPA Direct Debit instructions in accordance with SEPA 2025 rulebook requirements. The system maintains backward compatibility with full version naming and implements appropriate error handling for invalid references. ### Legal Entity Identifier (LEI) Code Capture and API Integration MPG now captures and stores Legal Entity Identifier (LEI) codes from the Ultimate Debtor field (CdtTrfTxInf/UltmtDbtr/Id/OrgId/LEI) in incoming pacs.008 messages. Stored LEI data is accessible through the Payment Details API and included in Instructions API responses, enhancing transaction transparency and supporting regulatory compliance requirements for ultimate fund originator identification. ### Enhanced camt.087 Payment Modification Processing with SEPA 2025 Shortened Naming Convention MPG now processes incoming camt.087 payment modification request messages that reference original pacs.008 transactions using the shortened naming convention "pacs.008" in the OrgnlMsgNmId field. This enhancement ensures compliance with SEPA 2025 rulebook requirements while maintaining backward compatibility with full version references (pacs.008.001.0X). Payment modification requests are handled according to established business rules. ### Enhanced camt.029 Resolution Processing with SEPA 2025 Shortened Naming Convention MPG now processes incoming camt.029 resolution messages that reference original pacs.008 transactions using the shortened naming convention "pacs.008" in the OrgnlMsgNmId field. This update supports SEPA 2025 compliance for payment cancellation request resolutions while maintaining backward compatibility with full version naming. The system properly evaluates and actions cancellation requests according to business rules. ### Enhanced pacs.028 Status Inquiry Processing with SEPA 2025 Shortened Naming Convention MPG now processes incoming pacs.028 status inquiry messages that reference original messages using shortened naming conventions (e.g., "camt.056") in the OrgnlMsgNmId field. This enhancement ensures proper validation and linking of status inquiries under SEPA 2025 rules while maintaining backward compatibility with full version references (camt.056.001.0X). Status requests are processed efficiently with appropriate validation and linking capabilities. --- ## Improvements ### Enhanced Payment Data Sanitization for Pacs.003 Messages Payment details validation now includes comprehensive sanitization before database storage. The system validates and removes illegal characters from incoming payment data, particularly in /DrctDbtTxInf/RmtInf fields, and generates alerts when non-compliant characters are detected. This ensures compliance with SEPA extended character set requirements. ### Improved Rejection Code Accuracy for Closed Account Payments Incoming payments failing due to closed accounts now return the correct AC04 rejection code instead of the generic AC06 code. The system performs additional account state validation via `GET /api/deposits/` and adds an optional errorSource field to ApiError events (CreditTransactionFailed, FailPaymentOrder, PaymentOrderFailed) to distinguish between closed and blocked account states without altering customer-facing information. ### Updated IBAN Plus Directory Integration IBAN Plus file retrieval process has been updated to access the latest monthly flat files from SWIFT's download area. The system now retrieves XML format files from the most recent available date through the SWIFTRef portal. ### Payment Data Sanitization for Pacs.003 Processing Incoming payment processing now includes validation and sanitization of payment details before database storage. The parseAndValidate method in IncomingScheduler.processPacs003 removes illegal character sequences and creates alerts for non-compliant data, ensuring adherence to SEPA character set standards. ### IBAN Plus File Retrieval Process Enhancement Monthly IBAN Plus file download process has been streamlined for accessing flat files through SWIFT's MySwift portal. The system now supports automated retrieval of XML format files from the SWIFTRef download area with improved file selection for the most current monthly datasets. ### Accurate Rejection Codes for Failed Account Transactions Payment rejection handling now uses appropriate reason codes based on actual account states. The system distinguishes between closed (AC04) and blocked (AC06) accounts by performing additional validation calls and enriching transaction events with account state information, improving payment processing accuracy while maintaining backward compatibility. --- ## Bug fixes ### Fixed transaction identification in incoming pacs.028 messages to prevent incorrect recalls Resolved issue where incoming pacs.028 transactions were identified only by txId and msgNmId, which could result in incorrect transaction recalls. Transaction identification now uses the complete key set: MSGNMID, TXID, DBTRAGT, STTLDT, INOUTTRN to ensure unique identification across multiple originator banks. ### Resolved NullPointerException in AML processing when Debtor Account is missing in Pacs 009 Fixed AcceptCustomerProfile handler error that occurred when processing Pacs 009 messages without Debtor Account information. The system now properly handles missing debtor account data during AML result processing without throwing NullPointerException. ### Enhanced transaction identification for incoming pacs.028 messages in external gateway Improved transaction identification logic for incoming scheduler pacs.028 messages by expanding identification parameters beyond txId and msgNmId. Transactions are now identified using MSGNMID, TXID, DBTRAGT, STTLDT, INOUTTRN to prevent duplicate key conflicts between originator banks and ensure accurate transaction recall operations. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.87 URL: https://docs.mambu.com/release-notes/payments/v1.44.87/ ## v1.44.87 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Features ### LEI Code Processing for Instant Payments MPG now captures and stores Legal Entity Identifier (LEI) codes from Ultimate Debtor information in incoming pacs.008 Instant payment messages. The system extracts LEI data from the CdtTrfTxInf/UltmtDbtr/Id/OrgId/LEI path in pacs.008.001.08 messages and stores it with the associated payment transaction. Stored Ultimate Debtor LEI codes are accessible through the Payment Details API and included in Instructions API responses for enhanced regulatory transparency and analytical capabilities. ### Shortened Naming Convention Support for camt.056 Cancellation Messages MPG now processes incoming camt.056 payment cancellation messages that reference original pacs.008 transactions using the shortened naming convention "pacs.008" in the OrgnlMsgNmId field. This update ensures compliance with SEPA 2025 rulebook requirements while maintaining backward compatibility with existing full version naming conventions (pacs.008.001.0X). The system correctly processes and actions cancellation requests regardless of the naming convention used. ### Shortened Naming Convention Support for pacs.004 Return Messages MPG now processes incoming pacs.004 payment return messages that reference original pacs.008 Instant transactions using the shortened naming convention "pacs.008" in the OrgnlMsgNmId field. The system successfully validates and links returns to original payments using either the shortened "pacs.008" format or the full version format (pacs.008.001.0X), ensuring proper reconciliation and compliance with SEPA 2025 rulebook standards. --- ## Improvements ### Enhanced logging for outgoing payment scheduler operations Improved logging capabilities in the outgoing payment scheduler to provide better visibility into SEPA transaction processing. The system now includes comprehensive trace logs for instant payment cancellation rejection methods, enabling clearer determination of successful transaction collection. Enhanced exception handling provides detailed context information, including specific method names and operational details when errors occur. ### Payment Components engine updated to version 25.18.0-RC for 2025 rulebook compliance Implemented Payment Components engine version 25.18.0-RC to support 2025 rulebook changes. The updated engine includes new validation libraries for regulatory compliance items and is deployed under the existing 2025 rulebook changes feature flag. This update ensures payment processing adheres to the latest industry standards and regulatory requirements. ### Improved diagnostic logging for outgoing payment gateway operations Enhanced logging framework for the outgoing payment gateway scheduler to provide better operational visibility. Added comprehensive logging for instant payment cancellation rejection processing methods, including success/failure indicators for SEPA transaction collection. Improved exception handling now includes method-specific context and detailed error information to reduce troubleshooting time. --- ## Bug fixes ### Fixed processing of camt.029 cancellation messages with original message name identification Resolved an issue where inbound camt.029 cancellation messages failed to process when containing `pacs.008` references. The system now correctly recognizes and processes these original message name identifiers, ensuring cancellation requests are properly actioned or evaluated without triggering "Unrecognized original message name id" errors. ### Fixed error handling for pacs.002 messages with invalid transaction references Corrected the invalid reference scenario processing for inbound pacs.002 messages. When a pacs.002 message contains an OrgnlMsgNmId like "pacs.008" but the referenced transaction cannot be found, the system now properly triggers the appropriate error handling and rejection process instead of failing to process the message. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.88 URL: https://docs.mambu.com/release-notes/payments/v1.44.88/ ## v1.44.88 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Features ### Enforced Single Outgoing Recall Request for SEPA Instant Payments MPG now enforces compliance with SEPA scheme rules by allowing only one recall request (camt.056) per original SEPA Instant Payment (pacs.008). When attempting to initiate a second recall for the same transaction, the system will reject the request with a clear error message: "A recall request has already been sent for this payment." The API will return a 400 Conflict response for duplicate recall attempts, while successful first-time recalls receive standard success responses. This enforcement operates on a per-transaction basis, allowing separate recalls for different payments while maintaining scheme compliance. ### Updated Timestamp Handling for Outgoing SEPA Instant Payments (pacs.008) Outgoing pacs.008 Instant messages now capture timestamps at the moment MPG receives the payment creation API call, rather than when the message leaves the payment engine. This change ensures compliance with SEPA 2025 rulebook requirements for the 10-second processing window. The AccptncDtTm field now uses millisecond precision with the format pattern: [0-9](-[0-9])T[0-9](:[0-9]) (\\.[0-9][1-9])?(Z|([-+][0-9](:[0-9])?)). Example format: 2025-08-11T15:43:05.789+02:00. ### Enhanced Processing for Incoming pacs.028 Messages with Shortened Naming Convention MPG now processes incoming pacs.028 status inquiry messages that reference original payment instructions using shortened naming conventions in the OrgnlMsgNmId field (e.g., "camt.056" instead of "Camt.056.001.0X"). This update ensures compatibility with SEPA 2025 rules while maintaining backward compatibility with existing full naming convention formats. The system successfully validates and links these messages for efficient status inquiry handling. ### Enhanced Processing for Incoming camt.029 Messages with Shortened Naming Convention MPG now correctly processes incoming camt.029 payment cancellation resolution messages that reference pacs.008 Instant payments using shortened naming conventions in the OrgnlMsgNmId field (e.g., "pacs.008" instead of "pacs.008.001.0X"). This enhancement ensures compliance with SEPA 2025 rulebook requirements for handling cancellation request resolutions while maintaining full backward compatibility with existing naming convention formats. --- ## Bug fixes ### Fixed null pointer exception in camt.056 additional information processing Resolved a critical issue where empty additional information fields in incoming camt.056 cancellation requests caused null pointer exceptions during camt.029 response generation. The fix ensures proper handling of transactions when additional info is not populated, preventing system crashes in the authorize/deny workflow through the /authorize/deny endpoint. ### Corrected inbound message validation for camt.056 OrgnlMsgNmId field Fixed validation logic for the OrgnlMsgNmId field in inbound camt.056 messages to properly handle invalid short message name identifiers. This resolves scenario 6.3 validation failures and ensures compliant processing of cancellation request messages. ### Enhanced camt.056 to camt.029 transaction flow error handling Improved error handling in the OutgoingScheduler for instant payment cancellation rejections when processing camt.056 messages with missing additional information. The fix prevents null pointer exceptions in both InstantCamt029V3Translator and Camt029V3Translator when generating outgoing camt.029 responses for transactions in TO_BE_REJECTED state. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.89 URL: https://docs.mambu.com/release-notes/payments/v1.44.89/ ## v1.44.89 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Features ### Internal Processing SLA for Outgoing Instant Payments MPG now enforces a strict 5-second internal processing window for outgoing SEPA Instant Payments. When you initiate a payment via API, MPG monitors the complete internal flow (message creation, AML checks, fund reservation) and automatically cancels the payment if processing exceeds 5 seconds. The system uses payment message timestamps as reference and removes any created reservations during cancellation. You will receive immediate notification if a payment is cancelled due to timeout, with the payment status updated to "cancelled". ### Timeout Handling for Outgoing Instant Payments MPG automatically releases fund reservations for outgoing SEPA Instant Payments if no pacs.002 confirmation is received within 10 seconds. The payment remains in "pending-settlement" status. If a late pacs.002 arrives after the 10-second window, MPG processes it immediately: rejections follow standard behavior, while acceptances trigger direct account debiting without reservation. If insufficient funds are available, MPG debits your pre-configured process account. Event notifications are sent at the 12-second mark and upon final payment resolution. ### Configuration of Instant Payment SLA Timer MPG now enforces a 5-second processing timer for incoming SEPA Instant Payments to ensure scheme SLA compliance. The system validates timestamps from incoming pacs.008 messages and must complete all processing within 5 seconds. Successful processing within the window creates account bookings and sends positive pacs.002 (ACCP) responses. If the 5-second window is exceeded, MPG prevents booking creation and immediately sends a pacs.002 reject message with appropriate timeout reason codes. ### Regulatory Change: LEI Code Addition to Processing Logic MPG now captures and stores Legal Entity Identifier (LEI) codes from the Ultimate Debtor field in incoming pacs.003 messages. The system parses LEI data from the CdtTrfTxInf/UltmtDbtr/Id/OrgId/LEI path in pacs.003.001.08 messages and associates it with the specific payment transaction. Stored Ultimate Debtor LEI information is accessible through the Payment Details API and included in Instructions API responses, enhancing transparency for regulatory and analytical requirements. --- ## Improvements ### Enhanced validation and performance improvements for /api/v1/instructions endpoint Implemented comprehensive validation layer and performance optimizations for the /api/v1/instructions endpoint. Added validation for non-existent filters with 400 error responses, mandatory filter combinations requiring both dateFrom and dateTo parameters to be either filled or empty, and requirement that dateFrom/dateTo must include one of messageId, messageType, or paymentsId. Enhanced query performance with pre-counting mechanism for large result sets and appropriate response handling. ### Optimized SEPA Instant settlement processing flow Removed timeout validation in the internal transaction credit settlement handler for SEPA Instant payments. The system now processes settlement requests without timeout checks after sending positive ACCP pacs.002 responses, streamlining the settlement flow for AML-approved instant credit transfers and improving processing efficiency for asynchronous settlement operations. ### Updated IBAN Plus directory integration Retrieved and integrated the latest IBAN Plus file from SWIFT network in XML format. Updated directory references to ensure accurate IBAN validation and routing for international payment processing, maintaining compliance with current SWIFT standards and improving payment instruction accuracy. ### Validation framework implementation for /api/v1/instructions endpoint Deployed enhanced validation framework for the /api/v1/instructions endpoint with feature toggle controls. Implemented filter validation layer, mandatory parameter combinations for dateFrom/dateTo fields, and query performance improvements. Feature toggle enabled in sandbox environment with planned production deployment following customer testing period to ensure backward compatibility. --- ## Bug fixes ### Instruction endpoint now correctly processes camt.029.001.08 and camt.027.001.06 bulk transactions Fixed issue where the instruction endpoint was ignoring specific CAMT message types (camt.029.001.08 and camt.027.001.06) during bulk transaction processing. This was causing incomplete batch returns where expected record counts did not match actual returned records, leading to premature batch termination in downstream processing jobs. ### Authorization hold settlement now correctly handles insufficient funds after pacs.002 timeout Resolved BALANCE_BELOW_ZERO error that occurred when pacs.002 messages arrived after timeout expiration and the debited account had insufficient funds. The system now properly settles transactions by debiting the suspense account instead of failing with "Authorization Hold Settlement Failed" status. ### AML response timeout handling improved for outgoing instant payments Fixed timing issue in outgoing instant payment flow where authorization holds were incorrectly released when AML results arrived after the 5-second internal processing timeout. The system now properly manages fund release timing based on the actual timeout threshold rather than AML response arrival time. ### Event tenant assignment corrected in external gateway Resolved issue where incoming events were persisted with incorrect tenant information, causing events to be stored in one schema while generated events were published to a different tenant's topic. Tenant ID determination and persistence now maintain consistency throughout the event processing pipeline. ### Gateway visibility restored for pacs.028 messages with short originalMessageNameId Fixed issue preventing pacs.028 messages with abbreviated originalMessageNameId values from appearing in the gateway interface. ### Incoming instant pacs.002 error handling standardized for invalid originalMessageNameId Corrected inconsistent behavior when processing incoming instant pacs.002 messages with invalid originalMessageNameId values (e.g., "pacs.123"). The system now properly saves notifications with appropriate failure causes instead of triggering unhandled alerts, aligning with standard pacs.002 processing behavior. ### Bulk transaction instruction endpoint processing enhanced for CAMT message types Addressed missing transaction records in bulk processing where camt.029.001.08 and camt.027.001.06 messages were not being mapped to final API response objects. This ensures complete batch processing and accurate record counts for downstream systems. ### Alert messaging improved for pacs.002 invalid original message ID errors Enhanced error message clarity when pacs.002 messages contain invalid or shortened original message name IDs. Alert messages now properly display the actual originalMessageNameId value instead of showing "null" references, improving troubleshooting capabilities. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.90 URL: https://docs.mambu.com/release-notes/payments/v1.44.90/ ## v1.44.90 **Release Dates** * **Sandbox:** 30.03.2026 --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.91 URL: https://docs.mambu.com/release-notes/payments/v1.44.91/ ## v1.44.91 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Improvements ### Resolved timeout handling for outgoing SEPA instant payments with late confirmations Fixed issue where outgoing SEPA instant payments showed "Rejected Timeout" status but were successfully processed by the central bank, resulting in funds being credited to receiver accounts without proper debiting from customer accounts. The system now correctly handles pacs.008 messages that are accepted after the timeout period, ensuring proper account reconciliation with txId tracking. ### Enabled SEPA 2025 rulebook compliance configuration Implemented configuration flags to support SEPA 2025 requirements: enable2025RulebookChanges flag for general SEPA 2025 features, sepaInstantTimeoutInSeconds set to 10 seconds for incoming instant payments, sepaInstantOutgoingTimeoutInSeconds set to 5 seconds for outgoing pacs.008 messages, and sepaOutgoingInstantPacs002WaitingTimeInSeconds set to 10 seconds for incoming pacs.002 timeout handling. ### Added feature flag control for outgoing instant payment timeout processing Implemented enableSepaInstantOutgoingTimeout feature flag to control the Internal Processing Timeout functionality for outgoing instant payments, providing granular control over timeout behavior in production environments. ### Configured default debit account for late instant payment confirmations Established default debit account ZSYW111 for Indexo tenant to handle scenarios where pacs.002 confirmations arrive after 10 seconds and the original debtor account has insufficient funds. This ensures proper settlement of outgoing instant credit transfers even when confirmations are delayed. ### Corrected account debiting for timeout-accepted instant payments Resolved issue where funds remained unbooked when outgoing SEPA instant payments were accepted by the central bank after the 10-second timeout threshold. The system now properly debits funds from debtor accounts even when reservations are reversed due to late acceptance, maintaining accurate account balances for payments with delayed confirmations. ### Optimized timeout handling and processing delays for instant payments Addressed performance issues in sandbox environment where 4-second delays between payment initiation and AML callout processing, combined with AML validation time, caused payments to exceed the 10-second timeout threshold. Improved processing efficiency to prevent legitimate payments from being incorrectly rejected due to internal processing delays. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.92 URL: https://docs.mambu.com/release-notes/payments/v1.44.92/ ## v1.44.92 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Improvements ### Enhanced logging for /api/v1/payments:settleInstantPayment endpoint Improved error tracking and debugging capabilities for the settleInstantPayment API endpoint. The system now logs all exceptions and execution paths when returning 400 status codes, enabling faster issue resolution and more comprehensive error investigation. ### Updated IBAN Plus file integration with SWIFT directory Updated integration to retrieve the latest IBAN Plus file from the SWIFT directory. The system now accesses monthly flat files in XML format from the SWIFTRef download area, ensuring current IBAN validation data is maintained. ### Comprehensive logging implementation for /api/v1/payments:settleInstantPayment Added detailed logging functionality to the settleInstantPayment API endpoint. All exception handling and execution paths are now tracked when 400 errors occur, providing complete visibility into payment settlement processes for improved troubleshooting. --- ## Bug fixes ### Fixed timestamp format for outgoing instant payments to comply with W3C standards The timestamp format for outgoing instant payments has been corrected to remove trailing zeros, ensuring compliance with W3C recommendations and regulatory requirements. This resolves formatting inconsistencies where outgoing payments displayed timestamps with trailing zeros while incoming payments correctly omitted them. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.93 URL: https://docs.mambu.com/release-notes/payments/v1.44.93/ ## v1.44.93 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Improvements ### Updated pacs.009 scheduler timing configuration for production environment Updated the pacs.009 scheduler timing configuration for the outgoing-financial-institution-credit-transfer-ISO20022 scheduler in production. The scheduler now operates from 4:00 to 14:45 UTC starting March 27, 2026 EOB, modified from the previous 5:00 to 15:45 UTC timeframe. ### Updated pacs.009 scheduler timing configuration with dual timeframe support Updated the pacs.009 scheduler timing configuration for the outgoing-financial-institution-credit-transfer-ISO20022 scheduler in production to support dual operational timeframes. The scheduler operates from 5:00 to 15:45 UTC starting Monday October 27, and from 4:00 to 14:45 UTC prior to Sunday October 26, with automatic transitions on October 23rd and October 26th. ### Fixed GET instruction API error for incoming camt.027 messages Resolved a SERVICE_INVALID error occurring when calling GET /api/v1/instructions?direction=I&messageId= for incoming camt.027 messages. The fix addresses the NoSuchMethodException for ClaimNonReceiptV06.getClmNonRct() by correcting the FIELDPATH handling in the Camt027MessageBuilder for incoming messages, which previously saved paths with /ClmNonRct/ prefix while outgoing messages did not. ### Scaled up production environment resources Increased resource allocation and scaling configuration for the production environment to support enhanced performance and capacity requirements. ### Completed impact assessment for payment batch booking process enhancement Delivered feasibility and impact assessment for implementing partial settlement functionality in payment batch processing. The assessment covers the technical effort and operational impact of allowing payment batches (R-messages) to proceed with partial booking when individual payments contain errors, particularly incorrect original message IDs, while marking faulty transactions and sending appropriate notifications. ### Updated payment component library with postal address validation fix Updated the payment component library to resolve validation errors with hybrid postal address formatting. The fix addresses SEPA_EPC_INST002 validation failures that occurred when postal addresses contained both structured elements (PstCd, TwnNm, Ctry) and unstructured elements (AdrLine) in hybrid format configurations. ### Replaced deprecated organization settings API with internal configuration Replaced the deprecated /api/settings/organization endpoint with internal tenant-specific configuration for setting value dates in backdated transactions. This change addresses API V1 access restrictions and ensures proper timezone handling through internal configuration mapping rather than external API calls. ### Created timezone configuration mapping for multi-environment support Implemented TIME_ZONE_ID_MAP configuration mapping across all environments to support tenant-specific timezone settings. The configuration retrieves timezone values from the tenant.organization_view table and maps them per environment, enabling proper timezone handling for payment processing operations. ### Updated payment component library with postal address validation improvements Applied the latest payment component library update that includes fixes for postal address validation issues. This update resolves hybrid postal address format validation errors where combinations of structured and unstructured address elements previously triggered SEPA_EPC_INST002 validation failures. ### Replaced deprecated organization API with timezone configuration mapping Implemented internal timezone configuration mapping to replace calls to the deprecated /api/settings/organization endpoint. The new configuration uses tenant-specific timezone settings retrieved from the organization database, ensuring proper timezone handling for backdated transaction value date calculations without relying on deprecated API endpoints. ### Updated payments component library to latest version Updated the payments component library to the most recent version, incorporating the latest fixes and improvements for payment processing functionality. ### Enhanced ps-scheduler logging for improved operational visibility Added comprehensive logging to the ps-scheduler component to provide better operational visibility and troubleshooting capabilities for payment scheduling operations. --- ## Bug fixes ### Fixed null pointer exception in camt.027 message processing when transaction list is empty Resolved a critical error that occurred when processing camt.027 messages with empty transaction lists. The instruction endpoint now properly handles cases where no transaction details are available, preventing system failures during message processing. ### Fixed instruction endpoint error for pacs.004 bulk message processing Corrected a 500 error in the instruction endpoint when processing pacs.004 bulk messages. The fix addresses message type routing issues that occurred after the 2025 regulatory changes, where pacs.003.001.08 messages were incorrectly processed as pacs.008 format, and resolves the missing getAmdmntInd() method exception. ### Fixed outgoing instant payment rejection logic for insufficient funds scenarios Corrected the payment flow for outgoing instant credit transfers when positive pacs.002 confirmations arrive after the 10-second timeout and insufficient funds exist in both debtor and default accounts. Payments now remain in pending_settlement status instead of being incorrectly rejected, with proper notification mechanisms for fund shortage situations. ### Fixed settlement date assignment for pacs.009 payments processed after cut-off time Resolved an issue where outgoing pacs.009 FI-to-FI payments processed outside scheduled hours were assigned incorrect settlement dates. The system now properly manages cut-off time enforcement to prevent processing of pacs.009 transfers beyond scheduler boundaries. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.94 URL: https://docs.mambu.com/release-notes/payments/v1.44.94/ ## v1.44.94 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Improvements ### Enhanced Gateway Dispatch Error Logging with Aggregate ID Added aggregateId parameter to gateway dispatch error logs to improve troubleshooting capabilities for Kafka dispatch failures. This enhancement provides more granular error tracking and faster resolution of GatewayDispatchToKafkaErrorAlert incidents. ### PACS.007 Processing Flow Investigation for Bulk Payment Status Discrepancies Investigated PACS.007 message processing flow following bulk payment processing issues where 346 reversed payments incorrectly received REVERSE_REJECTED status instead of REVERSE_ACCEPTED. The investigation identified status handling discrepancies in OutgoingDDScheduler for payments with txId references, particularly affecting storno transaction processing and alert generation with MS03 reason codes. ### Enhanced OutgoingScheduler Logging for Improved Incident Analysis Improved logging completeness for OutgoingScheduler processing flows to support more effective incident investigation and SF case analysis. Enhanced log coverage provides better visibility into scheduler progress and processing states during troubleshooting scenarios. ### Increased HTTP Timeout Values for CSM and AML Callouts Updated CALLOUT_HTTP_CONNECT_TIMEOUT_MS and CALLOUT_HTTP_READ_TIMEOUT_MS configuration values from default 10 seconds to 30 seconds for Check24 environments (production and sandbox). This aligns timeout settings with other client configurations and improves callout reliability for external service integrations. ### SWIFT IBAN Plus Directory File Retrieval Retrieved latest IBAN Plus directory file in XML format from SWIFT reference data portal (swift.com) for payment validation and routing purposes. Updated reference data ensures accurate IBAN validation against current SWIFT standards. ### Multi-Threading Implementation for Incoming PACS.003 Bulk Processing Implemented multi-threading batch processing enhancement for IncomingScheduler.processIncomingNotifications to improve PACS.003 bulk payment processing performance. Each incoming notification now processes on dedicated threads with maximum 5 concurrent threads, requiring corresponding CPU allocation increases for gateway-api pods. ### SEPABLKHEDSN Column Null Value Handling in Incoming Scheduler Updated incoming scheduler processing to prevent "Column 'SEPABLKHEDSN' cannot be null" database errors during payment message processing. This fix ensures proper column value handling for SEPA bulk header sequence numbers. ### AML Notification Retry Policy Investigation and Enhancement Investigated and improved AML retry policy following production issues where notifications failed with 500 status codes and generated multiple ScheduleAction commands. Enhanced retry logic includes improved logging across ps-scheduler and po-external-gateway-api services, optimized retry intervals, and better alert handling for failed AML callout notifications. ### Error Message Information Disclosure Remediation Implemented generic error message handling for the /props endpoint to prevent exposure of internal SQL statements, database structure, and MySQL driver details. Replaced verbose error responses containing PreparedStatementCallback and MysqlDataTruncation exceptions with sanitized client-facing messages while preserving detailed logging for server-side troubleshooting. ### Bootstrap Library Security Update Updated Bootstrap JavaScript library from vulnerable version 3.4.1 to current maintained version to address CVE-2024-6484 XSS vulnerability. Removed end-of-life Bootstrap 3.x dependency and upgraded to supported version with active security maintenance. --- ## Bug fixes ### Fixed error when decreasing incomingDirectDebitRetryDays system property Resolved an issue where decreasing the incomingDirectDebitRetryDays system property caused transaction status synchronization failures between po-external-gateway and po-api-projection. The payment service will now correctly handle FailPaymentOrderevents with IncomingDirectDebitRetryExhausted cause and stop inappropriate retry attempts when the retry period is reduced. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.95 URL: https://docs.mambu.com/release-notes/payments/v1.44.95/ ## v1.44.95 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Improvements ### Optimized pacs.003 batch processing performance for direct debit transactions Removed the handleReversals method from pacs.003 batch processing to significantly improve processing performance. This optimization ensures that when pacs.007 reversal notifications are processed before their corresponding pacs.003 notifications, the system now handles the reversal logic through the standard retry scheduler flow rather than during batch processing. The change maintains proper transaction state management while reducing processing overhead for high-volume direct debit batches. ### Updated IBAN Plus directory integration with latest SWIFT reference data Enhanced the IBAN Plus file retrieval process to use the most recent monthly flat files from swift.com. The system now automatically accesses the latest XML format IBAN Plus directory through the SWIFT Download Area, ensuring payment validation uses current international banking directory information for improved transaction accuracy and compliance. --- ## Bug fixes ### Fixed missing IncomingDirectDebitReceivedEvents when pod restarts during pacs.003 batch processing Resolved an issue where pod restarts during pacs.003 bulk processing with enablePacs003BatchTransactionProcessing = true would cause incomplete transaction handling. The system now properly executes handleReversals and persistBatchIncomingDirectDebitReceivedEvent steps for all transactions in the batch after restart, ensuring complete SEPA transaction processing continuity. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.96 URL: https://docs.mambu.com/release-notes/payments/v1.44.96/ ## v1.44.96 **Release Dates** * **Sandbox:** 30.03.2026 --- ## Features ### Enhanced Instructions Endpoint with Single Transaction Retrieval The Instructions endpoint now supports retrieving details for a single transaction using the new txId parameter. When direction, messageType, messageId, and txId are all provided, the system prioritizes txId and returns the specific transaction details, ignoring other parameters. This eliminates the need to fetch entire bulk transaction sets or use unbounded queries, reducing database load and improving query performance. --- ## Improvements ### IBAN Plus directory file retrieval process updated Updated the process for retrieving IBAN Plus directory files from SWIFT network. The system now accesses monthly XML format files through the SWIFTRef download area, ensuring up-to-date IBAN validation data for payment processing. ### AML result processing failure for outgoing instant credit transfers resolved Fixed intermittent failures in AML result processing for outgoing instant credit transfers that occurred daily since November 27, 2025. The issue prevented transaction status updates from BULKED to SENT_PENDING_CONFIRMATION, causing authorization hold reversals due to pacs.002 timeouts. Enhanced error logging for database update operations to improve failure detection and troubleshooting. ### Wiremock service removed from sandbox deployment pipeline Removed po-wiremock service from the sandbox environment deployment pipeline to streamline the deployment process and reduce unnecessary service dependencies in the testing environment. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # Payments - v1.44.97 URL: https://docs.mambu.com/release-notes/payments/v1.44.97/ ## v1.44.97 **Release Dates** * **Sandbox:** 31.03.2026 --- ## Improvements ### Enhanced notification service logging for improved troubleshooting Improved logging capabilities in the notification service to provide better diagnostic information and faster issue resolution. ### Resolved timeout issues on Incoming SEPA Direct Debit page Fixed timeout issues affecting the Incoming SEPA Direct Debit page during high-volume processing periods. The page now loads reliably when displaying pending and processed incoming pacs.003 payments, particularly during end-of-month operations when bulk message processing is at peak volume. ### Updated IBAN Plus reference file to latest version Retrieved and implemented the most recent IBAN Plus reference file from SWIFT to ensure accurate IBAN validation and processing capabilities. ### Fixed AML result processing failure for Outgoing Instant Credit Transfers Resolved an issue where AML accepted results were not properly processed for outgoing instant credit transfers, which previously caused transaction status updates to fail and prevented pacs.008 messages from being sent. The fix ensures proper status transitions from PENDING_AML to TO_BE_SENT and subsequent processing steps complete successfully. --- ## Bug fixes ### Fixed pacs.004 direct debit transaction status incorrectly showing REJECTED instead of RECEIVED Fixed an issue where pacs.004 direct debit transactions displayed a status of REJECTED when they should have shown RECEIVED. This occurred when original pacs.003 transactions were returned or refunded. The system now correctly sets pacs.004 transaction status to RECEIVED ('01') when the original pacs.003 status is RETURNED ('03') or REFUNDED ('34'). ### Fixed missing sepablk data error when updating rejected credit transfer status Resolved an error in external-gateway FailPaymentOrderHandler where suspended credit transfers being rejected would fail due to missing sepablk data. The system now properly handles sepatrnhed transaction and AML status updates to REJECTED without encountering null sepablk references in TemporaryDataService. ### Fixed duplicate transaction processing issue in incoming pacs.008 with same txId across different bulks Corrected the transaction filtering logic in incoming pacs.008 processing that incorrectly skipped transactions with identical txId values when they appeared in different bulks. The SepaRepository.filterOutExistingTransactions method now properly considers bulk differentiation, ensuring all valid transactions are processed regardless of txId duplication across separate bulks. ### Fixed user account remaining disabled after password reset following failed login attempts Resolved an issue where user accounts disabled after 5 failed login attempts remained disabled even after password reset. The system now properly re-enables user accounts during the password reset process, restoring normal access without requiring manual intervention. --- For more information on the release timeline, see [Mambu Release Cycle](/docs/mambu-release-cycle). --- # About Mambu API V1 URL: https://docs.mambu.com/api/pages/api-v1/about-mambu-api-v1/ ## Posting Data API requests that post data can either use URL-encoded query parameters or a JSON body to enter data. The `Content-Type` header must be set to `application/json` for the JSON request. The examples to the right, show the two methods for posting data. Note that for some requests, much more information can be posted using the JSON input than is available with query parameters. > Using query parameters ```curl curl -d "type=APPROVAL" https://user:pword@test.mambu.com/api/loans/4028329c3ad6c515013ad6d0f6e40006/transactions ``` > Using JSON: ```curl curl -H "Accept: application/json" -H "Content-Type: application/json" -X POST -d ' https://user:pword@test.mambu.com/api/loans/4028329c3ad6c515013ad6d0f6e40006/transactions` ``` ### Example The example to the right makes a request using the username `user`, the password `pword` to the tenant `demo` to retrieve all repayments for loan account `abc` > Request with authorization made ... ``` https://user:pword@demo.mambu.com/api/loans/abc/repayments ``` > And returns a response such as: ```json [ { "encodedKey": "402832b4380a2d8801380a9cac860010", "parentAccountKey": "402832b4380a2d8801380a9cac41000f", "dueDate": "2012-07-28T00:00:00+0200", "principalDue": "190", "principalPaid": "0", "interestDue": "25.45", "interestPaid": "0", "state": "PENDING" }, { "encodedKey": "402832b4380a2d8801380a9cac870011", "parentAccountKey": "402832b4380a2d8801380a9cac41000f", "dueDate": "2012-08-28T00:00:00+0200", "principalDue": "190", "principalPaid": "0", "interestDue": "26.29", "interestPaid": "0", "state": "PENDING" } ] ``` :::note Using the `Authorization` header You can alternatively supply your username and password directly via the `Authorization` header in the format `Basic ` where `base64-encoded-string` is the base 64 encoded value of your username and password separated by a colon ':', ie `dXNlcm5hbWU6cGFzc3dvcmQ=` would be the result for `username:password`. ::: --- # Audit Trail and the User-Agent Header URL: https://docs.mambu.com/api/pages/api-v1/audit-trail-and-the-user-agent-header/ > Error when User Agent header is not provided ```json { "errors": [ { "errorCode": 4, "errorSource": "The user agent cannot be null when the Audit Trail feature is enabled", "errorReason": "INVALID_PARAMETERS" } ] } ``` Audit trail tracks all activities performed in the Mambu Core Banking system via the UI or API v1 and v2. For more information, see [Audit Trail](/docs/audit-trail) in our User Guide. When the audit trail feature is enabled, you **must** provide a `User-Agent` header for **all requests to any endpoint**, or the request will fail with the error message `The user agent cannot be null when the Audit Trail feature is enabled`. Note that if you are using a REST client like Postman or Curl, this header is probably provided automatically. However, if you generate a request to the API, you must provide it yourself. The User-Agent header provides information regarding the browser and operating system (such as the browser version), and information about the library or tool issuing the request (such as the client Java version). It is generally used to assist with debugging problems. --- # Authentication URL: https://docs.mambu.com/api/pages/api-v1/authentication/ Mambu supports two methods for authenticating API requests: * Basic authentication, using Mambu UI login credentials for a user account with **API** access permissions. * API keys, which are unique UUID tokens provided in an `apiKey` header (Early Access Feature). ## Basic Authentication > Example using curl ```shell curl --location --request GET 'https://TENANT_NAME.mambu.com/api/users' \ --header 'Authorization: Basic U29tZVVzZXI6T3BlblNlc2FtZQ==' ``` For basic authorization, provide your username and password directly via the `Authorization` header in the format `Basic `, where `base64-encoded-string` is the base-64-encoded value of your username and password separated by a colon ':'. For example, a user with the username `SomeUser` and the password `OpenSesame` would take the value `SomeUser:OpenSesame` and base-64 encode it, yielding `U29tZVVzZXI6T3BlblNlc2FtZQ==`. They would then provide an `Authorization` header for their request with the value `Basic U29tZVVzZXI6T3BlblNlc2FtZQ==`. See the example `GET` requests to the `/users` endpoint using curl. Note that the login credentials must be for an account with **API** access permissions. For more information, see [Creating a User - Access Rights](/docs/creating-new-users#access-rights) in our User Guide. :::note To ensure the username and password cannot be intercepted, all requests must use HTTPS. ::: ## API Keys API keys are tokens that you provide in an `apiKey` header to authenticate requests. They are generated by API consumers, which are an abstraction similar to an OAuth client. API consumers are currently an Early Access Feature. If you would like to request access to this feature, please get in touch with your Mambu Customer Success Manager to discuss your requirements. For more information on API consumers and keys, see [API Consumers](/docs/api-consumers) in our User Guide. --- # Base URLs URL: https://docs.mambu.com/api/pages/api-v1/base-urls/ The base URL for API requests is: * `https://TENANT_NAME.mambu.com/api` :::note Replace `TENANT_NAME` above with the tenant name in your Mambu tenant URL. ::: To make API requests to your tenant's sandbox, use the following base URL: * `https://TENANT_NAME.sandbox.mambu.com/api` For more information, see the [Sandbox](/api/pages/api-v1/sandbox) section. --- # Custom View Filtering URL: https://docs.mambu.com/api/pages/api-v1/custom-view-filtering/ Custom views are used to define and display specific groups or subsets of clients, users, loan accounts, and other entities. Examples of custom views include: * Listing all clients in an active state. * Listing all loan accounts that are 90 days in arrears. * Listing all the withdrawal transactions higher than USD700,000. Custom views may be used to configure tabs and reports in the Mambu UI. Once they are defined, they may also be used to filter requests with the Mambu v1 API. Several `GET` requests allow filtering the returned results with the criteria defined by an existing custom view. This can be a quick and convenient way to easily filter requests. For more information on using custom views to filter requests, see [Custom Views and API v1](/docs/custom-views-and-api-v1) in our User Guide. For general information, see [Custom Views](/docs/custom-views). --- # Data Types and Examples URL: https://docs.mambu.com/api/pages/api-v1/data-types-and-examples/ ## Clients **Get all loan transactions for a specific client** ```json POST /api/clients/search { "filterConstraints":[ { "filterSelection":"ID", "filterElement":"EQUALS", "dataItemType":"CLIENT", "value":"197495342" } ], "sortDetails":{ "sortingColumn":"ID", "sortingOrder":"DESCENDING" } } ``` |Filter Selection Parameter|Data Type| |---|---| |`CREDIT_OFFICER_KEY`|`KEY`| |`CLIENT_ROLE_KEY`|`KEY`| |`BRANCH_KEY`|`KEY`| |`CENTRE_KEY`|`KEY`| |`GROUP_KEY`|`KEY`| |`ENCODED_KEY`|`KEY`| |`FULL_NAME`|`STRING`| |`FIRST_NAME`|`STRING`| |`MIDDLE_NAME`|`STRING`| |`LAST_NAME`|`STRING`| |`CREATION_DATE`|`DATE_UTC`| |`LAST_MODIFIED_DATE`|`DATE_UTC`| |`ID`|`STRING`| |`DEPOSITS_BALANCE`|`MONEY`| |`LOANS_BALANCE`|`MONEY`| |`PENDING_LOAN_AMOUNT`|`MONEY`| |`APPROVED_LOAN_AMOUNT`|`MONEY`| |`TOTAL_BALANCE`|`MONEY`| |`TOTAL_DUE`|`MONEY`| |`HOME_PHONE_NUMBER`|`STRING`| |`MOBILE_PHONE_NUMBER`|`STRING`| |`EMAIL_ADDRESS`|`STRING`| |`CLIENT_ADDRESS`|`STRING`| |`BIRTHDATE`|`DATE`| |`GENDER`|`ENUM`| |`LOAN_CYCLE`|`NUMBER`| |`GROUP_LOAN_CYCLE`|`NUMBER`| |`CLIENT_STATE`|`ENUM`| |`PORTAL_STATE`|`ENUM`| |`PREFERRED_LANGUAGE`|`ENUM`| |`GROUP_ID`|`STRING`| ## Groups **Get all groups created in specific date range** ```json POST /api/groups/search { "filterConstraints":[ { "filterSelection":"CREATION_DATE", "filterElement":"BETWEEN", "value":"2015-01-01", "secondValue":"2015-06-20" } ] } ``` **Get all groups that have the custom field definition with the encoded key `8afac14a34d69cd00134d70c0abe00d3` and custom field value `test`** ```json POST /api/groups/search { "filterConstraints":[ { "filterSelection":"8afac14a34d69cd00134d70c0abe00d3", "filterElement":"EQUALS", "value":"test", "dataFieldType":"CUSTOM" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`CLIENT_ROLE_KEY`|`KEY`| |`BRANCH_KEY`|`KEY`| |`CENTRE_KEY`|`KEY`| |`CREDIT_OFFICER_KEY`|`KEY`| |`ENCODED_KEY`|`KEY`| |`GROUP_NAME`|`STRING`| |`CREATION_DATE`|`DATE_UTC`| |`LAST_MODIFIED_DATE`|`DATE_UTC`| |`ID`|`STRING`| |`PREFERRED_LANGUAGE`|`ENUM`| |`DEPOSITS_BALANCE`|`MONEY`| |`LOANS_BALANCE`|`MONEY`| |`TOTAL_BALANCE`|`MONEY`| |`NUMBER_OF_MEMBERS`|`NUMBER`| |`LOAN_CYCLE`|`NUMBER`| ## Loan Accounts **Get all loans that are in two different products** ```json POST /api/loans/search { "filterConstraints":[ { "filterSelection":"PRODUCT_KEY", "filterElement":"IN", "values":[ "ff8080814eaa832d014eaa88e24d034c", "ad8080814eaa832d014eaa88e252034e" ] } ] } ``` **Get all loan accounts created within a date range** ```json POST /api/loans/search { "filterConstraints":[ { "filterSelection":"CREATION_DATE", "filterElement":"BETWEEN", "value":"2015-06-15", "secondValue":"2015-06-20" } ] } ``` **Get all loan accounts that have the custom field value `test`. This custom field definition is of type string and it belongs to a loan entity** ```json POST /api/loans/search { "filterConstraints":[ { "filterSelection":"8a808085507f02b901507f02f59700ea", "filterElement":"EQUALS", "value":"test" }, { "filterSelection":"CREATION_DATE", "dataItemType":"CLIENT", "filterElement":"ON", "value":"2015-10-19" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`ACCOUNT_HOLDER_KEY`|`KEY`| |`PRODUCT_KEY`|`KEY`| |`LOAN_RISK_LEVEL_KEY`|`KEY`| |`ENCODED_KEY`|`KEY`| |`LOAN_NAME`|`STRING`| |`ACCOUNT_ID`|`STRING`| |`ACCOUNT_HOLDER_ID`|`STRING`| |`RECIPIENT`|`STRING`| |`CREATION_DATE`|`DATE_UTC`| |`APPROVAL_DATE`|`DATE`| |`LAST_MODIFIED_DATE`|`DATE_UTC`| |`LAST_SET_TO_ARREARS_DATE`|`DATE`| |`LAST_LOCKED_DATE`|`DATE`| |`CLOSED_DATE`|`DATE`| |`DAYS_IN_ARREARS`|`NUMBER`| |`DAYS_LATE`|`NUMBER`| |`ACCOUNT_SUB_STATE`|`ENUM`| |`ACCOUNT_STATE`|`ENUM`| |`LOAN_AMOUNT`|`MONEY`| |`DISBURSED_TRANCHES_AMOUNT`|`MONEY`| |`NUM_INSTALLMENTS`|`NUMBER`| |`PRINCIPAL_DUE`|`MONEY`| |`PRINCIPAL_PAID`|`MONEY`| |`PRINCIPAL_BALANCE`|`MONEY`| |`INTEREST_DUE`|`MONEY`| |`INTEREST_PAID`|`MONEY`| |`INTEREST_BALANCE`|`MONEY`| |`INTEREST_ACCRUED`|`MONEY`| |`FEES_DUE`|`MONEY`| |`FEES_BALANCE`|`MONEY`| |`FEES_PAID`|`MONEY`| |`PENALTY_CALCULATION_METHOD`|`ENUM`| |`PENALTY_DUE`|`MONEY`| |`PENALTY_PAID`|`MONEY`| |`PENALTY_BALANCE`|`MONEY`| |`PENALTY_ACCRUED`|`MONEY`| |`PENALTY_RATE`|`BIG_DECIMAL`| |`ARREARS_TOLERANCE_PERIOD`|`NUMBER`| |`INTEREST_RATE`|`BIG_DECIMAL`| |`INTEREST_SPREAD`|`BIG_DECIMAL`| |`TOTAL_PAID`|`MONEY`| |`TOTAL_BALANCE`|`MONEY`| |`TOTAL_DUE`|`MONEY`| |`FIRST_REPAYMENT_DATE`|`DATE`| |`LAST_PAYMENT_DATE`|`DATE`| |`LAST_PAYMENT_AMOUNT`|`MONEY`| |`EXPECTED_MATURITY_DATE`|`DATE`| |`RESCHEDULED_ACCOUNT_ID`|`STRING`| |`REFINANCED_ACCOUNT_ID`|`STRING`| |`ORIGINAL_ACCOUNT_ID`|`STRING`| |`TAX_RATE`|`BIG_DECIMAL`| |`TAX_PAID`|`MONEY`| |`TAX_DUE`|`MONEY`| |`HAS_SETTLEMENT_ACCOUNT`|`BOOLEAN`| |`INTEREST_COMMISSION`|`BIG_DECIMAL`| |`FUNDS_AMOUNT`|`MONEY`| |`FUNDING_PERCENTAGE`|`BIG_DECIMAL`| |`NUMBER_OF_FUNDS`|`NUMBER`| |`FUNDS_ENABLED`|`BOOLEAN`| |`AVAILABLE_AMOUNT`|`MONEY`| |`WAS_RESCHEDULED`|`BOOLEAN`| |`WAS_REFINANCED`|`BOOLEAN`| |`PREPAYMENTS_RECALCULATION`|`ENUM`| |`APPLY_INTEREST_ON_PREPAYMENT_METHOD`|`ENUM`| |`LATE_PAYMENT_RECALCULATION_METHOD`|`ENUM`| |`REDRAW_BALANCE`|`MONEY`| |`EXPECTED_PRINCIPAL_REDRAW`|`MONEY`| ## Tranches **Get all loan accounts where loan disbursement tranches have been defined but not yet disbursed** ```json POST /api/loans/search { "filterConstraints":[ { "filterSelection":"DISBURSEMENT_TRANSACTION_KEY", "dataItemType":"TRANCHE", "filterElement":"EMPTY" } ] } ``` **Get all loan accounts with a loan disbursement tranche where the amount is `100`** ```json POST /api/loans/search { "filterConstraints":[ { "filterSelection":"AMOUNT", "dataItemType":"TRANCHE", "filterElement":"EQUALS", "value":"100" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`ENCODED_KEY`|`KEY`| |`PARENT_ACCOUNT_KEY`|`KEY`| |`DISBURSEMENT_TRANSACTION_KEY`|`KEY`| |`AMOUNT`|`MONEY`| |`EXPECTED_DISRBUSEMENT_DATE`|`DATE`| ## Disbursement Details **Get all loans disbursed during March 2021** ```json POST /api/loans/search { "filterConstraints":[ { "filterSelection":"DISBURSEMENT_DATE", "dataItemType":"DISBURSEMENT_DETAILS", "filterElement":"BETWEEN", "value":"2021-03-01", "secondValue":"2021-03-30" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`EXPECTED_DISBURSEMENT_DATE`|`DATE`| |`DISBURSEMENT_DATE`|`DATE`| ## Savings Accounts **Get all `APPROVED` and `PENDING_APPROVAL` savings accounts** ```json POST /api/savings/search { "filterConstraints":[ { "filterSelection":"ACCOUNT_STATE", "filterElement":"IN", "values":[ "PENDING_APPROVAL", "APPROVED" ] } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`ACCOUNT_HOLDER_KEY`|`KEY`| |`PRODUCT_KEY`|`KEY`| |`CURRENCY_CODE`|`KEY`| |`OVERDRAFT_RISK_LEVEL_KEY`|`KEY`| |`ENCODED_KEY`|`KEY`| |`ACCOUNT_ID`|`STRING`| |`ACCOUNT_HOLDER_ID`|`STRING`| |`RECIPIENT`|`STRING`| |`CREATION_DATE`|`DATE_UTC`| |`APPROVAL_DATE`|`DATE`| |`ACTIVATION_DATE`|`DATE`| |`LAST_MODIFIED_DATE`|`DATE_UTC`| |`MATURITY_DATE`|`DATE`| |`CLOSED_DATE`|`DATE`| |`ACCOUNT_STATE`|`ENUM`| |`ACCOUNT_NAME`|`STRING`| |`RECOMENDED_DEPOSIT_AMOUNT`|`MONEY`| |`DEPOSIT_AMOUNT`|`MONEY`| |`MAX_WITHDRAWAL_AMOUNT`|`MONEY`| |`TARGET_AMOUNT`|`MONEY`| |`BALANCE`|`MONEY`| |`MAX_BALANCE`|`MONEY`| |`ACCRUED_INTEREST`|`MONEY`| |`INTEREST_RATE`|`BIG_DECIMAL`| |`OVERDRAFT_INTEREST_ACCRUED`|`MONEY`| |`OVERDRAFT_AMOUNT`|`MONEY`| |`OVERDRAFT_EXPIRY_DATE`|`DATE`| |`LAST_SET_TO_ARREARS_DATE`|`DATE`| |`OVERDRAFT_INTEREST_RATE`|`BIG_DECIMAL`| |`OVERDRAFT_INTEREST_SPREAD`|`BIG_DECIMAL`| |`OVERDRAFT_LIMIT`|`MONEY`| |`OVERDRAFT_AVAILABLE_LIMIT`|`MONEY`| |`OVERDRAFT_IN_ARREARS`|`MONEY`| |`OVERDRAFT_DAYS_IN_ARREARS`|`NUMBER`| |`INTEREST_DUE`|`MONEY`| |`FEES_DUE`|`MONEY`| |`LENGTH_IN_DAYS`|`NUMBER`| |`ACCOUNT_TYPE`|`ENUM`| |`CURRENT_INTEREST_TIER_INDEX`|`NUMBER`| |`CURRENT_INTEREST_TIER_STARTING_BALANCE`|`MONEY`| |`CURRENT_INTEREST_TIER_ENDING_BALANCE`|`MONEY`| |`CURRENT_INTEREST_TIER_RATE`|`BIG_DECIMAL`| |`CURRENT_OVERDRAFT_INTEREST_TIER_INDEX`|`NUMBER`| |`CURRENT_OVERDRAFT_INTEREST_TIER_STARTING_BALANCE`|`MONEY`| |`CURRENT_OVERDRAFT_INTEREST_TIER_ENDING_BALANCE`|`MONEY`| |`CURRENT_OVERDRAFT_INTEREST_TIER_RATE`|`BIG_DECIMAL`| |`TAX_APPLIED`|`MONEY`| |`TAX_RATE`|`BIG_DECIMAL`| ## Transactions **Get the repayments transactions for loans that are more than 10 days in arrears** ```json POST /api/loans/transactions/search { "filterConstraints":[ { "filterSelection":"DAYS_IN_ARREARS", "filterElement":"MORE_THAN", "dataItemType":"LOANS", "value":"10" }, { "filterSelection":"EVENT", "filterElement":"EQUALS", "dataItemType":"LOAN_TRANSACTION", "value":"REPAYMENT" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`PARENT_ACCOUNT_KEY`|`KEY`| |`PRODUCT_TYPE_KEY`|`KEY`| |`USER_KEY`|`KEY`| |`BRANCH_KEY`|`KEY`| |`CENTRE_KEY`|`KEY`| |`PARENT_ACCOUNT_HOLDER_KEY`|`KEY`| |`CURRENCY_CODE`|`KEY`| |`PRODUCT_ID`|`STRING`| |`WAS_REVERSED`|`BOOLEAN`| |`TYPE_IS_REVERSAL`|`BOOLEAN`| |`INTERNAL_TRANSFER`|`BOOLEAN`| |`TRANSACTION_CHANNEL_KEY`|`KEY`| |`ENCODED_KEY`|`KEY`| |`TRANSACTION_ID`|`LONG`| |`TILL_ID`|`STRING`| |`ENTRY_DATE`|`DATE`| |`TRANSACTION_DATE`|`DATE_UTC`| |`EVENT`|`ENUM`| |`AMOUNT`|`MONEY`| |`ADVANCE_POSITION`|`MONEY`| |`ARREARS_POSITION`|`MONEY`| |`EXPECTED_PRINCIPAL_REDRAW`|`MONEY`| |`ORIGINAL_AMOUNT`|`MONEY`| |`ORIGINAL_AMOUNT_CURRENCY_CODE`|`STRING`| |`BALANCE `(Deprecated. Use `TOTAL_BALANCE`)|`MONEY`| |`TOTAL_BALANCE`|`MONEY`| |`PRINCIPAL_BALANCE`|`MONEY`| |`REDRAW_BALANCE`|`MONEY`| |`PRINCIPAL_PAID`|`MONEY`| |`INTEREST_PAID`|`MONEY`| |`DEFERRED_INTEREST`|`MONEY`| |`FEES_PAID`|`MONEY`| |`FEE_KEY`|`KEY`| |`FEE_TYPE`|`ENUM`| |`PENALTY_PAID`|`MONEY`| |`BRANCH`|`STRING`| |`CENTRE`|`STRING`| |`PARENT_ACCOUNT`|`STRING`| |`PARENT_ACCOUNT_ID`|`STRING`| |`PARENT_ACCOUNT_HOLDER`|`STRING`| |`PARENT_ACCOUNT_HOLDER_ID`|`STRING`| |`TAX_RATE`|`BIG_DECIMAL`| |`TAX_AMOUNT`|`MONEY`| |`INTEREST_RATE`|`BIG_DECIMAL`| |`PRINCIPAL_PAYMENT_FLAT_AMOUNT`|`MONEY`| |`PRINCIPAL_PAYMENT_PERCENTAGE`|`BIG_DECIMAL`| |`TOTAL_DUE_FLAT_AMOUNT`|`MONEY`| |`TOTAL_BALANCE_PERCENTAGE`|`BIG_DECIMAL`| |`OVERDRAFT_INTEREST_RATE`|`BIG_DECIMAL`| |`OVERDRAFT_LIMIT`|`MONEY`| ## Notifications **Get all notification messages for `LOAN_CREATED` notifications** ```json POST /api/notifications/messages/search { "filterConstraints":[ { "filterSelection":"EVENT", "filterElement":"EQUALS", "value":"LOAN_CREATED" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`SENDER_KEY`|`KEY`| |`RECIPIENT_CLIENT_KEY`|`KEY`| |`RECIPIENT_GROUP_KEY`|`KEY`| |`RECIPIENT_USER_KEY`|`KEY`| |`ENCODED_KEY`|`KEY`| |`CREATION_DATE`|`DATE_UTC`| |`SENT_DATE`|`DATE_UTC`| |`STATE`|`ENUM`| |`FAILURE_REASON`|`ENUM`| |`DESTINATION`|`STRING`| |`TYPE`|`ENUM`| |`EVENT`|`ENUM`| ## General Ledger Journal Entries **Get the journal entry with entry id `1`, posted by the user with the encoded key `8a8080a254a9659b0154a965a69a0004`** ```json POST /api/gljournalentries/search { "filterConstraints":[ { "filterSelection":"USER_KEY", "filterElement":"EQUALS", "value":"8a8080a254a9659b0154a965a69a0004" }, { "filterSelection":"ENTRY_ID", "filterElement":"EQUALS", "value":"1" } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`PRODUCT_TYPE`|`ENUM`| |`GL_ACCOUNT_KEY`|`KEY`| |`USER_KEY`|`KEY`| |`ENCODED_KEY`|`STRING`| |`ENTRY_ID`|`NUMBER`| |`DATE`|`DATE`| |`CREATION_DATE`|`DATE`| |`TRANSACTION_ID`|`STRING`| |`GL_ACCOUNT_ID`|`STRING`| |`GL_ACCOUNT_TYPE`|`ENUM`| |`SOURCE`|`ENUM`| |`DEBIT`|`MONEY`| |`CREDIT`|`MONEY`| ## Lines of Credit **Get all lines of credit identified by state `CLOSED`** ```json POST /api/linesofcredit/search { "filterConstraints":[ { "filterSelection":"STATE", "filterElement":"IN", "values":[ "CLOSED" ] } ] } ``` **Get all lines of credit identified by exposure limit types `APPROVED_AMOUNT` and `OUTSTANDING_AMOUNT`** ```json POST /api/linesofcredit/search { "filterConstraints":[ { "filterSelection":"EXPOSURE_LIMIT_TYPE", "filterElement":"IN", "values":[ "APPROVED_AMOUNT","OUTSTANDING_AMOUNT" ] } ] } ``` |Filter Selection Parameter|Data Type| |---|---| |`ID`|`STRING`| |`START_DATE`|`DATE`| |`EXPIRY_DATE`|`DATE`| |`APPROVAL_DATE`|`DATE`| |`STATE`|`ENUM`| |`SUBSTATE`|`ENUM`| |`EXPOSURE_LIMIT_TYPE`|`ENUM`| ## Object Search **Search through all object types for the object that might contain `john`** ```json GET /api/search?query=john&type=[CLIENT,USER]&limit=10 { "CLIENT": [ { "selectionType": "CLIENT", "displayString": "John Demo", "resultID": "517706810", "resultKey": "8a42711a4428c1f101442a1bbcbc0009" }, { "selectionType": "CLIENT", "displayString": "John Master", "resultID": "603117506", "resultKey": "8a42711a4428c1f101442a1ee710001b" } ], "CREDIT_OFFICER": [ { "selectionType": "CREDIT_OFFICER", "displayString": "johnty billingsworth", "resultID": "johntybilling", "resultKey": "8a19dab474909bc8017490f2fb9006a8" } ], "USER": [ { "selectionType": "USER", "displayString": "John Doe", "resultID": "61", "resultKey": "8a54e5b44449337f01444b03efa3000e" } ], "SAVINGS_ACCOUNT": [], "CUSTOM_FIELD_SELECTION": [], "CENTRE": [], "FILTER_CUSTOM_FIELD_SELECTION": [], "BRANCH": [], "LOAN_ACCOUNT": [], "GROUP": [], "LINE_OF_CREDIT": [] } ``` |Object type|Keyword fields| |---|---| |`CLIENT`|first name, middle name, last name, id| |`GROUP`|group name, id| |`LOAN_ACCOUNT`|account id| |`SAVINGS_ACCOUNT`|account id| |`USER`|first name, last name, username| |`BRANCH`|branch name, branch id| |`CENTRE`|centre name, centre id| --- # Detail Level URL: https://docs.mambu.com/api/pages/api-v1/detail-level/ Some Mambu API v1 endpoints support two levels of detail for responses, basic details and full details. To retrieve a response in full details, you must set the `fullDetails` query parameter to `true`. ## Basic details By default, Mambu API v1 will return basic details, this includes all first level elements of an object. ## Full details Some endpoints can return full details, this includes everything from basic details as well as all custom field values, any address or contact information, and any other related objects. --- # Filter Constraints URL: https://docs.mambu.com/api/pages/api-v1/filter-constraints/ Example query with an array of filters on a standard field and a custom field definition and its value, and a sorting order ```json { "filterConstraints":[ { "filterSelection":"CREATION_DATE", "filterElement":"BETWEEN", "value":"2015-01-01", "secondValue":"2015-06-20" }, { "filterSelection":"MY_CUSTOM_FIELD", "filterElement":"EQUALS", "dataItemType":"CLIENT", "dataFieldType":"CUSTOM", "value":"BIG spenders" } ], "sortDetails":{ "sortingColumn":"lastModifiedDate", "sortingOrder":"DESCENDING" } } ``` ### `filterContraints` array |Parameter|Value| |--- |--- | |filterSelection|The field on which the constraint will be applied. For custom fields, the custom field definition encoded key must be provided.| |filterElement|The constraint operator. Available filter elements can be found below.| |value|The constraint value. Required for filter elements with one or two values.| |secondValue|The constraint second value. Required for filter elements with two values.| |dataItemType|The entity where the field on which to apply the constraint is located. If the field is located in the same entity with the entity being searched, this field is optional. Possible values:
    • CLIENT - can be used for client/loans/savings/transactions endpoints
    • GROUP - can be used for group/loans/savings/transactions endpoints
    • LOANS - can be used for loans/transactions endpoints
    • TRANCHE - can be used for loans endpoint
    • DISBURSEMENT_DETAILS - can be used for loans/transactions endpoints
    • SAVINGS - can be used savings/transactions endpoints
    • TRANSACTION - cab be used for transactions/gljournalentries endpoint
    • JOURNAL_ENTRY - can be used for gljournalentries endpoint
    • NOTIFICATION_MESSAGE - can be used only for notification messages
    | |dataFieldType|`NATIVE`(default)/`CUSTOM` for custom field definition searches| ### `sortDetails` object |Parameter|Value| |--- |--- | |sortingColumn|The name of the column on which the order is going to take place| |sortingOrder|The order in which your results should be presented, either `ASCENDING` or `DESCENDING`| --- # Filter Elements URL: https://docs.mambu.com/api/pages/api-v1/filter-elements/ The table below contains a list of filters available for your search and which types of data you can use them with. |Filter Element|Number Of affected values|Available for| |---|---|---| |`EQUALS`|`ONE_VALUE`|`BIG_DECIMAL`,`BOOLEAN`,`LONG`,`MONEY`,`NUMBER`,`PERCENT`,`STRING`,`ENUM`,`KEY`| |`MORE_THAN`|`ONE_VALUE`|`BIG_DECIMAL`,`NUMBER`,`MONEY`| |`LESS_THAN`|`ONE_VALUE`|`BIG_DECIMAL`,`NUMBER`,`MONEY`| |`BETWEEN`|`TWO_VALUES`|`BIG_DECIMAL`,`NUMBER`,`MONEY`,`DATE`,`DATE_UTC`| |`ON`|`ONE_VALUE`|`DATE`,`DATE_UTC`| |`AFTER`|`ONE_VALUE`|`DATE`,`DATE_UTC`| |`BEFORE`|`ONE_VALUE`|`DATE`,`DATE_UTC`| |`STARTS_WITH`|`ONE_VALUE`|`STRING`| |`IN`|`LIST`|`ENUM` - When using the filter in Mambu default selection fields (for example, `ACCOUNT_STATE`) the names of the options (e.g. `ACTIVE` or `APPROVED`) may be used. `KEY` - When using the filter in custom field definitions, the encoded key of the custom field definition must be used and the names of the available options cannot be used.| |`TODAY`|`NO_VALUE`|`DATE`,`DATE_UTC`| |`THIS_WEEK`|`NO_VALUE`|`DATE`,`DATE_UTC`| |`THIS_MONTH`|`NO_VALUE`|`DATE`,`DATE_UTC`| |`THIS_YEAR`|`NO_VALUE`|`DATE`,`DATE_UTC`| |`LAST_DAYS`|`ONE_VALUE`|`NUMBER`| |`EMPTY`|`NO_VALUE`|`BIG_DECIMAL`,`LONG`,`MONEY`,`NUMBER`,`PERCENT`,`STRING`,`ENUM`,`KEY`,`DATE`,`DATE_UTC`| |`NOT_EMPTY`|`NO_VALUE`|`BIG_DECIMAL`,`LONG`,`MONEY`,`NUMBER`,`PERCENT`,`STRING`,`ENUM`,`KEY`,`DATE`,`DATE_UTC`| --- # HTTP Verbs URL: https://docs.mambu.com/api/pages/api-v1/http-verbs/ Standard HTTP verbs are used to indicate the API request method. | Verb | Function | |:---------|:----------------------------------------------------| | `GET` | To retrieve a resource or a collection of resources | | `POST` | To create a resource | | `PATCH` | To modify an existing resource | | `PUT` | To replace an existing resource | | `DELETE` | To delete a resource | ## Authentication Mambu supports two methods for authenticating API requests: * Basic authentication, using Mambu UI login credentials for a user account with **API** access permissions. * API keys, which are unique UUID tokens provided in an `apiKey` header (Early Access Feature). ### Basic Authentication > Example using curl ```shell curl --location --request GET 'https://TENANT_NAME.mambu.com/api/users' \ --header 'Authorization: Basic U29tZVVzZXI6T3BlblNlc2FtZQ==' ``` For basic authorization, provide your username and password directly via the `Authorization` header in the format `Basic `, where `base64-encoded-string` is the base-64-encoded value of your username and password separated by a colon ':'. For example, a user with the username `SomeUser` and the password `OpenSesame` would take the value `SomeUser:OpenSesame` and base-64 encode it, yielding `U29tZVVzZXI6T3BlblNlc2FtZQ==`. They would then provide an `Authorization` header for their request with the value `Basic U29tZVVzZXI6T3BlblNlc2FtZQ==`. See the example `GET` requests to the `/users` endpoint using curl. Note that the login credentials must be for an account with **API** access permissions. For more information, see [Creating a User - Access Rights](/docs/creating-new-users#access-rights) in our User Guide. :::note To ensure the username and password cannot be intercepted, all requests must use HTTPS. ::: ### API Keys API keys are tokens that you provide in an `apiKey` header to authenticate requests. They are generated by API consumers, which are an abstraction similar to an OAuth client. API consumers are currently an Early Access Feature. If you would like to request access to this feature, please get in touch with your Mambu Customer Success Manager to discuss your requirements. For more information on API consumers and keys, see [API Consumers](/docs/api-consumers) in our User Guide. ## Payloads Mambu API v1 has endpoints that usually accept and return only `application/json`. When making a `POST`, `PUT`, or `PATCH` request that sends data through a JSON body, you must set the `Content-Type` header to `application/json`. When making a `POST` request that sends data through query parameters, the `Content-Type` header must not be set. ## Requests API requests (also known as API calls) to the Mambu API identify who the requester is and exactly what information they wish to retrieve or which action they wish to perform. To put together an API Request you will need to combine: * The HTTP verb * The full URI to the resource * HTTP headers, for example, headers for [authentication](#authentication) and [payload content types](#payloads) * The JSON-formatted payload (if required) ## Responses > Error Response ```json { "errorCode":"4", "errorSource":"Property scheduleSettings.repaymentInstallments may not be null", "errorReason":"INVALID_PARAMETERS" } ``` > Single Resource - JSON object ```json { "field": "value" } ``` >Collection of Resources - JSON array ```json [ { "field": "value" }, { "field": "value" } ] ``` The response to a request will contain either the [JSON-formatted payload](#payloads) or an error response. ### Error response An error response will consist of: | Field | Type | Availability| Content | |---|---|---|---| | `errorCode` | number | Always present | A unique error code. For more information, see [API Responses and Error Codes](/docs/api-response-error-codes). | | `errorSource` | string | Sometimes present | A human-readable message capturing unsatisfied constraints. | | `errorReason` | string | Always present | A human-readable message stating the general category of the failure. | :::note The contents of the `errorSource` and `ErrorResponse` fields are subject to change without backwards compatibility. ::: ## Sandbox The *sandbox tenant* (also known as sandbox environment) is independent from the *production tenant*, and any changes you make in the sandbox will not affect the data in your production tenant. For more information, see [Sandbox](/docs/ sandbox) in our User Guide. To make requests to your tenant's sandbox, use the following base URL: * `https://TENANT_NAME.sandbox.mambu.com/api/` The sandbox is generally one version ahead of the production tenant. As such, it may include changes that are currently in, or may soon be in, the production environment. For more information, see [Mambu Release Cycle](/docs/ mambu-release-cycle). ### Sandbox management To manage your sandbox go to the Customer Service Portal. For more information and instructions, see [Customer Service Portal - Sandbox Management](/docs/ customer-service-portal#sandbox-management). ## Pagination To customize the response, the `offset` and `limit` parameters can be adjusted from their default values. :::warning When making a POST request that sends data through query parameters - as with Pagination - the Content-Type header must not be set. ::: ### `limit` The default limit for responses is 50. A value of up to 1,000 can be specified with `limit`. ### `offset` `offset` determines how many records will be skipped before being included in the returned results. The default offset value is 0. ## Detail Level Some Mambu API v1 endpoints support two levels of detail for responses, basic details and full details. To retrieve a response in full details, you must set the `fullDetails` query parameter to `true`. ### Basic details By default, Mambu API v1 will return basic details, this includes all first level elements of an object. ### Full details Some endpoints can return full details, this includes everything from basic details as well as all custom field values, any address or contact information, and any other related objects. ## Audit Trail and the User-Agent Header > Error when User Agent header is not provided ```json { "errors": [ { "errorCode": 4, "errorSource": "The user agent cannot be null when the Audit Trail feature is enabled", "errorReason": "INVALID_PARAMETERS" } ] } ``` Audit trail tracks all activities performed in the Mambu Core Banking system via the UI or API v1 and v2. For more information, see [Audit Trail](/docs/audit-trail) in our User Guide. When the audit trail feature is enabled, you **must** provide a `User-Agent` header for **all requests to any endpoint**, or the request will fail with the error message `The user agent cannot be null when the Audit Trail feature is enabled`. Note that if you are using a REST client like Postman or Curl, this header is probably provided automatically. However, if you generate a request to the API, you must provide it yourself. The User-Agent header provides information regarding the browser and operating system (such as the browser version), and information about the library or tool issuing the request (such as the client Java version). It is generally used to assist with debugging problems. ## Posting Data API requests that post data can either use URL-encoded query parameters or a JSON body to enter data. The `Content-Type` header must be set to `application/json` for the JSON request. :::warning `GET` and `POST` requests using query parameters should always use url-encoding for parameter values to make sure any special characters are properly escaped and do not cause errors or loss of information. ::: The examples to the right, show the two methods for posting data. Note that for some requests, much more information can be posted using the JSON input than is available with query parameters. > Using query parameters ```curl curl -d "type=APPROVAL" https://user:pword@test.mambu.com/api/loans/4028329c3ad6c515013ad6d0f6e40006/transactions ``` > Using JSON: ```curl curl -H "Accept: application/json" -H "Content-Type: application/json" -X POST -d ' https://user:pword@test.mambu.com/api/loans/4028329c3ad6c515013ad6d0f6e40006/transactions` ``` ### Example The example to the right makes a request using the username `user`, the password `pword` to the tenant `demo` to retrieve all repayments for loan account `abc` > Request with authorization made ... ``` https://user:pword@demo.mambu.com/api/loans/abc/repayments ``` > And returns a response such as: ```json [ { "encodedKey": "402832b4380a2d8801380a9cac860010", "parentAccountKey": "402832b4380a2d8801380a9cac41000f", "dueDate": "2012-07-28T00:00:00+0200", "principalDue": "190", "principalPaid": "0", "interestDue": "25.45", "interestPaid": "0", "state": "PENDING" }, { "encodedKey": "402832b4380a2d8801380a9cac870011", "parentAccountKey": "402832b4380a2d8801380a9cac41000f", "dueDate": "2012-08-28T00:00:00+0200", "principalDue": "190", "principalPaid": "0", "interestDue": "26.29", "interestPaid": "0", "state": "PENDING" } ] ``` :::info Using the `Authorization` header You can alternatively supply your username and password directly via the `Authorization` header in the format `Basic ` where `base64-encoded-string` is the base 64 encoded value of your username and password separated by a colon ':', ie `dXNlcm5hbWU6cGFzc3dvcmQ=` would be the result for `username:password`. ::: --- # Pagination URL: https://docs.mambu.com/api/pages/api-v1/pagination/ To customize the response, the `offset` and `limit` parameters can be adjusted from their default values. :::warning When making a POST request that sends data through query parameters - as with Pagination - the Content-Type header must not be set. ::: ## `limit` The default limit for responses is 50. A value of up to 1,000 can be specified with `limit`. ## `offset` `offset` determines how many records will be skipped before being included in the returned results. The default offset value is 0. --- # Payloads URL: https://docs.mambu.com/api/pages/api-v1/payloads/ Mambu API v1 has endpoints that usually accept and return only `application/json`. When making a `POST`, `PUT`, or `PATCH` request that sends data through a JSON body, you must set the `Content-Type` header to `application/json`. When making a `POST` request that sends data through query parameters, the `Content-Type` header must not be set. --- # Posting Data URL: https://docs.mambu.com/api/pages/api-v1/posting-data/ API requests that post data can either use URL-encoded query parameters or a JSON body to enter data. The `Content-Type` header must be set to `application/json` for the JSON request. :::warning `GET` and`POST` requests using query parameters should always use url-encoding for parameter values to make sure any special characters are properly escaped and do not cause errors or loss of information. ::: The examples to the right, show the two methods for posting data. Note that for some requests, much more information can be posted using the JSON input than is available with query parameters. > Using query parameters ```curl curl -d "type=APPROVAL" https://user:pword@test.mambu.com/api/loans/4028329c3ad6c515013ad6d0f6e40006/transactions ``` > Using JSON: ```curl curl -H "Accept: application/json" -H "Content-Type: application/json" -X POST -d ' https://user:pword@test.mambu.com/api/loans/4028329c3ad6c515013ad6d0f6e40006/transactions` ``` ## Example The example to the right makes a request using the username `user`, the password `pword` to the tenant `demo` to retrieve all repayments for loan account `abc` > Request with authorization made ... ``` https://user:pword@demo.mambu.com/api/loans/abc/repayments ``` > And returns a response such as: ```json [ { "encodedKey": "402832b4380a2d8801380a9cac860010", "parentAccountKey": "402832b4380a2d8801380a9cac41000f", "dueDate": "2012-07-28T00:00:00+0200", "principalDue": "190", "principalPaid": "0", "interestDue": "25.45", "interestPaid": "0", "state": "PENDING" }, { "encodedKey": "402832b4380a2d8801380a9cac870011", "parentAccountKey": "402832b4380a2d8801380a9cac41000f", "dueDate": "2012-08-28T00:00:00+0200", "principalDue": "190", "principalPaid": "0", "interestDue": "26.29", "interestPaid": "0", "state": "PENDING" } ] ``` :::note Using the`Authorization` header You can alternatively supply your username and password directly via the`Authorization` header in the format`Basic ` where`base64-encoded-string` is the base 64 encoded value of your username and password separated by a colon ':', ie`dXNlcm5hbWU6cGFzc3dvcmQ=` would be the result for`username:password`. ::: --- # requests URL: https://docs.mambu.com/api/pages/api-v1/requests/ --- title: Requests id: requests --- API requests (also known as API calls) to the Mambu API identify who the requester is and exactly what information they wish to retrieve or which action they wish to perform. To put together an API Request you will need to combine: * The [HTTP verb](/api/pages/api-v1/http-verbs) * The full URI to the resource * HTTP headers, for example, headers for [authentication](/api/pages/api-v1/authentication) and [payload content types](/api/pages/api-v1/payloads) * The JSON-formatted payload (if required) --- # Responses URL: https://docs.mambu.com/api/pages/api-v1/responses/ > Error Response ```json { "errorCode":"4", "errorSource":"Property scheduleSettings.repaymentInstallments may not be null", "errorReason":"INVALID_PARAMETERS" } ``` > Single Resource - JSON object ```json { "field": "value" } ``` >Collection of Resources - JSON array ```json [ { "field": "value" }, { "field": "value" } ] ``` The response to a request will contain either the [JSON-formatted payload](/api/pages/api-v1/payloads) or an error response. ## Error response An error response will consist of: | Field | Type | Availability| Content | |---|---|---|---| | `errorCode` | number | Always present | A unique error code. For more information, see [API Responses and Error Codes](/docs/api-response-error-codes). | | `errorSource` | string | Sometimes present | A human-readable message capturing unsatisfied constraints. | | `errorReason` | string | Always present | A human-readable message stating the general category of the failure. | :::note The contents of the `errorSource` and `ErrorResponse` fields are subject to change without backwards compatibility. ::: = --- # Sandbox URL: https://docs.mambu.com/api/pages/api-v1/sandbox/ The *sandbox tenant* (also known as sandbox environment) is independent from the *production tenant*, and any changes you make in the sandbox will not affect the data in your production tenant. For more information, see [Sandbox](/docs/ sandbox) in our User Guide. To make requests to your tenant's sandbox, use the following base URL: * `https://TENANT_NAME.sandbox.mambu.com/api/` The sandbox is generally one version ahead of the production tenant. As such, it may include changes that are currently in, or may soon be in, the production environment. For more information, see [Mambu Release Cycle](/docs/ mambu-release-cycle). ## Sandbox management To manage your sandbox go to the Customer Service Portal. For more information and instructions, see [Customer Service Portal - Sandbox Management](/docs/customer-service-portal#sandbox-management). --- # Searching and Filtering URL: https://docs.mambu.com/api/pages/api-v1/searching-and-filtering/ # Searching and Filtering Many entities allow you multiple ways to filter your request, either by providing fields and values as query parameters or by using the entity's `/search` facility. This option is available for: [Clients](/api/pages/api-v1/data-types-and-examples#clients), [Groups](/api/pages/api-v1/data-types-and-examples#groups), [Loan Accounts](/api/pages/api-v1/data-types-and-examples#loan-accounts) & [Loan Tranches](/api/pages/api-v1/data-types-and-examples#tranches), [Savings Accounts](/api/pages/api-v1/data-types-and-examples#savings-accounts) & [Savings Transactions](/api/pages/api-v1/data-types-and-examples#transactions), [Notifications](/api/pages/api-v1/data-types-and-examples#notifications), [General Ledger Journal Entries](/api/pages/api-v1/data-types-and-examples#general-ledger-journal-entries) and [Lines of Credit](/api/pages/api-v1/data-types-and-examples#lines-of-credit). Additionally, the [object search API](/api/api-v1/search/object-search) allows you to execute the same search query across multiple types of entity, for example, both loan and savings accounts, or both users and clients, although the number of fields which will be searched is limited. In each case you will use a `POST` request and provide your search parameters and sorting preference in the request body, while other constraints, such as the number of records to return, an offset to page through large result sets, or whether you would like full details or only basic data, can be provided as query parameters. :::info Performance Recommendation When querying Mambu data, we recommend using a batch size of up to 100 records for optimum output. This is both more performant and ensures easier troubleshooting for your integrations. Additionally, using the `EQUALS_CASE_SENSITIVE` filter when you know the case of the item you are searching for will also give you a more performant search. ::: --- # Timezone Offsets URL: https://docs.mambu.com/api/pages/api-v1/timezone-offsets/ # Timezone Offsets Here is how we handle timezone offsets in API v1 calls: * We use the following standard date format: ISO_8601_FORMAT_DATE_TIME = "YYYY-MM-DD'T'hh:mm:ss±hh:mm". * We either save the date as it is or extract the offset value if it contains an offset. * Unlike in API v2, in API v1 we don’t validate the timezone. >**Example** Each Mambu tenant has *one* timezone. Let’s take for example tenants in the East European time zone (UTC+02:00). | Date and time of request | What is saved in the database | |---|---| | 2021-03-09T13:37:50 | 2021-03-09 13:37:50 | | 2021-03-09T13:37:50+02:00 | 2021-03-09 11:37:50 | :::note
  • When posting a transaction in the present, the current offset should be used, according to the tenant’s time zone.
  • When posting a backdated transaction, the offset which was correct for that date and time should be used, according to the tenant’s time zone.
  • When posting a transaction in the future, the future offset should be used, according to the tenant’s time zone.
  • If your country uses Daylight Saving Time, posting transactions that occur during 'lost' hours, for example between 02:00:00 a.m. CEST and 2:59:59 a.m. CEST, will be allowed as the timestamp will not be validated, however, this can create timestamps that don’t actually exist, which may lead to unexpected errors if exporting or synchronising data to other systems which do validate timezones and time offsets. We also generally recommend not processing API calls during the minutes leading up to and after the switchover as small differences in clock synchronisation across various systems and services may lead to unexpected errors.
    • ::: --- # Mambu API v1 Reference Page URL: https://docs.mambu.com/api/pages/api-v1/welcome/ ## Welcome > This documentation was last updated on Wed Feb 19 11:59:30 CET 2025 and covers Mambu Version [v9.171.0](https://community.mambu.com/c/release-notes/) Welcome to the Mambu API v1 Reference documentation. :::info If you are looking for documentation for another API, you can use the **Mambu APIs** menu to view API Reference documentation for [API v2](/api/pages/api-v2/welcome), Payments API, or [Streaming API](/api/pages/streaming/streaming-index). For more information about all the APIs we offer, see [Mambu APIs](/docs/mambu-apis) in our User Guide. ::: :::warning Mambu API v1 is no longer being actively developed. We strongly recommend that all customers use our [API v2](/api/pages/api-v2/welcome) endpoints for all new integrations. Both versions will be running concurrently until further notice. ::: --- # About Mambu API v2 URL: https://docs.mambu.com/api/pages/api-v2/about-mambu-api-v2/ # About Mambu API v2 > Scroll down for code samples, example requests, and responses. Select a language for code samples in the tabs. Mambu API v2 is a fully compliant RESTful API and we recommend building all new integrations with API v2 (instead of [API v1](/api/pages/api-v2/welcome). --- # OAS v2 Discovery URL: https://docs.mambu.com/api/pages/api-v2/api-oas2-discovery/ # OAS v2 Discovery ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/swagger/resources \ -u 'username:password' ``` ```http GET https://TENANT_NAME.mambu.com/api/swagger/resources HTTP/1.1 Host: TENANT_NAME.mambu.com Authorization: Basic ``` ```javascript var headers = { 'Authorization':'Basic ' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/swagger/resources', method: 'GET', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Authorization' => 'Basic ' } result = RestClient.get 'https://TENANT_NAME.mambu.com/api/swagger/resources', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Authorization': 'Basic ' } r = requests.get('https://TENANT_NAME.mambu.com/api/swagger/resources', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/swagger/resources"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty("Authorization", "Basic "); con.setRequestMethod("GET"); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Authorization": []string, } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("GET", "https://TENANT_NAME.mambu.com/api/swagger/resources", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` ```json { "items": [ { "jsonPath": "json/clients_v2_swagger.json", "label": "Clients", "hashValue": "Clients", "index": 0 }, { "jsonPath": "json/clients_documents_v2_swagger.json", "label": "Client Documents", "hashValue": "Client_Documents", "index": 1 }, { "jsonPath": "json/branches_v2_swagger.json", "label": "Branches", "hashValue": "Branches", "index": 2 }, { "jsonPath": "json/centres_v2_swagger.json", "label": "Centres", "hashValue": "Centres", "index": 3 }, ... { "jsonPath": "json/configuration_iddocumenttemplates.yaml_v2_swagger.json", "label": "Identification Document Templates Configuration", "hashValue": "Identification_Document_Templates_Configuration", "index": 64 }, { "jsonPath": "json/configuration_loanrisklevels.yaml_v2_swagger.json", "label": "Loan Risk Levels Configuration", "hashValue": "Loan_Risk_Levels_Configuration", "index": 65 }, { "jsonPath": "json/currencies_v2_swagger.json", "label": "Currencies", "hashValue": "Currencies", "index": 66 } ] } ``` To retrieve either the basic OAS file or the enriched OAS file with custom field values for a specific API, you must first build the path for the resource. To build the path for a resource you must retrieve the `jsonPath` value. This value is provided when you retrieve the list of all available APIs. To retrieve the list of all available APIs you may use the `https://TENANT_NAME.mambu.com/api/swagger/resources` endpoint. The response returns an array of objects. Each object represents an API and includes its `jsonPath` value. Next, to retrieve the OAS file for a specific API. See [Retrieving OAS Files](/api/pages/api-v2/retrieving-v2-oas-files) below. --- # OAS v3 API Discovery URL: https://docs.mambu.com/api/pages/api-v2/api-oas3-discovery/ # OAS v3 API Discovery To retrieve either the basic OAS file or the enriched OAS file with custom field values for a specific API, you must first build the path for the resource. To build the path for a resource you must retrieve the `jsonPath` value. This value is provided when you retrieve the list of all available APIs. To retrieve the list of all available APIs you may use the `https://TENANT_NAME.mambu.com/api/openapi/resources` endpoint. The response returns an array of objects. Each object represents an API and includes its `jsonPath` value. Next, to retrieve the OAS file for a specific API. See [Retrieving OAS v3 Files](/api/pages/api-v2/retrieving-v3-oas-files) below. ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/openapi/resources \ -u 'username:password' ``` ```http GET https://TENANT_NAME.mambu.com/api/openapi/resources HTTP/1.1 Host: TENANT_NAME.mambu.com Authorization: Basic ``` ```javascript var headers = { 'Authorization':'Basic ' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/openapi/resources', method: 'GET', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Authorization' => 'Basic ' } result = RestClient.get 'https://TENANT_NAME.mambu.com/api/openapi/resources', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Authorization': 'Basic ' } r = requests.get('https://TENANT_NAME.mambu.com/api/openapi/resources', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/openapi/resources"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty("Authorization", "Basic "); con.setRequestMethod("GET"); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Authorization": []string, } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("GET", "https://TENANT_NAME.mambu.com/api/openapi/resources", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` ```json [ { "label": "Clients", "hashValue": "Clients", "index": 0, "resourcePaths": [ { "version": "v2", "jsonPath": "openapi/resources/clients/v2" } ] }, { "label": "Client Documents", "hashValue": "Client_Documents", "index": 1, "resourcePaths": [ { "version": "v2", "jsonPath": "openapi/resources/clients_documents/v2" } ] }, { "label": "Branches", "hashValue": "Branches", "index": 2, "resourcePaths": [ { "version": "v2", "jsonPath": "openapi/resources/branches/v2" } ] }, { "label": "Centres", "hashValue": "Centres", "index": 3, "resourcePaths": [ { "version": "v2", "jsonPath": "openapi/resources/centres/v2" } ] }, { "label": "Users", "hashValue": "Users", "index": 4, "resourcePaths": [ { "version": "v2", "jsonPath": "openapi/resources/users/v2" } ] } ] ``` --- # Audit Trail and the User-Agent Header URL: https://docs.mambu.com/api/pages/api-v2/audit-trail-and-the-user-agent-header/ # Audit Trail and the User-Agent Header > Error when User Agent header is not provided ```json { "errors": [ { "errorCode": 4, "errorSource": "The user agent cannot be null when the Audit Trail feature is enabled", "errorReason": "INVALID_PARAMETERS" } ] } ``` Audit trail tracks all activities performed in the Mambu Core Banking system via the UI or API v1 and v2. For more information, see Audit Trail in our User Guide. When the audit trail feature is enabled, you **must** provide a `User-Agent` header for **all requests to any endpoint**, or the request will fail with the error message `The user agent cannot be null when the Audit Trail feature is enabled`. Note that if you are using a REST client like Postman or Curl, this header is probably provided automatically. However, if you generate a request to the API, you must provide it yourself. The User-Agent header provides information regarding the browser and operating system (such as the browser version), and information about the library or tool issuing the request (such as the client Java version). It is generally used to assist with debugging problems. --- # Authentication URL: https://docs.mambu.com/api/pages/api-v2/authentication/ # Authentication Mambu supports two methods for authenticating API requests: * Basic authentication, using Mambu UI login credentials for a user account with **API** access permissions. * API keys, which are unique UUID tokens provided in an `apiKey` header (Early Access feature). ## Basic Authentication ```shell curl --location --request GET 'https://TENANT_NAME.mambu.com/api/users' \ --header 'Authorization: Basic U29tZVVzZXI6T3BlblNlc2FtZQ==' ``` ```http GET /api/users HTTP/1.1 Host: TENANT_NAME.mambu.com Authorization: Basic U29tZVVzZXI6T3BlblNlc2FtZQ== ``` ```javascript var settings = { "url": "https://TENANT_NAME.mambu.com/api/users", "method": "GET", "timeout": 0, "headers": { "Authorization": "Basic U29tZVVzZXI6T3BlblNlc2FtZQ==" }, }; $.ajax(settings).done(function (response) { console.log(response); }); ``` ```ruby require "uri" require "net/http" url = URI("https://TENANT_NAME.mambu.com/api/users") https = Net::HTTP.new(url.host, url.port) https.use_ssl = true request = Net::HTTP::Get.new(url) request["Authorization"] = "Basic U29tZVVzZXI6T3BlblNlc2FtZQ==" response = https.request(request) puts response.read_body ``` ```python url = "https://TENANT_NAME.mambu.com/api/users" payload= headers = { 'Authorization': 'Basic U29tZVVzZXI6T3BlblNlc2FtZQ==' } response = requests.request("GET", url, headers=headers, data=payload) print(response.text) ``` ```java OkHttpClient client = new OkHttpClient().newBuilder() .build(); Request request = new Request.Builder() .url("https://TENANT_NAME.mambu.com/api/users") .method("GET", null) .addHeader("Authorization", "Basic U29tZVVzZXI6T3BlblNlc2FtZQ==") .build(); Response response = client.newCall(request).execute(); ``` ```go package main "fmt" "net/http" "io/ioutil" ) func main() { url := "https://TENANT_NAME.mambu.com/api/users" method := "GET" client := &http.Client { } req, err := http.NewRequest(method, url, nil) if err != nil { fmt.Println(err) return } req.Header.Add("Authorization", "Basic U29tZVVzZXI6T3BlblNlc2FtZQ==") res, err := client.Do(req) if err != nil { fmt.Println(err) return } defer res.Body.Close() body, err := ioutil.ReadAll(res.Body) if err != nil { fmt.Println(err) return } fmt.Println(string(body)) } ``` For basic authorization, provide your username and password directly via the `Authorization` header in the format `Basic `, where `base64-encoded-string` is the base-64-encoded value of your username and password separated by a colon `:`. For example, a user with the username `SomeUser` and the password `OpenSesame` would take the value `SomeUser:OpenSesame` and base-64 encode it, yielding `U29tZVVzZXI6T3BlblNlc2FtZQ==`. They would then provide an `Authorization` header for their request with the value `Basic U29tZVVzZXI6T3BlblNlc2FtZQ==`. See the code samples for this section for sample `GET` requests to the `/users` endpoint using the above example. Note that the login credentials must be for a user account with **API** access permissions. For more information, see Creating a User - Access Rights in our User Guide. :::note To ensure the username and password cannot be intercepted, all requests must use HTTPS. ::: ## API Keys API keys are tokens that you provide in an `apiKey` header to authenticate requests. They are generated by API consumers, which are an abstraction similar to an OAuth client. API consumers are currently an Early Access feature. If you would like to request access to this feature, please get in touch with your Mambu Customer Success Manager to discuss your requirements. For more information on API consumers and keys, see API Consumers in our User Guide. --- # Base URLs URL: https://docs.mambu.com/api/pages/api-v2/base-urls/ ## Base URLs The base URL for requests to the API is `https://TENANT_NAME.mambu.com/api`. :::note Replace `TENANT_NAME` above with the tenant name in your Mambu tenant URL. ::: To make requests to your tenant's sandbox, use the following base URL: * `https://TENANT_NAME.sandbox.mambu.com/api` For more information, see the [Sandbox](/api/pages/api-v2/sandbox) section. --- # Considerations for specific field types URL: https://docs.mambu.com/api/pages/api-v2/considerations-for-specific-field-types/ # Considerations for specific field types * **The `DATE_TIME` operator**: When using a `DATE_TIME` operator, you can opt to provide the time offset for your timezone or use UTC. For example, searching for records that were created after a `DATE_TIME` of `2022-04-25T13:00:00+02:00` should give you the same results as using the UTC equivalent date time of `2022-04-25T11:00:00+00:00`. When using just the date, the local time zone will always be used. * **The `BEFORE` operator**: When using a `BEFORE` operator for dates, the date provided will not be included. If you wish to include the date provided, use the `BEFORE_INCLUSIVE` operator. * **The `BETWEEN` operator**: When using the `BETWEEN` operator with two dates, the start date (`value` parameter) will be inclusive while the end date (`secondValue` parameter) will be exclusive. This means that if you wish to include a record in your results that, for example, took place at 12:00pm on the 22nd July 2023, you should use `22023-07-22T12:01:00` as your end timestamp. * **The `EQUALS` and `EQUALS_CASE_SENSITIVE` operators**: If using `EQUALS` as the operator, true or false values are cast to boolean so `true`, `"true"`, and `"TRUE"` should all yield the same results. This includes checkbox type custom field definitions where the value is returned as an uppercase string of either `"TRUE"` or `"FALSE"`. This is **not** the case when using `EQUALS_CASE_SENSITIVE` as the operator, so, if searching based on a checkbox type custom field definition with the `EQUALS_CASE_SENSITIVE` operator, you will need to provide the value as an uppercase string. --- # Cursor-based search pagination URL: https://docs.mambu.com/api/pages/api-v2/cursor-based-search-pagination/ # Cursor-based search pagination Cursor-based search pagination offers significantly better performance, particularly in large data sets, than offset-based search. This method uses a defined _cursor_, which represents the current position in the data set, and a _limit_ to retrieve results. To start cursor pagination, the `cursor: “_”` query parameter needs to used in combination with `limit`. This is equivalent to starting the search from the first item in the data set. After each API call using a cursor query parameter, a new header is returned in the response: `Items-Next-Cursor`. This value is the cursor to be used in the next cursor-based search API call. When `Items-Next-Cursor` is empty (an empty string), the search is over: there are no items left in the data set. Cursor-based searching is supported for the following data types: | Endpoint | Query example | Cursor field(s) | |-----------------------------------------------------------------| ----------- |----------- | | [journal entries](/api/api-v2/gljournalentries/search) | `/gljournalentries:search?limit=100&cursor=_` |`entryId` | | [deposit accounts](/api/api-v2/deposits/search) | `/deposits:search?limit=1&cursor=_` | `lastModifiedDate` and `encodedKey`| | [deposit transactions](/api/api-v2/deposits_transactions/search) | `/deposits/transactions:search?limit=1&cursor=_` | `transactionId`| | [loan accounts](/api/api-v2/loans/search) | `/loans:search?limit=1&cursor=_` | `lastModifiedDate` and `encodedKey`| | [loan transactions](/api/api-v2/loans_transactions/search) | `/loans/transactions:search?limit=3&cursor=_` |`transactionId` | The journal entries, deposit transactions, and loan transactions data types use an indexed auto-incrementing ID field as their cursor. While the cursor is indexed, performance issues could arise if the search query contains additional filters that use non-indexed columns. Deposit accounts and loan accounts use a compound field to define the cursor, and do not allow for further query filters. When using cursor-based searching, some features of the search APIs are not supported: - journal entries: at least one filter by `creationDate` or `bookingDate` using the `BETWEEN` operator should be present; on top of this, other filters can be added, for example, a filter by `glAccountId` or `glAccountName`. - loan and deposit transactions: at least one filter by `creationDate` or `valueDate` using the `BETWEEN` operator should be present; on top of this, other filters can be added, for example, a filter by `parentAccountId`. - Loan and deposit accounts: exactly one filter by the `lastModifiedDate` field using the `BETWEEN` operator is accepted. - No sort criteria can be specified; the items are always sorted by the cursor field. - `paginationDetails=ON` is not supported. - The first cursor-based search (using the `“_”` as the cursor) will also compute the minimum and maximum cursor values. Therefore, this API call can take more time than the subsequent API calls, which will take roughly the same amount of time regardless of the cursor’s position in the data set. This is in contrast to offset-based searching, which takes increasingly more time as the offset value increases. For more information on pagination in Mambu APIs, see [pagination](/api/pages/api-v2/pagination). ## Cursor-based search pagination with `application/vnd.mambu.v2+octetstream` Accept header Some APIs can handle conditions where the `application/vnd.mambu.v2+octetstream` Accept header is sent together with the `cursor=_` parameter . This sends back an octet stream of all the data until the end of the cursor to a single file. The connection will only be closed if the client terminates it or all the data is retrieved from the database. --- # Details Level URL: https://docs.mambu.com/api/pages/api-v2/details-level/ # Details Level ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/?detailsLevel=FULL \ -H 'Accept: application/vnd.mambu.v2+json' ``` ```http GET https://TENANT_NAME.mambu.com/api/Insert-Resource-URI-here?detailsLevel=FULL HTTP/1.1 Host: TENANT_NAME.mambu.com Accept: application/vnd.mambu.v2+json ``` ```javascript var headers = { 'Accept':'application/vnd.mambu.v2+json' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/?detailsLevel=FULL', method: '', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Accept' => 'application/vnd.mambu.v2+json' } result = RestClient. 'https://TENANT_NAME.mambu.com/api/?detailsLevel=FULL', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Accept': 'application/vnd.mambu.v2+json' } r = requests.('https://TENANT_NAME.mambu.com/api/?detailsLevel=FULL', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/?detailsLevel=FULL"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty(“Accept”, “application/vnd.mambu.v2+json”); con.setRequestMethod(""); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Accept": []string, } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("", "https://TENANT_NAME.mambu.com/api/?detailsLevel=FULL", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` Mambu API v2 supports two details levels for responses: * `BASIC` -- By default, API v2 will return the `BASIC` level of detail. This includes all first level elements of an object. * `FULL` -- This details level includes everything from `BASIC` as well as all custom field values, any address or contact information, and any other related objects. To view a higher level of detail, include `detailsLevel` as a query parameter in your request and give it the value `FULL`. --- # Filter Operators URL: https://docs.mambu.com/api/pages/api-v2/filter-operators/ # Filter Operators ```json { "field": "overdraftSettings.allowOverdraft", "operator": "EQUALS", "value": true } ``` ```json { "field": "name", "operator": "EQUALS_CASE_SENSITIVE", "value": "Daily Savings" } ``` ```json { "field": "balances.totalBalance", "operator": "MORE_THAN", "value": 500000.50 } ``` ```json { "field": "accruedAmounts.interestAccrued", "operator": "LESS_THAN", "value": 10000.10 } ``` ```json { "field": "balances.feesDue", "operator": "BETWEEN", "value": 100, "secondValue" : 500 } ``` ```json { "field": "approvedDate", "operator": "ON", "value": "2021-06-15" } ``` ```json { "field": "lastModifiedDate", "operator": "AFTER", "value": "2022-04-20" } ``` ```json { "field": "creationDate", "operator": "BEFORE", "value": "2021-12-25" } ``` ```json { "field": "creationDate", "operator": "BEFORE_INCLUSIVE", "value": "2020-06-15" } ``` ```json { "field": "id", "operator": "STARTS_WITH", "value":"eban" } ``` ```json { "field": "id", "operator": "STARTS_WITH", "value":"EBAN" } ``` ```json { "field": "accountType", "operator": "IN", "values":[ "REGULAR_SAVINGS", "CURRENT_ACCOUNT" ] } ``` ```json { "field": "approvedDate", "operator": "TODAY" } ``` ```json { "field": "disbursementDetails.expectedDisbursementDate", "operator": "THIS_WEEK" } ``` ```json { "field": "lastPaymentDate", "operator": "THIS_MONTH" } ``` ```json { "field": "expectedMaturityDate", "operator": "THIS_YEAR" } ``` ```json { "field": "firstRepaymentDate", "operator": "LAST_DAYS", "value": 12 } ``` ```json { "field": "overdraftRiskLevelKey", "operator": "EMPTY" } ``` ```json { "field": "lastSetToArrearsDate", "operator": "NOT_EMPTY" } ``` The table below contains available operators as well as the types of field they are compatible with and the number of values they support. | **Operator** | **Affected values** | **Available for** | |--------------|---------------------|-------------------| | EQUALS | ONE_VALUE | BIG_DECIMAL, BOOLEAN, LONG, MONEY, NUMBER, PERCENT, STRING, ENUM, KEY | | EQUALS_CASE_SENSITIVE | ONE_VALUE | STRING, BOOLEAN, DATE, NUMBER, ENUM, KEY | | MORE_THAN | ONE_VALUE | BIG_DECIMAL, NUMBER, MONEY | | LESS_THAN | ONE_VALUE | BIG_DECIMAL, NUMBER, MONEY | | BETWEEN | TWO_VALUES | BIG_DECIMAL, NUMBER, MONEY, DATE, DATE_TIME | | ON | ONE_VALUE | DATE, DATE_TIME | | AFTER | ONE_VALUE | DATE, DATE_TIME | | BEFORE | ONE_VALUE | DATE, DATE_TIME | | BEFORE_INCLUSIVE | ONE_VALUE | DATE, DATE_TIME | | STARTS_WITH | ONE_VALUE | STRING | | STARTS_WITH_CASE_SENSITIVE | ONE_VALUE | STRING | | IN | LIST | ENUM,KEY | | TODAY | NO_VALUE | DATE, DATE_TIME | | THIS_WEEK | NO_VALUE | DATE, DATE_TIME | | THIS_MONTH | NO_VALUE | DATE, DATE_TIME | | THIS_YEAR | NO_VALUE | DATE, DATE_TIME | | LAST_DAYS | ONE_VALUE | NUMBER | | EMPTY | NO_VALUE | BIG_DECIMAL, LONG, MONEY, NUMBER, PERCENT, STRING, ENUM, KEY, DATE, DATE_TIME | | NOT_EMPTY | NO_VALUE | BIG_DECIMAL, LONG, MONEY, NUMBER, PERCENT, STRING, ENUM, KEY, DATE, DATE_TIME | --- # Generating SDKs from OAS URL: https://docs.mambu.com/api/pages/api-v2/generating-sdks-from-oas/ # Generating SDKs from OAS Once you have your OAS file you are free to use any number of tools to generate a client SDK in your preferred language, for example, the freely available and online [Swagger Editor](https://editor.swagger.io/). By either importing the file or copying the specification into the editor window you will be able to see both navigable documentation and the option located at the top of the window to **Generate Client**. Remember to edit the `host` field in your OAS file to reflect your Mambu domain before generating your SDK. For more information on your Mambu domain, see [Base URLs](/api/pages/api-v2/base-urls). --- # Grouped custom field sets URL: https://docs.mambu.com/api/pages/api-v2/grouped-custom-field-sets/ # Grouped custom field sets ## Grouped custom field set examples In the group custom field set examples, we assume we have a custom field set with ID `_assets` and it contains groups of three custom field definitions with IDs `asset_type`, `asset_value`, and `asset_age`. These are used to capture the client assets that are used as guarantees for loans. ### Affecting one custom field value in a custom field group > Adding one custom field value in a custom field group ```json [ { "op": "ADD", "path": "/_assets/2/asset_age", "value": "5" } ] ``` > Adding two custom field groups to a custom field set ```json [ { "op": "ADD", "path": "/_assets", "value": [ { "asset_type": "Land", "asset_age": "10", "asset_value": "965000" }, { "asset_type": "Car", "asset_age": "2", "asset_value": "25000" } ] } ] ``` To add, replace, or remove a single custom field value within a custom field group, the `path` property must specify the custom field set ID, the index of the group in the array, and the specific custom field definition. In the example to the right, we are adding a value for the `asset_age` property for the custom field group with index 2 in the array. ## Adding entire custom field groups to a custom field set To add an entire new custom field group or multiple new groups, the `path` property must specify just the custom field set ID. The new group will always be added to the end of the array. You cannot specify a specific index in the array to add it to. In the example to the right, we are adding two new custom field groups to the custom field set. ## Replacing or removing one custom field group in a custom field set > Replacing one custom field group in a custom field set ```json [ { "op": "REPLACE", "path": "/_assets/2", "value": { "asset_type": "House", "asset_age": "3", "asset_value": "100000" } } ] ``` To replace or remove an entire custom field group, the `path` property must specify the custom field set ID and the index of the group in the array. In the example to the right, we are replacing the entire custom field group that is at index 2 in the array. ## Replacing or removing all custom field groups in a custom field set > Removing all the custom field groups in a custom field set ```json [ { "op": "REMOVE", "path": "/_assets" } ] ``` To replace or remove all the custom field groups for a custom field set, the `path` property only needs the custom field set ID. In the example to the right we are removing the custom field group at index 2 in the array. --- # HTTP Verbs URL: https://docs.mambu.com/api/pages/api-v2/http-verbs/ # HTTP Verbs Standard HTTP verbs are used to indicate the API request method. | Verb | Function | |:---------|:----------------------------------------------------| | `GET` | To retrieve a resource or a collection of resources | | `POST` | To create a resource | | `PATCH` | To modify an existing resource | | `PUT` | To replace an existing resource | | `DELETE` | To delete a resource | --- # Idempotency URL: https://docs.mambu.com/api/pages/api-v2/idempotency/ # Idempotency ```shell # You can also use wget curl -X POST https://TENANT_NAME.mambu.com/api/deposits//transactions \ -H 'Content-Type: application/json' \ -H 'Accept: application/vnd.mambu.v2+json' \ -H 'Idempotency-Key: 01234567-9abc-def0-1234-56789abcdef0' ``` ```http POST https://TENANT_NAME.mambu.com/api/deposits//transactions HTTP/1.1 Host: TENANT_NAME.mambu.com Content-Type: application/json Accept: application/vnd.mambu.v2+json Idempotency-Key: 01234567-9abc-def0-1234-56789abcdef0 ``` ```javascript var headers = { 'Content-Type':'application/json', 'Accept':'application/vnd.mambu.v2+json', 'Idempotency-Key':'01234567-9abc-def0-1234-56789abcdef0' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/deposits//transactions', method: 'post', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Content-Type' => 'application/json', 'Accept' => 'application/vnd.mambu.v2+json', 'Idempotency-Key' => '01234567-9abc-def0-1234-56789abcdef0' } result = RestClient.post 'https://TENANT_NAME.mambu.com/api/deposits//transactions', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Content-Type': 'application/json', 'Accept': 'application/vnd.mambu.v2+json', 'Idempotency-Key': '01234567-9abc-def0-1234-56789abcdef0' } r = requests.post('https://TENANT_NAME.mambu.com/api/deposits//transactions', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/deposits//transactions"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); String idempotentKey = UUID.randomUUID().toString(); con.setRequestProperty(“Idempotency-Key”, idempotentKey); con.setRequestProperty(“Accept”, “application/vnd.mambu.v2+json”); con.setRequestMethod("POST"); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Content-Type": []string, "Accept": []string, "Idempotency-Key": []string, } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("POST", "https://TENANT_NAME.mambu.com/api/deposits//transactions", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` [Idempotent](https://en.wikipedia.org/wiki/Idempotence) requests to the Mambu API are guaranteed to be executed no more than once. Working with financial transactions, it is important to ensure some requests are not repeated for any reason, which may result in data loss or accidental duplication. You may configure requests to be idempotent by providing an `Idempotency-Key` header and providing a unique UUID token for the request. This will guard against the possibility of error if a request must be retried. When an idempotent request is processed, the status code and body of the response is associated with the idempotency key and stored in a cache. If the request is duplicated for any reason, the duplicate request will not be processed, and the response will be re-sent to the client. :::warning Idempotency keys expire after six hours in Mambu API v2. After this time period, requests using duplicate keys will be treated as new requests. ::: :::warning Mambu is moving towards returning 409 response code instead of 102 response code, when there already is an in progress call with the same idempotency key. ::: Idempotent requests that fail at the server level such validation failures are not stored in the cache. Subsequent requests with the same idempotency key will be processed as if they were new, receiving the same `400 BAD REQUEST` status code. For examples of idempotent requests, see the code samples for this section. :::note We do not recommend using idempotency for GET and DELETE requests, as such requests are naturally idempotent. ::: ## Idempotency Keys and Retry Mechanisms Idempotency keys **must** use the [v4 UUID format](https://www.itu.int/rec/T-REC-X.667-201210-I/en) (32 hexadecimal digits, in a 8-4-4-4-12 arrangement, such as `01234567-9abc-def0-1234-56789abcdef0`). We recommend generating UUIDs programmatically or by using an online generator such as [UUID Generator](https://www.uuidgenerator.net/version4) to ensure that all keys are valid V4 UUIDs. Retry mechanisms must: * Use the same key for initial calls and retries. * Retry at a reasonable frequency so as not to overload the API. * Properly identify and handle error codes. --- # OpenAPI Specification URL: https://docs.mambu.com/api/pages/api-v2/openapi-specification/ # OpenAPI Specification This API Reference documentation is automatically generated from OpenAPI Specification (OAS) files. We allow you to: * Retrieve a list of all available APIs. * Retrieve an OAS file in either a basic format (without custom field values) or an enriched format (with custom field values). You can use the JSON-formatted OAS files to scaffold client SDKs in various languages. See [Generating SDKs from OAS](/api/pages/api-v2/generating-sdks-from-oas) below. --- # Optimising Searches URL: https://docs.mambu.com/api/pages/api-v2/optimising-searches/ # Optimising Searches There are a few ways to make sure that your searches are optimised for performance. This becomes increasingly necessary the more records there are in the system. * **Make use of the `EQUALS_CASE_SENSITIVE` operator**: We recommend that you do not use the EQUALS operator, as it causes performance issues with larger data sets. Using the EQUALS_CASE_SENSITIVE operator can provide much faster results. The EQUALS operator will transform field values to lowercase before testing against the filter criteria, leading to performance issues. * **Avoid broad searches**: If your searches are returning a lot of results (more than 100k), consider adding narrower filter criteria and avoid pagination with large `offset` values. If possible, update the filter values instead of paginating by offset. The filter value can be updated based on data form previous searches or by splitting a large interval into smaller equal parts. For example, start by searching for journal entries with `creationDate AFTER 2023-07-22T00:00:00`, `limit=100` and sorted by `creationDate` in ascending order. Assuming the last journal entry in the result was created on `2023-07-22T01:24:35` continue by searching for journal entries with `creationDate AFTER 2023-07-22T01:24:35`. Alternatively instead of searching for `creationDate ON 2023-07-22` or `creationDate BETWEEN 2023-07-22T00:00:00 AND 2023-07-23T00:00:00` and paginating through the results, make more queries with smaller intervals such as `creationDate BETWEEN 2023-07-22T00:00:00 AND 2023-07-22T01:00:00`..`creationDate BETWEEN 2023-07-22T23:00:00 AND 2023-07-23T00:00:00`. * **Use indexed fields for search**: For a given entity, certain fields will be indexed in the database. Searching using these fields can dramatically speed up performance. Have at least one highly selective filter based on the indexed columns, do not rely on filter combinations to reduce the number of records returned by the query. If you have access to a database clone, you can use a GUI to list all indexed fields or an SQL query such as: `SELECT DISTINCT TABLE_NAME, INDEX_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.STATISTICS`. * **Prefer sorting by a filtered field**: Unless the number of records matching the specified filter criteria is very small (~10k) avoid sorting by a different field than the most constraining filter criteria. For example, if you are filtering by `lastModifiedDate` do not sort by `creationDate`. When using multiple filter criteria, you should only sort by the field of the most selective filter. * **Avoid large offsets for pagination**: Use a low value for the query offset parameter. Consider adding a supplementary filter or change the value for existing filters to have a lower total number of results rather than have a high offset value. Larger offsets increse response latency because 'skipping records' still requires that the application identifies and sorts the skipped records. For more information, see [Pagination](/api/pages/api-v2/pagination). * **Make use of the limit parameter for single record searches**: If you are making a search for something that should only return exactly one result, for example, an account by ID or encoded key, setting a `limit` of `1` will be more performant than making the same search query with no limit provided. For more information, see [Pagination](/api/pages/api-v2/pagination). * **Do not request full details if they are not required**: In most cases, we recommend keeping the default value for the `detailsLevel` query parameter, which is `BASIC` and then using the results to make subsequent requests to a `GET` endpoint using an encoded key or ID. For more information, see [Details Level ](/api/pages/api-v2/details-level). * **Time box queries**: If you are only interested in results occurring over a given time frame, for example, transactions for a given month or quarter, you can use the `BEFORE` and `AFTER` or `BETWEEN` operators to avoid making searches over the entire database. * **Do not include null values if they are not needed**: If you do not want to search for a field using a null value, do not include null values in the payload of the search request. --- # Pagination URL: https://docs.mambu.com/api/pages/api-v2/pagination/ # Pagination ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/?offset=10&limit=10&paginationDetails=ON \ -H 'Accept: application/vnd.mambu.v2+json' ``` ```http GET https://TENANT_NAME.mambu.com/api/Insert-Resource-URI-here?offset=10&limit=10&paginationDetails=ON HTTP/1.1 Host: TENANT_NAME.mambu.com Accept: application/vnd.mambu.v2+json ``` ```javascript var headers = { 'Accept':'application/vnd.mambu.v2+json' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/?offset=10&limit=10&paginationDetails=ON', method: '', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Accept' => 'application/vnd.mambu.v2+json' } result = RestClient. 'https://TENANT_NAME.mambu.com/api/?offset=10&limit=10&paginationDetails=ON', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Accept': 'application/vnd.mambu.v2+json' } r = requests.('https://TENANT_NAME.mambu.com/api/?offset=10&limit=10&paginationDetails=ON', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/?offset=10&limit=10&paginationDetails=ON"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty(“Accept”, “application/vnd.mambu.v2+json”); con.setRequestMethod(""); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Accept": []string, } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("", "https://TENANT_NAME.mambu.com/api/?offset=10&limit=10&paginationDetails=ON", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` ``` (...) content-type: application/vnd.mambu.v2+json date: Mon, 03 Sep 2018 10:56:15 GMT items-limit: 10 items-offset: 10 items-total: 35 (...) ``` Mambu API v2 has customisable pagination capabilities which can be used with all `GET` requests. It also has sorting and filtering capabilities for search endpoints. We strongly recommend using the pagination, sorting, and filtering capabilities when making requests which will return a large number of records because response times are much faster. ## Pagination query parameters Pagination is deactivated by default and must be specified in each request. There are three available query parameters you may use, `paginationDetails`, `offset`, and `limit`. ## `paginationDetails` The `paginationDetails` query parameter returns pagination details in the header of your response. The default value is `OFF`. To include pagination details set the value to `ON`. Pagination details includes the total number of records, the limit value, and the offset value. :::warning Please Note `PaginationDetails=ON` should only be used for the initial query. For all subsequent queries, for example, when paging through the results, we strongly advise to either pass `PaginationDetails=OFF`, or not include this parameter. If you request pagination details for all requests, there may be significant performance issues leading to higher response times. ::: ## `limit` The `limit` query parameter determines the number of records that will be retrieved. The default value is 50. The maximum value is 1,000. ## `offset` The `offset` query parameter determines how many records will be skipped before being included in the returned results. The default value is 0. In the example, we can see that there are 35 total records. By setting `offset` to 10 and `limit` to 10, we are returning the second set of 10 records, essentially "Page 2" of our paginated response. ## Pagination best practices Once you have used the pagination query parameters to retrieve all the available records in the database for your specific query, you no longer need to make any additional API requests. To determine whether you need to make any additional API requests you may compare the value of the `limit` parameter to the number of records retrieved in the body of your request. If the number of records is less than the value of the `limit` parameter then no additional API requests are necessary. If the number of records is equal to the `limit` value then you may make additional API requests. If you receive an empty array `[]` in the body of your request, this means there are no records for that request and you do not need to make any additional API requests. ## Sorting and filtering with search endpoints All the search endpoints in API v2 end in `:search`. Search endpoints accept a `filterCriteria` array of objects and a `sortingCriteria` object in their request body. When making broad searches that will return a lot of records, using pagination with appropriate values can ensure that your result set will not shift as new records matching your search criteria are created, which may otherwise lead to duplicates across pages. ### `sortingCriteria` The `sortingCriteria` object has two properties, `field` and `order`. **`field` property** We recommend you enter either an incremental ID or a timestamp as the value for the `field` property. **`order` property** The order property accepts two values, ascending (`ASC`) or descending (`DESC`). The default value is `DESC`, however, if using pagination or a search where new records are being actively created, for example transactions or journal entries created up to and including the current day, we strongly recommend you set the value to `ASC`. This will cause new records to be added to the end of your result set. ### `filterCriteria` If you are making a broad search that will return a lot of results, we recommend constraining your search query using a time interval. This may be done by setting the `field` property to a date property such as `creationDate` or `valueDate`. Setting the `operator` property to `BETWEEN`. And entering two dates as the values for the `value` and `secondValue` properties. This will ensure that no newly created records will interfere with a set of results. Please see the related note about searches using the `BETWEEN` operator in the [considerations for specific field types](/api/pages/api-v2/considerations-for-specific-field-types) section below for more information about this operator. --- # Payloads URL: https://docs.mambu.com/api/pages/api-v2/payloads/ # Payloads Mambu API v2 currently has endpoints that accept and return either `application/json`, `application/yaml`, or `multipart/form-data` payloads. When making a `POST`, `PUT`, or `PATCH` request, you must use the `Content-Type` header to specify the content type of the payload. --- # Requests URL: https://docs.mambu.com/api/pages/api-v2/requests/ # Requests ```shell # You can also use wget curl -X https://TENANT_NAME.mambu.com/api/ \ -H 'Accept: application/vnd.mambu.v2+json' ``` ```http GET https://TENANT_NAME.mambu.com/api/Insert-Resource-URI-here HTTP/1.1 Host: TENANT_NAME.mambu.com Accept: application/vnd.mambu.v2+json ``` ```javascript var headers = { 'Accept':'application/vnd.mambu.v2+json' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/', method: '', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Accept' => 'application/vnd.mambu.v2+json' } result = RestClient. 'https://TENANT_NAME.mambu.com/api/', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Accept': 'application/vnd.mambu.v2+json' } r = requests.('https://TENANT_NAME.mambu.com/api/', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty(“Accept”, “application/vnd.mambu.v2+json”); con.setRequestMethod(""); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Accept": []string, } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("", "https://TENANT_NAME.mambu.com/api/", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` API requests (also known as API calls) to the Mambu API identify who the requester is and exactly what information they wish to retrieve or which action they wish to perform. To put together an API request you will need to combine: * The [HTTP verb](/api/pages/api-v2/http-verbs) * The full URI to the resource * HTTP headers, for example, headers for [authentication](/api/pages/api-v2/authentication), [versioning](/api/pages/api-v2/versioning), and [payload content types](/api/pages/api-v2/payloads) * The [payload](/api/pages/api-v2/payloads) (if required) --- # Responses URL: https://docs.mambu.com/api/pages/api-v2/responses/ # Responses > Error Response ```json { "errorCode":"4", "errorSource":"Property scheduleSettings.repaymentInstallments may not be null", "errorReason":"INVALID_PARAMETERS" } ``` The response to a request will contain either an error response or a [payload in the content type](/api/pages/api-v2/payloads) that the endpoint accepts. ## Error response An error response will consist of: | Field | Type | Availability| Content | |---|---|---|---| | `errorCode` | number | Always present | A unique error code. For more information, see API Responses and Error Codes. | | `errorSource` | string | Sometimes present | A human-readable message capturing unsatisfied constraints. | | `errorReason` | string | Always present | A human-readable message stating the general category of the failure. | The contents of the `errorSource` and `ErrorResponse` fields are subject to change without backwards compatibility. --- # Retrieving v2 OAS Files URL: https://docs.mambu.com/api/pages/api-v2/retrieving-v2-oas-files/ # Retrieving v2 OAS Files ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/swagger/completejson/ \ -u 'username:password' ``` ```http GET https://TENANT_NAME.mambu.com/api/swagger/completejson/ HTTP/1.1 Host: TENANT_NAME.mambu.com Authorization: Basic ``` ```javascript var headers = { 'Authorization':'Basic ' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/swagger/completejson/', method: 'GET', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'Authorization' => 'Basic ' } result = RestClient.get 'https://TENANT_NAME.mambu.com/api/swagger/completejson/', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'Authorization': 'Basic ' } r = requests.get('https://TENANT_NAME.mambu.com/api/swagger/completejson/', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/swagger/completejson/"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty("Authorization", "Basic "); con.setRequestMethod("GET"); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "Authorization": []string } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("GET", "https://TENANT_NAME.mambu.com/api/swagger/completejson/", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` > Example response ```json { "swagger": "2.0", "info": { "version": "v2", "title": "clients" }, "host": "localhost:8889", "basePath": "/api", "tags": [ { "name": "Clients", "description": "Allows you to retrieve, create, update, or delete clients. Clients may have associated information such as their address, identification documents, or custom field values." } ], "schemes": [ "http", "https" ], "paths": { ... }, "securityDefinitions": { "basic": { "description": "", "type": "basic" } }, "definitions": { ... } } ``` Once you have followed the steps to [retrieve the `jsonPath` value](/api/pages/api-v2/oas-v2-discovery) for a specific API, you can build the path to a specific resource. To retrieve the specification file for a given API, join the base URL with the value of the relevant `jsonPath`. --- # Retrieving v3 OAS Files URL: https://docs.mambu.com/api/pages/api-v2/retrieving-v3-oas-files/ # Retrieving OAS v3 Files Once you have followed the steps to [retrieve the `jsonPath` value](/api/pages/api-v2/oas-v3-api-discovery) for a specific API, you can build the path to a specific resource. To retrieve the specification file for a given API, join the base URL with the value of the relevant `jsonPath`. ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/openapi/resources \ -u 'username:password' ``` ```json { "openapi" : "3.0.1", "info" : { "title" : "clients", "version" : "v2" }, "servers" : [ { "url" : "http://localhost:8889/api" }, { "url" : "https://localhost:8889/api" } ], "security" : [ { "basic" : [ ] } ], "tags" : [ { "description" : "Allows you to get, create, update, or delete clients. Clients may have associated information such as their address, identification documents, or custom field values.", "name" : "Clients" } ] } ``` ## Basic OAS file The basic OAS file will not include any custom field values and you do not need to authenticate to access this endpoint. The endpoint to retrieve the basic OAS file is: `https://TENANT_NAME.mambu.com/api/` For example, to retrieve the basic OAS file for the Clients API you would use: `https://TENANT_NAME.mambu.com/api/openapi/resources/clients/v2` ## Enriched OAS file The enriched OAS file will include any custom field values you have set up for your organisation at the time of generation. This endpoint requires authentication using HTTP Basic Auth. The endpoint to retrieve the enriched OAS file with custom field values is: `https://TENANT_NAME.mambu.com/api//complete` For example, to retrieve the enriched OAS file for the Clients API you would use: `https://TENANT_NAME.mambu.com/api/openapi/resources/clients/v2/complete` Both endpoints are available for both your production and sandbox environments. Replace `TENANT_NAME` with `TENANT_NAME.sandbox` to access API specifications for the sandbox environment, which is usually one version ahead of production. This gives you time to investigate new features and functionality before using it in production. --- # Sandbox URL: https://docs.mambu.com/api/pages/api-v2/sandbox/ # Sandbox The *sandbox tenant* (also known as sandbox environment) is independent from the *production tenant*, and any changes you make in the sandbox will not affect the data in your production tenant. For more information, see [Sandbox](/docs/sandbox) in our User Guide. To make requests to your tenant's sandbox, use the following base URL: * `https://TENANT_NAME.sandbox.mambu.com/api/` The sandbox is generally one version ahead of the production tenant. As such, it may include changes that are currently in, or may soon be in, the production environment. For more information, see [Mambu Release Cycle](/docs/mambu-release-cycle). ## Sandbox management To manage your sandbox go to the Customer Service Portal. For more information and instructions, see [Customer Service Portal - Sandbox Management](/docs/customer-service-portal#sandbox-management). --- # Searching by custom fields URL: https://docs.mambu.com/api/pages/api-v2/searching-by-custom-fields/ # Searching by custom fields > Search for entries where the given custom field definition has the value `FALSE` ```json { "filterCriteria": [ { "field": "_marketing_opt_in.investor_newsletter", "operator": "EQUALS_CASE_SENSITIVE", "value": "FALSE" } ] } ``` > Search for entries where the given custom field definition has one of the given values, sort by ID ```json { "filterCriteria": [ { "field": "_group_details.industry", "operator": "IN", "values": [ "agriculture", "arboriculture" ] } ], "sortingCriteria": { "field": "id", "order": "ASC" } } ``` You can build your filter and search queries using the native fields enumerated in the relevant schemas, for more information, see [Searching for Records](/api/pages/api-v2/searching-for-records). However, you can also use custom field definitions and their values in your filter and search queries for any entities that support custom field definitions. For more information, see [Custom Fields](/docs/custom-fields) in our User Guide. To filter or sort using a custom field definition you must provide the custom field set ID and the custom field definition ID using dot nation, for example `_custom_field_set_ID.custom_field_ID`. You can see an example of the syntax to the right. The custom field set can belong to the same entity or to a parent entity. --- # Searching for Records URL: https://docs.mambu.com/api/pages/api-v2/searching-for-records/ # Searching for Records > A basic search query for loans from a particular product type, sort by approval date `POST /loans:search` ```json { "filterCriteria": [ { "field": "loanName", "operator": "EQUALS_CASE_SENSITIVE", "value": "Agriculture Loan" } ], "sortingCriteria": { "field": "approvedDate", "order": "DESC" } } ``` > A search for current accounts which are active and overdrawn from two different branches using compound filters, sort by overdraft balance `POST /deposits:search` ```json { "filterCriteria": [ { "field": "accountState", "operator": "EQUALS_CASE_SENSITIVE", "value": "ACTIVE" }, { "field": "accountType", "operator": "EQUALS_CASE_SENSITIVE", "value": "CURRENT_ACCOUNT" }, { "field": "balances.overdraftAmount", "operator": "MORE_THAN", "value": 0 }, { "field": "assignedBranchKey", "operator": "in", "values": [ "8a193c26722b51b701722d779e7122de", "8a193c26722b51b701722d779e7122df" ] } ], "sortingCriteria": { "field": "balances.overdraftAmount", "order": "DESC" } } ``` Search functionality is provided for a number of entities through dedicated endpoints that can be identified by the `:search` suffix, for example to search for deposit accounts you can use the [`/deposits:search`](/api/api-v2/deposits/search) endpoint. Search endpoints accept a `POST` request that can include an object containing a `filterCriteria` array of objects and a `sortingCriteria` object in the request body. The `filterCriteria` array of objects allows you to narrow your search using multiple fields to filter by. Every entity that supports search has a schema that provides the enumerated values available for the filter properties, for example, the request body of the [`/deposits:search`](/api/api-v2/deposits/search) endpoint documents the available filter fields inline (`DepositAccountFilterCriteria`). The `sortingCriteria` object allows you to specify according to which field and in what way you would like to sort the returned results. Every entity that supports search provides a schema with all the available fields you can sort by. For example, the request body of the [`/deposits:search`](/api/api-v2/deposits/search) endpoint documents the available sort fields inline (`DepositAccountSortingCriteria`). Apart from native fields that are enumerated in the relevant schemas that you can use in your filter criteria, you can also filter by custom fields. For more information, see [Searching by custom fields](/api/pages/api-v2/searching-by-custom-fields). API v2 also provides a couple of additional features that allow you to further customize and manage your search queries. The pagination query parameters allow you to break up your search into smaller chunks, for more information, see [Pagination](/api/pages/api-v2/pagination) and [Optimising Searches](/api/pages/api-v2/optimising-searches). Additionally, you can perform cursor-based pagination which can significantly improve performance with large data sets. For more information, see [cursor-based search pagination](/api/pages/api-v2/cursor-based-search-pagination). The `detailsLevel` query parameter allows you to specify the level of detail to include in the results. For more information, see [Details Level](/api/pages/api-v2/details-level) and [Optimising Searches](/api/pages/api-v2/optimising-searches). --- # Standard custom field sets URL: https://docs.mambu.com/api/pages/api-v2/standard-custom-field-sets/ # Standard custom field sets In the examples provided for standard custom fields sets, we assume we have a custom field set with ID `_employer_information` and it contains a total of two custom field definitions with IDs `company` and `position`. ## Standard custom field set examples: ### Affecting a single custom field value in a custom field set > Adding a value to a single custom field definition in a custom field set ```json [ { "op": "ADD", "path": "/_employer_information/company", "value": "Google" } ] ``` To add, replace, or remove a value for a single custom field definition in a custom field set, pass the custom field set ID **and** the custom field definition ID to the `path` property. To add or replace a value, enter it directly to the `value` property. To remove a value, do not include the `value` property in the JSON object. In the example to the right, we are adding a value for the `company` custom field definition. ### Affecting all the custom field definitions in a custom field set > Replacing all the custom field values in a custom field set ```json [ { "op": "REPLACE", "path": "/_employer_information", "value": { "company": "Amazon", "position": "senior frontend developer" } } ] ``` To add, replace, or remove all the custom field values in a custom field set, pass the custom field set ID to the `path` property. To add or replace values, provide an object with all the custom field values within the custom field set to the `value` property including the custom field value you are adding or replacing. To remove values, do not include the `value` property in the JSON object. In the example to the right, we are replacing the values for both the `company` and `position` custom field definitions. :::note When adding or replacing values, if you omit any custom field definitions that are part of the custom field set then their values will be removed. ::: In the first example to the right, we are removing the value for the `company` custom field definition. In the second example to the right, we are removing the values for all the custom field definitions in the `_employer_information` custom field set. > Removing one custom field value from the custom field set ```json [ { "op": "REMOVE", "path": "/_employer_information/company" } ] ``` > Removing all the custom field values from a custom field set ```json [ { "op": "REMOVE", "path": "/_employer_information" } ] ``` --- # Time Zone Offsets URL: https://docs.mambu.com/api/pages/api-v2/timezone-offsets/ # Time Zone Offsets Here is how we handle time zone offsets in API v2 calls: * We use the following standard date format: ISO_8601_FORMAT_DATE_TIME = "YYYY-MM-DD'T'hh:mm:ss±hh:mm". * We calculate the offset for the date sent by the client, at that moment in time, taking into consideration the tenant’s time zone. For example: "−05:00" for New York on standard time (UTC-05:00), "−04:00" for New York on daylight saving time (UTC-04:00). * We compare the offset value sent by the client with the offset value calculated by us. If they don’t match an exception is thrown which informs the client about the correct offset. See example. >Example JSON body showing an invalid date offset request ```json { "errors": [ { "errorCode": 4, "errorSource": "Invalid date offset for value 2021-03-09T13:37:50 org offset is +02:00", "errorReason": "INVALID_PARAMETERS" } ] } ``` Example Each Mambu tenant has *one* time zone. Let’s take for example tenants in the East European time zone (UTC+02:00). | Date and time of request | Error message or What is saved in the database | |---|---| | 2021-03-09T13:37:50 | “Invalid date offset for value 2021-03-09T13:37:50 org offset is +02:00” | | 2021-03-09T13:37:50+03:00 | “Invalid date offset for value 2021-03-09T13:37:50 org offset is +02:00” | | 2021-03-09T13:37:50+02:00 | 2021-03-09 13:37:50 | :::note When posting a transaction in the present, the current offset should be used, according to the tenant’s time zone.When posting a backdated transaction, the offset as it was on the day and time of the backdated transaction should be used, according to the tenant’s time zone.When posting a transaction in the future, the future offset should be used, according to the tenant’s time zone.If your country uses Daylight Saving Time, posting transactions that occur during 'lost' hours, for example between 02:00:00 a.m. CEST and 2:59:59 a.m. CEST, will result in API error messages related to the offset. We also generally recommend not processing API calls during the minutes leading up to and after the switchover as small differences in clock synchronisation across various systems and services may lead to unexpected errors. ::: --- # Using Custom Fields URL: https://docs.mambu.com/api/pages/api-v2/using-custom-fields/ # Using custom fields Custom fields are fields you may create for several entities that allow you to capture additional relevant information and they are grouped together in custom field sets. A custom field consists of the custom field definition and the custom field value. The *custom field definition* is the custom field you create using either the Mambu UI or API which contains information such as its name, ID, type, and usage settings. The *custom field value* is the actual value that a custom field attached to an entity holds. For more information about custom fields, how to create them, and which entities support them, see Custom Fields in our User Guide. In API v2, if a JSON object includes a custom field value, then at the end of the JSON object, there will be a custom field set property which will contain the custom field definition ID and the custom field value. :::note A custom field value in a request body may not be an empty string or null regardless of whether the custom field definition is marked as required or not. ::: There are two kinds of custom field sets, standard and grouped. A **standard** custom field set can contain multiple single custom field definitions. Each custom field definition may contain only one value. In a JSON object, it is represented by a custom field set property that contains an object with the associated custom field values. A **grouped** custom field set contains groups of custom field definitions. You may have multiple groups of custom field definitions within the custom field set. In a JSON object, it is represented by a custom field set property that contains an array of objects with the associated custom field values and the index of each object in the array. The type of custom field set dictates how custom field definitions and their values must be handled in `PATCH` operations. Here is an example of a single custom field set and a grouped custom field set: > Single custom field set ```json { ... "_customFieldSet": { "customFieldDefinitionId1": "value", "customFieldDefinitionId2": "value", "customFieldDefinitionId3": "value" } ... } ``` > Grouped custom field set ```json { ... "_customFieldSet": [ { "_index": "0", "customFieldDefinitionId1": "value", "customFieldDefinitionId2": "value", "customFieldDefinitionId3": "value" }, { "_index": "1", "customFieldDefinitionId1": "value", "customFieldDefinitionId2": "value", "customFieldDefinitionId3": "value" } ] ... } ``` You can identify any custom field set because the ID starts with an underscore `_`. To retrieve the custom field values of any object, you must set the `detailsLevel` query parameter to `FULL` when making a request. For more information, see [Details Level](/api/pages/api-v2/details-level). You may make `PATCH` requests to add, replace, or remove a custom field value that you have appropriate access to. We will provide more details on how to perform `PATCH` requests below. For more information on how access to custom field values is managed, see Custom Fields - Configuring rights for roles. :::note Mambu API v2 PATCH operations respect the RFC6902 standards. We recommend that you use [a tool for PATCH generation](https://chbrown.github.io/rfc6902/) to avoid syntax mistakes. ::: ### Example Here you can see an example of a standard custom field set with ID `_loanPerformanceScore` that includes two custom field definitions with IDs `amountScore` and `timeScore` and their values. ```json { "id": "ABC001", "loanName": "Mortgage Loan", "loanState": "PARTIAL_APPLICATION", ... "_loanPerformanceScore": { //custom field set "amountScore": "10", //custom field values nested under the set "timeScore": "5" } } ``` Here you can see an example of a grouped custom field set with ID `_assets` and three custom field definitions with IDs `asset_age`, `asset_type`, and `asset_value` and their values. ```json { "encodedKey": "8a19aad43801888d017801f0dd841c1d", "id": "190955358", "state": "ACTIVE", "creationDate": "2021-03-05T11:31:05+01:00", "lastModifiedDate": "2022-08-08T12:42:35+02:00", "activationDate": "2021-11-18T10:19:13+01:00", "approvedDate": "2021-03-05T11:31:05+01:00", "firstName": "John ", "lastName": "Smith ", ... "_assets": [ //custom field set { //custom field values in groups nested under the set "_index": "0", "asset_value": "965000", "asset_type": "land", "asset_age": "10" }, { "_index": "1", "asset_value": "25,000", "asset_type": "car", "asset_age": "2" } ] } ``` --- # Versioning URL: https://docs.mambu.com/api/pages/api-v2/versioning/ # Versioning ```shell # You can also use wget curl -X GET https://TENANT_NAME.mambu.com/api/swagger/completejson/ \ -H 'apikey: APIKEY' ``` ```http GET https://TENANT_NAME.mambu.com/api/swagger/completejson/ HTTP/1.1 Host: TENANT_NAME.mambu.com apikey: APIKEY ``` ```javascript var headers = { 'apikey':'APIKEY' }; $.ajax({ url: 'https://TENANT_NAME.mambu.com/api/swagger/completejson/', method: 'GET', headers: headers, success: function(data) { console.log(JSON.stringify(data)); } }) ``` ```ruby require 'rest-client' require 'json' headers = { 'apikey' => 'APIKEY' } result = RestClient.get 'https://TENANT_NAME.mambu.com/api/swagger/completejson/', params: { }, headers: headers p JSON.parse(result) ``` ```python headers = { 'apikey': 'APIKEY' } r = requests.get('https://TENANT_NAME.mambu.com/api/swagger/completejson/', params={ }, headers = headers) print r.json() ``` ```java URL obj = new URL("https://TENANT_NAME.mambu.com/api/swagger/completejson/"); HttpURLConnection con = (HttpURLConnection) obj.openConnection(); con.setRequestProperty("apikey", "APIKEY"); con.setRequestMethod("GET"); int responseCode = con.getResponseCode(); BufferedReader in = new BufferedReader( new InputStreamReader(con.getInputStream())); String inputLine; StringBuffer response = new StringBuffer(); while ((inputLine = in.readLine()) != null) { response.append(inputLine); } in.close(); System.out.println(response.toString()); ``` ```go package main "bytes" "net/http" ) func main() { headers := map[string][]string{ "apikey": []string } data := bytes.NewBuffer([]byte) req, err := http.NewRequest("GET", "https://TENANT_NAME.mambu.com/api/swagger/completejson/", data) req.Header = headers client := &http.Client resp, err := client.Do(req) // ... } ``` > Example response ```json { "swagger": "2.0", "info": { "version": "v2", "title": "clients" }, "host": "localhost:8889", "basePath": "/api", "tags": [ { "name": "Clients", "description": "Allows you to retrieve, create, update, or delete clients. Clients may have associated information such as their address, identification documents, or custom field values." } ], "schemes": [ "http", "https" ], "paths": { ... }, "securityDefinitions": { "basic": { "description": "", "type": "basic" } }, "definitions": { ... } } ``` Mambu API v2 provides a versioning system to assist with backwards compatibility. Contract changes will result in a new version of each affected resource becoming available without the old version immediately becoming obsolete. Some features documented here may be in beta or part of an Early Access Release for selected customers. This means contract changes without backwards compatibility are still possible. Any such changes will be mentioned in advance in the release notes. For more information about the stages a feature can be in, see [Mambu Release Cycle](/docs/mambu-release-cycle). Versioning is supported in API requests via the `Accept` header. Template: `application/vnd.mambu.+json` To retrieve a specific version of an entity, fill a value into the template above. The highest currently supported version is `v2`. --- # Welcome URL: https://docs.mambu.com/api/pages/api-v2/welcome/ # Welcome Welcome to the Mambu API v2 documentation. Here you can learn everything you need to know about API v2 and how to interact with Mambu! :::note If you are looking for documentation for another API, you can use the **Mambu APIs** menu to view API Reference documentation for [API v1](/api/pages/api-v1/welcome), Payments API, or [Streaming API](/api/pages/streaming/streaming-index). For more information about all the RESTful APIs we offer, see [Mambu APIs](/docs/mambu-apis) in our User Guide. ::: We offer language bindings in cURL, HTTP, JavaScript, Node.js, Ruby, Python, Java, and Go. You can view code examples in the area to the right, and you can switch the programming language of the examples with the tabs at the top right. You can also download OpenAPI specifications for all of our endpoints which can be used to generate client SDKs, interactive documentation, create mock servers and more. For more information, see the [OpenAPI specification](/api/pages/api-v2/openapi-specification) section. --- # Best Practices URL: https://docs.mambu.com/api/pages/audit-trail/best-practices/ * Limit your scans to the smallest timeframes possible. The less data that needs to be scanned, the faster the response will be. Furthermore, you will spend less of your quota. * Use `contains` (see [Operators](/api/audit-trail/search-audit-events#operators)) with smaller timeframes. * Periodically pulling batches of all records (or a big subset) is possible, but not the recommended approach. ## Search response time Search metadata via the Audit Trail API becomes available in 15-minute sequences. In other words, if you've searched on 15:46:00 UTC, then metadata will be updated and available at 16:02:00. If you've searched at 16:14:00 UTC, then the metadata will be updated and available at 16:17:00. Otherwise, the response will contain the previous cached value. --- # Data Retention and Service Quota URL: https://docs.mambu.com/api/pages/audit-trail/data-retention-and-service-quota/ ## Data retention We start storing events from the point that the Audit Trail feature is enabled. By default, events in Production are stored for 5 years, but only 6 months in Sandbox. After this period, events are irreversibly deleted. If you want to change the production retention period for Audit Trail, please contact your CSM. ## Service quota * Each tenant receives 1 request per second for the `/v2/events` endpoint. Requests above this amount will be throttled and an exception will be returned. Here is an example of an exception: ```json HTTP Status: 429 ``` * With one search request you can access up to 50,000 records. The default limit for search requests is 10,000 records. * Each call to the API will scan a certain amount of bytes. Depending on your Audit Trail tier, you are entitled to a certain amount of bytes to scan per year. Upon breaching the limit, we will inform you about it. * You can only retrieve up to 30 days of usage history per request to safeguard against using up your quota. For example, you can scan from 01/01/2025 -> 30/01/2025, and then from 31/01/2025 -> 28/02/2025. * Depending on your Audit Trail tier, you are entitled to a certain amount of storage. Upon breaching the limit, we will inform you about it and discuss further steps - either to increase the tier or remove old data. --- # Pagination URL: https://docs.mambu.com/api/pages/audit-trail/pagination/ :::note All results are ordered by the `occurred_at` timestamp field in ascending order. ::: From the sample response, there are two parameters which help with pagination. When you scan a certain period, you will receive 10,000 events by default, and up to 50,000. However, if for a given period there are more events than 10,000/50,000 then `hasMore: true` will indicate that. To fetch the next batch of events, you have to provide the `nextStartTime` value to the `occurred_at[gte]` query parameter. Taking the previous response body, the query will look like this: ``` curl 'https://TENANT_NAME.mambu.com/api/v2/events?occurred_at\[gte\]=2025-01-04T00:03:13.000Z&occurred_at\[lte\]=2025-01-04T23:59:59Z&event_source\[eq\]=UI&resource\[eq\]=login' \ --header 'apikey: ' ``` --- # Security URL: https://docs.mambu.com/api/pages/audit-trail/security/ For security reasons, the following information is removed from request payloads when using Audit Trail: ``` PASSWORD PAGINATION_DETAILS FETCHING_INFO MOBILE_PHONE EMAIL_ADDRESS ADDRESSES BIRTH_DATE MOBILE_PHONE1 MOBILE_PHONE2 FIRST_NAME LAST_NAME HOME_PHONE MIDDLE_NAME NOTES GROUP_NAME ADDRESS_LINE_1 ADDRESS_LINE_2 ADDRESS_LATITUDE ADDRESS_LONGITUDE DESCRIPTION TITLE TEXT ASSET_NAME LOAN_NAME NAME POST_CODE COUNTRY REGION GENDER IBAN ``` --- # Mambu Audit Trail API URL: https://docs.mambu.com/api/pages/audit-trail/welcome/ # Welcome Welcome to the Mambu Audit Trail API Reference documentation! The Audit Trail capability tracks all activities that were performed in the Mambu Core Banking Engine via either the UI or the [V1](/api/pages/api-v1/welcome) and [V2](/api/pages/api-v2/welcome) API. Audit records are grouped per tenant. Audit records include who did what and when. You can search and filter through stored events using an API. A key difference between Audit Trail and [Activities](/docs/tracking-activities) is Audit Trail's ability to track both changes to your system, as well as system access history, due to the support for not only write operations such as POST, PUT, DELETE, and PATCH; but also GET (read) operations. This provides more granular user activity tracking, which is not possible in Activities. ## Use cases Some example use cases might be: * Investigate suspicious activity or potential fraud. * Detect actions performed by an unauthorized user. * Monitor and gather data about specific activities or users. * Track failed login attempts (e.g. brute force attack upon your system). * Generate compliance and audit reports from audit data. :::note Use of Audit Trail requires [API Consumers](/docs/api-consumers), which is an Early Access feature. For more information see [Authentication](#authentication). ::: :::note The new version of Audit Trail is designed to be more scalable and optimised for storage over speed. Therefore, you may experience slower performance as a result of this design decision. ::: ## Audit Trail V2 release information Audit Trail V2 includes some significant improvements over V1, and some changes which may break your current implementation. Before upgrading to the `/v2/events` endpoints, please refer to the extensive documentation on this page and the items listed in [Backwards Compatibility](/docs/backwards-compatibility) to ensure that your migration process is smooth. ## Supported operations Base URL: `https://TENANT_NAME.mambu.com/api` | Action | Endpoint | Description | | --- | --- | --- | | `GET` | `/v2/events` | Retrieve a list of events. | | `GET` | `/v2/events/metadata` | Get information on how much data has been scanned. | :::info If you are looking for documentation for another API, you can use the **Mambu APIs** menu to view API Reference documentation for [API v1](/api/pages/api-v1/welcome), [API v2](/api/pages/api-v2/welcome), [Streaming API](/api/pages/streaming/streaming-index), or [Mambu Payment Gateway](/api/pages/payments-mpg/welcome). For more information about all the APIs we offer, see [Mambu APIs](/docs/mambu-apis) in our User Guide. ::: ## Authentication To authenticate audit trail requests you must use an API key generated by an API consumer that has the Manage Audit Trail (`MANAGE_AUDIT_TRAIL`) permission assigned to it. For more information, see [API Consumers](/docs/api-consumers). ## Headers Other than the authentication header with the API key, you do not need to use any additional headers. --- # About the Mambu Payments API URL: https://docs.mambu.com/api/pages/payments-mpg/about-the-mambu-payments-api/ The Payments API allows you to orchestrate the movement of money between an account in Mambu and an account at a third-party financial institution, both domestic as well as international, using SEPA-compliant messages for interchange. The orchestration includes triggering payment execution on the user-specified date, debiting or crediting the account in Mambu, and storing-and-forwarding the credit or debit instruction for settlement in a third party financial institution via the Mambu Payment Gateway. The Mambu Payment Gateway in turn sends it out to Payment Network. Before using the Mambu Payment Gateway, you will need to carry out the steps outlined in our [payments documentation](/docs/payments-settings). This includes setting up an [API consumer](/docs/payments-settings#1-create-api-consumer-and-key-for-mambu-payments-gateway-api), [transaction channels](/docs/payments-settings#3-create-the-payment-transaction-channels), and configuring your [bank identification codes](/docs/payments-settings#3-create-the-payment-transaction-channels) and [job schedulers](/docs/payments-settings#7-set-incoming-and-outgoing-schedulers-configuration). ## Base URLs The base URL for requests to the Payments API is found below: `https://TENANT_NAME.mambu.com/api/v1` You may also use the sandbox environment for testing. The sandbox environment is generally one version ahead of the production environment. The base URL for your sandbox environment is: `https://TENANT_NAME.sandbox.mambu.com/api/v1` ## HTTP verbs Standard HTTP verbs are used to indicate the API request method. | Verb | Function | |:---------|:----------------------------------------------------| | `GET` | To retrieve a resource or a collection of resources | | `POST` | To create a resource | | `PATCH` | To modify an existing resource | | `PUT` | To replace an existing resource | | `DELETE` | To delete a resource | --- # Incoming and Outgoing Messages URL: https://docs.mambu.com/api/pages/payments-mpg/incoming-and-outgoing-messages/ The Payments API is designed to handle messages coming from external sources such as clearing houses or other financial institutions, as well as to send XML-formatted payment instructions to your own clearing and settlement provider. ## Incoming messages For handling by the Payments API, all incoming messages must be routed to the [`/payments/incoming`](/api/payments-mpg/submit-incoming-message/) endpoint. This endpoint accepts XML and responds with an HTTP status of `202 accepted`, indicating that the message has been received and will be processed. The response includes a `messageId`, which can be used to later identify the transaction. For example, it can be used with `getPaymentDetails` or `getCollectionDetails` API requests to retrieve payment details and the current status of the transaction. In case of any incoming message errors, the endpoint responds with a `4xx` status code and an array of messages giving details on the errors encountered. Errors can range from invalid content type to individual fields within the message not conforming to the payment scheme specification. Errors will be reported using the `TPPMessage` model, and should be handled by your service. :::note As this endpoint may be exposed to external systems, we strongly recommend using a separate API key for each service calling this API. This is an industry best practice and makes debugging easier, it also allows you to rotate or invalidate keys for a particular service in cases of system error or during security incidents. ::: ## Outgoing messages > Example outgoing message ``` Content-Type: application/xml Authorization: BASIC AuThKey== Message-Type: urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02 Message-Id: SCTORD156820211213000000012649 <?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02"> <FIToFICstmrCdtTrf> ... </FIToFICstmrCdtTrf> </Document> ``` When you create payments or inquiries, the Mambu Payment Gateway generates the appropriate ISO 20022 XML message and schedules it to be sent to the webhook callout URL configured in the Mambu Payment Gateway UI. See the [callout configuration](/docs/payment-gateway-system-properties#callout-configuration) section of the Mambu Payment Gateway system properties article in our User Guide for more information on configuring your callout URL, including authentication options. Outgoing messages are XML formatted messages conforming to the ISO 20022 specification - specifically, the subset supported by the SEPA payment scheme. The `Message-Type` header includes the type of message sent, such as `pacs.008.001.02` for a SEPA credit transfer or `camt.056.001.01` for cancellation of a payment. :::warning We strongly recommend that you implement a deduplication or idempotency mechanism on the service which is receiving the outgoing messages. Networks can be unstable and it is possible that the same payment message can be sent multiple times. ::: #### Parameters | Name | Type | Description | In | Required | |------|------|-------------|----|----------| | Content-Type | string | The encoding of the content in the body of the request. This will always be `application/xml` | Header | true | | Authentication | string | BASIC authentication credentials. Base64 encoded representation of the credentials provided in webhook configuration in the Mambu Payment Gateway settings | Header | false | | Message-Type | string | Message namespace URN. For example `urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02` | Header | true | | Message-Id | string | Message ID, representing the `GrpHdr>MsgId` field of the message | Header | true | | Body | XML | The actual, generated XML message. The content of the message will, depending on the source, include data provided in an API request, data from another payment or collection instruction, or a combination of both. Visit our User Guide for examples of selected messages or refer to the European Payments Council [document library](https://www.europeanpaymentscouncil.eu/search?kb%5B0%5D=type%3A81) for more comprehensive descriptions of the message types supported by the SEPA payment scheme. | body | true | --- # Open API Specification URL: https://docs.mambu.com/api/pages/payments-mpg/open-api-specification/ > Use this link to access the [latest Open API Specification](pathname:///files/mambu-payments-api-spec-oas3.json). This documentation is automatically generated from an OpenAPI Specification (OAS). This OAS file can also be used to quickly scaffold client SDKs, in various languages, for interacting with our APIs using a number of tools, including the online [Swagger Editor](https://editor.swagger.io/). You can access the latest version of this specification using the link provided. --- # Welcome URL: https://docs.mambu.com/api/pages/payments-mpg/payments-index/ :::note Removal of Mambu Payment Gateway At Mambu we are committed to delivering cutting-edge financial technology. Our recent acquisition of Numeral allows us to provide you with an even more powerful and efficient payment solution with advanced [payment capabilities](https://mambu.com/en/payments-numeral). Therefore we have made the decision to discontinue the development and support of Mambu Payment Gateway. Our teams are available to discuss your options, including a potential migration to Numeral. We understand the implication that this change may have on your operations and are committed to supporting you throughout the transition period. For all technical information about the new Mambu Payments product, refer to the documentation: * [Mambu Payments functional documentation](https://docs.numeral.io/docs/get-started) * [Mambu Payments API documentation](https://docs.numeral.io/reference/introduction) ::: For all users still actively using the Mambu Payments Gateway, refer to the pages below: [Mambu Payments Gateway](/api/pages/payments-mpg/payments-mpg-index). --- # Welcome URL: https://docs.mambu.com/api/pages/payments-mpg/payments-mpg-index/ Welcome to the Mambu Payments Gateway API Reference documentation. Our Payments API allows you to process payments made via the Single Euro Payments Area (SEPA) payments scheme. It is independent from the existing Mambu API and webhook infrastructure. :::note Enabling the Payments capability The Payments capability is an add-on feature and is not enabled by default. When you enable the Payments capability, you will get access to the Payments API and Mambu Payment Gateway. If you would like to discuss enabling this service for your Mambu instance, please get in touch with your Customer Success Manager or Application Engineer. ::: For more information about the Payments capability and the Mambu Payment Gateway, see [Payments Introduction](/docs/payment-gateway-introduction) in our User Guide. :::note If you are looking for documentation for another API, you may use the **More APIs** menu to view API Reference documentation for [API v1](/api/pages/api-v1/welcome), [API V2](/api/pages/api-v2/welcome), or [Streaming API](/api/pages/streaming/streaming-index). For more information about all the APIs we offer, see [Mambu APIs](/docs/mambu-apis) in our User Guide. ::: --- # Using the API URL: https://docs.mambu.com/api/pages/payments-mpg/using-the-api/ ## Authentication To access the Payments API, you must create an API consumer that has the **Manage Payments** (`MANAGE_PAYMENTS`) permission assigned to it and create API keys using this API consumer. API keys inherit the scope of access settings from the API consumer that creates them. You must authenticate every request to the Payments API using an API key in the request header. You may create and manage API consumers and keys either through the Mambu UI or using the [API Consumers endpoint](/api/api-v2/consumers/get-all/) provided by Mambu API v2. For more information, see [API Consumers](/docs/api-consumers) in our User Guide. :::note API consumers and keys is currently an Early Access feature. If you would like to request early access to this feature, please get in touch with your Mambu Customer Success Manager to discuss your requirements. For more information, see [Mambu Release Cycle - Feature Release Status](/docs/mambu-release-cycle#feature-release-status). ::: > Example authenticated request using cURL ```bash curl --request GET 'https://TENANT_NAME.mambu.com/api/v1/collections/d45a34ed341321bca4d89e42452dc074' \ --header 'apikey: i9TCzwUBwyTVQrfPEAhk0oEpOUCt0O2M' ``` ## Content types Depending on the endpoint, the Payments API will accept one of two content types: JSON and XML. The format should be specified in the `Content-Type` header with either the value `application/json` or `application/xml`. Check the parameters table for each request for the required value for the `Content-Type` header. For certain requests, including some POST requests, there is no need to supply a request body. For these requests, the `Content-Type` header can be omitted. ## Idempotency Many POST requests take an optional `Idempotency-Key` header. The value of this header should be a randomly generated string, unique to the request. We recommend using a UUID generator or library to create idempotency keys in the UUID v4 format. The following example shows a typical UUID: `c2f53453-439c-4efa-9e27-58877160638b`. Using an idempotency key helps avoid duplicate requests. When an idempotent request is processed, the status code and body of the response is associated with the idempotency key and stored in a cache. If the request is duplicated for any reason, the duplicate request is not processed, and the response is re-sent to the client. --- # About Mambu Streaming API URL: https://docs.mambu.com/api/pages/streaming/about-mambu-streaming/ # About Mambu Streaming API The purpose of the Streaming API is to provide a high-performance and reliable mechanism to stream significant amounts of data out of Mambu on a constant basis, without posing unnecessary pressure on the API and webhook infrastructure. In order to subscribe to Mambu notifications events and consume them, a dedicated API is exposed to be used by clients. The typical workflow is: 1. Create a subscription specifying the topic names you want to read. 2. Start reading batches of events from the subscription. 3. Commit the cursors found in the event batches back to Mambu, which will store the offsets. If the connection is closed, and later restarted, clients will get events from the point of your last cursor commit. If you need more than one client for your subscription to distribute the load you can read the subscription with multiple clients, for more details please check the get events endpoint. --- # Authentication URL: https://docs.mambu.com/api/pages/streaming/authentication/ # Authentication To access the Streaming API, you must create an API consumer that has the **Manage Events Streaming** (`MANAGE_EVENTS_STREAMING`) permission assigned to it and create API keys using this API consumer. API keys inherit the scope of access settings from the API consumer that creates them. You must authenticate every request to the Streaming API using an API key in the request header. You may create and manage API consumers and keys either through the Mambu UI or using the [API Consumers endpoint](https://api.mambu.com/#mambu-api-v2-api-consumers) provided by Mambu API v2. For more information, see API Consumers in our User Guide. :::note Please note API consumers and keys is currently an Early Access feature. If you would like to request early access to this feature, please get in touch with your Mambu Customer Success Manager to discuss your requirements. For more information, see Mambu Release Cycle - Feature Release Status. ::: > Example authenticated request using cURL ```bash curl --request GET 'https://TENANT_NAME.mambu.com/api/v1/subscriptions/d45a34ed341321bca4d89e42452dc074/events' \ --header 'apikey: i9TCzwUBwyTVQrfPEAhk0oEpOUCt0O2M' ``` --- # Base URLs URL: https://docs.mambu.com/api/pages/streaming/base-urls/ # Base URLs The base URL for requests to the Streaming API is found below: - `https://TENANT_NAME.mambu.com/api/v1` To make requests to your tenant's sandbox, use the following base URL: - `https://TENANT_NAME.sandbox.mambu.com/api/v1` :::info Replace `TENANT_NAME` above with the tenant name in your Mambu tenant URL. ::: --- # Committing Cursors URL: https://docs.mambu.com/api/pages/streaming/committing-cursors/ # Committing Cursors `POST /subscriptions//cursors` ## Request Cursors can be committed by making a POST request to the subscription's cursor resource `/subscriptions//cursors`: :::note Please be aware that the `X-Mambu-StreamId` header is required when committing a cursor. The value should be the same as the `X-Mambu-StreamId` header you receive when opening a stream of events. Also, each client can only commit batches that it has received. ::: > Sample Request ```curl curl -v -X POST "https://TENANT_NAME.mambu.com/api/v1/subscriptions/0691160a-b519-4595-b85c-a400fc73e963/cursors"\ -H "X-Mambu-StreamId: 93ae5174-b863-4f8f-ba33-d274854d1f3d" \ -H "Content-type: application/json" \ -d ``` > Body Parameter ```json { "items": [ { "partition": "1", "offset": "001-0001-000000000000000000", "event_type": "mrn.event.demo_tenant.streamingapi.client_approved", "cursor_token": "db4b4c27-f880-4406-a382-b057acf432cd" } ] } ``` ## Response The possible successful responses for a commit are: - `204`: Cursors were successfully committed and offset was increased. - `200`: Cursors were committed but at least one of the cursors didn’t increase the offset, since it was less than or equal to the already committed one. The response body will also include json with a list of cursors and the results of their commits. The timeout for commit is `60` seconds. If you open the stream, read data, and don’t commit anything for `60` seconds - the stream connection will be closed from the Mambu side. Please note that if there are no events available to send and you get only empty batches - there is no need to commit; Mambu will close the connection only if there is some uncommitted data and no commits happened for `60` seconds. If the connection is closed for any reason, the client still has `60` seconds to commit the events it received from the moment the events were sent. After that, the session will be considered closed and it will no longer be possible to commit with that `X-Mambu-StreamId`. If the commit was not made - then the next time you start reading from a subscription you will get data from the last point of your commit, you will receive the events you haven’t committed again and will need to deduplicate. --- # Consuming Events from a Subscription URL: https://docs.mambu.com/api/pages/streaming/consuming-events-from-a-subscription/ # Consuming Events from a Subscription `GET /subscriptions//events` ## Request Events can be consumed by sending a `GET` request to the subscription's event resource `/subscriptions//events`. :::note The consumption of events is handled by your client application. If your client application is not able to process the format of the streaming notification, you may encounter a validation error. For an example of how to handle a message with a validation error, see the consumeEvents class in the Streaming-API-Java-Sample-Client GitHub repository. ::: > Sample Request ```curl curl -v -X GET "https://TENANT_NAME.localhost:8889/api/v1/subscriptions/0691160a-b519-4595-b85c-a400fc73e963/events" ``` ### Response The response is a stream that groups events into JSON batches separated by an endline (\n) character. The output can be seen in the right panel. Each batch contains the following fields: - `cursor`: The cursor of the batch which should be used for committing the batch. - `events`: The array of events of this batch. - `info`: An optional field that can hold useful information (e.g. the reason why the stream was closed by Mambu). :::note When a stream is started, the client receives a header named `X-Mambu-StreamId`, which must be used when committing cursors. See [Committing Cursors](/api/pages/streaming/committing-cursors) for more information. ::: > Sample Response ```shell HTTP/1.1 200 OK X-Mambu-StreamId: 93ae5174-b863-4f8f-ba33-d274854d1f3d Transfer-Encoding: chunked , "info": } { "cursor" : , "events": [ { "metadata": { "occurred_at": "2018-11-18T22:50:12.602Z", "eid": "fde622d5-f975-4786-8e1d-d328c29761f9", "event_type": "mrn.event.demo_tenant.streamingapi.client_approved", "partition": "1", "received_at": "2018-11-18T22:50:12.786Z", "flow_id": "jOK94UJFdtKsthWOgOJCwuGC", "version": "1.0.0" }, "occurred_at": "2018-11-18T22:50:12.602Z", "body": "Client was approved notification body", "content_type": "text/plain; charset=UTF-8", "template_name": "Demo Template 1", "category": "DATA" } ]} { "cursor" : } ``` --- # Creating an Event Stream URL: https://docs.mambu.com/api/pages/streaming/creating-an-event-stream/ # Creating an event stream Before you can subscribe to an event stream using the API you will first need to specify the set of events to be streamed using the Mambu UI. We strongly recommend reading our support article on the [Streaming API](/docs/streaming-api) for a walkthrough. Using the UI you will also create the body of each event notification using JSON, XML, or plain text and can make use of placeholders to include specific information such as client or account IDs, transactions amounts, or the values of custom fields. Once the event streams have been created using the UI you will have a set of topics that you can subscribe to using the `POST /subscriptions` API by passing them in the `event_types` array. --- # Creating Subscriptions URL: https://docs.mambu.com/api/pages/streaming/creating-subscriptions/ # Creating Subscriptions `POST /subscriptions` ## Request A subscription can be created by sending a `POST` request to the `/api/v1/subscriptions` resource. > Sample Request ```curl curl -v -X POST "https://TENANT_NAME.mambu.com/api/v1/subscriptions" -H "Content-type: application/json" -d ``` > Body Parameter ```json { "owning_application": "demo-app", "event_types": ["mrn.event.TENANT_NAME.streamingapi.client_approved","mrn.event.TENANT_NAME.streamingapi.client_rejected"], "consumer_group": "default", "read_from": "end" } ``` The `consumer_group` and `read_from` fields are optional. * `consumer_group`: The name of the consumer group the subscription is associated with. A consumer group is a set of consumers which cooperate to consume messages from some topics. The default value is `default`. For more information, see [Subscription Cursors](/api/pages/streaming/subscription-cursors). * `read_from`: The position in the stream from where the subscription should start receiving events. It can be `begin` (the oldest available event) or `end` (the newest available event). The default value is `end`. For more information, see [Subscription Cursors](/api/pages/streaming/subscription-cursors). ## Response The response returns the whole subscription object that was created, including the server-generated id field. > Sample Response ```json { "owning_application": "demo-app", "event_types": [ "mrn.event.TENANT_NAME.streamingapi.client_approved" ], "consumer_group": "default", "read_from": "end", "id": "0691160a-b519-4595-b85c-a400fc73e963", "created_at": "2018-11-18T22:27:29.156Z" } ``` --- # Deleting a Subscription URL: https://docs.mambu.com/api/pages/streaming/deleting-a-subscription/ # Deleting a Subscription `DELETE /subscriptions/` ## Request A subscription can be removed by sending a DELETE request to the `/subscriptions/` resource. > Sample Request ```curl curl -X DELETE https://TENANT_NAME.mambu.com/api/v1/subscriptions/071569bc-89f2-4b52-8277-6ed9614ffbb3 ``` ### Response The possible responses for the delete are: - `204`: The subscription has been successfully deleted. - `404`: The subscription does not exist, along with this error message a response body is received. >Sample Response ```json { "title": "Not Found", "status": 404, "detail": "Subscription with id \"071569bc-89f2-4b52-8277-6ed9614ffbb3\" does not exist" } ``` --- # Event Streaming Configurations URL: https://docs.mambu.com/api/pages/streaming/event-streaming-configurations/ # Event Streaming Configurations This page describes in detail the behaviour of the parameters used for event streaming, and our recommendations for various streaming configurations. ## `batch_limit` Defines the maximum number of events that the server will send in each batch during streaming. * **Low value (e.g., 1-10)**: * If the `batch_limit` is low, the application will receive small batches of events frequently. This will cause the application to make frequent calls to commit offsets, especially if `commit_timeout` is set low (see below). * With `commit_timeout`: If `commit_timeout` is low (e.g., 5 seconds), the client needs to commit the small batches quickly to avoid reaching the commit timeout, potentially causing rebalancing if it fails to do so in time. * **Pros**: * Lower latency: Faster processing of individual events since batches are smaller and processed more frequently. * Reduced memory usage: Less memory is required to hold smaller batches of events. * **Cons**: * Decreased throughput: More frequent HTTP requests or commit operations can lead to increased overhead and lower overall throughput. * Higher overhead: Increased number of network calls can strain resources, especially under high load. * **Example** * With a low `commit_timeout` (5 seconds), the client must commit very frequently, increasing the risk of timeouts and frequent rebalancing. * The application fetches and processes up to 10 events in a single batch. * More frequent commits are made, increasing the number of HTTP calls. * Suitable for scenarios requiring low latency in event processing. * **Use case**: Real-time applications where immediate processing and responsiveness are crucial, such as fraud detection systems. * **High value (e.g., 100-1000)**: * A higher `batch_limit` leads to fewer, larger batches, reducing the number of network requests. However, if `commit_timeout` is low, the client must commit larger batches within the timeout window, which could increase latency in processing. * If `commit_timeout` is high (e.g., 30-60 seconds), larger batches can be processed and committed without the pressure of frequent timeouts, resulting in smoother streaming and higher throughput. * **Pros**: * Increased throughput: Processing more events in a single batch reduces the number of HTTP requests or commit operations, enhancing overall throughput. * Efficiency: Less overhead from network calls and cursor commits, leading to more efficient resource utilization. * **Cons**: * Latency: Higher latency in processing individual events, as the application waits to accumulate a large number of events before processing. * Memory usage: Increased memory consumption as more events are held in memory before processing. * **Example** * With a high `commit_timeout` (60 seconds), the application can process and commit larger batches with minimal rebalancing and smoother operation. * The application fetches and processes up to 400 events in a single batch. * Fewer commits are made, reducing the frequency of HTTP calls to commit offsets. * Suitable for scenarios where high throughput is prioritized over low latency. * **Use case**: Processing bulk data operations where individual event latency is less critical, such as nightly batch processing tasks. ## `max_uncommitted_events` Defines the maximum number of uncommitted events allowed before the server pauses and waits for a commit. * **Low value (e.g., 10)**: * The server frequently pauses the stream to wait for a commit after just a few events. This can cause delays in the stream, especially if the `batch_limit` is large or if the commit operation takes time. * With `max_uncommitted_events`: If `commit_timeout` is low, the client will struggle to commit events fast enough to avoid pausing. Frequent rebalancing can occur if the client doesn’t meet the commit deadline. * **Pros**: * Lower risk of data loss: Fewer events are buffered, minimizing the potential loss in case of failures. * Controlled memory usage: Limits the number of events held in memory, preventing excessive memory consumption. * **Cons**: * Increased commit frequency: More frequent commits may be necessary, leading to higher overhead and potentially lower throughput. * Reduced flexibility: Less capacity to handle bursts of high event rates without committing more frequently. * **Example** * With a low `commit_timeout` (5 seconds), the stream will frequently pause, and the application must be highly responsive in committing to avoid timeouts and session closures. * The application buffers up to 20 events across all partitions before committing. * Ensures that offsets are committed frequently, reducing the risk of significant data loss. * **Use case**: Critical real-time applications where data integrity is paramount, such as financial transaction processing systems. * **High value (e.g., 1000)**: * The client has more flexibility to process and commit events without frequent pauses, leading to better throughput. The risk is that if the application crashes, a larger number of uncommitted events may be lost or reprocessed. * A high `commit_timeout` allows the client more time to handle the larger number of uncommitted events. However, if `commit_timeout` is too low, the client may not be able to commit large batches in time, risking session termination and rebalancing. * **Pros**: * Increased flexibility: Allows more events to be buffered, accommodating spikes in event rates without immediate commits. * Reduced commit frequency: Fewer commits are required, lowering overhead and improving throughput. * **Cons**: * Higher risk of data loss: In the event of a crash or failure, more uncommitted events may be lost or need to be reprocessed. * Increased memory usage: More events are held in memory, potentially leading to higher memory consumption. * **Example** * With a high `commit_timeout` (60 seconds), the application can commit larger chunks at a slower pace without significant risk of stream pausing. * The application allows up to 1000 events to be buffered across all partitions before requiring a commit. This reduces the frequency of commit operations, enhancing throughput. * **Use case**: Applications that can tolerate some level of data loss in exchange for higher performance, such as logging systems where occasional duplicates are acceptable. ## `batch_flush_timeout` Defines the maximum time the server will wait before flushing a batch of events, even if it hasn't reached the `batch_limit`. * **Low value (e.g., 5 seconds)**: * The server flushes smaller batches more frequently. With a low `commit_timeout`, this can lead to more frequent commits as smaller batches will need to be committed quickly. * If `commit_timeout` is low, the client may struggle to keep up with frequent commits. However, if `commit_timeout` is high, the client has more time to process and commit the smaller batches, avoiding rebalancing or session termination. * **Pros**: * Lower risk of data loss: Fewer events are buffered, minimizing the potential loss in case of failures. * Controlled memory usage: Limits the number of events held in memory, preventing excessive memory consumption. * **Cons**: * Increased commit frequency: More frequent commits may be necessary, leading to higher overhead and potentially lower throughput. * Reduced flexibility: Less capacity to handle bursts of high event rates without committing more frequently. * **Example** * With a low `commit_timeout` (5 seconds), the client is at risk of frequent rebalancing because it needs to commit small, frequent batches quickly. * The application flushes events as soon as 5 seconds have passed, regardless of whether the `batch_limit` is reached. * Smaller batches are processed more frequently, reducing latency. * **Use case**: Real-time applications where timely processing is essential, such as live analytics dashboards or real-time monitoring systems. * **High value (e.g., 60 seconds)**: * The server waits longer before flushing, leading to larger batches but longer delays between receiving data. This can lead to fewer commits, but the size of the batches can make committing slower if `commit_timeout` is low. * If `commit_timeout` is low, large batches may overwhelm the client, leading to commit failures. With a higher `commit_timeout`, the client has adequate time to commit larger batches without risking session closure. * **Pros**: * Increased flexibility: Allows more events to be buffered, accommodating spikes in event rates without immediate commits. * Reduced commit frequency: Fewer commits are required, lowering overhead and improving throughput. * **Cons**: * Higher risk of data loss: In the event of a crash or failure, more uncommitted events may be lost or need to be reprocessed. * Increased memory usage: More events are held in memory, potentially leading to higher memory consumption. * **Example** * With a high `commit_timeout` (60 seconds), the client can handle larger, less frequent batches more efficiently without worrying about session timeouts. * The application waits up to 60 seconds to accumulate events before flushing. * Larger batches are likely to be processed, enhancing throughput. * **Use case**: Applications where high throughput is critical and some latency is acceptable, such as bulk data ingestion systems. ## `commit_timeout` Defines the maximum amount of time the server will wait for the client to commit after sending a batch. If the client doesn’t commit in time, the stream is terminated, and the partitions may be reassigned. * **Low value (e.g., 5-10 seconds)**: * The client must be highly responsive in committing events. If the client takes too long (due to network delays or heavy processing), it may frequently trigger session terminations and rebalancing. * When `batch_limit` or `batch_flush_timeout` are high, the client might not have enough time to commit large batches within the short timeout, risking session closures. * **Pros**: * Lower latency: Faster detection of consumers that are slow or unable to commit within the allowed timeframe, leading to quicker rebalancing. * Improved responsiveness: The system quickly reassigns uncommitted events if a consumer fails to commit, improving overall responsiveness in failure scenarios. * **Cons**: * Higher risk of rebalancing: More frequent rebalancing, as consumers may not always be able to commit within the shorter time window, leading to potential interruptions. * Increased overhead: Constant rebalancing can increase the number of partition reassignments, adding to the system’s overhead and potentially impacting throughput. * **Example** * In this case, the client must commit events very quickly, and if the batches are too large (due to a high `batch_limit` or `max_uncommitted_events`), the client may fail to commit in time, leading to frequent rebalancing. * The application expects commit acknowledgments within 5 seconds after processing a batch of events. * Faster detection of unresponsive consumers, leading to quicker rebalancing. * **Use case**: Ideal for low-latency, real-time applications where event processing is fast, such as monitoring systems or real-time analytics platforms. * **High value (e.g., 30-60 seconds)**: * The client has more time to process and commit events, reducing the risk of session closures. This is generally better for throughput and stability, especially in applications that need to process large batches or handle fluctuating traffic. * A high `commit_timeout` allows for larger `batch_limit` and `max_uncommitted_events` values, since the client has more time to process and commit events. * **Pros**: * Increased flexibility: Allows more time for slow consumers to process and commit events, reducing the risk of stream rebalancing. * Fewer rebalances: Less frequent rebalancing since the timeout gives more time for commit operations to complete. * **Cons**: * Increased latency: The application might wait longer for commit operations to complete, potentially delaying the detection of slow or failed consumers. * Risk of stale connections: Prolonged commit times may hold resources unnecessarily if a consumer has stalled or failed but hasn’t reached the timeout. * **Example** * The client has more time to handle large batches or spikes in traffic, reducing the risk of stream termination due to uncommitted events. * The application allows up to 60 seconds for a commit acknowledgment after processing a batch of events. * Slow consumers are given enough time to process and commit, reducing the likelihood of rebalancing. * **Use case**: Suitable for applications where event processing may take longer, such as large data processing jobs or tasks that involve external dependencies like database writes. --- # Event Streaming Recommendations URL: https://docs.mambu.com/api/pages/streaming/event-streaming-recommendations/ # Event Streaming Recommendations for Clients/Tenants This page contains our recommendations for various client configurations. ## Category 1: A load not greater than 150k events/notifications per 40 minutes 1. Real-time low-latency processing * `batch_limit`: 10 * `max_uncommitted_events`: 100 * `batch_flush_timeout`: 2 seconds * `commit_timeout`: 5 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) 2. High-throughput, less frequent processing * `batch_limit`: 50 * `max_uncommitted_events`: 500 * `batch_flush_timeout`: 10 seconds * `commit_timeout`: 60 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) 3. Balanced approach * `batch_limit`: 20 * `max_uncommitted_events`: 200 * `batch_flush_timeout`: 5 seconds * `commit_timeout`: 20 seconds * Recommended consumers: 3 (1 per partition) ## Category 2: A load between 150k and 350k events/notifications per 40 minutes 1. Real-time low-latency processing * `batch_limit`: 15 * `max_uncommitted_events`: 150 * `batch_flush_timeout`: 3 seconds * `commit_timeout`: 10 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) 2. High-throughput, less frequent processing * `batch_limit`: 100 * `max_uncommitted_events`: 1000 * `batch_flush_timeout`: 10 seconds * `commit_timeout`: 90 seconds * `stream_timeout`: 70 minutes Recommended consumers: 3 (1 per partition) 3. Balanced approach * `batch_limit`: 50 * `max_uncommitted_events`: 500 * `batch_flush_timeout`: 5 seconds * `commit_timeout`: 30 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) ## Category 3: A load between 350k and 550k events/notifications per 40 minutes 1. Real-time low-latency processing * `batch_limit`: 20 * `max_uncommitted_events`: 200 * `batch_flush_timeout`: 2 seconds * `commit_timeout`: 5 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) 2. High-throughput, less frequent processing * `batch_limit`: 100 * `max_uncommitted_events`: 1500 * `batch_flush_timeout`: 10 seconds * `commit_timeout`: 60 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) 3. Balanced approach * `batch_limit`: 50 * `max_uncommitted_events`: 1000 * `batch_flush_timeout`: 5 seconds * `commit_timeout`: 30 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 3 (1 per partition) ## Category 4: A load between 750k and 1M events/notifications per 40 minute 1. Real-time low-latency processing * `batch_limit`: 25 * `max_uncommitted_events`: 300 * `batch_flush_timeout`: 3 seconds * `commit_timeout`: 10 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 6 (1 per partition) 2. High-throughput, less frequent processing * `batch_limit`: 200 * `max_uncommitted_events`: 3000 * `batch_flush_timeout`: 15 seconds * `commit_timeout`: 120 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 6 (1 per partition) 3. Balanced approach * `batch_limit`: 100 * `max_uncommitted_events`: 2000 * `batch_flush_timeout`: 10 seconds * `commit_timeout`: 60 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 6 (1 per partition) ## Category 5: A load between 1M and 2M events/notifications per 40 minutes 1. Real-time low-latency processing * `batch_limit`: 50 * `max_uncommitted_events`: 500 * `batch_flush_timeout`: 5 seconds * `commit_timeout`: 10 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 8 (1 per partition) 2. High-throughput, less frequent processing * `batch_limit`: 300 * `max_uncommitted_events`: 5000 * `batch_flush_timeout`: 20 seconds * `commit_timeout`: 180 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 8 (1 per partition) 3. Balanced approach * `batch_limit`: 150 * `max_uncommitted_events`: 3000 * `batch_flush_timeout`: 10 seconds * `commit_timeout`: 60 seconds * `stream_timeout`: 70 minutes * Recommended consumers: 8 (1 per partition) --- # HTTP Verbs URL: https://docs.mambu.com/api/pages/streaming/http-verbs/ # HTTP Verbs Standard HTTP verbs are used to indicate the API request method. | Verb | Function | |:---------|:----------------------------------------------------| | `GET` | To get events or statistics from a subscription | | `POST` | To create a subscription or commit a cursor | | `DELETE` | To delete a subscription | --- # Java Sample Client URL: https://docs.mambu.com/api/pages/streaming/java-sample-client/ # Java Sample Client To help get you started quickly, a sample project (in Java) implementing a Streaming API client is available at [https://github.com/mambu-gmbh/Streaming-API-Java-Sample-Client](https://github.com/mambu-gmbh/Streaming-API-Java-Sample-Client). --- # OpenAPI Specification URL: https://docs.mambu.com/api/pages/streaming/openapi-specification/ # Open API Specification > Use this link to access the [latest Open API Specification](pathname:///swagger_files/streaming.json). This documentation is automatically generated from an OpenAPI Specification (OAS). This OAS file can also be used to quickly scaffold client SDKs, in various languages, for interacting with our APIs using a number of tools, including the online [Swagger Editor](https://editor.swagger.io/). You can access the latest version of this specification using the link provided. --- # Mambu Streaming API URL: https://docs.mambu.com/api/pages/streaming/streaming-index/ # Welcome > This documentation was last updated on Mon Feb 24 13:30:47 CET 2025 and covers Mambu Version [v9.171.1](https://community.mambu.com/c/release-notes/) Welcome to the Mambu Streaming API Reference documentation! The Streaming API allows you to subscribe to constant, real-time updates of activities within Mambu. If your connection is interrupted, your cursor position is saved so that when you reconnect, you will pick up exactly where you left off. The Streaming API is independent from the Mambu API and webhook infrastructure. :::note Enabling the Mambu Streaming API Please note that this feature is an add-on feature and is not enabled for customers on our standard packages. For certain contracts concluded before 2021, this feature is limited to the Enterprise product tier. If you would like to request access to this feature, please get in touch with your Mambu Customer Success Manager to discuss your requirements. ::: For information about setting up event streaming notification templates in the Mambu UI, see [Streaming API](/docs/streaming-api) in our User Guide. :::note This API is distinct from the [Streaming Publisher stats](/api/api-v2/streaming_publisher_stats/streaming-publisher-stats) endpoint in the core v2 API, which exposes operational metrics about the publisher (for example, the number of undelivered events) rather than the event payloads themselves. ::: :::info If you are looking for documentation for another API, you can use the **Mambu APIs** menu to view API Reference documentation for [API v1](/api/pages/api-v1/welcome), [API v2](/api/pages/api-v2/welcome), or Payments API. For more information about all the APIs we offer, see [Mambu APIs](/docs/mambu-apis) in our User Guide. ::: --- # Subscription Cursors URL: https://docs.mambu.com/api/pages/streaming/subscription-cursors/ # Subscription Cursors The cursors in the Subscription API have the following structure: The fields are: - `partition`: The partition this batch belongs to. A batch can only have one partition. - `offset`: The offset of this batch. The offset is server-defined and opaque to the client - clients should not try to infer or assume a structure. - `event_type`: Specifies the event-type of the cursor (as in one stream there can be events of different event-types) - `cursor_token`: The cursor token generated by Mambu. > Cursor Structure ```json { "partition": "1", "offset": "001-0001-000000000000000000", "event_type": "mrn.event.demo_tenant.streamingapi.client_approved", "cursor_token": "e8f6bc5d-65b7-4466-9d95-507da0e79d3c" } ``` --- # API Reference: accounting/interestaccrual URL: https://docs.mambu.com/api/v2/accounting/interestaccrual/ **Accounting Interest Accrual**: Allows search of interest accrual breakdown entries by various criteria. POST /accounting/interestaccrual:search Summary: Allows search of interest accrual breakdown entries by various criteria. Description: Returns a list of interest accrual breakdown entries matching the specified search criteria, providing transparency into daily interest calculations for accounting purposes. --- # API Reference: accounting/reports URL: https://docs.mambu.com/api/v2/accounting/reports/ **Accounting Reports**: Create and get accounting reports POST /accounting/reports Summary: Create accounting report Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /accounting/reports/{reportKey} Summary: Get accounting reports Parameters: reportKey (path, required): The report's encoded key. --- # API Reference: apikey/rotation URL: https://docs.mambu.com/api/v2/apikey/rotation/ **API Consumers**: Rotation for API keys. POST /apikey/rotation Summary: Rotate API key Parameters: secretkey (header, required): Secret key used to authenticate to this endpoint in order to perform a rotate ke --- # API Reference: application/status URL: https://docs.mambu.com/api/v2/application/status/ **Application**: Allows you to retrieve application information. Application may have associated information such as data access state. GET /application/status Summary: Allows you to retrieve the state of application data access --- # API Reference: backgroundprocess URL: https://docs.mambu.com/api/v2/backgroundprocess/ **Background Process**: Allows you to check the status of manual and automatic end of day (EOD) processes and, under certain conditions, to cancel them. GET /backgroundprocess/latest Summary: Get the latest manual or automatic end of day (EOD) process by specifying the type PUT /backgroundprocess/{encodedKey} Summary: Cancel manual or automatic end of day (EOD) processes using the encoded key Parameters: encodedKey (path, required): The encoded key of the background process which should be changed. --- # API Reference: branches URL: https://docs.mambu.com/api/v2/branches/ **Branches**: Allows you to get and create branches. GET /branches Summary: Get branches POST /branches Summary: Create branch Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /branches/{branchId} Summary: Get branch Parameters: branchId (path, required): The ID or or encoded key of a branch. --- # API Reference: bulks URL: https://docs.mambu.com/api/v2/bulks/ **Bulks**: Allows you to query the results of bulks operations/ background process. The scope of this API is to get the status of the entire bulk and also return the list of successful transactions and the list of the transactions resulting in error. Since bulk operations work as independent transactions, it can happen that some of the operations were successful while others failed. This API can be used for example to get the status of bulk deposit transactions (see /deposits/deposit-transactions:bulk) GET /bulks/{bulkProcessKey} Summary: Allow retrieval the status of a bulk process via key Parameters: bulkProcessKey (path, required): The identifier of the bulk process --- # API Reference: cards URL: https://docs.mambu.com/api/v2/cards/ **Cards**: Allows you to get, create, update, and delete card references and their associated items. GET /cards/savings-products-settings Summary: Get all active card savings product settings POST /cards/savings-products-settings Summary: Create card savings product settings Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /cards/{cardReferenceToken}/authorizationholds Summary: Create an authorization hold corresponding to a given card. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cardReferenceToken (path, required): The token used to externally identify the card. GET /cards/{cardReferenceToken}/authorizationholds/{authorizationHoldExternalReferenceId} Summary: Get card authorization hold Parameters: cardReferenceToken (path, required): The token used to externally identify the card.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. DELETE /cards/{cardReferenceToken}/authorizationholds/{authorizationHoldExternalReferenceId} Summary: Reverse a card authorization hold. Parameters: cardReferenceToken (path, required): The token used to externally identify the card.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. PATCH /cards/{cardReferenceToken}/authorizationholds/{authorizationHoldExternalReferenceId} Summary: Partially update an authorization hold Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cardReferenceToken (path, required): The token used to externally identify the card.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. POST /cards/{cardReferenceToken}/authorizationholds/{authorizationHoldExternalReferenceId}:decrease Summary: Decreases the amount of an authorization hold. If the amount is greater or equal to the authorization hold amount, then the authorization hold is reversed. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cardReferenceToken (path, required): The token used to externally identify the card.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. POST /cards/{cardReferenceToken}/authorizationholds/{authorizationHoldExternalReferenceId}:increase Summary: Increase authorization hold amount Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cardReferenceToken (path, required): The token used to externally identify the card.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. POST /cards/{cardReferenceToken}/authorizationholds:bulk Summary: Create bulk authorization holds corresponding to a given card Parameters: cardReferenceToken (path, required): The token used to externally identify the card. GET /cards/{cardReferenceToken}/balanceInquiry Summary: Get account balances using card tokens Parameters: cardReferenceToken (path, required): The token used to externally identify the card. POST /cards/{cardReferenceToken}/financialtransactions Summary: Create a financial transaction corresponding to a given card Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cardReferenceToken (path, required): The token used to externally identify the card. GET /cards/{cardReferenceToken}/financialtransactions/{cardTransactionExternalReferenceId} Summary: Get card transaction Parameters: cardReferenceToken (path, required): The token used to externally identify the card.; cardTransactionExternalReferenceId (path, required): The external reference of a card transaction used to identify the card transacti POST /cards/{cardReferenceToken}/financialtransactions/{cardTransactionExternalReferenceId}:decrease Summary: Reverse card transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cardReferenceToken (path, required): The token used to externally identify the card.; cardTransactionExternalReferenceId (path, required): The external reference of a card transaction used to identify the card transacti --- # API Reference: centres URL: https://docs.mambu.com/api/v2/centres/ **Centres**: Allows retrieving centres which are being used by an organisation. A Centre is a common meeting area that credit officers and the individual and group clients go to. GET /centres Summary: Get centres GET /centres/{centreId} Summary: Get centre Parameters: centreId (path, required): The ID or encoded key of the centre to be returned. --- # API Reference: clients URL: https://docs.mambu.com/api/v2/clients/ **Clients**: Allows you to get, create, update, or delete clients. Clients may have associated information such as their address, identification documents, or custom field values. GET /clients Summary: Get clients POST /clients Summary: Create client Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /clients/{clientId} Summary: Get client Parameters: clientId (path, required): The ID or encoded key of the client to be returned. PUT /clients/{clientId} Summary: Update client Parameters: clientId (path, required): The ID or encoded key of the client to be updated. DELETE /clients/{clientId} Summary: Delete client Parameters: clientId (path, required): The ID or encoded key of the client to be deleted. PATCH /clients/{clientId} Summary: Partially update client Parameters: clientId (path, required): The ID or encoded key of the client to be updated. GET /clients/{clientId}/creditarrangements Summary: Credit arrangements list returned. Parameters: clientId (path, required): The ID or encoded key of the client to be returned. GET /clients/{clientId}/role Summary: Get client role for client Parameters: clientId (path, required): The ID or encoded key of the client to be returned. POST /clients:search Summary: Search clients --- # API Reference: clients/documents URL: https://docs.mambu.com/api/v2/clients/documents/ **Client Documents**: Allows you to get or create client documents. GET /clients/documents/{documentId} Summary: Download client document Parameters: documentId (path, required): The ID or encoded key of the client document to be returned. GET /clients/documents/{documentId}/metadata Summary: Get client document Parameters: documentId (path, required): The ID or encoded key of the client document to be returned. POST /clients/{clientId}/documents Summary: Create client document Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; clientId (path, required): The ID or encoded key of the client to be returned. GET /clients/{clientId}/documentsMetadata Summary: Get all client documents Parameters: clientId (path, required): The ID or encoded key of the client to be returned. --- # API Reference: comments URL: https://docs.mambu.com/api/v2/comments/ **Comments**: Get or create comments. Comments have information such as the owner key, user key, creation date, last modified date, and text. GET /comments Summary: Get comments for an entity POST /comments Summary: Create a new comment for an entity. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v --- # API Reference: communications/messages URL: https://docs.mambu.com/api/v2/communications/messages/ **Communications**: Allows you to get messages, send messages, and resend the ones that failed. POST /communications/messages Summary: Send communication message Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /communications/messages/{encodedKey} Summary: Get communication message Parameters: encodedKey (path, required): The encoded key of the message to be returned. POST /communications/messages:resend Summary: Resend failed communication message(s) Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /communications/messages:resendAsyncByDate Summary: Resend failed communication message(s) asynchronously by date Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /communications/messages:resendAsyncByKeys Summary: Resend failed communication message(s) asynchronously using keys Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /communications/messages:search Summary: Searching communication messages POST /communications/messages:searchSorted Summary: Searching sorted communication messages --- # API Reference: configuration/accountingrules.yaml URL: https://docs.mambu.com/api/v2/configuration/accountingrules.yaml/ **Accounting Rules Configuration**: Allows you to retrieve or overwrite the accounting rules configuration details. GET /configuration/accountingrules.yaml Summary: Retrieve accounting rulesconfiguration PUT /configuration/accountingrules.yaml Summary: Update the current accounting rules configuration Parameters: Accept (header, required) --- # API Reference: configuration/authorizationholds.yaml URL: https://docs.mambu.com/api/v2/configuration/authorizationholds.yaml/ **Authorization Holds Configuration**: Allows you to get or update authorization holds configuration GET /configuration/authorizationholds.yaml Summary: Get authorization holds configuration PUT /configuration/authorizationholds.yaml Summary: Update authorization holds configuration Parameters: Accept (header, required) --- # API Reference: configuration/branches.yaml URL: https://docs.mambu.com/api/v2/configuration/branches.yaml/ **Branches Configuration**: Allows you to get and update the branches configuration. GET /configuration/branches.yaml Summary: Get branches configuration PUT /configuration/branches.yaml Summary: Update branch configuration Parameters: Accept (header, required) --- # API Reference: configuration/centres.yaml URL: https://docs.mambu.com/api/v2/configuration/centres.yaml/ **Centres Configuration**: Allows you to get and update the centres configuration. GET /configuration/centres.yaml Summary: Get centres configuration PUT /configuration/centres.yaml Summary: Update centres configuration Parameters: Accept (header, required) --- # API Reference: configuration/clientroles.yaml URL: https://docs.mambu.com/api/v2/configuration/clientroles.yaml/ **Client Roles Configuration**: Allows you to get and update the client roles configuration. GET /configuration/clientroles.yaml Summary: Get client roles configuration PUT /configuration/clientroles.yaml Summary: Update client roles configuration Parameters: Accept (header, required) --- # API Reference: configuration/currencies.yaml URL: https://docs.mambu.com/api/v2/configuration/currencies.yaml/ **Currencies Configuration**: Allows you to get and update the currencies configuration. GET /configuration/currencies.yaml Summary: Get currencies configuration PUT /configuration/currencies.yaml Summary: Update currencies configuration Parameters: Accept (header, required) --- # API Reference: configuration/customfields URL: https://docs.mambu.com/api/v2/configuration/customfields/ **Custom Fields Configuration**: Allows you to get and update the custom field definitions configuration. GET /configuration/customfields.yaml Summary: Get custom field definitions configuration PUT /configuration/customfields.yaml Summary: Update custom field definitions configuration Parameters: Accept (header, required); X-Mambu-Async (header); X-Mambu-Callback (header) GET /configuration/customfields/template.yaml Summary: Get custom field definitions configuration --- # API Reference: configuration/depositproducts.yaml URL: https://docs.mambu.com/api/v2/configuration/depositproducts.yaml/ **Deposit Products Configuration**: Get configuration for all deposit products GET /configuration/depositproducts.yaml Summary: Get configuration for all deposit products PUT /configuration/depositproducts.yaml Summary: Update all deposit products configuration Parameters: Accept (header, required); X-Mambu-Async (header); X-Mambu-Callback (header) --- # API Reference: configuration/endofdayprocessing.yaml URL: https://docs.mambu.com/api/v2/configuration/endofdayprocessing.yaml/ **End of Day Processing Configuration**: Allows you to get and update the end of day processing configuration. GET /configuration/endofdayprocessing.yaml Summary: Get end of day processing configuration PUT /configuration/endofdayprocessing.yaml Summary: Update end of day processing configuration Parameters: Accept (header, required) --- # API Reference: configuration/grouprolenames.yaml URL: https://docs.mambu.com/api/v2/configuration/grouprolenames.yaml/ **Group Role Names Configuration**: Allows you to get and update the group role names configuration. GET /configuration/grouprolenames.yaml Summary: Get group role names configuration PUT /configuration/grouprolenames.yaml Summary: Update group role names configuration Parameters: Accept (header, required) --- # API Reference: configuration/holidays.yaml URL: https://docs.mambu.com/api/v2/configuration/holidays.yaml/ **Holidays Configuration**: Allows you to get or update the holidays configuration. GET /configuration/holidays.yaml Summary: Get holidays configuration PUT /configuration/holidays.yaml Summary: Update holidays configuration Parameters: Accept (header, required) --- # API Reference: configuration/iddocumenttemplates.yaml URL: https://docs.mambu.com/api/v2/configuration/iddocumenttemplates.yaml/ **Identification Document Templates Configuration**: Allows you to get or update the ID templates configuration. GET /configuration/iddocumenttemplates.yaml Summary: Get ID templates configuration PUT /configuration/iddocumenttemplates.yaml Summary: Update ID templates configuration Parameters: Accept (header, required) --- # API Reference: configuration/indexrates.yaml URL: https://docs.mambu.com/api/v2/configuration/indexrates.yaml/ **Index Rates Configuration**: Allows you to get and update the index rates configuration. GET /configuration/indexrates.yaml Summary: Get index rates configuration PUT /configuration/indexrates.yaml Summary: Update index rates configuration Parameters: Accept (header, required) --- # API Reference: configuration/internalcontrols.yaml URL: https://docs.mambu.com/api/v2/configuration/internalcontrols.yaml/ **Internal Controls Configuration**: Allows you to get and update the internal controls configuration. GET /configuration/internalcontrols.yaml Summary: Get internal controls configuration PUT /configuration/internalcontrols.yaml Summary: Update internal controls configuration Parameters: Accept (header, required) --- # API Reference: configuration/labels.yaml URL: https://docs.mambu.com/api/v2/configuration/labels.yaml/ **Object Labels Configuration**: Allows you to get and update the object labels configuration. GET /configuration/labels.yaml Summary: Get object labels configuration PUT /configuration/labels.yaml Summary: Update object labels configuration Parameters: Accept (header, required) --- # API Reference: configuration/loanproducts.yaml URL: https://docs.mambu.com/api/v2/configuration/loanproducts.yaml/ **Loan Products Configuration**: Get loan products configuration GET /configuration/loanproducts.yaml Summary: Allows you to get or update the loan products configuration. PUT /configuration/loanproducts.yaml Summary: Update loan products configuration Parameters: Accept (header, required); X-Mambu-Async (header); X-Mambu-Callback (header) --- # API Reference: configuration/loanrisklevels.yaml URL: https://docs.mambu.com/api/v2/configuration/loanrisklevels.yaml/ **Loan Risk Levels Configuration**: Allows you to get or update the loan risk levels configuration. GET /configuration/loanrisklevels.yaml Summary: Get loan risk levels configuration PUT /configuration/loanrisklevels.yaml Summary: Update loan risk levels configuration Parameters: Accept (header, required) --- # API Reference: configuration/organization URL: https://docs.mambu.com/api/v2/configuration/organization/ **Organization Configuration**: Allows you to get and update the organization details configuration. GET /configuration/organization.yaml Summary: Get organization details configuration PUT /configuration/organization.yaml Summary: Update organization details configuration Parameters: Accept (header, required) GET /configuration/organization/template.yaml Summary: Get organization details configuration template --- # API Reference: configuration/transactionchannels.yaml URL: https://docs.mambu.com/api/v2/configuration/transactionchannels.yaml/ **Transaction Channels Configuration**: Allows you to get and update the transaction channels configuration. GET /configuration/transactionchannels.yaml Summary: Get transaction channels configuration PUT /configuration/transactionchannels.yaml Summary: Update transaction channels configuration Parameters: Accept (header, required) --- # API Reference: configuration/userroles URL: https://docs.mambu.com/api/v2/configuration/userroles/ **User Roles Configuration**: Allows you to get and update the user roles configuration. GET /configuration/userroles.yaml Summary: Get user roles configuration PUT /configuration/userroles.yaml Summary: Update user roles configuration Parameters: Accept (header, required); X-Mambu-Async (header); X-Mambu-Callback (header) GET /configuration/userroles/template.yaml Summary: Get user roles configuration template --- # API Reference: consumers URL: https://docs.mambu.com/api/v2/consumers/ **API Consumers**: Allows you to manage API consumers and their keys. GET /consumers Summary: Get all API consumers POST /consumers Summary: Create API consumer Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /consumers/{apiConsumerId} Summary: Get API consumer Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer. PUT /consumers/{apiConsumerId} Summary: Update API consumer Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer to be updated.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v DELETE /consumers/{apiConsumerId} Summary: Delete API consumer Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer to be deleted. PATCH /consumers/{apiConsumerId} Summary: Partially update API consumer Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer to be updated.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /consumers/{apiConsumerId}/apikeys Summary: Create API key Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v DELETE /consumers/{apiConsumerId}/apikeys/{apiKeyId} Summary: Delete API key Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer.; apiKeyId (path, required): The ID of the API key. GET /consumers/{apiConsumerId}/keys Summary: Get API keys Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer. POST /consumers/{apiConsumerId}/secretkeys Summary: Create secret key Parameters: apiConsumerId (path, required): The ID or encoded key of the API consumer.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v --- # API Reference: creditarrangements URL: https://docs.mambu.com/api/v2/creditarrangements/ **Credit Arrangements**: Allows you to get, create, update, and delete credit arrangements. **creditArrangementsSearch**: Search credit arrangements GET /creditarrangements Summary: Get credit arrangements POST /creditarrangements Summary: Create credit arrangement Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /creditarrangements/{creditArrangementId} Summary: Get credit arrangement Parameters: creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be returned. PUT /creditarrangements/{creditArrangementId} Summary: Update credit arrangement Parameters: creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be updated. DELETE /creditarrangements/{creditArrangementId} Summary: Delete credit arrangement Parameters: creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be deleted. PATCH /creditarrangements/{creditArrangementId} Summary: Partially update credit arrangement Parameters: creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be updated. GET /creditarrangements/{creditArrangementId}/accounts Summary: Get all loan and deposit accounts linked to credit arrangement Parameters: creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be returned. GET /creditarrangements/{creditArrangementId}/schedule Summary: Get credit arrangement schedule Parameters: creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be returned. POST /creditarrangements/{creditArrangementId}:addAccount Summary: Add account to credit arrangement Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; creditArrangementId (path, required): The ID or encoded key of the credit arrangement for an account to be added. POST /creditarrangements/{creditArrangementId}:changeState Summary: Change credit arrangement state Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; creditArrangementId (path, required): The ID or encoded key of the credit arrangement to be updated. POST /creditarrangements/{creditArrangementId}:removeAccount Summary: Remove account from credit arrangement Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; creditArrangementId (path, required): The ID or encoded key of the credit arrangement for an account to be removed. POST /creditarrangements:search Summary: Search credit arrangements --- # API Reference: crons/earlyeod URL: https://docs.mambu.com/api/v2/crons/earlyeod/ **Crons**: Allows you to trigger the hourly and end of day processing earlier, on the current day POST /crons/earlyeod:run Summary: Trigger hourly and end of day Processing earlier, on the current day --- # API Reference: crons/eod URL: https://docs.mambu.com/api/v2/crons/eod/ **Crons**: Allows you to trigger the hourly and end of day processing on the previous day POST /crons/eod:run Summary: Trigger hourly and end of day Processing on the previous day --- # API Reference: currencies URL: https://docs.mambu.com/api/v2/currencies/ **Currencies**: Allows you to get, create, update, or delete currencies. GET /currencies Summary: Get all currencies POST /currencies Summary: Create currency Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /currencies/{currencyCode} Summary: Get currency by code Parameters: currencyCode (path, required): The currency code. PUT /currencies/{currencyCode} Summary: Update currency by code Parameters: currencyCode (path, required): The currency code. DELETE /currencies/{currencyCode} Summary: Delete currency by code Parameters: currencyCode (path, required): The currency code. --- # API Reference: currencies/accountingRates URL: https://docs.mambu.com/api/v2/currencies/accountingrates/ **Accounting Rates**: Create or get accounting rates GET /currencies/{currencyCode}/accountingRates Summary: Get accounting rates Parameters: currencyCode (path, required): The currency code. POST /currencies/{currencyCode}/accountingRates Summary: Create accounting rates Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; currencyCode (path, required): The currency code. --- # API Reference: customfields URL: https://docs.mambu.com/api/v2/customfields/ **Custom Fields**: Allows you to get custom field definitions. GET /customfields/{customfieldId} Summary: Get custom field definition Parameters: customfieldId (path, required): The ID or encoded key of the custom field definition to be returned. --- # API Reference: customfieldsets URL: https://docs.mambu.com/api/v2/customfieldsets/ **Custom Field Sets**: Allows you to get custom field sets. GET /customfieldsets Summary: Get custom field sets GET /customfieldsets/{customFieldSetId}/customfields Summary: Get custom field definitions by custom field set Parameters: customFieldSetId (path, required): The encoded key or ID of the custom field set used to get all the custom field d --- # API Reference: data/import URL: https://docs.mambu.com/api/v2/data/import/ **DataImport**: Allows you to import data POST /data/import Summary: Allows you to import data POST /data/import/events/{eventKey}:action Summary: Allows you to approve or reject a data import event Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; eventKey (path, required): Data import event key GET /data/import/{importKey} Summary: Allows you to retrieve a data import response Parameters: importKey (path, required): The identifier of the import background task --- # API Reference: database/backup URL: https://docs.mambu.com/api/v2/database/backup/ **Database Backup**: Allows you to trigger database backups and download them once they are ready. Your user or API consumer must have the `DOWNLOAD_BACKUPS` permission to access these endpoints. POST /database/backup Summary: Trigger database backup Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /database/backup/{databaseBackupVersion} Summary: Download database backup Parameters: databaseBackupVersion (path, required): The version of the database backup. --- # API Reference: depositproducts URL: https://docs.mambu.com/api/v2/depositproducts/ **Deposit Products**: WARNING: Please use these APIs only to migrate products across your environments. We are working to update these endpoints, yet until then do not attempt to create products from scratch via the APIs as you may damage your Mambu instance. GET /depositproducts Summary: Get deposit products POST /depositproducts Summary: Create deposit product Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /depositproducts/{depositProductId} Summary: Get deposit product Parameters: depositProductId (path, required): The ID or encoded key of the deposit product to be returned. PUT /depositproducts/{depositProductId} Summary: Update deposit product Parameters: depositProductId (path, required): The ID or encoded key of the deposit product to be updated. DELETE /depositproducts/{depositProductId} Summary: Delete deposit product Parameters: depositProductId (path, required): The ID or encoded key of the deposit product to be deleted. PATCH /depositproducts/{depositProductId} Summary: Partially update deposit product Parameters: depositProductId (path, required): The ID or encoded key of the deposit product to be updated. POST /depositproducts/{depositProductId}:batchUpdate Summary: Perform a batch update action on the specified deposit product Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositProductId (path, required): The ID or encoded key of the deposit product to perform batch update action on. --- # API Reference: deposits URL: https://docs.mambu.com/api/v2/deposits/ **Deposit Account Balances**: Get historical balances for the deposit account **Deposit Account Documents**: Get deposit account document. **Deposit Accounts**: Get, create, update, or delete deposit accounts. **Deposit Account Interest Availability**: Allows you to create, get, update or delete Interest Availabilities. **FundedLoanAccounts**: Allows retrieval of the loan account schedule for a loan account with the given id or encodedKey and funded by the deposit account with the given id or encodedKey. **MultipleDepositsTransactionAsync**: Make multiple automatic asynchronous deposit transactions for deposit accounts. This feature is disabled by default, please get in touch with your Mambu Customer Success Manager to enable this feature. GET /deposits Summary: Get deposit accounts POST /deposits Summary: Create deposit account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v PUT /deposits/bulkUpdates Summary: Bulk update deposit accounts Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /deposits/interest-availabilities:bulk Summary: Create Interest Availabilities for a group of accounts Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /deposits/{depositAccountId} Summary: Get deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. PUT /deposits/{depositAccountId} Summary: Update deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. DELETE /deposits/{depositAccountId} Summary: Delete inactive deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. PATCH /deposits/{depositAccountId} Summary: Partially update deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. GET /deposits/{depositAccountId}/authorizationholds Summary: Get authorization holds related to a deposit account, ordered from newest to oldest by creation date Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}/authorizationholds Summary: Create an authorization hold corresponding to a given account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. GET /deposits/{depositAccountId}/authorizationholds/{authorizationHoldExternalReferenceId} Summary: Get account authorization hold Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. DELETE /deposits/{depositAccountId}/authorizationholds/{authorizationHoldExternalReferenceId} Summary: Reverse account authorization hold Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; authorizationHoldExternalReferenceId (path, required): The ID used to reference the authorization hold. GET /deposits/{depositAccountId}/balances Summary: Get historical balances for the deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. GET /deposits/{depositAccountId}/blocks Summary: Get all block funds for a deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}/blocks Summary: Create a block fund for the account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. DELETE /deposits/{depositAccountId}/blocks/{externalReferenceId} Summary: Unblock a previously blocked fund for a deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; externalReferenceId (path, required) PATCH /deposits/{depositAccountId}/blocks/{externalReferenceId} Summary: Updates the amount of an existing blocked fund on a deposit account. If the new amount equals the seized amount the block fund will transition to a seized state. Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; externalReferenceId (path, required): The external reference ID of the transaction. GET /deposits/{depositAccountId}/cards Summary: Get cards associated with an account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}/cards Summary: Represents the information needed to create and associate a new card to an account. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. DELETE /deposits/{depositAccountId}/cards/{cardReferenceToken} Summary: Represents the information needed to delete a card associated to an account using its reference token. Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; cardReferenceToken (path, required): The reference token of the card to be returned. GET /deposits/{depositAccountId}/funding Summary: Get all loan accounts funded by the deposit account with the given ID or encoded key Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. GET /deposits/{depositAccountId}/funding/{loanAccountId}/schedule Summary: Allows retrieval of the loan account schedule for a loan account with the given id or encodedKey and funded by the deposit account with the given id or encodedKey. Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; loanAccountId (path, required): The ID or encoded key of the loan account. GET /deposits/{depositAccountId}/interest-availabilities Summary: Get Interest Availabilities Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}/interest-availabilities Summary: Create Interest Availability Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. GET /deposits/{depositAccountId}/interest-availabilities/{interestAvailabilityKey} Summary: Get Interest Availability Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; interestAvailabilityKey (path, required): The encoded key of the Interest Availability. PUT /deposits/{depositAccountId}/interest-availabilities/{interestAvailabilityKey} Summary: Update Interest Availability Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; interestAvailabilityKey (path, required): The encoded key of the Interest Availability. DELETE /deposits/{depositAccountId}/interest-availabilities/{interestAvailabilityKey} Summary: Delete Interest Availability Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; interestAvailabilityKey (path, required): The encoded key of the Interest Availability. GET /deposits/{depositAccountId}/templates/{templateId} Summary: Get deposit account document Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; templateId (path, required): The ID of the deposit product template. GET /deposits/{depositAccountId}/templates/{templateId}/pdf Summary: Download deposit account document PDF Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account.; templateId (path, required): The ID of the deposit product template. GET /deposits/{depositAccountId}/withholdingtaxes Summary: Get deposit account withholding tax history Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}:applyInterest Summary: Represents information to apply accrued interest. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit to apply interest to. POST /deposits/{depositAccountId}:changeInterestRate Summary: Change deposit account interest rate Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}:changeState Summary: Represents the information to post an action, such as approving a deposit account. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}:changeWithholdingTax Summary: Change deposit account withholding tax rate Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}:reopen Summary: Reopen a deposit account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit to be reopened. POST /deposits/{depositAccountId}:startMaturity Summary: Represents the information to post an action, such as approving a deposit account. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits/{depositAccountId}:transferOwnership Summary: Transfer the account ownership from current account holder to a new one (client/group). Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account to have it's ownership transferred. POST /deposits/{depositAccountId}:undoMaturity Summary: Represents the action to undo the maturity period for the specified deposit account. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit account. POST /deposits:search Summary: Search deposit accounts --- # API Reference: deposits/balanceSummary URL: https://docs.mambu.com/api/v2/deposits/balancesummary/ **Deposit Account Balance Summary**: Get balance summary for the deposit account POST /deposits/balanceSummary:search Summary: Search deposit account balance summary GET /deposits/{depositAccountId}/balanceSummary Summary: Get balance summary for the deposit account Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account. --- # API Reference: deposits/transactions URL: https://docs.mambu.com/api/v2/deposits/transactions/ **DepositTransactionDocuments**: Get deposit transaction document **DepositTransactions**: Search for and return deposit transactions for deposit accounts. POST /deposits/deposit-transactions:bulk Summary: Create bulk deposit transactions. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /deposits/transactions/{depositTransactionId} Summary: Get deposit transaction Parameters: depositTransactionId (path, required): The ID or encoded key of the deposit transaction. PATCH /deposits/transactions/{depositTransactionId} Summary: Edit custom information or notes for deposit transaction Parameters: depositTransactionId (path, required): The ID or encoded key of the deposit transaction. GET /deposits/transactions/{depositTransactionId}/templates/{templateId} Summary: Get deposit transaction document Parameters: depositTransactionId (path, required): The ID or encoded key of the deposit transaction.; templateId (path, required): The ID of the deposit product template. POST /deposits/transactions/{depositTransactionId}:adjust Summary: Adjust a deposit transaction, which may bulk adjust multiple transactions Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositTransactionId (path, required): The ID or encoded key of the deposit transaction. POST /deposits/transactions:search Summary: Search deposit transactions for deposit accounts by various criteria POST /deposits/{depositAccountId}/deposit-transactions Summary: Create deposit transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. POST /deposits/{depositAccountId}/fee-transactions Summary: Apply a fee on a deposit account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. POST /deposits/{depositAccountId}/seizure-transactions Summary: Seize a block amount on a deposit account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. GET /deposits/{depositAccountId}/transactions Summary: Get deposit transactions Parameters: depositAccountId (path, required): The ID or encoded key of the deposit account used to get all of its transactions POST /deposits/{depositAccountId}/transactions/deposits Summary: Create deposit transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. POST /deposits/{depositAccountId}/transactions/withdrawals Summary: Create withdrawal transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. POST /deposits/{depositAccountId}/transfer-transactions Summary: Create transfer transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. POST /deposits/{depositAccountId}/withdrawal-transactions Summary: Create withdrawal transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; depositAccountId (path, required): The ID or encoded key of the deposit that the transaction will be created for. --- # API Reference: documents URL: https://docs.mambu.com/api/v2/documents/ **Documents**: Allows you to get, create, or delete documents. POST /documents Summary: Create document Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /documents/documentsMetadata Summary: Get all documents' metadata GET /documents/{documentId} Summary: Download document Parameters: documentId (path, required): The ID or encoded key of the document to be returned.
    The ID or encoded key o DELETE /documents/{documentId} Summary: Delete document Parameters: documentId (path, required): The ID or encoded key of the document to be deleted.
    The ID or encoded key of --- # API Reference: extensionpoints URL: https://docs.mambu.com/api/v2/extensionpoints/ **ExtensionPoints**: API for listing extension points (extension profiles) and their available phases GET /extensionpoints Summary: Get all extension points Description: Returns all extension points (profiles) and their available phases GET /extensionpoints/{transactionType} Summary: Get process definitions for extension point phases Description: Returns the process definitions attached to the given extension point phases Parameters: transactionType (path, required): Transaction type identifier (e.g. type.name) PUT /extensionpoints/{transactionType} Summary: Attach process definitions to extension point phases Description: Attaches the process definitions to the given extension point phases Parameters: transactionType (path, required): Transaction type identifier (e.g. type.name) DELETE /extensionpoints/{transactionType} Summary: Detach all process definitions from extension point Description: Detaches all process definitions from all phases of the given extension point Parameters: transactionType (path, required): Transaction type identifier (e.g. type.name) --- # API Reference: fundingsources URL: https://docs.mambu.com/api/v2/fundingsources/ **fundingSources**: Allows performing actions for a loan account funding sources owned by client investors. Sell is the only permitted action POST /fundingsources/{fundingSourceId}:sell Summary: Performs the sell of a funding share owned by an investor. Investors can sell the total share or only a part of the investment. In case of a partial sale, multiple operations can be performed until the entire investment is sold. For the seller, money will be deposited in the funding account, for the buyers money will be withdrawn from provided accounts. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; fundingSourceId (path, required): Id/Encoded key of the funding source --- # API Reference: glaccounts URL: https://docs.mambu.com/api/v2/glaccounts/ **General Ledger Accounts**: Get general ledger accounts by type or specific general ledger accounts, along with their balances. GET /glaccounts Summary: Get general ledger accounts POST /glaccounts Summary: Create general ledger account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /glaccounts/{glAccountId} Summary: Get general ledger account Parameters: glAccountId (path, required): The general ledger account code or encoded key. PATCH /glaccounts/{glAccountId} Summary: Partially update an existing general ledger account Parameters: glAccountId (path, required): The general ledger account code or encoded key. --- # API Reference: gljournalentries URL: https://docs.mambu.com/api/v2/gljournalentries/ **Journal Entries**: Create general ledger journal entries. GET /gljournalentries Summary: Get general ledger journal entries POST /gljournalentries Summary: Create general ledger journal entries. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /gljournalentries:search Summary: Search for general ledger journal entries --- # API Reference: groups URL: https://docs.mambu.com/api/v2/groups/ **Groups**: Allows you to search groups by various criteria. GET /groups Summary: Get groups POST /groups Summary: Create group Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /groups/{groupId} Summary: Get group Parameters: groupId (path, required): The ID or encoded key of the group to be returned. PUT /groups/{groupId} Summary: Update group Parameters: groupId (path, required): The ID or encoded key of the group to be updated. DELETE /groups/{groupId} Summary: Delete group Parameters: groupId (path, required): The ID or encoded key of the group to be deleted. PATCH /groups/{groupId} Summary: Partially update group Parameters: groupId (path, required): The ID or encoded key of the group to be updated. GET /groups/{groupId}/creditarrangements Summary: Credit arrangements list returned. Parameters: groupId (path, required): The ID or encoded key of the group to be returned. POST /groups:search Summary: Search groups --- # API Reference: indexratesources URL: https://docs.mambu.com/api/v2/indexratesources/ **Index Rate Sources**: Allows you to get, create, update, or delete index rate sources. **Index Rates**: Allows you to get, create, update, or delete index rates. GET /indexratesources Summary: Get index rate sources POST /indexratesources Summary: Create index rate source Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /indexratesources/{indexRateSourceId} Summary: Get index rate sources Parameters: indexRateSourceId (path, required): The ID of the index rate source. DELETE /indexratesources/{indexRateSourceId} Summary: Delete index rate source Parameters: indexRateSourceId (path, required): The ID of the index rate source. GET /indexratesources/{indexRateSourceId}/indexrates Summary: Get index rates for a source Parameters: indexRateSourceId (path, required): The ID of the index rate source. POST /indexratesources/{indexRateSourceId}/indexrates Summary: Create index rate Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; indexRateSourceId (path, required): The ID of the index rate source. DELETE /indexratesources/{indexRateSourceId}/indexrates/{indexRateId} Summary: Delete index rate Parameters: indexRateSourceId (path, required): The ID of the index rate source.; indexRateId (path, required): The encoded key of the index rate to be deleted. --- # API Reference: installments URL: https://docs.mambu.com/api/v2/installments/ **installments**: Allows you to retrieve installments GET /installments Summary: Get installments for `ACTIVE` or `ACTIVE_IN_ARREARS` loan accounts --- # API Reference: loanproducts URL: https://docs.mambu.com/api/v2/loanproducts/ **Loan Products**: WARNING: Please use these APIs only to migrate products across your environments. We are working to update these endpoints, yet until then do not attempt to create products from scratch via the APIs as you may damage your Mambu instance. GET /loanproducts Summary: Get loan products POST /loanproducts Summary: Create loan product Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /loanproducts/{loanProductId} Summary: Get loan product Parameters: loanProductId (path, required): The ID or encoded key of the loan product to be returned. PUT /loanproducts/{loanProductId} Summary: Update loan product Parameters: loanProductId (path, required): The ID or encoded key of the loan product to be updated. DELETE /loanproducts/{loanProductId} Summary: Delete loan product Parameters: loanProductId (path, required): The ID or encoded key of the loan product to be deleted. PATCH /loanproducts/{loanProductId} Summary: Partially update loan product Parameters: loanProductId (path, required): The ID or encoded key of the loan product to be updated. --- # API Reference: loans URL: https://docs.mambu.com/api/v2/loans/ **Collateral Assets**: Allows you to start a background process to update loan accounts with the latest accounting rates. **Loan Account Balances**: Get balances for the loan account **Loan Accounts**: Allows you to get a loan account document (populated template) by providing a loan account ID and a template ID. **Loan Account Funding**: Allows you to operate with the loan account funding sources. **Loan Account Planned Fees**: Allows you to get and update planned fees for the installments of the loan accounts. **LoanAccountRepaymentScheduleVersioning**: Allows you to retrieve a loan account repayment schedule versioning by provided loan account encodedKey. GET /loans Summary: Get loan accounts POST /loans Summary: Create loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /loans/migrate Summary: Create loan account via external migration Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /loans/{loanAccountId} Summary: Get loan account Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. PUT /loans/{loanAccountId} Summary: Update loan account Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. DELETE /loans/{loanAccountId} Summary: Delete loan account Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. PATCH /loans/{loanAccountId} Summary: Partially update loan account Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. GET /loans/{loanAccountId}/authorizationholds Summary: Get authorization holds related to a loan account, ordered from newest to oldest by creation date Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. GET /loans/{loanAccountId}/balances Summary: Get loan account balances Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/balances/{loanAccountBalance}:applyInterest Summary: Apply interest on a loan account balance Description: Applies the interest that has accrued on a single interest-bearing-fee balance of the loan account, affecting only that balance rather than the account as a whole. To apply the account's regular accrued interest — including payment-holiday and decoupled arrears interest — use POST loans/{loanAccountId}:applyInterest instead. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account.; loanAccountBalance (path, required): Loan account balance to apply interest on GET /loans/{loanAccountId}/cards Summary: Get cards associated with an account Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/cards Summary: Represents the information needed to create and associate a new card to an account. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. DELETE /loans/{loanAccountId}/cards/{cardReferenceToken} Summary: Represents the information needed to delete a card associated to an account using its reference token. Parameters: loanAccountId (path, required): The ID or encoded key of the loan account.; cardReferenceToken (path, required): The reference token of the card to be returned. PUT /loans/{loanAccountId}/funding Summary: Update loan account funding sources Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/funding Summary: Create funding sources for a loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. DELETE /loans/{loanAccountId}/funding Summary: Delete loan account funding sources Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. DELETE /loans/{loanAccountId}/funding/{fundEncodedKey} Summary: Delete loan account funding source Parameters: loanAccountId (path, required): The ID or encoded key of the loan account.; fundEncodedKey (path, required): The encoded key of the funding source. PATCH /loans/{loanAccountId}/funding/{fundEncodedKey} Summary: Update loan account funding source Parameters: loanAccountId (path, required): The ID or encoded key of the loan account.; fundEncodedKey (path, required): The encoded key of the funding source. GET /loans/{loanAccountId}/plannedfees Summary: Get planned fees Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. PUT /loans/{loanAccountId}/plannedfees Summary: Update planned fees Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/plannedfees Summary: Create planned fees Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. DELETE /loans/{loanAccountId}/plannedfees/{plannedInstallmentFeeKey} Summary: Delete planned fee Parameters: loanAccountId (path, required): The ID or encoded key of the loan account.; plannedInstallmentFeeKey (path, required): The encoded key of the planned installment fee to be deleted. POST /loans/{loanAccountId}/plannedfees:apply Summary: ApplY planned fees from the past installments, as backdated or from future installments, on the first pending installment Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. GET /loans/{loanAccountId}/templates/{templateId} Summary: Get loan account document Parameters: loanAccountId (path, required): The ID or encoded key of the loan account.; templateId (path, required): The ID of the loan product template. GET /loans/{loanAccountId}/templates/{templateId}/pdf Summary: Download loan account document PDF Parameters: loanAccountId (path, required): The ID or encoded key of the loan account.; templateId (path, required): The ID of the loan product template. POST /loans/{loanAccountId}:applyInterest Summary: Apply accrued interest Description: Applies the interest that has accrued on the loan account. This is the general accrued-interest action: it applies the account's regular accrued interest and, where applicable, interest accrued during payment holidays and interest accrued on arrears (the latter posted as a separate transaction when interest from arrears is decoupled, as used by Mortgages). To apply the interest accrued on a single interest-bearing-fee balance instead, use POST loans/{loanAccountId}/balances/{loanAccountBalance}:applyInterest. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeArrearsSettings Summary: Change arrears settings for loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeDueDatesSettings Summary: Change due dates settings for loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeFeeRate Summary: Change loan account fee rate Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeInterestRate Summary: Change loan account interest rate Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeLoanTerm Summary: Change loan account term Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changePeriodicPayment Summary: Change the periodic payment amount for an active loan, so that it is still possible to have principal and interest installments, but with a smaller or greater total due amount than the initial one. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeRepaymentValue Summary: Change repayment value for loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:changeState Summary: Change loan account state Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:payOff Summary: Pay off loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:previewPayOffAmounts Summary: Preview pay off due amounts in a future date Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:refinance Summary: Refinance loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:reschedule Summary: Reschedule loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:terminate Summary: Terminate loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:undoRefinance Summary: Undo loan account refinance action Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:undoReschedule Summary: Undo loan account reschedule action Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:undoWriteOff Summary: Undo write off for loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. GET /loans/{loanAccountId}:versions Summary: Get all versions of loan account Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}:writeOff Summary: Write off loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans:previewSchedule Summary: Preview loan account schedule for non-existent loan account POST /loans:reevaluateCollateral Summary: Update collateral asset amounts Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v POST /loans:search Summary: Search loan accounts --- # API Reference: loans/schedule URL: https://docs.mambu.com/api/v2/loans/schedule/ **Loan Accounts**: Allows you to get a loan account schedule by provided loan account ID or encoded key. POST /loans/schedule:preview Summary: Preview loan account schedule for non-existent loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /loans/{loanAccountId}/schedule Summary: Get loan account schedule Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. PUT /loans/{loanAccountId}/schedule Summary: Update loan account schedule Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/schedule/previewProcessPMTTransactionally Summary: Preview loan account schedule using transactional processing for PMT. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/schedule:previewTranches Summary: Preview loan account schedule for non-existent loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. --- # API Reference: loans/tranches URL: https://docs.mambu.com/api/v2/loans/tranches/ **Loan Account Tranches**: Allows you to get or update the loan account tranches list for the provided loan account ID or encoded key. GET /loans/{loanAccountId}/tranches Summary: Get loan account tranches list Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. PUT /loans/{loanAccountId}/tranches Summary: Update loan account tranches list Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. --- # API Reference: loans/transactions URL: https://docs.mambu.com/api/v2/loans/transactions/ **Loan Transactions**: Allows you to get and create loan transactions for loan accounts. GET /loans/transactions/{loanTransactionId} Summary: Get loan transaction Parameters: loanTransactionId (path, required): The ID or encoded key of the loan transaction to be returned. POST /loans/transactions/{loanTransactionId}:adjust Summary: Adjust loan transaction Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanTransactionId (path, required): The ID or encoded key of the loan transaction to be returned. POST /loans/transactions:search Summary: Search loan transactions POST /loans/{loanAccountId}/creditbalance-deposit-transactions Summary: Represents the information for creating a transaction of type `CREDIT_BALANCE_DEPOSIT`. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/disbursement-transactions Summary: Make a disbursement on a loan Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/fee-transactions Summary: Apply a fee on a loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/lock-transactions Summary: Lock loan account income sources (interest, fees, penalties) Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/payment-made-transactions Summary: Make payment in redraw balance for loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/principal-overpayment-transactions Summary: Make non-scheduled principal overpayment transaction on loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/redraw-repayment-transactions Summary: Make a redraw repayment transaction on a loan Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/repayment-transactions Summary: Make repayment transaction on loan account Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. GET /loans/{loanAccountId}/transactions Summary: Get loan transactions Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. GET /loans/{loanAccountId}/transactions:versions Summary: Get loan transactions for all loan account versions Parameters: loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/unlock-transactions Summary: Unlock loan account income sources (interest, fees, penalties) Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. POST /loans/{loanAccountId}/withdrawal-transactions Summary: Make withdrawal from redraw balance Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; loanAccountId (path, required): The ID or encoded key of the loan account. --- # API Reference: notificationsettings/webhook URL: https://docs.mambu.com/api/v2/notificationsettings/webhook/ **NotificationSettings**: Defines if the notification settings should be enabled or disabled GET /notificationsettings/webhook Summary: Get the webhook notification settings Description: This endpoint retrieves the current notification settings for webhooks, indicating whether they are enabled or disabled for the specific tenant. PUT /notificationsettings/webhook Summary: Update the webhook notification settings Description: This endpoint updates the state of the webhook notification settings to either ENABLED or DISABLED. --- # API Reference: organization/holidays URL: https://docs.mambu.com/api/v2/organization/holidays/ **Holidays**: Allows you to manage holidays. GET /organization/holidays Summary: Get holidays PUT /organization/holidays Summary: Update holidays --- # API Reference: organization/holidays/general URL: https://docs.mambu.com/api/v2/organization/holidays/general/ **Holidays**: Allows you to manage holidays. POST /organization/holidays/general Summary: Create holidays Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /organization/holidays/general/{holidayIdentifier} Summary: Get holiday Parameters: holidayIdentifier (path, required): The ID or encodedKey of the holiday. DELETE /organization/holidays/general/{holidayIdentifier} Summary: Delete holiday Parameters: holidayIdentifier (path, required): The ID of the holiday to be deleted. --- # API Reference: organization/holidays/nonworkingdays URL: https://docs.mambu.com/api/v2/organization/holidays/nonworkingdays/ **Holidays**: Allows you to manage non-working days. GET /organization/holidays/nonworkingdays Summary: Get non-working days PUT /organization/holidays/nonworkingdays Summary: Update non-working days --- # API Reference: organization/identificationDocumentTemplates URL: https://docs.mambu.com/api/v2/organization/identificationdocumenttemplates/ **ID Templates**: Allows you to get ID templates. GET /organization/identificationDocumentTemplates Summary: Get ID templates --- # API Reference: organization/transactionChannels URL: https://docs.mambu.com/api/v2/organization/transactionchannels/ **Transaction Channels**: Allows you to manage transaction channels. GET /organization/transactionChannels Summary: Get transaction channels POST /organization/transactionChannels Summary: Create transaction channel Description: Create transaction channel. **Note**: A new Transaction Channel will be linked to the active custom fields that are defined for all available channels. However, if a custom field does not have every entity available it must be linked manually. Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /organization/transactionChannels/{transactionChannelId} Summary: Get transaction channel Parameters: transactionChannelId (path, required): The ID of the transaction channel to be returned. PUT /organization/transactionChannels/{transactionChannelId} Summary: Update transaction channel Parameters: transactionChannelId (path, required): ID for the transaction channel to be updated. DELETE /organization/transactionChannels/{transactionChannelId} Summary: Delete transaction channel Parameters: transactionChannelId (path, required): The ID of the transaction channel to be deleted. --- # API Reference: profitsharing/cash-flows URL: https://docs.mambu.com/api/v2/profitsharing/cash-flows/ **CashFlows**: Allows create, get, update, and delete of cash flows. GET /profitsharing/cash-flows Summary: Allows retrieval of a list of cash flows POST /profitsharing/cash-flows Summary: Create a new cash flow Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /profitsharing/cash-flows/{cashFlowId} Summary: Allows retrieval of a single cash flow Parameters: cashFlowId (path, required): The id of the cash flow PUT /profitsharing/cash-flows/{cashFlowId} Summary: Update an existing cash flow Parameters: cashFlowId (path, required): The id of the cash flow POST /profitsharing/cash-flows/{cashFlowId}/settings Summary: Create new settings for a cash flow Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; cashFlowId (path, required): The id of the cash flow GET /profitsharing/cash-flows/{cashFlowId}/settings/{cashFlowSettingsId} Summary: Retrieves the settings for a cash flow Parameters: cashFlowId (path, required): The id of the cash flow; cashFlowSettingsId (path, required): The id of the cash flow settings PUT /profitsharing/cash-flows/{cashFlowId}/settings/{cashFlowSettingsId} Summary: Update settings for an existing cash flow Parameters: cashFlowId (path, required): The id of the cash flow; cashFlowSettingsId (path, required): The id of the cash flow settings --- # API Reference: profitsharing/pools URL: https://docs.mambu.com/api/v2/profitsharing/pools/ **Pools**: Allows you to get, create, update, and delete pool. GET /profitsharing/pools Summary: Allows retrieval of a list of pools POST /profitsharing/pools Summary: Create a new investment pool Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /profitsharing/pools/{poolId} Summary: Allows retrieval of a single pool Parameters: poolId (path, required): The id of the pool PUT /profitsharing/pools/{poolId} Summary: Update an existing investment pool Parameters: poolId (path, required): The id of the pool POST /profitsharing/pools/{poolId}/settings Summary: Create new settings for investment pool Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; poolId (path, required): The id of the pool GET /profitsharing/pools/{poolId}/settings/{poolSettingsId} Summary: Retrieves settings for an investment pool Parameters: poolId (path, required): The id of the pool; poolSettingsId (path, required): The id of the pool settings PUT /profitsharing/pools/{poolId}/settings/{poolSettingsId} Summary: Update settings for an existing investment pool Parameters: poolId (path, required): The id of the pool; poolSettingsId (path, required): The id of the pool settings --- # API Reference: profitsharing/product-settings URL: https://docs.mambu.com/api/v2/profitsharing/product-settings/ **ProductSettings**: Allows create, get, update, and delete of product settings. POST /profitsharing/product-settings Summary: Create new product settings Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /profitsharing/product-settings/{productSettingsId} Summary: Allows retrieval of product settings Parameters: productSettingsId (path, required): The id of the product settings PUT /profitsharing/product-settings/{productSettingsId} Summary: Update existing product settings Parameters: productSettingsId (path, required): The id of the product settings POST /profitsharing/product-settings:search Summary: Allows the retrieval of product settings based on criteria --- # API Reference: profitsharing/proposals URL: https://docs.mambu.com/api/v2/profitsharing/proposals/ **Proposals**: Allows to retrieve proposals. POST /profitsharing/proposals/{proposalId}/approve Summary: Allows approval of a proposal Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v; proposalId (path, required): The identifier of the proposal POST /profitsharing/proposals/{proposalId}/pool-cycles/{poolCalculationCycleId}/product-cycles/{productCalculationCycleId}/account-details:search Summary: Allows the retrieval of proposal accounts details and account payment/profit cycle calculation by proposal id and other params. Parameters: proposalId (path, required): The identifier of the proposal; poolCalculationCycleId (path, required): The identifier of the pool calculation cycle; productCalculationCycleId (path, required): The identifier of the product calculation cycle POST /profitsharing/proposals:search Summary: Allows the retrieval of proposals calculation Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v --- # API Reference: setup/general URL: https://docs.mambu.com/api/v2/setup/general/ **General Setup**: Allows you to get the general setup. GET /setup/general Summary: Get general setup --- # API Reference: setup/organization URL: https://docs.mambu.com/api/v2/setup/organization/ **Organization Details**: Allows you to get or update the organization details. GET /setup/organization Summary: Get organization details PUT /setup/organization Summary: Update organization details --- # API Reference: streaming/publisher/stats URL: https://docs.mambu.com/api/v2/streaming/publisher/stats/ **StreamingPublisher**: Provides operational statistics about the Mambu streaming events publisher — for example, the number of events that have not yet been delivered downstream. Use this endpoint to monitor the health of your streaming integration alongside the rest of the core v2 admin API. This endpoint does not return event payloads. To consume the actual event stream — creating subscriptions, reading events, and committing cursors — see the [Mambu Streaming API](/api/streaming/mambu-streaming-api). GET /streaming/publisher/stats Summary: Get streaming publisher statistics --- # API Reference: subscriptions URL: https://docs.mambu.com/api/v2/subscriptions/ **Subscription**: Allows you to get, create, or delete streaming events subscriptions. POST /subscriptions Summary: Allows the creation of a streaming events subscription DELETE /subscriptions/{subscriptionId} Summary: Allows the deletion of a streaming events subscription Parameters: subscriptionId (path, required): The Id of subscription. POST /subscriptions/{subscriptionId}/cursors Summary: Commits offsets of the subscription Parameters: subscriptionId (path, required): The Id of subscription. GET /subscriptions/{subscriptionId}/events Summary: Get subscription events Parameters: subscriptionId (path, required): The Id of subscription. GET /subscriptions/{subscriptionId}/stats Summary: Get subscription statistics Parameters: subscriptionId (path, required): The Id of subscription. --- # API Reference: tasks URL: https://docs.mambu.com/api/v2/tasks/ **Tasks**: Allows you to get, create, update, or delete tasks. A task represents a human task that can be assigned by one user to another. GET /tasks Summary: Gets tasks POST /tasks Summary: Create task Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /tasks/{taskId} Summary: Get task Parameters: taskId (path, required): The ID or encoded key of the task. PUT /tasks/{taskId} Summary: Update task Parameters: taskId (path, required): The ID or encoded key of the task. DELETE /tasks/{taskId} Summary: Delete task Parameters: taskId (path, required): The ID or encoded key of the task. PATCH /tasks/{taskId} Summary: Partially update task Parameters: taskId (path, required): The ID or encoded key of the task. --- # API Reference: templates URL: https://docs.mambu.com/api/v2/templates/ **Templates**: A template is the configuration of the handler defined for a certain event. POST /templates Summary: Create a new template Description: This endpoint creates a new template, performing all necessary validations. Note: Currently, only Webhook templates are supported. GET /templates/{templateId} Summary: Get template by id Description: This endpoint retrieves a specific template, regardless of its type (webhook, SMS, or email), based on the provided templateId. Parameters: templateId (path, required): The ID of the template to be retrieved. DELETE /templates/{templateId} Summary: Delete an existing template Description: This endpoint deletes an existing webhook template identified by the provided templateId. Parameters: templateId (path, required): The ID of the template to be deleted. PATCH /templates/{templateId} Summary: Update an existing template Description: This endpoint updates an existing template, performing all necessary validations on the updated object. Note: Currently, only Webhook templates are supported. A valid PATCH request contains an array of PATCH operation objects.



    Click for more details on the PATCH Request Object Structure

    These objects can be:

    • For REPLACE Operation:
      {
        \"op\": \"REPLACE\",
        \"path\": \"<path for replacement>\",
        \"value\": \"<new value for the property>\"
      }
      • path: Can be an editable property of the webhook template or the ID of a filter constraint or request header (\"path\": \"<nested object id>/<nested object property to be edited>\") along with the property to be edited.
      • value: Mandatory.
    • For REMOVE Operation:
      {
        \"op\": \"REMOVE\",
        \"path\": \"<path_for_removal>\"
      }
      • path: Can be a nullable property of the webhook template or the ID (\"path\": \"<nested object id>\") of an existing filter constraint or request header.
      • No value should be set.
    • For ADD operation
      • For simple properties:
        {
          \"op\": \"ADD\",
          \"path\": \"<property_to_add_value_for>\",
          \"value\": \"<value_for_the_property>\"
        }
        • path: Can be a template property.
      • For new request headers or filter constraints:
        {
          \"op\": \"ADD\",
          \"path\": \"headers/<header property>\",
          \"value\": \"<value to be added for specified property for the new header>\"
        }
      • {
          \"op\": \"ADD\",
          \"path\": \"filterConstraints/<filter constraint property>\",
          \"value\": \"<value to be added for specified property for the new filter constraint>\"
        }
    • In a single PATCH call, you can add only one new request header and one new filter constraint. If multiple attempts are made to add within the same array, only the last value for each type will be populated in the newly added nested object of each type.
    • For nested objects inside the template with PATCH, ADD works for addition only (given the custom syntax with the headers or filterConstraints identifiers) and REPLACE is the one used for the replacement of the values of the nested objects' properties.
    " Parameters: templateId (path, required): The ID of the template to be updated. --- # API Reference: userroles URL: https://docs.mambu.com/api/v2/userroles/ **User Roles**: Allows you to get, create, update, or delete user roles. GET /userroles Summary: Get user roles POST /userroles Summary: Create user role Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /userroles/{roleId} Summary: Get user role Parameters: roleId (path, required): ID or encoded key of the user role to return. PUT /userroles/{roleId} Summary: Update user role Parameters: roleId (path, required): ID or encoded key of the user role to update.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v DELETE /userroles/{roleId} Summary: Delete user role Parameters: roleId (path, required): ID or encoded key of the user role to delete. PATCH /userroles/{roleId} Summary: Partially update user role Parameters: roleId (path, required): ID or encoded key of the user role to update. --- # API Reference: users URL: https://docs.mambu.com/api/v2/users/ **Users**: Allows you to get, create, update, or delete users. Note that certain fields (for example, the password) are stripped out from the response for security reasons. GET /users Summary: Get users POST /users Summary: Create user Parameters: Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v GET /users/{userId} Summary: Get user Parameters: userId (path, required): The ID or encoded key of the user to be returned. PUT /users/{userId} Summary: Update user Parameters: userId (path, required): The ID or encoded key of the user to be updated.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v DELETE /users/{userId} Summary: Delete user Parameters: userId (path, required): The ID or encoded key of the user to be deleted. PATCH /users/{userId} Summary: Partially update user Parameters: userId (path, required): The ID or encoded key of the user to be updated.; Idempotency-Key (header): Key that can be used to support idempotency on this POST. Must be a valid UUID(v