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 plugin created the transfer and placed a hold on amount + fee
  • Preparing submission (PENDING): the plugin prepares the message for JD
  • Bank processing (PROCESSING): the plugin sent the transfer to JD and waits for the settlement result. A timeout keeps the transfer here while reconciliation asks JD for the outcome
  • Settled (COMPLETED): the STR settled the transfer and the plugin committed the hold
  • Rejected (REJECTED): JD or the STR rejected the transfer, and the plugin released the hold
  • Failed (FAILED): the ledger refused the hold, or reconciliation could not settle the transfer. When reconciliation stops after its last attempt, the hold stays in place and an operator resolves the transfer (reconciliation status MANUAL_REVIEW)
  • Cancelled (CANCELLED): the transfer was cancelled from CREATED or PENDING, and the plugin released the hold

​
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
  • Failed (FAILED): the ledger refused the credit, or the sending bank charged back a completed credit

​
P2P

P2P state machine diagram
  • Confirmed (CREATED): the customer confirmed the transfer between internal accounts
  • Processing (PROCESSING): Midaz transaction in progress
  • Settled (COMPLETED): both accounts updated successfully
  • Failed (FAILED): the ledger refused the posting

​
Fee review before confirmation

For TED OUT and P2P, 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: the initiation expired without confirmation. An initiation is valid for 24 hours. A TED OUT initiation expires earlier, at the close of that day’s operating window
Customers can review the fee before they confirm the transfer.

​
Status history

The plugin records every status transition. Get Transfer returns them in statusHistory, each with the previous status, the new status, a timestamp, and a reason when one applies.

​
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 creation date: createdFrom and createdTo
  • By type: TED OUT, TED IN, or P2P
  • By status: e.g., only COMPLETED transfers for reconciliation, or FAILED for investigation
  • By reconciliation status: reconciliationStatus
  • By amount: minAmount and maxAmount
  • By ledger: ledgerId

​
For developers

​
Storage

The plugin stores transfer data in PostgreSQL. The recipientAccountId field references a Midaz account when the recipient is internal. The organization is the main filter.

​
Incoming TED deduplication

Before it processes a TED IN transfer, the plugin stores the raw JD message. This lets the plugin recover incoming transfers if the service fails during processing. Each stored message is unique by JD’s NumCabSeq. If JD re-delivers the same message, the plugin identifies it as a duplicate and ignores it.

​
What the plugin sends to Midaz

The plugin posts every settled movement to Midaz as a ledger transaction, but Midaz records the accounting entry, not the transfer’s banking details. Counterparty identity (bank, branch, account, holder name and document) and BACEN references (controlNumber, clearingControlNumber) live only in the plugin’s Transfer record. For a TED IN, the credit enters the ledger from the @external/BRL account. The sender’s identity is not encoded into the Midaz transaction. The Midaz transaction carries only correlation metadata: Correlation works in both directions:
  • The transfer record stores midazTransactionId, so Get Transfer returns the full banking detail for any ledger entry.
  • The Midaz transaction stores the transfer identifier in metadata.aggregateId, so you can filter Midaz transactions by it to find the ledger entry for a transfer.
Custom metadata you pass when you initiate a TED OUT or P2P transfer never reaches Midaz. The plugin stores it on the transfer and returns it as clientMetadata.

​
Entity relationships

The TED domain model follows these relationships:
  • Each Transfer belongs to a single Midaz organization and can have multiple TransferStatusHistory records.
  • TED OUT and P2P transfers 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