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

Inbound and Outbound 3rd Party UK Faster Payments​

We are pleased to announce that the UK Faster Payments payment method now supports 3rd party inbound and outbound domestic transfers for both Corporates and Consumers.

For GBP managed accounts connected to this service, you will receive a sort code and account number when upgrading the managed account. These details can be used for domestic payments in GBP. The payment reference that was previously required to make deposits will not be required when using this sort code and account number.

Please note: Managed accounts may be marked as inactive for a short period of time after opening, whilst the account details are assigned. Once assigned a webhook notification will be sent to you confirming that the account is now active. You should only initiate the upgrade account request once the account is marked active. Find more details on how to upgrade managed accounts in our guide.

If you would like to start using this payment method now, please contact us via the Support Portal so that we can enable it for you.

In due course all GBP managed accounts will be automatically upgraded.

Deposit Transactions - Additional Sender Information​

When depositing funds using the new UK Faster Payments payment method, the senderIban, senderName and senderReference fields will be included as part of the managed account deposit transaction.

All three fields are available when retrieving a managed account statement, as part of the entry.additionalFields, and when you are notified of a managed account deposit via the webhook. They are also displayed as part of the managed account activity within the portal.

These fields will be added to SEPA and SWIFT deposits soon.

Affected APIs:

• GET /managed_accounts/{id}/statement

Affected Webhooks:

• POST /managed_accounts/deposits/watch

Consumer place of birth - New Optional Field​

When onboarding a consumer identity you can optionally include the placeOfBirth field. If provided, this information is pre-filled for the user when they are submitting their information for KYC.

If the user hasn’t completed KYCm, you can also update the field via the Update Consumer API endpoint.

Affected APIs:

• POST /consumers
• PATCH /consumers

Physical Cards - New Optional second line for name on card​

The name on card for physical cards now supports 2 lines. You can optionally specify a second line via the nameOnCardLine2 field when upgrading a virtual card to a physical card. When provided, the second line will also be printed on the physical card itself.

Affected APIs:

