Rejected transfer. Funds still blocked.

System architecture

Map every service that participates in one transfer.

Asynchronous recovery path

Transfer state machine

Think in states before thinking in screens.

Compliance rejection path

Expected flow

A rejection must restore financial availability.

API evidence

The synchronous transfer flow behaves as designed.

{
  "debtorAccountId": "ACC-ES-4410",
  "beneficiaryIban": "DE89370400440532013000",
  "amount": 8750,
  "currency": "EUR",
  "idempotencyKey": "idem-5e71-transfer-8750"
}

{
  "transferId": "TRF-908771",
  "status": "REJECTED",
  "rejectionCode": "AML_REVIEW_FAILED",
  "fundsReleaseStatus": "PENDING"
}

HTTP success and business success are different things.

Event evidence

The recovery depends on an asynchronous contract.

{
  "eventType": "transfer.rejected",
  "eventVersion": "2.0",
  "eventId": "evt-trf-908771-r1",
  "timestamp": "2026-09-11T15:18:42.413Z",
  "data": {
    "transferId": "TRF-908771",
    "debtorAccountId": "ACC-ES-4410",
    "amount": 8750,
    "currency": "EUR",
    "rejectionCode": "AML_REVIEW_FAILED",
    "releaseFunds": true
  }
}

Log analysis

Follow transfer state and money state independently.

Data validation

Testing the hypothesis at data level

The API and event flow indicated that the transfer had reached a rejected state, but the customer's available balance suggested that the original funds reservation was still active.

At this point, the investigation moves beyond the service response and checks whether the persisted data reflects the expected business state.

The objective is not to query the database for every test, but to use SQL when backend data can confirm or reject a specific investigation hypothesis.

1. Confirm the transfer state and reservation

SELECT
    t.transfer_id,
    t.status AS transfer_status,
    t.amount,
    r.status AS reservation_status,
    r.reserved_amount
FROM transfers t
LEFT JOIN fund_reservations r
    ON r.transfer_id = t.transfer_id
WHERE t.transfer_id = 'TRF-908771';

transfer_status    = REJECTED
reservation_status = ACTIVE
reserved_amount    = 8750.00

This confirms the inconsistency: the business transaction is rejected, but the funds reservation remains active.

2. Verify the customer balance impact

SELECT
    account_id,
    ledger_balance,
    reserved_amount,
    available_balance
FROM account_balances
WHERE account_id = 'ACC-ES-4410';

ledger_balance    = 12480.00
reserved_amount   = 8750.00
available_balance = 3730.00

The ledger balance has not decreased, but the active reservation is still reducing the amount available to the customer.

3. Check whether the release event was processed

SELECT
    e.event_type,
    e.event_version,
    e.processing_status,
    e.created_at
FROM integration_events e
WHERE e.transfer_id = 'TRF-908771'
ORDER BY e.created_at;

transfer.created  | 1.0 | PROCESSED
funds.reserved    | 1.0 | PROCESSED
transfer.rejected | 2.0 | FAILED

The data supports the event-flow hypothesis: the rejection event exists, but downstream processing did not complete successfully.

4. Detect the broader pattern

SELECT
    COUNT(*) AS affected_transfers,
    SUM(r.reserved_amount) AS total_funds_still_reserved
FROM transfers t
JOIN fund_reservations r
    ON r.transfer_id = t.transfer_id
WHERE t.status = 'REJECTED'
  AND r.status = 'ACTIVE';

This query changes the question from “Did one transfer fail?” to “Is this a repeatable systemic state inconsistency?”

SQL is used here as investigation evidence: each query exists to validate a specific hypothesis about state, money or event processing.

Root cause

The funds-release service cannot consume the rejection event.

The producer publishes transfer.rejected v2.0, while the Funds Release Consumer supports only v1.0. The message moves to the DLQ and €8,750 remains reserved.

Defect

Translate distributed-system evidence into banking risk.

Risk analysis

Financial systems fail in the edges between valid states.

Test strategy

Deciding where quality needs to be proven

Not every risk requires the same type of test.

For a critical banking flow, the strategy should connect business risk with the level at which the behaviour can be validated most effectively.

Coverage decisions

Entry and exit thinking

For this flow, release readiness is defined by business-state consistency, not simply by the percentage of test cases that pass.