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

Change of SMS Sender ID from "Weavr" to "AUTHMSG"​

We have made improvements to the Sender ID of the SMS that is sent during 3DS verification. “Weavr” will no longer be shown in the SMS and the SenderID shown in several countries will be “AUTHMSG” which is a more generalised Sender ID.

Data Insights Dashboard 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 enhancing our dashboards by introducing the following functionality:

1. A new filter has been added across all dashboards (where applicable), which gives you the option to filter activity within the platform at ‘Programme Name’ level. This is especially beneficial in cases where a number of sub-programmes/applications are set up within your profile.

2. The detailed table within the Physical Cards Overview table has been updated to also include the 'Physical Delivery Tracking Number'.

Mobile Friendly Data Insights​

We’ve improved the data insights tab in the Innovator portal. You can now view and interact with the dashboards from your mobile device.

Resend invites to Directors and Representatives directly from the Innovator Portal​

You can now resend invites to Directors and Representatives to complete their KYC from the Innovator Portal. This is particularly useful if they missed the email or the link that was originally sent to them, has expired.

Note that you can only resend the invite if the director’s / representative’s KYC status is marked as Initiated.

Weavr Back-Office APIs​

The Weavr Back-Office API is a RESTful API that enables you to automate operations for your end-customers. The API includes a subset of the operations already offered in the Weavr Multi API that do not require your end-customer to be logged in.

In this release we will be adding the following operations to the API:

• Charge fee to a corporate
• Charge fee to a consumer
• Get a managed account's details
• Get a managed account statement
• Get a managed card statement
• Create/get a transfer transaction
• Un/block cards

Read the Back Office API guide to learn more on how to integrate and make use of the API.

New error code for KYC Level 1 nationality restrictions​

An additional conflict error code has been added when initiating KYC for a consumer for which the indicated KYC level is not sufficient.

KYC Level 1 is not allowed for individuals with a nationality outside of the EEA or UK. In this case the individual would need to be onboarded at a higher KYC level - a 409 error code KYC_LEVEL_NOT_ALLOWED will be returned in order to indicate this.

Affected API

• POST /consumers/kyc
• POST /consumers/kyc_mobile_sumsub

Physical Cards - Tracking Information​

We are enhancing the information provided in connection with physical cards. When upgrading a virtual managed card to be a physical card the deliveryTrackingMethod and deliveryTrackingCode information will now be visible within the Multi Portal; as part of the card additional information section. Additionally this information will also be available within the Multi and Backoffice GET APIs.

Please note: the deliveryTrackingCode information will be incude for delivery methods that support this (for example Registered Mail & First Class Mail). The tracking code will be included within 24 hours following card dispatch.

Affected APIs:

• GET multi/backoffice/managed_cards/{CARD_ID}
• GET multi/managed_cards/{CARD_ID}
• GET multi/managed_cards

Card Purchase - Decline Reasons Additional Detail​

Transaction data available within the Multi Portal and the Managed Card Statement (GET) have been expanded. Card purchase transactions will now include decline reasons and spend rule failure reasons.

This update provides data consistency across all three sources: Portal, Multi API & webhooks. ( spendRuleFailedReason is displayed as authRuleFailedReason within webhooks)

Affected APIs:

• GET managed_cards/{id}/statement

NameOnCard - Regex Alignment​

We have consolidated the supported characters for use within the NameOnCard field of Managed Cards.

Full regex list can be found HERE

SMS - Additional Validation Response​

An additional validation response will be introduced in connection with mobile SMS verification.

409 (conflict) - “MOBILE_COUNTRY_NOT_SUPPORTED” will be returned if the country is not supported for delivery of an SMS code.

Affected APIs:

• POST /consumer
• POST /corporate
• PATCH /consumer
• PATCH /corporate

SMS - Mobile Number - Update Limit​

A limit will be introduced on the number of times a consumer user can update their mobile number within a calendar year.

