Как минимизировать риск при снятии денег с банкомата при обрыве связи с банком

Что проверяют

Умеете ли вы как аналитик разложить операцию на шаги и для каждого шага описать, что происходит при обрыве связи. Следом почти всегда спрашивают самый неприятный случай: деньги выданы, а подтверждение до банка не дошло.

Как отвечать

Начните с последовательности: банкомат отправляет запрос на авторизацию, банк проверяет остаток и блокирует сумму (hold), банкомат получает одобрение, выдаёт купюры и фиксирует результат. Окончательное списание происходит позже, при клиринге. Дальше пройдите по точкам обрыва:

• ответ на авторизацию не пришёл: банкомат по таймауту деньги не выдаёт и отправляет отмену (reversal, в ISO 8583 это сообщения класса 04xx). Отмена хранится в очереди store-and-forward и повторяется, пока банк её не подтвердит;
• одобрение пришло, выдача не удалась: купюры застряли или клиент не забрал их и банкомат втянул пачку обратно. Уходит полная или частичная отмена на фактически невыданную сумму;
• деньги выданы, подтверждение не ушло: блокировка на счёте остаётся, а результат доотправляется после восстановления связи;
• идемпотентность: у каждой операции есть уникальный идентификатор, и повторный запрос или повторная отмена с тем же идентификатором не приводят к двойному списанию или двойному возврату;
• сверка: электронный журнал банкомата, счётчики кассет и данные процессинга регулярно сверяются, расхождения уходят в разбор спорных операций.

Отдельно упомяните stand-in: если банк-эмитент недоступен, процессинг может одобрять операции сам в пределах небольшого лимита, это бизнес-решение о допустимом риске.

Где спотыкаются

Предлагают «проверять связь перед операцией». Обрыв случается посреди операции, и проверка на старте ничего не гарантирует.

Разбирают только одну точку обрыва. Сильный ответ перечисляет все переходы между состояниями и для каждого называет действие.

Забывают про повторы: отмена отправлена дважды, и без идентификатора операции клиент получает деньги назад два раза.