# Scheduled Transfers

## Introduction

Scheduled Transfers enable seamless integration of future-dated payment functionality into your application. It supports both recurring and one-off payments with full control over scheduling and execution. The feature is compatible with SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst), offering flexibility to accommodate a wide range of payment scenarios.

This API replaces the previous [`Standing Orders`](/guides/digital-banking/sepa-transfers/standing-orders/) and [`Timed Orders`](/guides/digital-banking/sepa-transfers/timed-orders/) functionality, expanding capabilities to cover a broader range of scheduled payment scenarios with improved control and reliability. See the overview page to learn more about SEPA and the different types of SEPA payment schemes.

## Prerequisites:

You must implement the following features in order to use scheduled transfers in your solution:

- [Device binding](/guides/authentication/device-binding/)
- [Strong Customer Authentication](/guides/authentication/strong-customer-authentication/)
- [Verification of a Payee](/guides/digital-banking/sepa-transfers/verification-of-payee/#verification-of-payee)
- [SEPA Credit Transfers](/guides/digital-banking/sepa-transfers/sepa-credit-transfer/)
- [SEPA Instant Credit Transfers](/guides/digital-banking/sepa-transfers/sepa-instant-credit-transfer/)


## How It Works

A Scheduled Transfer functions similarly to a standard SEPA Credit Transfer (SCT) or SEPA Instant Credit Transfer (SCT Instant), depending on the selected transfer type. You should allow end users to choose between SCT and SCT Instant when configuring a scheduled transfer. Due to regulatory requirements, offering only SCT is not permitted. You must support SCT Instant as well.

Before a transfer can be scheduled, the customer must complete the [`Verification of Payee (VoP)`](/guides/digital-banking/sepa-transfers/verification-of-payee/#verification-of-payee) process to confirm the recipient's account details. Once verified, the frontend should guide the user through setting up the transfer, which initiates a change request. The customer then authorizes the request using either SMS OTP or a device signing challenge.

### Process Overview:

1. The customer logs into their account and initiates a scheduled transfer. As part of this process, they provide the recipient's name and IBAN, which triggers the VoP check.
2. The customer selects the transfer type (SCT or SCT Inst) and inputs relevant details such as:
  - Amount
  - Execution schedule (e.g., recurring or one-off)
  - Execution date
  - Verification of Payee ID
3. The customer authorizes the scheduled transfer using two-factor authentication (2FA) via SMS One-Time Password (OTP), or Device signing challenge
4. Before each scheduled execution, Solaris performs a real-time account check, including:
  - Validation of `available_balance`
  - Account status (must be `ACTIVE`)
5. If validations pass, Solaris executes the transfer. The transaction is booked on the customer’s account with one of the following booking types based on previous chosen method: `SEPA_CREDIT_TRANSFER` or `SEPAInstantCreditTransfer`


Schedule transfers have the same transaction type and booking type as a standard SCT and SCT Instant, which is `SEPA_CREDIT_TRANSFER` or `SEPAInstantCreditTransfer` respectively.

## Execution Rules for Scheduled Transfers

### One time scheduled transfers:

- The execution_schedule is set to `ONE-TIME`.
- For one-off transfers, `active_from` is the single execution date.
- The `active_to` property is not required.
- The transfer status changes from `ACTIVE` to `CONCLUDED` immediately after execution.


### Recurring scheduled transfers:

- The execution_schedule is set to "WEEKLY" , "EVERY_TWO_WEEKS" , "MONTHLY" , "QUARTERLY" , "EVERY_SIX_MONTHS" or "ANNUALLY" .
- A scheduled transfer is executed on the date defined in the `active_from` field.
- For recurring transfers, the transfer is executed on the last day of each recurrence interval, starting from `active_from`.
- When creating a recurring transfer, the customer can set an `active_to` date to specify when it should stop. Based on this `active_to` date,the scheduled transfer transitions from `ACTIVE` to `CONCLUDED`.


### Execution failures:

In the event of a scheduled transfer execution failure:

- No booking will be recorded on the customer’s account.
- For regular SEPA Credit Transfers (SCT), the transfer status will be set to `declined`, and the `SEPA_CREDIT_TRANSACTION_DECLINED` webhook will be issued.
- For instant SEPA Credit Transfers (SCT Inst), the transfer status will be set to `FAILED`, accompanied by the `INSTANT_SEPA_CREDIT_TRANSFER_FAILED` webhook.
- Failed scheduled transfers will not be retried; the schedule will continue with the next execution as specified in the execution schedule.
- For transfers designated as `ONE-TIME` , a failure will immediately result in the scheduled transfer status being updated to `CONCLUDED`, with no further retry attempts.


A scheduled transfer may fail for various reasons. Depending on whether the transfer is a regular or instant SEPA Credit Transfer, the appropriate webhook will be sent. The specific reason for failure will be detailed in the failure_reason property.

Typical causes of transfer decline include:

- The target account is blocked, preventing transactions.
- The source account is blocked, preventing transactions.
- Insufficient funds to complete the transfer.
- The target account is closed.
- The source account is closed.


## Cancellation of Scheduled Transfers:

Customers can cancel their previously set scheduled transfers at any time. Currently, modifying an existing scheduled transfer is not supported. To make changes, customers must cancel the existing transfer and create a new one.
In rare cases, Solaris may also cancel scheduled transfers, such as during account closure or upon a customer support request. Such cancellations are handled manually by Solaris Customer support teams. Please use the [PATCH Cancel a Scheduled Transfer](/api-reference/digital-banking/sepa-transfers/#tag/Scheduled-Transfers/paths/~1v1~1accounts~1%7Baccount_id%7D~1scheduled_transfers~1%7Bid%7D~1cancel/patch) API endpoint to enable your customer to cancel a scheduled transfer.

## Scheduled Transfer Statuses

The scheduled transfer can have different statuses:

`AUTHORIZATION_REQUIRED` : When the creation of the scheduled transfer was triggered, but it has not yet been approved by using two-factor authentication (2FA) via an SMS OTP or a device signing challenge.

`ACTIVE` : When the scheduled transfer was created after the change request process and is now actively running.

`CONCLUDED` : When the scheduled transfer reaches it's last execution date as defined in the `active_to` property for recurring transfers. In case of a `ONE-TIME` scheduled transfer, the status changes once it's executed on the `active_from` date.

`CANCELED` : When the scheduled transfer is canceled.

Solaris will send a [`SCHEDULE_TRANSFER_STATUS_CHANGED`](/api-reference/onboarding/webhooks/#tag/Webhook-events/paths/scheduled_transfer_status_changed/post) webhook when the status of the scheduled transfer is changed to ACTIVE, CONCLUDED and CANCELED.

## Related webhooks:

Solaris recommends subscribing to the following webhook events, to better automate your processes. For detailed instructions on implementing Solaris webhooks, check the webhooks documentation.

`SCHEDULE_TRANSFER_STATUS_CHANGED` : When the status of the scheduled transfer is changed to ACTIVE, CONCLUDED and CANCELED.

`SEPA_CREDIT_TRANSACTION_DECLINED`  : When the execution of the scheduled transfer with a transfer type SCT fails, you'll receive this webhook specifying the schedule transfer id in the `schedule_id` property and the reason of the failure in the `rejection_reason` property.

`INSTANT_SEPA_CREDIT_TRANSFER_FAILED` : When the execution of the scheduled transfer with a transfer type `SCT_INSTANT` fails, you'll receive this webhook specifying the schedule transfer id in the `schedule_id` property and the reason of the failure in the "rejection_reason" property.

`INSTANT_SEPA_CREDIT_TRANSFER_EXECUTED` : Only sent when the scheduled transfer with a transfer type `SCT_INSTANT` was executed successfully. The webhook will also specify which schedule transfer was successfully executed by providing the `schedule_id` property.

`BOOKING` : Whenever the execution of the scheduled transfer, irrespectively to the transfer type, was successful and created a booking.

## API reference documentation:

To implement scheduled transfers, integrate the following endpoints in your solution:

- [POST Create a Scheduled Transfer](/api-reference/digital-banking/sepa-transfers/#tag/Scheduled-Transfers/paths/~1v1~1accounts~1%7Baccount_id%7D~1scheduled_transfers/post)
- [PATCH Cancel a Scheduled Transfer](/api-reference/digital-banking/sepa-transfers/#tag/Scheduled-Transfers/paths/~1v1~1accounts~1%7Baccount_id%7D~1scheduled_transfers~1%7Bid%7D~1cancel/patch)
- [GET Get scheduled transfers for an account](/api-reference/digital-banking/sepa-transfers/#tag/Scheduled-Transfers/paths/~1v1~1accounts~1%7Baccount_id%7D~1scheduled_transfers/get)
- [GET Get a single Scheduled Transfer](/api-reference/digital-banking/sepa-transfers/#tag/Scheduled-Transfers/paths/~1v1~1accounts~1%7Baccount_id%7D~1scheduled_transfers~1%7Bid%7D/get)