## Read the transaction as a whole

`status` describes journey progress. `decision` is `pending`, `approved` or `rejected`. When present, `decision_reason` adds the documented reason. Use the reference for the complete object and current enums; do not infer a decision from a single stage name.

| Scenario | Application handling |
| --- | --- |
| `created` and intermediate stages | Keep the process pending |
| `manual_review_pending` | Wait for review; do not release as approved |
| `approved` with `decision=approved` | Apply your rules for continuing the process |
| `rejected` with `decision=rejected` | Handle rejection according to your procedure |
| `expired` | Close or restart according to your policy |

Statuses such as `liveness_passed` or `document_passed` describe a completed step and do not replace the final decision. An interrupted connection is not evidence of rejection or approval either.

## Synchronize your business decision

Store the relation between your process and the transaction. When an event arrives, verify its origin, recognize duplicates and read current state before performing irreversible effects. An older event must not overwrite a newer decision merely because it arrives later.

KYC approval does not determine credit approval, the absence of payment fraud or a person’s authority to represent an organization. Your operation remains responsible for those assessments. See [redelivery and reconciliation](/en/developers/kyc/redelivery-and-reconciliation) and exercise these scenarios in the [simulator](/en/developers/kyc/simulator).