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.

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 paranthesis))
• ")" (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.

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

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

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.

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

Updates to the Consumer due diligence process​

An additional step is being introduced to the Consumer KYC process flow, whereby individuals are now required to provide additional details. Details collected vary depending on the KYC level chosen.

The occupation and sourceOfFunds information that is currently collected via the Create Consumer API will be included in this new step for the individuals to fill in directly. The occupation and sourceOfFunds fields in the Create Consumer API are being deprecated and thus you do not need to request this information during your registration process.

The APIs effected are as follows:

• Post /multi/consumers

• Get /multi/consumers

• Patch /multi/consumers

• • rootUser.occupation, and sourceOfFunds and sourceOfFundsOther have been deprecated.
• • 409 SOURCE_OF_FUNDS_OTHER_MISSING has been removed.

• Post /multi/consumers/kyc

• • 409 SOURCE_OF_FUNDS_OTHER_MISSING has been removed

SEPA Instant wire transfers​

Wire transfers made within the European SEPA network will now use SEPA Instant Credit Transfer (SCT Inst – hereafter “SEPA Instant”) if the receiving bank supports this payment method.

Here are some more details:

• Outbound wire transfers up to €15k will automatically be routed via SEPA Instant, subject to an automatic check that the receiving bank/FI supports it.

• In cases where the receiving bank/FI does not support SEPA Instant, the payment will automatically fall back to normal SEPA and continue successfully, all else being correct.

• SEPA Instant provides payment rails that are available 24/7 and 365 days per year.

• Existing features and procedures of SEPA payments remain the same (such as EUR currency, SCA two-factor authentication requirement).

There are no additional charges for our customers to use SEPA Instant compared to the previous standard SEPA wire transfer fees. Enjoy!

View SCA enrolments and challenge history in the Innovator Portal​

You can now view the SCA enrolment status of your Corporate and Consumer users, 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.

Duplicated OWTs in statement​

This change addresses a bug where OWTs appeared to be duplicated on the Managed Account Activity Statement in the portal.

The purpose of the two entries has now been made clear. One record shows the status of transaction, and the other record indicates when the debit entry has been made, reducing the account’s actual balance.

Example of how an OWT is shown at various stages:

OWT submitted and being processed:

OWT completed (funds sent from source instrument):

Data Insights Managed Outgoing Transfers dashboard enhancement​

Data Insights offers you the possibility to analyse your outgoing wire transfers via the Managed Accounts Outgoing Transfer dashboard. We have now enhanced the dashboard by including transfer type details to be able to distinguish between the different transfer types at transaction level.

Updates to the charge fees and access token back-office APIs​

A new /fees/charge endpoint has been added to the back-office API that replaces both the consumer and corporate charge fee endpoints.

A new /access_token endpoint has been added to the back-office API that replaces the /impersonate_identity_login.

Please note that the following back-office APIs have been marked as deprecated:

• corporates/fees/charge

• consumers/fees/charge

• impersonate_identity_login