It will be possible to update a consumer users mobile number up to three times per calendar year. Requests beyond this will receive the below validation response:

409 (conflict) - “MOBILE_NO_CHANGE_LIMIT_EXCEEDED”

Affected APIs:

• PATCH /consumer

OWT information in the managed account statement​

The activity statement for managed accounts in the innovator portal now contains additional information for Outgoing Wire Transfers:

• Beneficiary name
• Beneficiary account
• Beneficiary bank code
• Reference/description

Most of the above information, apart from the description, was already available in the GET a managed account statement API; this has now been added as well. When retrieving a managed account statement, for records of transactionId.type = OUTGOING_WIRE_TRANSFER, we now share the payment ‘description’ (that was entered by the user when making the payment), under additionalFields = description

Affected APIs:

• GET /managed_accounts/{id}/statement

Strong Customer Authentication for Sends​

As part of our continued compliance with Strong Customer Authentication (SCA) requirements, two-factor authentication will be extended to also include Sends. This can be challenged using OTP via SMS. More authentication methods will be coming soon.

In the meantime we are planning to introduce some exemptions such as the low-value to reduce the number of the challenges required as allowed by the regulation. The exemption will work out of the box.

We will soon be reaching out directly and providing dedicated information to help you upgrade your integration and incorporate SCA processes in your product. In the meantime, you can have a look at our documentation here.

Spend Rules Optimisations​

Spend rules capabilities for both the Multi and Backoffice APIs will allow a more granular configuration & management. This new framework will provide improved efficiencies in rule configuration; in addition to API optimisations, and reduced impact from future rule changes/introductions.

The following information highlights the specific areas changing and what this will now provide:

Setting card level spend rules​

The PUT Spend Rules API endpoint will be deprecated in favour of 3 new 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 new create and update spend rules API endpoints, only the rules that you want to configure need to be provided. The rules that do not apply can be excluded. The delete spend rule API will remove all rules from the card specified.

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
• Profile level spend rules: These are the spend rules that are configured in the Multi portal > Settings > Managed Cards screen.
• Identity level spend rules: These are spend rules that are associated with the cardholder (owner of the card).

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

Innovator portal Spend Rules configuration screen​

An enhanced UI card details screen will be provided, allowing viability of all spend rules associated with a card; allocated by each of the three object groups.

Affected Multi APIs:

• /managed_cards/{id}/spend_rules

Affected Backoffice APIs:

• /managed_cards/{id}/spend_rules

Deposit Transaction Fee Incorporation​

As you are aware, it is possible to configure a fee for each deposit registered on a managed account - Managed Account Fees.

In order to maintain compliance with regulations, the way a deposit transaction value is reflected in the “GET a managed account statement” API response and “Account Deposit” webhook message, will be refined.

The transaction amount of the deposit will be inclusive of any applicable fee amount, representing the initial amount deposited (before fee collection).

The fee value itself will continue to be shared in the transactionFee field, and this content is not changing.

Example​

Current:

• A £100.00 deposit with a deposit fee of £2.00 shows as transactionAmount.amount = 9800 and transactionFee.amount = 200

After the change:

• A £100.00 deposit with a deposit fee of £2.00 will show as transactionAmount.amount = 10000 and transactionFee.amount = 200

Affected API:

• GET /managed_accounts/{id}/statement

Affected webhook:

• POST /managed_accounts/deposits/watch

Account & Card Activity Statement Refinement​

Currently two entries are returned on the activity statement screens for transactions such as deposits, original credit transactions, and the credit portion of a send. Display adjustments will differentiate these events and what they represent:

One record will represent the credit entry once the transaction is complete, with an amount in bold.

One record will represent the status of the transaction, with status either “Pending” or “Completed”, and an amount that is greyed-out.

Example deposit transaction:

Managed Account - PDF Statements​

A new option will be available when retrieving a Managed Account Statement. The additional format of pdf will be supported for statement download.

