SMS OTP expiry time​

In order to provide a consistent experience and level of security for end-customers using SMS OTPs, the validity of all SMS OTPs are now aligned to 5 minutes, whereas some actions previously had a longer validity. This applies to mobile verification and all step-up actions.

Please find here more details about our Step-up Documentation.

New step-up required after successful password change​

As a measure to improve the security of information belonging to end-customers, we are introducing a new rule regarding token validity after a user changes their password.

When a user changes their password (reset password flow) /passwords/lost_password/start /passwords/lost_password/resume, they will now have to perform a step-up to view information that may have been previously covered by a step-up in the last 180 days. This is because the validity of the tokens will have been reset and requires a fresh step-up.

Please find here more details about our Step-up Documentation.

New dashboard field for end-customer “Fee Group”​

The Consumers Overview and Corporates Overview dashboards can be used to monitor any new identities that are created, and their relevant details.

We have now introduced a “Fee Group” column within the Details tables; this can help you monitor which identities are linked to the plans that you support.

Reject duplicate identities for consumers programmes​

We are launching a new feature that will block same user creating multiple identities on your programme. This is going to help you:

1. Prevent fraud
2. Increase security
3. Improve customer support
4. Enhance compliance
5. Reduce costs

When detecting a duplicate identity, we will communicate via webhook the following:

• identity_id

• reason of rejection

• state of the account

• timestamp

Here’s an example of a response for a Duplicate identity:

Reversal of returned Outgoing Wire Transfers​

We are improving the processing of transactions if an Outgoing Wire Transfer is returned by the beneficiary bank or other payment service provider, and making the status of the original Outgoing Wire Transfer clearer.

If an Outgoing Wire Transfer was sent successfully, but ultimately refused and returned by the beneficiary bank, the funds will be credited back to the managed account, as well as any fees (this option can be selected via a new portal option). The original Outgoing Wire Transfer will also be updated with a new state RETURNED (currently the Outgoing Wire Transfers remain in the state COMPLETED). When calling a statement there will be a new transactionState entry with a RETURNED state, indicating the OWTs that were returned.

A new state RETURNED will be added to the “Outgoing Wire Transfer transaction” webhook, and will be sent if an Outgoing Wire Transfer is updated to this state.

The Outgoing Wire Transfers will also have the state RETURNED in the following APIs

GET: outgoing_wire_transfers

GET: outgoing_wire_transfers/\id\}

GET: managed_accounts/{id\}/statement

In the portal, in the Managed Account activity statement, the original Outgoing Wire Transfer will have a tag displayed “RETURNED”.

Previously, an OWT would never transition beyond a COMPLETED state. However, it will now be possible for an OWT to transition from COMPLETED to RETURNED.

Restrictions on onboarding Non Profit Organisations​

This change will impact you if you plan to onboard charities or non-profit organisations, because financial services for these types of organisation are no longer supported.

The full list of supported company types is listed in the API documentation, and the restriction of non-profit organisations will be enforced when creating a corporate using POST multi/corporates.

Corporates of type NON_PROFIT_ORGANISATION will not be accepted and if you attempt to onboard a company having company.type = NON_PROFIT_ORGANISATION, a 409 COMPANY_TYPE_UNSUPPORTED conflict response will be returned.

Country of residence required upon consumer identity creation​

The end consumer’s country of residence is key information that is required at the very first step of onboarding (consumer creation) so that the consumer can be directed to the correct onboarding flow depending on the jurisdiction in which they reside.

Currently, when creating a consumer identity using POST /multi/consumers, the country of residence of the consumer (rootUser.address.country) is optional. In such cases, the country would be provided later, during the due diligence process.

We are now making the country of residence mandatory immediately upon creation, in POST /multi/consumers. This will be used to help determine the appropriate due diligence process that the user needs to go through.

If a country is not provided in the call, the API will respond with 400 Bad Request Error.

Removing “Set spend rules for a managed card” deprecated API​

The deprecated “Set spend rules” PUT API will be removed in favour of the 3 existing API endpoints:

Create spend rules config API endpoint: This new POST API endpoint should be used when setting up the spend rules for the first time on a card.

Update spend rules config API endpoint: This new PATCH API endpoint should be used when spend rules have already been set on a card and these need amending to add or alter the rules that are currently configured.

Delete spend rules config API endpoint: This new DELETE API endpoint should be used when spend rules need to be removed that are currently configured on a card.

Unlike the PUT spend rules API endpoint, when using the create, update and delete spend rules API endpoints, only the rules that you want to configure need to provided. The rules that do not apply can be left out.

Affected APIs:

PUT /managed_cards/\{id\}/spend_rules

POST /managed_cards/\{id\}/spend_rules

PATCH /managed_cards/\{id\}/spend_rules

DELETE /managed_cards/\{id\}/spend_rules

Retrieving Spend Rules

The current spend rules response combines all rules that apply. This response object will be deprecated and the Get Spend Rules API endpoint enhanced to contain three response objects (groupings):