• POST /managed)cards/{{id}/physical
• POST /managed_cards/assign

Spend Rule - Allowed merchant countries​

You can now specify an allowed or blocked list of countries from where the user can make purchases. The card purchase country is determined from the merchant's registration country.

The allowed and blocked lists can be configured in the card profile level via the Multi portal or per card in the Multi API.

Affected APIs:

• GET /managed_cards/{id}/spend_rules
• PUT /managed_cards/{id}/spend_rules

Spend Rule - Single card purchases​

You can now specify the minimum and / or maximum amount of a single card purchase via the Multi API.

Card purchases that are below the minimum amount or above the maximum amount will be automatically declined. This control can be configured per card.

Affected APIs:

• GET /managed_cards/{id}/spend_rules
• PUT /managed_cards/{id}/spend_rules

Card purchase simluator - forex configuration​

You can now simulate card purchases that include a forex fee and / or a forex padding via the Multi portal. This option has been added to the Purchase by Card ID and Purchase by Card Number simulators.

Authorisation webhook - additional forex information​

The forexPadding field is now available as part of the card authorisation webhook. This field is included when the purchase currency is different from the card's currency and therefore forex is required.

Affected webhooks:

• POST /managed_cards/authorisations/watch

Service status annoucements​

You can now view the status of our services and subscribe to receive service status updates. The same announcements are also visible in the Multi portal.

Card friendly names - Emojis Support​

Your customers can now include emojis in their card friendly names to further personalise their cards ✨

Updated the company registration number to optional​

You can now onboard sole traders who do not have a company registration number. The company.registrationNumber parameter can now be left empty.

Note, that for other company types, the registration number is still required to complete the KYB process.

Affected APIs:

• GET /corporates
• POST /corporates
• PATCH /corporates

New sender name information in the deposit webhook​

The account deposit webhook now includes new senderName field as part of the deposit information.

Affected webhooks:

• POST /managed_accounts/deposits/watch

New cancelled type for card authorisations​

Card authorisations are cancelled if an approve or reject decision is not received by the provider in the agreed time. This ensures that no authorisations are wrongly approved.

If a card authorisation is cancelled by the provider, you will receive a card authorisation webhook notification having the authorisationType field set as CANCELLED. Cancelled card authorisations are now included in the card statement API endpoint with their entry.transactionId.type being AUTHORISATION_CANCELLATION.

Affected webhooks:

• POST /managed_cards/authorisations/watch

Affected APIs:

• GET /managed_cards/{id}/statement

New Pending state for deposit, transfer and send transactions​

In most cases, transactions are executed instantly, however there are cases where a transaction needs to be temporarily paused. This may be due to different reasons, ranging from asynchronous processes to transaction monitoring.

If a deposit, transfer or send transaction is in a pending state, its transaction state will be marked as PENDING and will resume automatically as soon as all requirements are met.

Affected APIs:

• GET /transfers
• GET /transfers/{id}
• POST /transfers
• GET /sends
• GET /sends/{id}
• POST /sends

Additional transaction information in the managed account and managed card statement​

The following fields are now available in the the managed account and managed card statement:

• actualBalanceAfter
• actualBalanceAdjustment
• availableBalanceAfter
• availableBalanceAdjustment
• entryState

Instrument balances are represented using both an actual and an available balance. The actual balance shows how much funds actually reside on the instrument, while the available balance shows how much funds are available to be used. If there are no pending transactions on the instrument, the available and actual balance should be equal. Transaction entries returned in the statement APIs are reporting a balance change in one or both balances.

Note that the balanceAfter field is now deprecated in favor of the availableBalanceAfter.

The new transaction entryState field indicates whether a transaction has moved into a PENDING or COMPLETED state. When a transaction is in a PENDING state, this means that some fund movements have completed however additional fund movements are still pending. Once a transaction is moved to a COMPLETED state, this means that all expected fund movements are now complete.

Affected APIs:

• GET /managed_cards/{id}/statement
• GET /managed_accounts/{id}/statement

New check for mobile number​

The mobile number used by authorised users within the same corporate or consumer identity must be unique. If a mobile number is already being used by another user, the API will return an HTTP 409 - Conflict error with error code MOBILE_NOT_UNIQUE.

Detailed consumer due diligence status information​

You can now download the due diligence screening report of a consumer from the Multi Portal. In the report, you will find detailed information on the status of the due diligence process and any reasons for which the identity hasn't been approved yet.

This report will only be available if the identity has not completed due diligence.

New sender name field with deposit transactions​

In the deposit transaction details screen in the Multi portal, you can now see the sender of deposit transactions received on your customers' managed accounts.

More flexible end-customer send transaction fees​

Send transactions can transfer funds between cards and managed accounts. You can now charge a different fee, based on the source and destination instrument types involved in the transaction.

End-customer fees can be configured in the Multi portal.

More fine grained forex fee options​

When configuring your end-customer forex fees in the Multi portal, you can now choose from increments of 0.25%.

Please note that forex fees are attached to a card when it is being created, so if you change the fee afterwards, the new rate will only apply for newly created cards.

Additional due diligence failure details in webhooks​

A new rejectionComment field has been added in the consumer and corporate due diligence webhooks to include a detailed description as to why due diligence has been temporarily rejected. This information should be used together with the failureReason field to provide more information to the user.

Affected webhooks:

• POST /consumers/kyc/watch
• POST /corporates/kyb/watch
• POST /corporates/kyb/beneficiaries/watch

A fresh new look for our webhooks​

We have updated our webhook API documentation design style so that it is in line with the Multi API design style. Don't worry, nothing has changed with the webhooks themselves.

You can find the new webhook documentation here.

Corporate root user company position allowed values​

Corporate root users who are opening an account on behalf of a company must either be a director or an authorised representative of the company. This is already being checked as part of the corporate KYB process, however the rootUser.companyPosition will now start accepting only DIRECTOR or AUTHORISED_REPRESENTATIVE as valid values.

Affected APIs:

• POST multi/corporates
• GET multi/corporates

Corporate company type cannot be updated​

Different company types require different KYB processes and therefore the companyType field cannot be updated once a corporate identity is created. The companyType field will be removed from the update corporate API endpoint.

Affected APIs:

• PATCH multi/corporates

Removed redundant error code for already activated or deactivated users​

When activating an already activated user, the API will start returning an http 204 - No Content response instead of returning an http 409 - Conflict with error code USER_ALREADY_ACTIVATED.

Similarly, when deactivating an already deactivated user, the API will start returning an http 204 - No Content response instead of returning an http 409 - Conflict with error code USER_ALREADY_DEACTIVATED.

Affected APIs:

• POST multi/users/{user_id}/activate
• POST multi/users/{user_id}/deactivate

Added support for more Consumer occupations​

Additional occupation options have been added to consumer identities. Now you can enable your customers to choose STUDENT, UNEMPLOYED, RETIRED or OTHER as their occupation.

Affected APIs:

• GET multi/consumers
• POST multi/consumers
• PATCH multi/consumers