Past Backwards Compatibility Changes
  • 01 Nov 2023
  • 11 Minutes To Read
  • Dark
    Light
  • PDF

Past Backwards Compatibility Changes

  • Dark
    Light
  • PDF

Article Summary

The backwards compatibility changes that happened in the last years were the following:

ChangeReference IDBackwards compatible until
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). For more information, see Managing Users under Federated Authentication - Branch assignment.CIAM-2668November 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-3031March 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-53February 27, 2023
Upgrade to latest AWS Application Load Balancer (ALB) security policy requiring forward secrecy and strong protocols and ciphers.IAM-356March 2021
Update on the data access model for GET/POST:search APIs.NTF-133February 5, 2021
Change for users with restricted branch access via API 2.0 across Mambu.CORE-1843September 24, 2020
Apply Read permission standards on API 1.0 GET 'Branches' endpoints.ADM-2011November 12, 2020
Apply Read permission standards on API 1.0 GET 'Centres' endpoints.ADM-2083November 12, 2020
Replacing Default Sort Criterion 'lastModifiedDate' with 'creationDate' for Paginated Lists via API 2.0 across Mambu.DEP-1580; CORE-2721; CUS-2438; CUS-2445September 30, 2020
Apply Read permission standards on API 1.0 GET 'Transaction Channels' endpoint.ADM-1958September 18, 2020
Apply Read permission standards on API 1.0 GET 'Roles' endpoint.IAM-815September 18, 2020
Enforce task visibility based on branch access.TCS-1779May 20, 2020
Enforce "View User Details" permission for APIs.IAA-227March 20, 2020
Mambu-SSO Role Mapping on user provisioning.IAA-24August 31, 2019
Mambu Platform TLS 1.0 and 1.1 restriction.APP-712April 8, 2019
Android App TLS 1.0 and 1.1 restriction.MOB-401April 8, 2019
Custom Field Set ID Update.API-1721December 2018

Scheduled 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.

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:

  • Clients & Groups
  • Deposits
  • Loans

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

2020

Change for Users with restricted branch access

Mambu has made a change to the 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 behavior, 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.

Apply Read permission standards on API 1.0 GET 'Branches' endpoint

With the introduction of Granular Administrator Permissions Standards 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.

  • GET /api/branches
  • GET /api/branches/{branchID}

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.

Apply Read permission standards on API 1.0 GET 'Centres' endpoint

With the introduction of Granular Administrator Permissions Standards 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.

  • GET /api/centres
  • GET /api/centres/{centreID}

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.

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:

  • GET /api/deposits (DEP-1580)
  • GET /api/loans (CORE-2721)
  • GET /api/clients (CUS-2438)
  • GET /api/groups (CUS-2445)

Apply Read permission standards on API 1.0 GET 'Transaction Channels' endpoint

With the introduction of Granular Administrator Permissions Standards 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 from September 19th, 2020. **.

Apply Read permission standards on API 1.0 GET 'Roles' endpoint

With the introduction of Granular Administrator Permissions Standards 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 from September 19th, 2020. **.

  • GET /api/userroles
  • GET /api/userroles/{encodedKey}

Restrict 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 his clients that might contain sensitive information.

If you want to learn more on tasks and visibility rights, please refer to our updated support page here.

2019

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:

  • API access
  • View user details permission

Any user without these permissions will no longer be able to read user data via our APIs.

Mambu-SSO Role Mapping on User Provisioning

Description

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 to get an answer from our Product team or contact tech support.

Read more in our Mambu-SSO Role Mapping on User Provisioning. support article.

Reference IDDeployment dateDeployment versionBackwards compatible untilImpacted Area(s)Tenant action required
TCS-83January 20th, 2019 on ProductionV9August 31st, 2019User AuthenticationPotential

Mambu Platform TLS 1.0 and 1.1 restriction

Description
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.

Reference IDDeployment dateDeployment versionBackwards Compatibility maintained byImpacted AreasAction Required
APP-71225 Feb-2019 on SandboxNone. The restriction will happen at a fixed date, does not require a new version deployment.6 weeks from Sandbox EnablingGeneral - All AreasYes

An email with the exact date when TLS 1.0 and 1.1 will be restricted will be sent to Mambu Champions.

Android App TLS 1.0 and 1.1 restriction

Description
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 to the latest version and check the compatibility with your device manufacturer.

Reference IDDeployment dateDeployment versionBackwards compatible untilImpacted Area(s)Tenant action required
MOB-401April 8th, 2019 on Production9.1April 7th, 2019Android ApplicationPotential

2018

Custom Field Set ID Update

Description
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 as

Custom Field Set ID prior updateCustom Field Set ID after update
MonthlySalary_MonthlySalary
Reference IDDeployment dateDeployment versionBackwards Compatibility ByTypeAction Required
API-1721December 2018V9.0December 2018API 2.0Yes

Was this article helpful?