Card level spend rules: These are spend rules that are associated with the specific card itself

Identity level spend rules: These are spend rules that are associated with the cardholder (owner of the card).

Profile level spend rules: These are the spend rules that are configured in the Multi portal > Settings > Managed Cards screen

Please note that the response objects will only contain rules that have been configured within its group, thereby omitting all un-configured rules.

Affected APIs:

GET /managed_cards/\{id\}/spend_rules

Additional SCA methods for 3DS transaction verifications​

Following up on our alternative multifactor authentication methods release we have done recently where we introduced biometrics and third party auth app push confirmations (via Twilio Authy), we are now making biometrics and push authentication available for confirmation of card purchases, in addition to the existing default solution using SMS one-time passcodes (OTPs). These alternative multifactor authentication methods are designed to be 3-D Secure (3DS) and SCA-compliant out of the box.

Embedders with native mobile apps are invited to beta test biometric 3DS/SCA for card payments while we recommend all other (web application) setups test out push confirmations via Twilio Authy. Both of these new multifactor authentication methods add convenience and security benefits compared to SMS OTPs, as well as enhancing brand recognition and app engagement in the UX around card payment confirmations.

If you choose to use Twilio Authy or Biometrics, one-time-passwords via SMS will be automatically configured as a fallback option to ensure that your customers always have a way to verify their purchases.

SMS is a mandatory selection as a fallback authentication method when configuring Twilio Authy or Biometrics for Primary authentication methods for 3DS.

Please contact Weavr Support to learn more on how you can benefit from this new feature.

Data Insights - Terminology Alignments and Enhancements​

We are continuously working on improving the functionality within Data Insights to allow you to analyse and understand your data better. As part of this release, we have worked on various alignments across our dashboards to ensure further consistency and uniformity including:

1. Renaming of ‘Deposits’ within the Managed Accounts Incoming Transfers dashboard. Going forward, we are referring to this transaction type as ‘Incoming Wire Transfer’. Note that this will be a consistent terminology used throughout all Data Insights dashboards when referring to this transaction type.

2. Currently, Details tables within dashboards show:

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

Going forward, the Transaction Amount column will be showing the instrument amount (i.e. the amount in the currency of the instrument). The reason for this enhancement is that the Instrument Amount portrays a more correct value of the transaction since this is the amount that is used to adjust balances. Please note that there will be minimal to no changes to the previously reported numbers. This change applies to the following dashboards:

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

SMS Sender ID set to "AUTHMSG" for OTP and SCA SMSes sent to UK​

We have made improvements to the Sender ID of the SMS that is sent during 3DS verification to OTP and SCA SMSes sent to the UK. The SMSes will be sent with “AUTHMSG” as SenderID

Simplified company ownership (UBO) questionnaire for KYB onboarding​

Part of our ambition to improve the corporate onboarding journey, we are releasing a simplified UBO form, that will allow Root users completing KYB on behalf of their Corporate to better understand the details needed when declaring a Ultimate Beneficial Owner (natural person owning at least 25% of the shares or voting rights).

SMS notification to old SCA-enrolled mobile number when replaced by new mobile number​

Enhancement for security around SCA: if an end user changes his mobile number enrolled for receiving SMS OTPs, we will send an SMS notification to their previously enrolled mobile number provided, that old mobile number was previously validated. This message by default states: "Your account’s mobile number ending in {last 4 digits of the previous mobile number\} has been updated with {last 4 digits on the new mobile number\}. If you haven’t requested this change, please contact support".

Change email via PATCH - one request per minute​

If an end user requests to change their email address, we send a validation email for them to confirm. We have now added a 1 minute delay between any re-sends of this validation email to prevent spamming or accidental repeat messages.

Do not display deactivated Corporate identities​

Part of the Single Login Accessing Multiple Corporates feature, we have implemented a new functionality that will allow users to be displayed only the Active identities they are linked to. When calling Get/Identities the response will only contain the Active Identities that the user is linked to.

Trusted payees list for Outgoing Wire Transfers and Sends​

Allow end customers to save payees for Outgoing Wire Transfers and Sends into a "trusted payees" list. Aside from convenience and a reduced chance of making errors when making payments, this allows for the introduction an SCA exemption, where the account holder can request that payments to saved beneficiaries are exempted from the requirement to pass an SCA challenge every time.

Please contact Weavr Support to learn more on how you can benefit from this new feature.

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.

Authorisation Forwarding​

We will be introducing the ability for card purchase authorisation details to be forwarded to you via a webhook. This enables you to play a part in whether a card purchase is accepted or declined.

Authorisation Forwarding is an optional feature that can assist you to decide whether to accept or decline Authorisation on a card purchase in real time and it enables you to run your own checks on top of any spend controls you may have configured in the card profiles or on the card itself when your customers perform purchases.

Please contact Weavr Support to learn more about this feature.