Skip to main content

· 3 min read

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

· One min read

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.

· 2 min read

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.

· One min read

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

· One min read

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

· 2 min read

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

· One min read

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

· One min read

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

· One min read

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}

· One min read

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

The 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