SEPA Credit Transfers (SCT)

SEPA Credit Transfers (SCT) allow the initiator of the transfer (sender) to make Euro-denominated payments to SEPA countries accounts.

At Treezor, SCT can be used in two directions:

• SCTR are Received into a Wallet and mapped to Payin objects
• SCTE are Emitted from a Wallet and mapped to Payout objects

Received Credit Transfers (SCTR)

When an SCTR is received, a Payin object is created, along with a payin.create webhook.

Treezor receives batches of SCTR from other banks every worked day between 6:30 and 19:00 Paris local time. They are handled and Wallets are credited as they are received.

Tip – In addition to your usual IBAN, you can provide Virtual IBANs to receive SCTR

Virtual IBANs have many benefits over your main IBAN (restriction in the direction they can be used, restriction in validity period, easier funds movements categorization, etc.).

Structure of an SCTR Payin

Caution – UserId initial value in Production

In Production environment, all SCTR are initially received with userId attribute valued to 3. It is strictly forbidden to use this value, this is a technical user for Treezor use only.

Rejection of an SCTR

Immediate rejection

An SCTR can be immediately rejected for multiple reasons.

In this case, a sepa.return_sctr webhook is sent with the reason code provided in the return_reason_code attribute.

Delayed rejection

Treezor enforces AML/CFT checks before validating an SCTR.

When a supicious SCTR is encountered, the SCTR funds are frozen and Treezor sends you:

• A payinrefund.create webhook with reasonTms attribute set to null and payinrefundStatus attribute set to PENDING (which freezes the funds).
• A payinrefund.update webhook with reasonTms attribute populated by an explaination.

Upon further inspection by Treezor, the following occurs depending on whether or not the anomaly is confirmed:

• No anomaly – A payinrefund.cancel webhook is sent (the wallet can be credited by the SCTR).
• Anomaly confirmed – A payinrefund.update webhook is sent, with a VALIDATED payinrefundStatus (which refunds the SCTR).

Information – AML/CFT inspection by Treezor can last up to 48h

Therefore, an SCTR can be delayed by up to 48 hours.

Emitted Credit Transfers (SCTE)

Treezor allows to send funds from wallets to external accounts using SCTE.

Requirements

• The sender's Wallet must be valid and not frozen
• The sender's User must be valid
• You have the IBAN of the recipient
• You have created an active Beneficiary using this IBAN

Although SCTE can be created an any time, they will only take place on a SEPA Open Banking Day.

Parameters

Attribute	Type	Description
walletId	integer	The unique identifier of the debited Wallet.
beneficiaryId	integer	The unique identifier of the Beneficiary of the Transfer. You must have created the Beneficiary object beforehand.
amount	float	The amount of the credit transfer.
currency	string	The currency of the credit transfer. Must be EUR.

Here is an example of {payload}:

Returns the Payout object, with its payoutStatus set to PENDING at first. You will then receive sequentially the following webhooks.

Webhook	When	Specific attributes
payout.update	When the SCTE is sent to the SEPA network.	PENDING status and 160014 codeStatus
payout.update	When the SCTE is delivered to the recipient.	VALIDATED status

Processing

Emitted SEPA Credit Transfers (SCTE) are executed the next worked day when requested before the cutoff point (10AM).

When exceeding €10,000 or deemed of interest are subject to additional controls, during which Treezor can ask you to provide:

• An invoice, bill, contract, or similar document.
• A RIB of the creditor, edited by the creditor's bank.

Treezor is entitled to refuse an SCTE when the aforementioned requirements are not met, or upon suspicion of fraudulent activity.

Rejection of an SCTE

A beneficiary's bank can reject an SCTE for multiple reasons.

In this situation a payoutrefund.create webhook is sent, with the reasonCode for the rejection provided.

Recalling an SCTE

To recall an SCTE, please check out the dedicated article.

Mass SCTE (Mass Payout)

Alert – This feature is not available yet

If you're interested in mass payouts, please contact your Treezor Account Manager for more information.

Information – Feature limitations

• Currently a single Wallet can be debited per Mass Payout but many Beneficiaries can be credited. Attempts to debit multiple Wallets will be ignored.
• The Mass SCTE feature is incompatible with the Encryption feature.

The Mass Payout feature allows you to request several SEPA Credit Transfer emissions at once, using an XML file following the PAIN001.001.03 ISO 20022 (opens new window) standard.

This file contains an array of objects, each object specifying a debtor's IBAN, a creditor's IBAN and an amount.

The main use case is to handle exports from payroll and accounting software.

Tip – Both machine-to-machine and end user usage is possible

• When requested by end user, only the end user's wallets can be debited.
• When requested by machine-to-machine, only Wallets that you manage can be debited.

Upload

First, you upload the file using the following request.

To check that your file conforms to the PAIN001.001.03 standard, you can use the associated XSD schema. The file size is limited to 10Mo.

Treezor immediately checks for integrity and ISO compliance. If the file complies to the expected format, the following object is returned.

The importId, provided as UUIDv4, allows you to check on the import's status later on.

Processing

Treezor process your file within a few hours after the upload. Therefore, if you need your mass payout processed before the cutoff time, you must to anticipate this delay.

For each of the SCTE contained within the file, Treezor attempts to create a distinct SCTE.

If the associated Beneficiary doesn't already exist, it is automatically created. If it already exists but its usableForSct is false, the Beneficiary will be updated to usableForSct=true.

• If the payout can be created, your receive a payout.create webhook
• If the payout can't be created, an error is logged and can be retrieved at a later stage

For each created SCTE, its label indicates the following: CreditTransferTransactionInformation (<CdtTrfTxInf>) → RemittanceInformation (<RmtInf>) → Unstructured (<Ustrd>)

→ symbolize a children XML node.

In addition to usual Payout failure reasons, the following Mass Payout-specific reasons can be returned:

• The debtor wallet was not found
• The debtor wallet status is not VALIDATED
• The beneficiary can not be created
• The payout has already been executed This reflects an internal error on your side
• The payout can not be created and max retry has been reached This reflects an internal error on our side

Checking the status

List of available status values.

Status	Description
PENDING	When the file has been uploaded
COMPUTING	When checking the debtor and creditor
COMPUTING_WITH_ERROR	When checking the debor and creditor, with at least one error
COMPLETED Final	When everything is successful
COMPLETED_WITH_ERROR Final	When an error occured while checking the debtor or one of the creditors

To check the status of a previously created Mass Payout, you can use the following request:

Returns either the following object with the url attribute populated upon complete processing of the Mass Payout, providing you with an URL to download a CSV file.

Or the following object in case of a global error, preventing Treezor from parsing the uploaded file.

Global errors can be:

Error	Context
The debtor's wallet with IBAN file:IBAN does not exist.	When we are not able to identify the Wallet from the provided IBAN
Unknown debtor with IBAN:file:IBAN. All linked creditors were skipped	When the Wallet doesn't not belong to the currently authenticated User
Debtor with IBAN:file:IBAN has a CANCELED wallet. All linked creditors were skipped	When the Wallet is in an CANCELED state

Report

Errors contained in the report are comprised of CreditTransferTransactionInformation (<CdtTrfTxInf>) → PaymentIdentification (<PmtId>) → EndToEndIdentification (<EndToEndId>)

Successful

The following illustrates a report without errors.

With errors

The following illustrates a report with an error on the second creditor due to insufficient funds on the debited Wallet.