Administrative Seizures (SATD)

Introduction

A Saisie Administrative à Tiers Détenteur (SATD) is a French administrative seizure procedure through which the tax administration may require a financial institution holding funds on behalf of a debtor to seize and, where applicable, transfer those funds to the Public Treasury.

Because the payment accounts opened for end users are held in Xpollens' books, Xpollens is the third-party holder (tiers détenteur) and the legal recipient of SATDs issued by the French tax administration (DGFIP).

In this guide, the term debtor refers to the Partner's end user/customer targeted by the SATD.

Xpollens is therefore responsible for the regulatory processing of the seizure, including:

• identifying the debtor and the relevant account(s);
• determining the amount that can be seized;
• reserving the available seizable funds;
• managing the applicable legal holding period;
• processing any total or partial release (mainlevée);
• transferring seized funds to the Public Treasury when the seizure reaches maturity;
• exchanging the required information with the DGFIP.

The Partner is not the legal recipient of the SATD and does not perform the administrative processing with the DGFIP.

However, the Partner is notified of the events that affect its end users and their accounts so that it can:

• inform the end user when required;
• understand balance movements resulting from the seizure;
• reconcile seizure and release operations;
• reconcile applicable processing fees according to the contractual pricing agreement.

The SATD lifecycle is managed by Xpollens and exposed to the Partner through callbacks.

1. SATD overview

A SATD may concern, for example:

• taxes;
• fines;
• public-sector debts.

When a SATD concerns a Partner end user holding one or several Xpollens accounts, Xpollens identifies the relevant debtor and determines the amount that can legally be seized.

For individual debtors, applicable legal protections are taken into account, including the non-seizable bank balance (Solde Bancaire Insaisissable – SBI).

The exchanges between Xpollens and the DGFIP are handled directly by Xpollens and do not require any operational action from the Partner.

2. Partner-visible SATD lifecycle

The main SATD statuses relevant to the Partner are:

Processing states used before a SATD is successfully associated with a debtor are outside the scope of this Partner integration guide.

Workflow

stateDiagram-v2
    [*] --> Matched : SATD matched with a debtor

    Matched --> InProgress : Seizure processing starts
    Matched --> Finalized : Case closed without execution
    Matched --> Canceled : SATD canceled

    InProgress --> InProgress : Partial or total release<br/>Seized amount updated
    InProgress --> Finalized : SATD executed at maturity
    InProgress --> Canceled : SATD canceled

    Finalized --> [*]
    Canceled --> [*]

Typical lifecycle

1. Xpollens receives the SATD from the DGFIP.
2. Xpollens associates the SATD with the relevant debtor.
3. The Partner receives a SeizureCreatedOrUpdated callback with status Matched.
4. Xpollens determines the amount that can be seized from the debtor's account(s).
5. If funds are seized, one or several account movements are generated.
6. Each account movement is notified through an InternalTransfer callback.
7. The SATD becomes InProgress, and an updated SeizureCreatedOrUpdated callback contains the current seizedAmount.
8. During the legal holding period, the DGFIP may issue a total or partial release.
9. If funds are released, the corresponding amount is credited back to the impacted debtor account(s), generating new InternalTransfer callback(s), followed by an updated SeizureCreatedOrUpdated callback.
10. If the seizure reaches maturity without a release preventing execution, the seized funds are transferred to the Public Treasury and the SATD becomes Finalized.

3. Seizure processing

3.1 Debtor identification

When a SATD is received, Xpollens identifies whether the debtor corresponds to one of the Partner's end users and determines the related account(s).

Once the SATD has been associated with the debtor, the Partner is notified through:

SeizureCreatedOrUpdated

with:

status = Matched

The appUserId included in the callback identifies the affected debtor in the Partner integration.

Example:

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "seizureId": "02ac534c-f08f-4854-abd8-112f2d8cd0dd",
    "status": "Matched",
    "appUserId": "rx193bo32"
  }
}

The callback may contain additional SATD information. See SeizureCreatedOrUpdated callback.

3.2 Determination of seizable funds

Xpollens determines the amount that can be seized, taking into account:

