ODG-PASSGateway
Не платёжная система. ODG-PASS Gateway — программный инструмент пред-валидации на информационном слое. funds_moved: false · деньги и счета банка мы не трогаем.

Bank & regulator pack · Stage 2 groundwork

Безопасность для банка: технический задел до разрешения регулятора

Документ описывает, почему терминал не участвует в платёжном потоке, где проходят данные, и как банк подключает робота внутри своего периметра. Подходит для IT, информационной безопасности и регуляторного обзора на этапе пилота.

1 · Границы доверия trust zones

Мы — производитель инструмента (software vendor). Банк — оператор своей среды и своего sandbox/UAT. Платёжный поток и клиентские деньги остаются в банковской инфраструктуре.

Zone A · Public

Публичный Gateway (Mode 1)

Браузерный терминал: пред-валидация ISO 20022, светофор 🟢🟡🔴. Без банковских ключей. Данные пользователя не заменяют банковский контур.

LIVE
Zone B · Bank perimeter

Bank Connector (Mode 2)

Модуль в сети банка: робот проверок + адаптер к их test endpoint. Sandbox-credentials вводит банк локально.

PILOT / LICENSED
┌──────────────────── BANK PERIMETER ────────────────────┐ │ Client ops / Compliance │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────┐ │ │ │ ODG-PASS Bank Connector │ │ │ │ · Validation Robot (ISO 20022) │ │ │ │ · Sandbox adapter (bank creds) │ │ │ │ · Reports 🟢🟡🔴 (signal only) │ │ │ └──────────────┬──────────────────────┘ │ │ │ test messages only │ │ ▼ │ │ Bank sandbox / UAT / regulatory test env │ └────────────────────────────────────────────────────────────┘ │ optional: license heartbeat (no payment payload) ▼ ODG-PASS License Service (vendor)
Мы никогда: не двигаем средства · не храним банковские sandbox-ключи на публичном сайте · не подменяем решение банка · не блокируем платежи (только сигнал).

2 · Mode 1 и Mode 2 deployment models

КритерийMode 1 · Public terminalMode 2 · Bank Connector
НазначениеДемо, бизнес, обучение, ранняя проверкаПилот / эксплуатация в банке
Где выполняетсяБраузер + публичный API /validateСервер/VM банка (Docker)
Банковские секретыНе запрашиваютсяТолько внутри банка
Участие в платежахНет · funds_moved: falseНет · только тестовые сообщения
МонетизацияПубличный доступ / repair-fee (отдельно)Годовая лицензия на ПО
СтатусLIVEPRE-REGULATORY PACK

3 · Bank Connector — что строим заранее target architecture

Коннектор — лёгкий агент, который банк разворачивает у себя до формального разрешения регулятора, чтобы показать архитектуру и пройти security review.

Поставка: Docker-образ или VM-пакет · gated download после NDA · checksum / подпись релиза.

4 · Два ключа — не путать credential separation

Лицензионный ключ (ODG-PASS → банку)

Право пользоваться Connector. Привязка к организации, срок, тариф. Не даёт доступа к платежам.

Sandbox credentials (банк → свой контур)

Endpoint, API key, mTLS-сертификаты — вводятся только внутри банка. ODG-PASS не хранит и не обрабатывает на публичном сайте.

5 · Переход MT → MX — канал для клиентов банка transition bridge

На срок миграции с MT на ISO 20022 MX банку не обязательно сразу переписывать весь интернет-банк и корпоративный канал. ODG-PASS Gateway даёт контролируемый мост: клиенты банка работают в терминале, а банк решает, как им выдать доступ.

Как банк подключает клиентовСуть
Ссылка / QR из интернет-банкаВременный токен сессии · бренд банка · срок действия задаёт банк
Встраивание (iframe / SSO)Терминал внутри онлайн-банка · без публичных API-ключей на нашем сайте
Приём на API банкаКлиент отправляет уже проверенный MX на endpoint банка → транслятор → ядро
Пилотные ключи оценкиКраткосрочный доступ для корпоративных клиентов на период перехода · выдаёт банк
Клиент банка (юр. / физ. лицо) │ ▼ ┌───────────────────────────────┐ │ ODG-PASS Gateway (терминал) │ ← пред-валидация 🟢🟡🔴 │ pain.001 / pacs.008 · MX │ ← полная структура ISO 20022, без обрезания полей └───────────────┬───────────────┘ │ только структурированное сообщение ▼ API приёма БАНКА (домен банка) │ ▼ Трансляторы MT/MX банка → ядро / RTGS / SWIFT │ ▼ funds_moved: false у ODG-PASS — исполнение только в банке

Ценность для банка: меньше CAPEX на срочную переделку всех клиентских каналов; меньше отказов и repair fee; ниже риск штрафов и предписаний регулятора из‑за неверного формата MX при переходе. Мы снижаем риск формата — не заменяем комплаенс банка и не гарантируем отсутствие всех санкций.

6 · Почему это безопасно для банка security summary

РискКак снят
Утечка платёжных данныхКоннектор в периметре банка; публичный Mode 1 не требует банковских секретов
Участие в расчётахНет доступа к RTGS/SWIFT production; только пред-валидация / тест
Подмена решения банкаSignal, not verdict — рекомендация, не блок
Санкции / complianceСигнал для ручной проверки; не замена банковского AML/CFT
Зависимость от облака вендораРобот работает локально; в интернет — только license check (опционально offline JWT)
Целостность правилДетерминированный валидатор + версионирование rulepack

Полная матрица контролей, STRIDE, порты, retention — в Security Appendix (для ИБ и регулятора).

7 · Что показать регулятору supervisory narrative

  1. Роль: программный валидатор сообщений ISO 20022, не платёжная система и не EMI/банк.
  2. Данные: метаданные платёжных сообщений для проверки формата; не храним клиентские деньги.
  3. Размещение: Mode 2 — в инфраструктуре лицензиата (банка), согласно политике локализации.
  4. Контроль: банк сам решает, какие тесты прогонять; мы поставляем инструмент.
  5. Аудит: логи проверок, версия rulepack, активация лицензии — артефакты для надзора.
  6. Ограничение: продукт не инициирует и не исполняет платежи (funds_moved: false).

8 · Путь пилота onboarding

1Запрос пилота · NDA · обмен этим пакетом с IT/ИБ
2Security review (appendix) · согласование зоны развёртывания
3Evaluation license key · gated download Connector
4Банк вводит свои sandbox credentials внутри периметра
5Тестовые прогоны · отчёты для compliance · feedback
6Параллельно: материалы для регулятора (роль, границы, не-участие в потоке)

ODG-PASS Innovation LLC · ODG-PASS Gateway · Bank technical pack v0.2 · MT→MX bridge · funds_moved: false