Why did my balance go negative?

Classic write skew. Both transactions saw the pre-state of the row, both decided their predicate held, both committed. Defenses (pick one):

1. SELECT … FOR UPDATE to lock the row before the check.
2. Move the check into the constraint: CHECK (balance >= 0) — the second transaction will get a constraint violation instead of corrupting the balance.
3. SERIALIZABLE isolation, with retry on serialization_failure.

I'd take option 2 plus a unique idempotency key on the transfer.

Adding the CHECK constraint right now.