• the amount requested in the SATD;
• the balances available on the debtor's account(s);
• applicable regulatory protections, including the SBI when relevant.

The amount effectively reserved is exposed to the Partner as:

seizedAmount

The seized amount can therefore be lower than the total amount requested by the DGFIP.

3.3 Seizable funds greater than zero

When funds are available for seizure, Xpollens reserves the applicable amount.

If the debtor has several impacted accounts, the seizure may result in several account movements.

For each movement, the Partner receives an:

InternalTransfer

callback.

The movement is a debit from the debtor's account toward the account used by Xpollens to hold the seized funds during the legal holding period.

Conceptually:

Debtor account
      |
      | Internal Transfer
      v
Seized funds holding account

The seizure operation is corrective:

isCorrective = true

The account statement label is based on:

Saisie administrative + <order number>

After the seizure movements have been processed, the Partner receives an updated:

SeizureCreatedOrUpdated

callback with:

status = InProgress

and the amount effectively seized.

Example:

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "seizureId": "02ac534c-f08f-4854-abd8-112f2d8cd0dd",
    "status": "InProgress",
    "amount": {
      "value": "1500.00",
      "currency": "EUR"
    },
    "seizedAmount": {
      "value": "1000.00",
      "currency": "EUR"
    },
    "appUserId": "rx193bo32"
  }
}

3.4 Multiple accounts

A single SATD may affect several accounts belonging to the same debtor.

In this situation:

• Xpollens determines the amount to seize on each impacted account;
• each account movement generates its own InternalTransfer callback;
• all seizure-related operations remain associated with the same SATD;
• the operations array of SeizureCreatedOrUpdated can contain several related operations.

The Partner must therefore not assume that one SATD corresponds to one account movement.

Example:

SATD
 |
 +-- Account A -> InternalTransfer #1
 |
 +-- Account B -> InternalTransfer #2
 |
 +-- Account C -> InternalTransfer #3

3.5 No seizable funds

A SATD can remain active even when no funds can currently be seized.

In this case, the Partner receives:

status = InProgress
seizedAmount = 0.00 EUR

Example:

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "seizureId": "02ac534c-f08f-4854-abd8-112f2d8cd0dd",
    "status": "InProgress",
    "seizedAmount": {
      "value": "0.00",
      "currency": "EUR"
    },
    "appUserId": "rx193bo32"
  }
}

At maturity, the SATD is closed and a new SeizureCreatedOrUpdated callback is sent with:

status = Finalized

and:

seizedAmount = 0.00 EUR

4. Legal holding period and execution

Once funds have been seized, they remain reserved during the applicable legal period.

During this period:

• the funds are no longer available to the debtor;
• they have not yet been transferred to the Public Treasury;
• a release may still modify the amount held.

According to the SATD processing workflow, execution occurs at J+30 from the matching of the SATD.

At maturity, if the seizure is still executable:

1. Xpollens transfers the seized funds to the Public Treasury.
2. The SATD is closed.
3. The Partner receives an updated SeizureCreatedOrUpdated callback with:

status = Finalized

Example:

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "seizureId": "02ac534c-f08f-4854-abd8-112f2d8cd0dd",
    "status": "Finalized",
    "seizedAmount": {
      "value": "1000.00",
      "currency": "EUR"
    },
    "appUserId": "rx193bo32"
  }
}

No Partner API call is required to execute the seizure.

5. SATD release (mainlevée)

A release (mainlevée) is an administrative decision that reduces or releases the funds previously seized.

A release may be:

• partial: only part of the seized amount is released;
• total: the full amount held is released.

A release is received and processed directly by Xpollens.

The Partner does not need to call an API to initiate the release.

5.1 Release of funds

When funds are released, Xpollens credits the corresponding amount back to the impacted debtor account(s).

For each account movement, the Partner receives an:

InternalTransfer

callback.

Conceptually:

Seized funds holding account
      |
      | Internal Transfer
      v
Debtor account

The release movement is corrective:

isCorrective = true

The account statement label is based on:

Annulation saisie administrative + <order number>

