Beta Release Single Login Accessing Multiple Corporates
This is a “beta” release because we will only activate it for you on sandbox upon your request, so that integration can start. Activation on production will need to be at a mutually agreed time.
At this point in time, the change is optional, and is only considered a breaking change if you choose to activate the feature. If you do not request the feature, no changes to your application are required.
User login functionality will be enhanced whereby, root users will have the possibility to access and manage financial services of more than one Corporate Identity using a single set of credentials (email+Password).
Enabling this feature (upon your request) will trigger a breaking change in the user authentication APIs, when a new user is created with the same credentials across more than one Corporate identity. However, if your users access one identity only, your integration will not be affected.
The changes are under the following endpoints:
-
User Authentication - Access -
Post/Login with password -
- In the Response 200, token type is a new field and only applies to users linked to multiple identities
-
User Authentication - Access -
Get/Get user identities -
- Retrieve a list of identities for the users linked to multiple identities
-
User Authentication - Access -
Post/Acquire a new access token -
- Used for situations when the user would like to switch between his identities
-
Identities - Corporates -
Post/Create a corporate -
- The change is related to the fact that now we have more 409 conflict codes
-
Identities - Corporates -
Patch/Update a corporate -
- If the corporate identity was created with a user that did not passed KYC, it will not be allowed PATCH with another existing user that performed KYC for another corporate identity
Please contact our support team to register your interest in enabling this feature and/or to check if you will be affected by this change. More information on the changes in the APIs will be provided soon.
Corporate due diligence - background checks on directors
The onboarding process for Corporates has been updated and a single business representative (the Root User of a Corporate) can fill in all the required details to pass KYB.
The person filling in the KYB information can gather the required details of their company directors and UBOs and input/attach the information themselves, without those other directors/owners needing to login or perform any steps by themselves.
The step for UBO verification was included in the previous release (Release 22). This change involves the details required for all directors. The Root User will need to provide basic details (name, date of birth, nationality) of all directors (apart from any director performing full KYC).
An underlying AML check will be performed to confirm that the individuals are not included in any sanctions list.
You will receive STATUS_UPDATED updates for these individuals through the corporates/kyb/beneficiaries/watch webhook, where additionalInformation-> beneficiary-> type is OTHER_DIRECTOR , to indicate the status of the background checks.
In the unlikely event where any director fails these AML checks, causing the corporate to be rejected, Weavr customer support will provide guidance to determine the reason and steps for fixing this.
Removal of Mobile Number Verification APIs
The consumer and corporate root users' mobile number verification Send and Verify APIs will cease to operate, superseded by the Enrolment APIs previously introduced.
To verify users' mobile numbers the existing Authentication Factors SMS Enrolment APIs should instead be utilised. Once enrolled, the user’s mobile number will be marked as verified automatically.
These Enrolment APIs are already available within the Sandbox environment and you can find more information on how to enrol users using the Authentication Factor APIs in our guides.
Affected APIs:
-
/multi/corporates/verification/mobile/send -
/multi/corporates/verification/mobile/verify -
/multi/consumers/verification/mobile/send -
/multi/consumers/verification/mobile/verify
Kindly note, that if a root user device was enrolled using the affected API the device is not enrolled for Strong Customer Authentication (SCA). Therefore, we suggest, that once you develop the Authentication Factor API, you should prompt the end-user to enrol their device again. Alternatively, please contact customer support to help facilitate the re-enrolling of a device for a root user.
Token validity will be reduced to 5 minutes
In line with regulation, we are changing the duration of validity for the token that is returned when authentication is performed. Currently, the token is valid for 15 minutes from the last activity; and this will now be changed to 5 minutes.
Affected APIs:
/multi/login_with_password
OpenAPI Schema Version Upgrade
The Multi API will stop using the OpenAPI 3.0.2 schema version and will start using the 3.1.0 version. The OpenAPI Specification can be found here
If you are using an OpenAPI generator you may need to confirm that the generator has support for this new version.
Sends Between Same Identity Instruments
We have refined the validation in connection with the Send money-movement transaction.
When transferring funds between instruments, if the destination instrument belongs to the same identity as the source instrument, then a Send transaction will no longer be possible and a 409 will be returned with the error code “DESTINATION_BELONGS_TO_SAME_IDENTITY”.
For transferring funds between instruments on the same identity a Transfer type transaction is the correct method and should be used instead.
Data Insights - Cards Overview Enhancements
Data Insights offers you the possibility to analyse your cards via the Cards Overview dashboard. We have enhanced the dashboard by including new details about your cards within the Card Details table. A new filter has also been added which allows you to filter on active cards.