Understand transaction datetime fields

Banking transactions carry up to three datetime fields. They are not all consistently populated — which fields you receive depends on the institution and the transaction's status — so it matters which one your application relies on.

What each field means

How consistently are they returned?

Population varies by data holder. In Australia (CDR), institutions are required to supply a posting datetime for posted transactions, while the execution and value datetimes are only supplied where available — so:

• POSTED transactions should reliably carry posting_datetime.
• PENDING transactions have not settled, so they typically carry execution_datetime but no posting_datetime.
• execution_datetime and value_datetime coverage differs between institutions; do not assume every transaction has them.

Handle missing fields

1. Treat posting_datetime as your primary transaction date.
2. Fall back to execution_datetime when posting_datetime is empty. This mirrors the API's own behaviour: the from/to date filters on GET /v1/banking/transactions compare against posting_datetime and fall back to execution_datetime, and transactions with neither are excluded from date-filtered results.
3. Treat value_datetime as supplementary. Use it when present (for example, for interest-sensitive calculations), but never build logic that requires it.
4. Key your records on transaction_id, not on datetimes. Datetimes can shift as a transaction moves from pending to posted, and institutions can back-date transactions.

For the full transaction schema, see the API reference. Related: Query transactions by date range.