Skip to main content

Version 3.32

· 2 min read
Dragos Tigoianu

Beneficiary names for OWTs now support special characters

When creating an Outgoing Wire Transfer (OWT), it will be possible to include special characters as part of the destinationBeneficiary.name field.

The supported characters are inline with the accepted SEPA or FPS payment schemes. If an unsupported characters is used this will be automatically converted to “.”, avoiding any interruption to the OWT submission.

For SEPA we follow the EPC guidelines of the Extended Character Set.

For FPS, the special characters are:

  • "/" (forward slash)
  • "-" (hyphen)
  • "?" (question mark)
  • ":" (colon)
  • "(" (left parenthesis))
  • ")" (right parenthesis)
  • "." (full stop)
  • "," (comma)
  • "’" (right single quote)
  • "+"(plus sign)
  • (blank space)
  • "#" (hash)
  • "=" (equals)
  • "!" (exclamation mark)
  • ” (right double quote)
  • "%" (percentage)
  • "&" (ampersand)
  • "*" (asterisk)
  • "<" (less than)
  • ">" (greater than)
  • ";" (semicolon)
  • "{" (left curly bracket)
  • "@" (commercial at)
  • CrLf (carriage return line feed)

Ability to increase the maximum allowable characters on bespoke plastic cards

If you provide physical cards for your customers and opt for our bespoke plastic cards; depending on your bespoke design and configuration, it will be possible to increase the maximum allowable characters of the nameOnCard and nameOnCardLine2 fields printed on the cards, to a maximum of 27 characters per field.

For on-demand designs, the maximum allowable characters for both fields will remain at 20 characters.

If you already use a bespoke card design, or would like to upgrade your cards and design, please contact Weavr Support to determine the maximum allowable characters for your bespoke plastic card programmes.


Version 3.31

· One min read
Dragos Tigoianu

'Remove Card' endpoint added to back-office

The /managed_cards/\{id\}/remove endpoint has been added to the back-office API set. When using this endpoint you will be destroying the managed card identified by the id path parameter. Unlike block, this action is not reversible.

A managed card must be empty before it can be destroyed using this operation.


Version 3.29.1

· 2 min read
Dragos Tigoianu

Deactivating Corporate Identity will not lead to delete user account

This feature is for users that are linked to multiple Corporates with one set of credentials. If a root user is linked to multiple Corporates, and one of those Corporates is deactivated, the user will continue to have access to the other Corporates linked to the account. The same approach is taken if a user is deactivated that is linked to one particular Corporate, they will continue to have access to the other linked Corporates. If you would like a user to be linked to multiple Corporate identities, with a single set of credentials (email+password), please contact our support team to register your interest in enabling this feature.

Fees Details Dashboard Enhancement

The Fees Details Dashboard can be used to view any fees calculated within your profile.

Due to the possibility of having ‘Fee Groups' set up for different identities (depending on the agreed contractual agreements), we have now introduced a new field within the Fee Details table which allows you the view the 'Fee Group’ (where applicable).

New Webhook Notifications

We have added new webhooks so that you are notified when:

  • A user has attempted to login
  • A user has stepped-up a token by performing second factor authentication

You can find the full list of published webhooks here


Version 3.29

· 5 min read
Dragos Tigoianu

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.


Version 3.28

· 3 min read
Dragos Tigoianu

Data Insights - Transaction Amounts Alignment

Currently, in the following dashboards on Data Insights, all Transaction Amounts are displayed in your Billing (Reporting) Currency:

  • Card Authorisations
  • Card Settlements
  • Managed Accounts Incoming Transfers
  • Managed Accounts Outgoing Transfers
  • Sends Overview

Following this release, the definitions of transaction amount columns within the Details tables will be aligned across all dashboards to ensure consistency and uniformity as follows:

  • Transaction Base Amount: amount in your billing currency
  • Transaction Amount: amount in the original transaction currency

Note that all other charts across these dashboards will not be impacted with this change and will still show amounts in your billing currency (i.e. Transaction Base Amount).

Corporate due diligence - requesting additional details through questionnaires

Additional steps are being introduced in the Corporate KYB process flow, where through a questionnaire, details will be requested on the company itself and its directors. For the company, questions relate to business activity and expected volumes, whilst for the director performing KYC, questions relate to confirmation of PEP status.

The industry and source of funds information that is currently collected via the Create Corporate API will now be requested directly from the root user via the questionnaire. As such, the industry, sourceOfFunds and sourceOfFundsOther fields in the Create Corporate API will be deprecated (and set as optional for now) so that you do not have to request this information during your registration process.

The APIs affected are as follows:

  • Post /multi/corporates , Get /multi/corporates , Patch /multi/corporates

    • industry, sourceOfFunds and sourceOfFundsOther have been deprecated
    • 409 SOURCE_OF_FUNDS_OTHER_MISSING has been removed
  • Post /multi/consumers/kyb

    • 409 INDUSTRY_MISSING and 409 SOURCE_OF_FUNDS_OTHER_MISSING have been removed

Corporate due diligence - requesting additional details and documents for UBOs

As part of the information requested during onboarding, when UBO details are being provided, the percentage of company ownership now needs to be entered for the individual UBOs.

For each UBO, a copy of the Id document as well as a proof of address document need to be uploaded by the root user, through a link provided. (Note that if the Id document contains the address, then this can be also used as the proof of address document.)

Production API Rate Limit

Following our commitment to ensure high levels of service and availability, since 1st of December 2022 API rate limits for Sandbox environment have been in force.

From 27th February 2023, limits will also apply on production that are appropriate to the needs of your application, whilst preventing abuse. Limits can be increased on request by contacting support and will be based on your legitimate usage.

If API requests exceed these limits, an HTTP status code (429 - Too Many Requests) will be returned on each request to indicate this condition, until the frequency time window has elapsed. See response code 429 in the API documentation for more details.

View SCA challenge details per transaction type in the Innovator Portal

You can now view the SCA challenge details of your Send and OWT transactions, directly from the Innovator portal. All SCA challenge activity and history initiated by your users can also be tracked in the Innovator portal user’s details screen.