Block mobile number change for 24 hours after account password change or email address change​

As a measure to improve the security of information belonging to end-customers, we are introducing a new rule that will help securing user’s account.

If a user changes their password (via the reset password flow)

/passwords/lost_password/start /passwords/lost_password/resume

they will not be able to change the mobile number in the next 24 hours.

This guards against account-hijack risks by keeping the mobile number unchanged to receive security notifications, and preventing takeover of second-factor authentication.

Longer Requires_SCA validity for wire transfers and Sends​

Until now, SCA authorisation for OWT and Send payments has allowed a pending/pending_challenge status for up to 30 minutes.

As more businesses use embedded payments within multi-party approval workflows, this may not be enough time for an approving person to complete the SCA step on a pending payment, especially where users are dealing with forward-dated or bulk payments (both features we are releasing soon). Accordingly we have increased the timeout to 7 days to accommodate these use cases.

Block list of commonly encountered spam or throwaway email domains​

Working with accurate data and verifiable user-identities is essential to a well run embedded finance programme.

One problem that can face embedders, is end-users registering accounts with throwaway email domains. This could mean those users lose access to the email address, and is a common sign of invalid users, including potentially malicious sign ups.

Therefore we have implemented throughout our systems, a block list of commonly encountered temporary or spam email domains. We will validate all sign ups against this list and block any attempt to register with an email addresses from these domains.

Error 409 - "Email_Domain_Not_Allowed" - will be returned if an email domain on the list is used.

We review and maintain this block list regularly. However, please contact us if you feel sign ups are being blocked incorrectly.

Bulk Transactions​

There are often times that end customers want to work through a list or batch of payments, and doing this one by one can be rather slow and inefficient.We’re introducing a new Bulk Transactions feature which enables Embedders to present a new workflow to end customers where they can execute multiple payments under a single SCA approval. The individual payments will be automated and status of each, plus the overall Bulk Transaction, communicated via webhooks.Both OWTs and Sends can be used as the payment method in Bulk Transactions.

Bulk Transactions can also handle mixtures of GBP and EUR in the Payables, provided a Corporate has funding accounts in the right currencies.If all Payables in a Bulk Transaction list are to Payees previously registered in a Corporate Trusted Payees list then an SCA exemption can be applied, further reducing friction in business payments use cases.

Sender ID of SMS OTPs to Singaporean phone numbers (+65)​

We have updated the Sender ID of the SMS OTP for card transactions of cardholders with a Singapore mobile number (+65). This will now show as being originated by “Thredd”, and will ensure the SMS message is not blocked due to an unregistered Sender ID. This is as a result of a regulatory change in Singapore coming into effect on 31st July that requires all SMS Sender IDs to be registered.

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.