The statement includes settled transactions only, for the range that you request. Pending transactions and authorisations will not be included on the pdf statement, but will continue to be returned in the json and csv formats, as well as continue to be displayed on the innovator portal as normal.

This improvement provides functionality to meet a regulatory requirement of providing the Managed Account owner with a statement in a 'durable medium', and should be added to your client offering.

To receive the statement as a pdf, send application/pdf in the accept Header Parameter.

API affected:

• GET /managed_accounts/{id}/statement

Outgoing Wire Transfer (OWT) “Description” Validation​

The description field within the "Create an OWT" API can be used for a payment reference or message to accompany a payment. This field is optional, but when completed, is passed to the ultimate beneficiary.

The validation on this field has been updated to match bank-transfer standards, maintaining compliance with receiving-banks, and ensuring an entered description can be processed. The length of the message depends on the type of OWT being created:

• SEPA and SWIFT = <=35 characters
• Faster Payments = <=18 characters

API affected:

• POST /outgoing_wire_transfers

Manual Transactions - New Webhook​

A new webhook endpoint has been added, such that, In the event of a manual transaction adjustment occurring on an instrument, a webhook notification message will be automatically triggered that contains essential information on the action taken, ensuring systems remain in synch with Weavr.

The webhook message provides the ID, timestamp of the transaction, target instrument, as well as the relevant adjustment details, such as balance value.

Affected webhook:

• POST /manual_transactions/watch

Confirm Password UI Component​

To strengthen the validation on password input during user onboarding, a new UI component called “confirm password” will be introduced. This confirm password component validates again the existing “password” component to ensure an exact match.

Read our Confirm Password UI Component guide on how to make use of this new capability in your product.

Corporate KYB - UBO Additional Information Requirements​

As part of our ongoing improvements to compliance and due diligence processes, we have extended the information captured as part of UBO applications; where UBO business ownership is 25% or greater.

For each qualifying UBO, the following information will need to be provided:

• Place of Birth
• Official ID
• Email Address
• Address, including country of permanent residence

Capturing of this additional information will be required, per qualifying UBO application, as of 12th April 2022.

Annual Corporate KYB Refresh.​

As part of our ongoing improvements to compliance and due diligence processes, we have extended verification procedures; in connection with pre-existing corporate KYB information.

On an annual basis KYB information supplied will undergo additional verification. Information will be refreshed as part of this process, which will include corporate root users re-validating through the KYB process, and if necessary, for directors to provide updated KYC information.

Once a refresh has been initiated there are three indications:

• The corporate due diligence status will show a purple bar, stating KYB refreshing, on the Weavr portal.
• The corporate root user, and individual directors (if necessary), will receive an email advising the need to update due diligence information.
• A webhook event will be triggered that includes an additional “OngoingStatus” parameter, indicating the refresh progress.

Two additional email templates have been incorporated as part of the notification to root users and directors. Default branding is used for such templates, but these can be branded according to your corporate design. If you have not already provided input for branding in connection with these emails, and wish to update this, please contact us via our support portal https://support.weavr.io and our team will be able to provide assistance with your specific requirements.

Corporate & Consumer Charge Fee - Additional Transaction Details​

When using the charge fee API, additional transaction details will be included within the response payload, including the state and transaction ID, allowing the correlation of transaction and associating fee.

Affected APIs:

• POST /consumers/fees/charge
• POST /corporates/fees/charge

Password & Passcode UI Components - New Submit Events​

Password and Passcode UI components will support the use of enter key interactions for triggering events. Such events can be used instead of requiring users to click a button, allowing for smoother interactions and automatic form submissions.

For more information please refer to our Password UI component and Passcode UI component guides.

Prepaid Cards - Fund Transfers on Destroyed & Expired Cards​

When using the Transfer API, unloading of funds will be supported for prepaid cards in a destroyed or expired status. Such transfers must be to another managed account or managed card belonging to the same corporate or consumer identity.

Affected APIs:

• POST /transfers