The release can concern one or several debtor accounts.

5.2 Updating the seized amount

After a partial or total release, the Partner receives an updated:

SeizureCreatedOrUpdated

callback containing the new seizedAmount.

Example after a partial release:

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "seizureId": "02ac534c-f08f-4854-abd8-112f2d8cd0dd",
    "status": "InProgress",
    "seizedAmount": {
      "value": "400.00",
      "currency": "EUR"
    },
    "appUserId": "rx193bo32"
  }
}

The exact terminal lifecycle following a total release is intentionally not detailed in this guide. Partners should rely on subsequent SeizureCreatedOrUpdated callbacks for the current SATD status.

6. End-to-end sequence

sequenceDiagram
    autonumber

    actor DGFIP as DGFIP
    participant Xpollens as Xpollens
    participant Partner as Partner

    DGFIP->>Xpollens: SATD notification
    Xpollens->>Xpollens: Associate SATD with debtor
    Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>status = Matched

    alt Case closed without seizure
        Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>status = Finalized

    else Seizable funds > 0
        loop For each impacted account
            Xpollens->>Xpollens: Reserve seizable funds
            Xpollens-->>Partner: InternalTransfer<br/>Debtor account -> seized funds holding account<br/>isCorrective = true
        end

        Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>status = InProgress<br/>seizedAmount = current amount

        alt Partial or total release received
            DGFIP->>Xpollens: Release notification

            loop For each impacted account
                Xpollens->>Xpollens: Release all or part of seized funds
                Xpollens-->>Partner: InternalTransfer<br/>Seized funds holding account -> debtor account<br/>isCorrective = true
            end

            Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>seizedAmount = updated amount

        else Seizure reaches maturity
            Xpollens->>Xpollens: Transfer seized funds to Public Treasury at J+30
            Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>status = Finalized
        end

    else Seizable funds = 0
        Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>status = InProgress<br/>seizedAmount = 0.00 EUR
        Xpollens->>Xpollens: Close SATD at maturity
        Xpollens-->>Partner: SeizureCreatedOrUpdated<br/>status = Finalized<br/>seizedAmount = 0.00 EUR
    end

7. SeizureCreatedOrUpdated callback

The SeizureCreatedOrUpdated callback is sent when a seizure is created or updated.

For the Partner, it is the main event used to follow the SATD lifecycle and the current amount seized.

7.1 Callback envelope

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "...": "..."
  }
}

7.2 Main fields

7.3 operations fields

Each entry of data.operations can contain:

7.4 Example

{
  "type": "SeizureCreatedOrUpdated",
  "data": {
    "seizureId": "02ac534c-f08f-4854-abd8-112f2d8cd0dd",
    "status": "InProgress",
    "accountOfficeLabel": "Paris Office",
    "officeNumber": "123456",
    "orderNumber": "ORD-123456",
    "noticeDate": "2026-08-12",
    "amount": {
      "value": "1500.00",
      "currency": "EUR"
    },
    "seizedAmount": {
      "value": "1000.00",
      "currency": "EUR"
    },
    "appUserId": "rx193bo32",
    "operations": [
      {
        "operationType": "TRANSFER",
        "operationId": "demoOperationId",
        "operationLabel": "Saisie administrative ORD-123456",
        "accountId": "rx193bo32",
        "amount": {
          "value": "1000.00",
          "currency": "EUR"
        },
        "direction": "Debit",
        "operationDate": "2026-08-12T10:30:00.000Z"
      }
    ]
  }
}

8. InternalTransfer callback

An InternalTransfer callback is sent for an Internal Transfer operation affecting an account.

In the SATD context, it is used by the Partner to identify and reconcile the movements generated by:

• the seizure of funds;
• a partial release;
• a total release.

8.1 Main fields

For SATD-generated seizure and release movements:

isCorrective = true

8.2 Seizure movement

Conceptually:

sender.accountId    = debtor account
recipient.accountId = seized funds holding account

Typical statement label:

Saisie administrative + <order number>

Example structure:

