Skip to main content

Initiate a SEPA Instant Recall

This guide walks you through the end-to-end process of creating and, if required, approving a SEPA Instant (SCT Inst) recall in ImPAI.

It combines two core APIs:

  • Recall Creation – create a recall for a previously booked/settled payment
    👉 Recall Creation API
  • Recall Approval – approve or reject the recall under the Four-Eyes Principle
    👉 Recall Approval API

Prerequisites​

Before you start:

  • ✅ You have valid OAuth access tokens and the required roles/permissions.
  • ✅ You can identify the original outgoing SEPA Instant payment that should be recalled (e.g. via its Global ID or internal ID).
  • ✅ The original payment is in a booked/settled state and is eligible for recall according to scheme and bank rules.
  • ✅ You have a strategy for storing the internalId identifier returned by ImPAI for tracking and follow-up (e.g. resolutions).

Step 1️⃣ – Select the Original Payment​

A recall is always based on a previously sent and settled SCT Inst payment.

Typical ways to select the transaction:

  • From your UI Transactions screen, selecting a successfully processed outgoing payment.
  • From a transaction list API, filtering for a specific Global ID / internal ID / external reference.
  • From reconciliation systems detecting an error or fraud after settlement.

Ensure that:

  • The payment is not already in a recall or return process.
  • The state allows recall (otherwise the recall creation call will not be accessible).

Step 2️⃣ – Create a Recall​

To start the recall flow, you submit a recall creation request using the Recall Creation API:

POST /api/sct-inst/v1/recall/create

This call creates an interbank camt.056 recall message linked to the original SCT Inst credit transfer.

What the call requires (conceptually)​

At a high level, the request contains:

  • Identifiers
    A reference to the original SCT Inst transaction (the internal ID) so ImPAI can link the recall to the underlying payment.
  • Recall Details
    Business information such as:
    • the reason code for the recall (e.g. duplicate, fraud, customer request)
    • any additional explanation required by the scheme or counterparties

ImPAI validates that the original payment:

  • exists,
  • is in a state where recall is allowed, and
  • is not already subject to a conflicting R-transaction.

Typical recall workflow​

  1. Locate the original, settled outgoing SCT Inst payment that needs to be recalled.
  2. Build the recall request with an appropriate reason and references to the original payment.
  3. Send POST /recall/create with the required headers (e.g. Authorization, X-Request-Id).
  4. ImPAI validates the request (eligibility, state, format, business rules).
  5. If accepted, ImPAI creates a new recall transaction and generates the interbank camt.056 message.

What you get back​

If the recall is accepted:

  • You receive a response header with technical identifiers for tracking the recall call.
  • The payload includes recall identifiers (e.g. recall transaction ID), which you can store for later use.
  • The original payment lifecycle is updated to show that a recall is in progress.
Full Details

For the full request schema, field-level definitions, and detailed response examples, see:
👉 Recall Creation API

Step 3️⃣ – Check for Approval Required​

Depending on configuration, a recall may:

  • Be sent straight to clearing without manual approval, or
  • Enter an Approval Pending state, requiring a second user (checker) to approve or reject.

You can determine this by:

  • Inspecting the status returned by the creation response.
  • Checking the transaction in the Approvals UI (if available).

If the recall is Approval Pending, continue with Step 4.
If not, the recall continues automatically and you can move on to monitoring.

Step 4️⃣ – Approve a Recall (Optional)​

If the recall is governed by the Four-Eyes Principle, an authorized user must approve or reject it.

Use the Recall Approval API:

POST /api/sct-inst/v1/recall/approval

What the call requires (conceptually)​

The approval request contains:

  • Identifier
    The internalId of the recall message to be approved (or rejected).
  • Decision
    Whether to approve or reject the recall.
  • Rejection Reason (when applicable)
    A justification that is stored for audit and compliance if you reject.

ImPAI validates that:

  • the recall is still Approval Pending,
  • the user / client has permission to decide,
  • the decision is consistent with the current state.

What you get back​

On success:

  • The recall is approved and sent into the interbank process, or rejected and stopped.
  • The response returns updated identifiers and/or status information for tracking.
  • The decision is recorded in the audit trail together with any provided rejection reason.
Full Details

For schema and examples of the approval call, see:
👉 Recall Approval API

Step 5️⃣ – Track Recall & Follow-Up​

After the recall is sent or rejected:

  • Use your UI screens to monitor the final outcome (accepted, rejected, partially processed).
  • Watch for incoming camt.029 (Resolution of Investigation) messages, which may be exposed through your APIs or UI as Resolution entries.
  • Depending on the outcome, your internal processes may:
  • close the recall as successful,
  • close it as unsuccessful, or
  • trigger further investigation.

Example Flow at a Glance​

Summary​

  • Use Recall Creation to initiate a recall for a booked/settled outgoing payment.
  • If configured, the recall may require manual approval under the Four-Eyes Principle.
  • Use Recall Approval to approve or reject the recall request.
  • Monitor the final outcome via your UI screens and subsequent resolution messages.

APIs Used in this Flow

StepAPIPurposeDetails
CreationPOST /recall/createCreate Recall👉 Go
Approval (optional)POST /recall/approveRelease Recall👉 Go