ATM Reconciliation

Цель процесса

Reconciliation нужна, чтобы подтвердить: финансовые записи, журналы банкомата и физическое движение наличных согласованы между собой. Если источники расходятся, создается exception для расследования.

Что сверяется

Источник	Что дает	Ограничения
ATM EJ	Хронологию сессии и событий ATM	Формат и полнота зависят от ПО и настроек
Device log / XFS result	Результаты CDM/CIM/card reader/EPP	Коды и детализация зависят от vendor/SP
Switch log	Авторизационные запросы/ответы, reversal/advice	Может не знать физический результат выдачи без сообщений ATM
Issuer/host log	Решение issuer и состояние авторизации	Не всегда видит device-level outcome
Core banking posting	Проводки/hold по счету	Может обновляться асинхронно
Cassette counters	Логическое движение банкнот по кассетам	Требует сверки с физическим пересчетом
Physical cash balance	Фактические остатки при инкассации	Зависит от процедур инкассации

Основной сценарий

flowchart TD
    START["Cut-off / инкассация / daily close"]
    EJ["Загрузить ATM EJ"]
    HOST["Загрузить switch / host logs"]
    CASH["Загрузить cassette counters и physical count"]
    SCHEME["Загрузить scheme / clearing data, если применимо"]
    MATCH["Сопоставить по Terminal ID, STAN, RRN, времени, сумме"]
    OK{"Все источники согласованы?"}
    BAL["In balance: день закрыт"]
    EXC["Out of balance: exception"]
    INVEST["Расследование: EJ, device log, video, counters"]
    ADJ["Adjustment / reversal / dispute action"]

    START --> EJ --> MATCH
    START --> HOST --> MATCH
    START --> CASH --> MATCH
    START --> SCHEME --> MATCH
    MATCH --> OK
    OK -->|Да| BAL
    OK -->|Нет| EXC --> INVEST --> ADJ

Типовые exception-сценарии

Сценарий	Возможное объяснение	Действие
Approved в host, no dispense в EJ	Ошибка диспенсера после approval	Проверить reversal/advice; при отсутствии — adjustment
Approved и cash taken в EJ, клиент спорит	Клиентская претензия	Проверить EJ, видео, counters, switch log
Partial dispense	Выдана часть суммы	Сверить фактически выданную сумму и корректировку
Host transaction есть, EJ нет	Потеря/невыгрузка EJ, сбой терминала	Поднять локальные журналы и мониторинг
EJ есть, host transaction нет	Offline/timeout/неуспешная отправка	Проверить очередь сообщений и network logs
Cash short / cash over	Физический остаток не совпал	Инкассационное расследование

Offline/degraded ATM scenarios требуют отдельной маркировки в reconciliation: если связь с host/processor отсутствовала или advice/reversal был задержан, нужно отдельно фиксировать время сбоя, восстановление канала и момент фактической отправки сообщений. Российский контекст: ATM-Russia-Offline-Operation.

Reversal / adjustment / reconciliation

Reversal — это сообщение/механизм исправления конкретной операции. Reconciliation — процесс проверки согласованности источников. Adjustment — корректирующее действие после выявленного расхождения. Эти три понятия связаны, но не взаимозаменяемы.

Для МИР/НСПК reconciliation нужно читать на двух уровнях:

• публичный уровень: Правила ПС «Мир» описывают общий порядок платежного клиринга, расчетов, представления операций и взаимодействия в спорных/нестандартных ситуациях;
• операционный уровень: конкретные файлы, поля, reason codes, сроки и message-level rules могут находиться в стандартах НСПК и банковских процедурах, которые не являются публичными.

Связанные заметки

• ATM-Authorization-Hold-Clearing-Settlement
• ATM-No-Dispense-и-Reversal
• ATM-Электронный-Журнал
• ATM-Incident-Evidence-Package
• ATM-Fraud-Monitoring
• ATM-Russia-Anti-Fraud-Cash-Withdrawal
• ATM-Russia-Offline-Operation
• ATM-Cash-Cost-Model
• ATM-Cash-Recycling-Business-Case
• TERM-reconciliation
• TERM-ej · TERM-reversal · TERM-settlement
• ATM-МИР-и-НСПК

Источники

• ISO: ISO 8583:2023.
• НСПК: Правила ПС «Мир» v4.3.
• Mastercard: Chargeback Guide — ATM disputes.