Skip to main content
Every transfer generates a complete audit trail. This page describes the data available for reporting, reconciliation, and compliance.

​
What data is recorded per transfer

​
Transfer status lifecycle

​
TED OUT

TED OUT state machine diagram
  • Customer confirmed (CREATED) — the customer confirmed the transfer, now queued for submission
  • Submitted to bank network (PENDING) — message sent to JD Consultores, awaiting acknowledgment
  • Bank processing (PROCESSING) — JD accepted the transfer and routes it
  • Settled (COMPLETED) — transfer successfully settled at the destination bank
  • Rejected (REJECTED) — JD returned a business error (e.g., invalid account data)
  • Failed (FAILED) — technical failure (timeout or service unavailability)
  • Cancelled (CANCELLED) — customer cancelled before the transfer was submitted

​
TED IN

TED IN state machine diagram
  • Transfer detected (RECEIVED) — incoming message persisted, pending internal processing
  • Recipient validated (PROCESSING) — the system credits the recipient account
  • Amount credited (COMPLETED) — recipient account successfully credited
The sending bank can reverse a settled inbound transfer. To handle these chargebacks, TED IN supports a COMPLETED → FAILED transition.

​
P2P

P2P state machine diagram
  • Confirmed (CREATED) — transfer initiated between internal accounts
  • Processing (PROCESSING) — Midaz transaction in progress
  • Settled (COMPLETED) — both accounts updated successfully
  • Failed (FAILED) — processing error
  • Cancelled (CANCELLED) — cancelled before processing began

​
Fee review before confirmation (TED OUT only)

For TED OUT, customers go through a two-step flow: PaymentInitiation lifecycle diagram
  • Pending confirmation — the plugin calculated and presented the fee. The customer has not confirmed it yet
  • Processed — the customer confirmed and the plugin created the transfer
  • Expired — 24 hours elapsed without confirmation
Customers can review the full cost (amount + fee) before they confirm the transfer.

​
Status history

The plugin records every status transition with a timestamp, the previous state, the new state, and a reason for errors and cancellations. This gives you a full audit trail for every transfer — who changed what and when. The changedBy field records the actor that made the transition — for example, a system process or a reconciliation worker. It can be empty.

​
Reconciliation fields

Use these fields to match transfer records against your bank statements:

​
Data retention

Do not delete transfer records. The plugin never deletes or expires them, so you own their retention. Keep transfer and audit records for at least 5 years, per BACEN record-keeping requirements.

​
Querying your data

Use List Transfers to query transfers with the following filters:
  • By date range — filter by createdAt or completedAt
  • By type — TED OUT, TED IN, or P2P
  • By status — e.g., only COMPLETED transfers for reconciliation, or FAILED for investigation

​
For developers

​
Storage

The plugin stores transfer data in PostgreSQL. The recipientDetails field uses JSONB. This field holds the different data structures for TED OUT, TED IN, and P2P recipients. The recipientAccountId field references a Midaz account when the recipient is internal. Each tenant has its own database, and the organization is the main filter within a tenant. The plugin maintains the following indexes for common query patterns:
  • (midaz_organization_id, created_at) for paginated listings.
  • (midaz_organization_id, status, created_at) for status-based filtering.
  • (control_number, date) (unique) for JD reconciliation lookups.
The transfer_status_history audit table uses one index for audit and investigation workflows:
  • (transfer_id, changed_at DESC) for transfer-level history.

​
Incoming TED deduplication

Before it processes a TED IN transfer, the plugin stores the raw JD message in the JDIncomingMessage table. This lets the plugin recover incoming transfers if the service fails during processing. To prevent duplicate processing, the table enforces a unique constraint on sequenceNumber (JD’s NumCabSeq). If JD re-delivers the same message, the plugin automatically identifies it as a duplicate and ignores it.

​
Entity relationships

The TED domain model follows these relationships:
  • Each Transfer belongs to a single organization and can have multiple TransferStatusHistory records.
  • TED OUT transfers can originate from a PaymentInitiation in the two-step transfer flow.
  • Each JDIncomingMessage can create at most one Transfer of type TED_IN.
Entity relationships diagram