Introducing SEPA transfers#

We are excited to announce the launch of SEPA transfers - for both Consumers and Corporates. You can now extend your product capabilities to enable your customers to both receive funds from 3rd parties, as well as send funds to 3rd party bank accounts in the SEPA region.

The “Outgoing Wire Transfers” API endpoints have been updated to include Strong Customer Authentication (SCA) regulatory requirements. If an outgoing wire transfer needs to be verified via SCA, the transaction’s state will be updated to PENDING_CHALLENGE.

When this occurs, you will need to initiate an SCA challenge with the logged in user using the multi/outgoing_wire_transfers/{id}/challenges/otp/{channel} API endpoint.

Please note that before users can verify outgoing wire transfers, they must have enrolled their mobile device for strong customer authentication.

Affected APIs:

• POST /multi/outgoing_wire_transfers
• POST /multi/outgoing_wire_transfers/{id}/challenges/otp/{channel}
• POST /multi/outgoing_wire_transfers/{id}/challenges/otp/{channel}/verify
• POST /multi/authentication_factors
• POST /multi/authentication_factors/otp/{channel}
• POST /multi/authentication_factors/otp/{channel}/verify

Deprecated APIs:

• POST /multi/corporates/verification/mobile/send
• POST /multi/corporates/verification/mobile/verify
• POST /multi/consumers/verification/mobile/send
• POST /multi/consumers/verification/mobile/verify

New optional mobile number field for authorised users#

You can now store the mobile number associated with a user. The mobile number is required if you are onboarding your users for strong customer authentication using one time passwords sent over SMS text messages.

Affected APIs:

• GET /multi/users
• POST /multi/users
• GET /multi/users/{user_id}
• PATCH /multi/users/{user_id}

Added support for more Corporate company types#

Different company types require different KYB processes to get approved. KYB flows have been added for PUBLIC_LIMITED_COMPANY, LIMITED_LIABILITY_PARTNERSHIP and NON_PROFIT_ORGANISATION. Now you can onboard these types of companies via the API.

Affected APIs:

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

Improved handling for locked user credentials#

User credentials can be temporarily locked due to consecutive failed login attempts. If a user credentials becomes locked, the login API endpoint will now start returning HTTP error code 403 - Locked.

Affected endpoint:

• POST /multi/login_with_password

New feature to reset the contactless limit of wearable physical cards#

From time to time, customers using wearable physical cards, are required to input their PIN to confirm point of sale transactions. To eliminate the need to have to input their PIN, they can reset the contactless limit associated with their wearable device.

You can enable your customers to reset their contactless limit for their wearable physical cards via a new API.

Affected APIs:

• POST /multi/managed_cards/{id}/physical/contactless_limit/reset

New optional date of birth field for users#

We added a new optional dateOfBirth field to authorised users and corporate root users. This field is only required if you are onboarding teenagers onto your product.

Affected endpoints are:

• POST /multi/users
• PATCH /multi/users/{id}
• GET /multi/users
• GET /multi/users/{id}
• POST /multi/corporates
• PATCH /multi/corporates/{id}
• GET /multi/corporates
• GET /multi/corporates{id}

Updated the validation for the source instrument of an outgoing wire transfer#

The sourceInstrument.id and sourceInstrument.type properties are new both required when submitting an outgoing wire transfer

Affected APIs:

• GET /multi/outgoing_wire_transfers
• GET /multi/outgoing_wire_transfers/{id}
• POST /multi/outgoing_wire_transfers

New error code when submitting an outgoing wire transfer with a destroyed source instrument#

The source instrument of an outgoing wire transfer must be active to execute the transaction. If the instrument is destroyed the API will return a 409 - Conflict error with error code SOURCE_INSTRUMENT_DESTROYED.

Affected APIs:

• POST /multi/outgoing_wire_transfers

New manufacturing status details for physical cards#

A new manufacturingState field has been added to the managedCard.physicalCardDetails object to improve traceability of the fulfillment of physical cards.

The following are the supported manufacturing statuses:

