Skip to main content

Create a Resolution for a Recall

This guide explains how to create a Resolution of Investigation for a previously received Recall in SEPA Instant (SCT Inst).

It combines:

  • Resolution Creation – send a formal outcome for a Recall (typically via camt.029)
    👉 Resolution Creation API
  • Resolution Approval (if required) – approve or reject the outgoing Resolution under the Four-Eyes Principle
    👉 Resolution Approval API

Prerequisites​

Before you start:

  • ✅ You have valid OAuth access tokens and appropriate roles/permissions.
  • ✅ Your bank has received a Recall (camt.056) for a payment, and internal investigation has determined the outcome.
  • ✅ You know the original transaction and recall identifiers that the Resolution must refer to.
  • ✅ You understand the applicable resolution reason codes and their meaning.

Step 1️⃣ – Identify the Recall to be Resolved​

A Resolution is always tied to an existing Recall that the bank has previously received and investigated.

You can select the underlying Recall:

  • Via a UI Recall / R-transaction view, showing open investigation cases.
  • Via internal workflow tools used by operations or investigations teams.

Ensure that:

  • the Recall is still awaiting a final decision, and
  • no Resolution has already been sent for this case.

Step 2️⃣ – Create the Resolution​

To communicate the final decision (e.g. accept or reject the Recall), use the Resolution Creation API:

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

This generates a camt.029 Resolution of Investigation message linked to the Recall and underlying payment.

What the call requires (conceptually)​

The Resolution request generally contains:

  • Identifiers
    References to the original SCT Inst transaction and the associated Recall, so that all parties can link the outcome correctly.
  • Resolution Details
    Including, for example:
    • a resolution / reject reason code (e.g. funds already withdrawn, legal reasons, no agreement to return)
    • structured or free-text additional information explaining the decision

ImPAI validates that:

  • the Recall exists and is in a state where a Resolution can be sent, and
  • the chosen reason codes and fields comply with scheme and technical rules.

Typical resolution workflow​

  1. An operations team reviews the Recall and decides whether to return the funds or not.
  2. The client system (UI or backend) builds a Resolution request referencing the Recall and underlying payment.
  3. The system sends POST /resolution/create with the decision encoded in reason codes and texts.
  4. ImPAI validates the request and, if accepted, creates a Resolution transaction and generates a camt.029 message.

What you get back​

If the Resolution is accepted:

  • You receive technical identifiers (e.g. a responseId and the original request id).
  • The payload contains a resolution transaction identifier that can be stored for future reference.
  • The Recall’s lifecycle is updated to reflect that a final outcome has been communicated.
Full Details

For complete request/response structures and validation rules, see: 👉 Resolution Creation API

Step 3️⃣ – Check for Approval Required​

Some institutions may require manual approval before sending a Resolution, especially if:

  • the decision impacts customer relationships significantly, or
  • high-value or sensitive cases are involved.

You can:

  • Check the status after calling the Resolution Creation API.
  • Use an Approvals UI to see whether the Resolution is in an Approval Pending state.

If approval is required, proceed to Step 4.
Otherwise, the Resolution is sent automatically and you can move on to monitoring.

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

If the Four-Eyes Principle is enabled for this flow, an authorized user must approve or reject the outgoing Resolution.

Use:

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

What the call requires (conceptually)​

The request will include:

  • Identifier
    The internalId of the Resolution transaction that is awaiting approval.
  • Decision
    Whether to approve (send the Resolution) or reject (cancel or rework the case).
  • Rejection Reason (when rejecting)
    A short justification stored for audit and operational transparency.

ImPAI ensures:

  • the transaction is still Approval Pending,
  • the user is authorized, and
  • the decision is consistent with the case state.

What you get back​

On success:

  • The Resolution is either sent to the counterparties (via camt.029) or cancelled.
  • The response confirms the decision and may carry updated identifiers or state information.
  • The decision is stored as part of the end-to-end audit trail of the investigation.
Full Details

For more details on the approval request and responses, see: 👉 Resolution Approval API

Step 5️⃣ – Track the Investigation Outcome​

Once the Resolution has been sent or rejected:

  • Use your UI or internal tools to view the final state of the Recall and its Resolution.
  • Downstream systems (e.g. case management, customer communication) can act based on the final decision.
  • The full chain (original payment → recall → resolution) remains available for compliance and audit purposes.

Example Flow at a Glance​

Summary​

  • Use Resolution Creation to send the final decision for a received Recall.
  • Optionally require manual approval via the Four-Eyes Principle before sending the Resolution.
  • Use Resolution Approval to approve or reject the outgoing Resolution.
  • Track the complete chain from payment → recall → resolution for audit and operational insight.

APIs Used in this Flow

StepAPIPurposeDetails
CreationPOST /resolution/createCreate Resolution👉 Go
Approval (optional)POST /resolution/approveRelease Resolution👉 Go