IOSOR

IOSOR База знаний

Fraud burn rows на prepaid ledger

Помечайте blocked и abusive OTP-попытки так, чтобы finance видел prevented burn рядом с real debit — без fake Delivered и тихих дыр в кошельке.

Стоп злоупотреблений не должен быть невидимым. Когда velocity caps, spike trip wire или destination deny блокируют OTP-попытку, prepaid ledger обязан показать fraud burn row — prevented spend — рядом с settled debits реальных попыток. Finance не может считать «не списали» равным «ничего не было», а product — красить blocked traffic как Delivered.

Связанные: debit и delivery status в одном ledger, debit доставки OTP и сессия verify, Abuse spike: стоп без fake success, Fraud ops при реальном OTP volume.

IOSOR — white-label prepaid.

Prevented burn — не free debit

Заблокированная попытка может оставить ноль settled debit и всё равно нуждаться в видимом burn class: capped, denied, spike-stopped, allowlist-miss. Строка отвечает: «какой wallet risk мы избежали?» без выдуманного charge. Settled debit остаётся для billable attempts, которые реально вышли из hold. Смешение двух классов создаёт fake savings или fake spend.

Классы строк, которые finance фильтрует

Класс Money Честность product
Settled attempt Debit settled Outcome может лагать — никогда fake Delivered
Cap blocked Нет settle (или release) Velocity limited — не Delivered
Spike stopped Нет settle Spike stopped — не Delivered
Destination deny Нет settle Destination blocked
Prevented burn rollup Агрегат avoided USD Night view для

Join stop events без fake success

У каждой burn row — correlation key к stop event: identity class, destination, window, trip reason. UI и ledger — один словарь (Общий язык статусов для product и finance). Spike: Abuse spike: стоп без fake success.

Export: burn vs spend

Нужны поля: burn class, avoided amount (или zero-settle flag), settled amount, correlation ID, UTC window, stop reason. Soft USD 1 000/мес считает отсутствие burn filters риском recon; USD 20 доказывает один коридор с settled и blocked в одном файле. Ритм чтения: Fraud ops при реальном OTP volume.

Чеклист покупателя по fraud burn rows

  1. Blocked OTP оставляют burn class, а не тишину?
  2. Settled debit не спарен с fake Delivered на стопах?
  3. Cap / spike / deny классы различимы и filterable?
  4. Correlation key стыкует UI stop и ledger row?
  5. Export отделяет prevented burn от real spend?
  6. Soft volume language blocked, пока burn rows в draft?

Любое «нет» оставляет fraud ledger honesty в draft.

Начните с IOSOR

Запустите один именованный стоп на живом OTP-намерении — cap, spike или отказ направления. Выгрузите то же окно UTC. Финансы должны видеть settled-дебит рядом со строками burn: capped, spike-stopped, denied. UI продукта и ledger делят причину стопа. Тихий кошелёк — не доказательство, что «ничего не было».

Итог IOSOR

Заблокированный OTP — строка burn на prepaid-ledger, не бесплатный дебит и не пропавшее событие.

Делайте: держите класс burn, избежанную сумму или флаг zero-settle, correlation ID и причину стопа в одном файле, который финансы фильтруют.

Не делайте: прятать предотвращённый расход или рисовать стоп как Delivered, чтобы ledger казался чистым.

Был ли материал полезен?

Связанные гайды