• REQUESTED: The physical card has been requested.
• SENT_FOR_FULFILLMENT: The card has been sent for printing.
• DISPATCHED: The card has been manufactured and dispatched.
• DELIVERED: The card has been received and activated by the recipient.

The following endpoints return the 'ManagedCard' in their response, and will now start including this optional detail in case of physical cards:

• GET /multi/managed_cards post
• GET /multi/managed_cards/{id}
• PATCH /multi/managed_cards/{id}
• POST /multi/managed_cards/assign
• POST /multi/managed_cards/{id}/physical
• POST /multi/managed_cards/{id}/physical/activate
• POST /multi/managed_cards/{id}/physical/replace_lost_stolen

You can also view the manufacturing state of a physical card in the Multi Portal by accessing the card’s detail screen.

Card spend limits can now be applied to a time interval#

You can now set spend limits for different time intervals to better control the usage of debit mode cards.

In addition to the ALWAYS interval, we have added the following intervals:

• DAILY: starting from 00:00:00 UTC of current day to 23:59:59 UTC of current day
• WEEKLY: 00:00:00 UTC Monday of current week to following Sunday 23:59:59 UTC
• MONTHLY: 1st of current calendar month to end of current calendar month
• QUARTERLY: starting from beginning of current quarter where quarters are defined as follows
  • 1 January 00:00:00 UTC to 31 March 23:59:59 UTC
  • 1 April 00:00:00 UTC to 30 Jun 23:59:59 UTC
  • 1 July 00:00:00 UTC to 30 September 23:59:59 UTC
  • 1 October 00:00:00 UTC to 31 December 23:59:59 UTC
• YEARLY: 1 January 00:00:00 UTC of current calendar year to 31 December 23:59:59 UTC of current calendar year

Affected APIs:

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

New required fields when creating a Consumer Identity#

When creating a consumer you will need to start providing the consumer’s date of birth and the main source of funds type for funds that will be deposited by the consumer via the parameters rootUser.dateOfBirth and sourceOfFunds.

This information is required to complete KYC for the customer and the API endpoint POST /consumers/_/create will return a 400 - Invalid Request error if either of the parameters is not provided.

Affected APIs:

• POST /multi/consumers

New errors codes when consuming a user invite#

Authorised users can be onboarded using an invitation process. To accept an invite, the user needs to set a valid password that will be used to login. If the provided password is invalid, the API will return a 409 - Conflict with error codes:

• PASSWORD_ALREADY_USED
• PASSWORD_TOO_SHORT
• PASSWORD_TOO_LONG
• PASSWORD_TOO_SIMPLE
• PASSWORD_KEY_ALREADY_IN_USE
• PASSWORD_ALREADY_CREATED

Affected APIs:

• POST /multi/users/{user_id}/invite/consume

New error code when transferring or sending funds#

The transfers and sends API will return a 409 - Conflict error with error code SOURCE_AND_DESTINATION_MUST_BE_DIFFERENT if the specified source and destination instruments are the same.

Affected APIs:

• POST /multi/transfers
• POST /multi/sends

New error codes when sending funds to other identities#

To send funds, both the source instrument as well as the destination instrument must be active. If one of the instruments is not active the sends API will return a 409 - Conflict error with error codes SOURCE_INSTRUMENT_DESTROYED or DESTINATION_INSTRUMENT_DESTROYED.

Affected APIs:

• POST /multi/sends

New error code when deleting a managed account#

Managed accounts which have debit mode cards linked to them, cannot be deleted. The API will return a 409 - Conflict error with error code INSTRUMENT_HAS_LINKED_CARDS if the managed account being deleted has cards linked to it.

Affected APIs:

• POST /multi/managed_accounts/{id}/remove

New error codes when transferring funds#

To transfer funds, both the source instrument as well as the destination instrument must be active. If one of the instruments is not active the transfers API will return a 409 - Conflict error with error codes SOURCE_INSTRUMENT_DESTROYED or DESTINATION_INSTRUMENT_DESTROYED.

Affected APIs:

• POST /multi/transfers