Открыть меню

Сценарии внедрения ATM-стеков

Создано 28 мая 2026 г. Обновлено 28 мая 2026 г. 3 мин чтения

Публичный навигационный hub по вариантам ATM-стеков: NCR/APTRA/NDC, Diebold/Vynamic/DDC, KAL multivendor, TellME и switch-centric ISO 8583.

Сценарии внедрения ATM-стеков

Кратко

Эта заметка описывает не фактический стек одного банка, а типовые варианты, которые могут встречаться в ATM-парках. В реальном внедрении банк может использовать один из вариантов, сочетание нескольких вариантов или собственную гибридную архитектуру.

Главная идея: ATM hardware, terminal application, host protocol, switch, EMS, платежная схема и reconciliation могут выбираться независимо, но в расследовании инцидентов их нужно рассматривать как связанный стек.

Как читать

  1. Начать с ATM-ПО-обзор и ATM-Производители-обзор.
  2. Выбрать сценарий ниже.
  3. Сверить его с протоколами в ATM-NDC-DDC, ATM-ISO-8583 и ATM-XFS-CEN.
  4. Для спорных операций перейти к ATM-Электронный-Журнал, ATM-No-Dispense-и-Reversal и ATM-Reconciliation.

Сценарии

СценарийКогда встречаетсяКлючевая идея
ATM-Стек-NCR-APTRA-NDCNCR-heavy парк или NDC-hosted архитектураHost-driven ATM flow вокруг APTRA/NDC
ATM-Стек-Diebold-Vynamic-DDCDN/Wincor-heavy парк или миграция ProTopas/WebIUS → VynamicDDC/Vynamic и централизованные журналы/мониторинг
ATM-Стек-KAL-Kalignite-MultivendorРазнородный парк, где нужно единое terminal appMultivendor terminal layer поверх разных XFS/SP
ATM-Стек-TellME-Russian-MultivendorРоссийский/СНГ mixed fleet и локальные требованияMultivendor ATM software с российским контекстом
ATM-Стек-ISO8583-Switch-CentricSwitch-centric архитектура с акцентом на ISO 8583 и backendATM application как канал к процессинговому switch

Слои сравнения

СлойВариантыЧто проверять
HardwareNCR, DN/Wincor, Hyosung, GRG, SAGA, Hitachidispenser/recycler, cassette/retract/reject, EPP, card reader
Device abstractionCEN/XFS, XFS4IoT, vendor SPверсия SP, event model, поддержка конкретной модели
ATM applicationAPTRA, Vynamic, Kalignite, TellME, native vendor appсценарии, EJ, offline queue, remote update
Host protocolNDC, DDC, ISO 8583 profile, proprietaryhost-driven vs terminal-driven, mapping device events
Switch/processingWAY4, TranzAxis, BASE24, собственный switchrouting, authorization, reversal, clearing/reconciliation
EMS/monitoringVynamic View, WebIUS, Kalignite Enterprise, vendor EMSсбор EJ/logs, incidents, remote commands
Scheme profileМИР/НСПК, Visa, Mastercard, UnionPay, on-usreversal, dispute, card capture, clearing rules

Тенденции

  • Multivendor вместо lock-in. Банки часто хотят единые сценарии и мониторинг поверх разного железа, но поведение устройств в edge cases остается model-specific.
  • Cash recycling. Рециркуляция снижает нагрузку на инкассацию, но усложняет reconciliation, проверку пригодности банкнот и разбор partial dispense.
  • Централизация EJ/logs. Для dispute и reconciliation важен быстрый поиск по EJ, host log, RRN/STAN и device events.
  • Разделение terminal app и processing. APTRA/Kalignite/TellME/Vynamic живут на терминальном слое; WAY4/TranzAxis/BASE24 обычно относятся к backend/switch/card processing.
  • Российский слой. Для МИР/НСПК, fraud control и локальных требований нужны отдельные источники и caveat по закрытым операционным стандартам.

Что требует проверки по каждому внедрению

  • exact ATM model and module configuration;
  • XFS SP vendor/version;
  • terminal application version;
  • NDC/DDC/ISO profile;
  • scheme profile: МИР/НСПК, on-us, Visa/Mastercard/UnionPay;
  • EJ format and retention;
  • mapping device events to host messages;
  • reversal queue behavior;
  • dispute evidence requirements.

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

Источники

Ссылаются на эту заметку

Источник: публичный слой Obsidian Vault.