{
  "type": "InternalTransfer",
  "internalTransferId": "P2P_example",
  "creationDate": "2026-08-12T10:30:00.000Z",
  "status": "Completed",
  "amount": {
    "value": "500.00",
    "currency": "EUR"
  },
  "sender": {
    "accountId": "<DEBTOR_ACCOUNT_ID>"
  },
  "recipient": {
    "accountId": "<SEIZED_FUNDS_ACCOUNT_ID>"
  },
  "extraDatas": {
    "label1": "Saisie administrative ORD-123456"
  },
  "isCorrective": true
}

8.3 Release movement

Conceptually:

sender.accountId    = seized funds holding account
recipient.accountId = debtor account

Typical statement label:

Annulation saisie administrative + <order number>

Example structure:

{
  "type": "InternalTransfer",
  "internalTransferId": "P2P_example_release",
  "creationDate": "2026-08-20T09:15:00.000Z",
  "status": "Completed",
  "amount": {
    "value": "200.00",
    "currency": "EUR"
  },
  "sender": {
    "accountId": "<SEIZED_FUNDS_ACCOUNT_ID>"
  },
  "recipient": {
    "accountId": "<DEBTOR_ACCOUNT_ID>"
  },
  "extraDatas": {
    "label1": "Annulation saisie administrative ORD-123456"
  },
  "isCorrective": true
}

9. Retrieving related Internal Transfers

The Partner does not create the Internal Transfers used by Xpollens to process a SATD.

These transfers are generated automatically by Xpollens.

If required for reconciliation or support purposes, the Partner can retrieve the generated Internal Transfer using the Internal Transfers API.

Get an Internal Transfer

GET /api/v2.0/internal-transfers/{internalTransferId}

The response includes information such as:

• internalTransferId;
• creationDate;
• amount;
• status;
• reason;
• sender.accountId;
• recipient.accountId;
• extraDatas;
• processUnpaid;
• isCorrective;
• checkLimits.

Example:

{
  "internalTransferId": "P2P_2024931940",
  "creationDate": "2025-03-12T08:19:36.9961387+00:00",
  "amount": {
    "value": "1.00",
    "currency": "EUR"
  },
  "status": "Completed",
  "reason": null,
  "sender": {
    "accountId": "17e4cfee-5771e6ac6"
  },
  "recipient": {
    "accountId": "b2av3fjvc-0831r2pm0"
  },
  "extraDatas": {
    "description": "Description",
    "label1": "Fees",
    "label2": "SubLabel",
    "label3": "Tag"
  },
  "processUnpaid": false,
  "isCorrective": false,
  "checkLimits": true
}

List Internal Transfers

Internal Transfers associated with an account can also be retrieved through:

GET /api/v2.0/internal-transfers

Available filters include:

The POST /api/v2.0/internal-transfers endpoint is not required for SATD processing. SATD-related transfers are initiated by Xpollens.

10. Internal Transfer statuses

The Internal Transfers API defines the following statuses:

Partners should primarily use the InternalTransfer callback to receive movement updates and the GET endpoints when the operation needs to be retrieved afterwards.

11. Callback acknowledgement

Callbacks include the following HTTP headers:

Webhook-Id
Webhook-Processdate

Webhook-Id uniquely identifies the callback delivery.

Webhook-Processdate indicates the callback processing/send date.

Partner callback endpoints must acknowledge successful reception according to the callback contract.

The documented successful acknowledgement statuses are:

202 Accepted

or:

204 No Content

depending on whether the Partner wishes to continue receiving further updates for the callback flow.

Partner implementations should ensure that callback processing is idempotent, as the same business object can legitimately generate several updates over its lifecycle.

12. Partner responsibilities

The Partner does not perform the SATD regulatory processing.

From an integration perspective, the Partner should:

• receive and process SeizureCreatedOrUpdated callbacks;
• receive and process the associated InternalTransfer callbacks;
• identify the affected debtor using appUserId;
• reconcile SATD-related account movements;
• support several operations for the same SATD when several accounts are impacted;
• update its own end-user support and operational tools when relevant;
• inform the end user according to the Partner's applicable customer communication obligations;
• reconcile processing fees according to the contractual pricing agreement.

The Partner does not need to:

• receive the SATD directly from the DGFIP;
• identify the debtor on behalf of the DGFIP;
• call an API to reserve the funds;
• call an API to release the funds;
• call an API to transfer the seized funds to the Public Treasury;
• communicate the regulatory response to the DGFIP.

13. Processing fees

SATD processing fees may be recharged to the Partner according to the applicable contractual pricing schedule.

The SATD and operation identifiers exposed through the callbacks provide the information required to reconcile the affected debtor and the associated account movements.

14. Implementation recommendations

Partners should treat SeizureCreatedOrUpdated as an update event for an existing SATD rather than assuming that each callback represents a new seizure.

Recommended integration principles:

• use seizureId as the unique business identifier of the SATD;
• expect several SeizureCreatedOrUpdated callbacks for the same seizureId;
• use the most recent callback as the current known state of the SATD;
• do not assume that a SATD affects only one account;
• support several InternalTransfer callbacks for one SATD;
• use appUserId to associate the SATD with the relevant debtor;
• use operations[].accountId and InternalTransfer.sender/recipient.accountId for account-level reconciliation;
• use internalTransferId to retrieve a transfer through the Internal Transfers API when necessary;
• process callbacks idempotently;
• do not trigger SATD account movements from the Partner side.

15. Partner event summary

16. FAQ

Does the Partner receive the SATD directly from the DGFIP?

No. Xpollens is the legal third-party holder and receives the SATD from the DGFIP.

The Partner is informed through Xpollens callbacks.

Does the Partner need to call an API to seize funds?

No.

The seizure is performed by Xpollens.

The Partner receives the resulting account movement through an InternalTransfer callback.

How does the Partner know which debtor is affected?

The SeizureCreatedOrUpdated callback contains:

appUserId

which identifies the debtor in the Partner integration.

How is the Partner informed that money has actually been seized?

The Partner receives:

1. one or several InternalTransfer callbacks corresponding to the account movement(s);
2. an updated SeizureCreatedOrUpdated callback containing the current seizedAmount.

Can one SATD affect several accounts?

Yes.

A SATD may generate several Internal Transfers if several accounts belonging to the same debtor are impacted.

Can the amount seized be lower than the amount requested in the SATD?

Yes.

amount represents the amount requested by the administration, while seizedAmount represents the amount effectively seized.

What happens if no money can be seized?

The SATD can move to:

InProgress

with:

seizedAmount = 0.00 EUR

It is subsequently closed according to the SATD lifecycle.

What happens when a partial release is received?

Xpollens returns the released amount to the impacted account(s).

The Partner receives:

1. one or several InternalTransfer callbacks for the returned funds;
2. an updated SeizureCreatedOrUpdated callback containing the new seizedAmount.

What happens when a total release is received?

Xpollens returns the relevant seized funds to the debtor's account(s).

The Partner receives the corresponding InternalTransfer callback(s) and an updated SeizureCreatedOrUpdated callback.

The subsequent status should be taken from the callback received for the SATD.

Does the Partner have to initiate the release?

No.

The release is received from the administration and processed by Xpollens.

Can the Partner retrieve an Internal Transfer after receiving the callback?

Yes.

Use:

GET /api/v2.0/internal-transfers/{internalTransferId}

Should the Partner call POST /api/v2.0/internal-transfers for a SATD?

No.

SATD-related Internal Transfers are generated by Xpollens as part of the seizure lifecycle.

Are SATD-related transfers corrective operations?

Yes, the seizure and release P2P movements used in the SATD workflow are flagged with:

isCorrective = true

Which label is displayed for a seizure movement?

The functional label is based on:

Saisie administrative + <order number>

Which label is displayed when seized funds are returned after a release?

The functional label is based on:

Annulation saisie administrative + <order number>

17. API and callback references

The SATD integration relies primarily on the following Xpollens interfaces:

The Internal Transfers API is exposed through the Xpollens API gateway.

Sandbox base URL:

https://sb-api.xpollens.com

Authentication is required for API requests according to the standard Xpollens authentication mechanism.