ODG-PASSGateway
ODG-PASS Gateway — корректные структурированные данные платежа на информационном слое. Зона ответственности: структура и корректность данных. Исполнение — в банке.

Bank & regulator pack · Stage 2 groundwork

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

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

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

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

Zone A · Public

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

Инструмент для клиентов банка на переходе MT→MX: структурированные данные ISO 20022, светофор 🟢🟡🔴, pain.001 / pacs.008. Банк не обязан перестраивать интернет-банк сразу — выдаёт доступ к терминалу так, как решите вы.

LIVE
Zone B · Bank perimeter

Bank Connector (Mode 2)

Validation API в сети банка: /v1/validate, audit trail, ключи только внутри периметра. Клиент остаётся в ДБО — исполнение в ядре банка.

PILOT / LICENSED
┌──────────────────── BANK PERIMETER ────────────────────┐ │ Client ops / Compliance │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────┐ │ │ │ ODG-PASS Bank Connector │ │ │ │ · Validation service (ISO 20022) │ │ │ │ · Sandbox adapter (bank creds) │ │ │ │ · Reports 🟢🟡🔴 (signal only) │ │ │ └──────────────┬──────────────────────┘ │ │ │ structured MX / metadata only │ │ ▼ │ │ Bank ingest → core / SWIFT (execution at bank) │ └────────────────────────────────────────────────────────────┘ │ 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
НазначениеМост MT→MX · канал для клиентов, пока интернет-банк ещё на старом форматеValidation API в периметре банка · встраивание в ДБО
Где выполняетсяБраузер + публичный API /validateСервер/VM банка (Docker)
Банковские секретыНе запрашиваютсяТолько внутри банка
Исполнение платежаНет · только данные и MXНет · только структура; исполнение в ядре банка
МонетизацияПубличный доступ / repair-fee (отдельно)Годовая лицензия на ПО
СтатусLIVEPRE-REGULATORY PACK

2b · Invisible Compliance — Validation API bank standard 2026

Банкам не нужно заставлять клиентов скачивать софт. Основной продукт (~90% пилотов) — встраивание модуля пред-валидации в существующий интернет-банк через защищённый API. Клиент нажимает «Проверить» — банк вызывает ODG-PASS — мгновенный сигнал 🟢🟡🔴 и понятное исправление. Клиент не покидает сайт банка.

СлойДля когоСуть
PRIMARYРозница и СМБValidation API · REST/gRPC · микросервис в VPC банка · ISO 20022 / PAS 08 · структурированные данные
ADD-ONКорпоратыProfessional Terminal · пакетные операции · доступ через корпоративный кабинет банка · sync по API
BRIDGEКлиенты на переходе MT→MXБанк выдаёт доступ к терминалу (ссылка, iframe, корпоративный канал) · клиент готовит платёж в новом формате, пока старый интернет-банк не перестроен
Клиент в интернет-банке │ «Проверить» / перед «Отправить» ▼ ┌───────────────────────────────┐ │ Validation API (в VPC банка) │ ← ODG-PASS · детерминированная проверка │ 🟢🟡🔴 + «исправьте поле X» │ ← signal, not verdict └───────────────┬───────────────┘ │ ▼ Ядро / платёжный конвейер банка (исполнение только в банке)

Ответы ИБ: скачивание не обязательно (есть API) · данные в вашем контуре · логируемо · не блокируем платежи · не заменяем AML/CFT.

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

Коннектор — лёгкий агент в VPC банка: международные cross-border платежи, API /v1/validate по контракту bank pack.

Поставка: Docker (bank_connector/docker-compose.yml) или systemd · API key / mTLS на ingress банка · без CORS * в production.

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

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

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

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

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

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

Пока интернет-банк и корпоративный канал ещё рассчитаны на старый формат (MT / свободный текст), банку не обязательно сразу переписывать все экраны. ODG-PASS — инструмент, который банк предоставляет клиентам: платёж готовится в ISO 20022 MX (pain.001 / pacs.008), структура полная. Как именно выдать доступ — решает банк: ссылка, встраивание, API, корпоративный портал.

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

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

5b · ISO 20022 — pain.001 / pacs.008 для специалистов банка message anatomy

ODG-PASS собирает два слоя из одного набора полей: клиентский pain.001.001.09 (инициация) и межбанковский pacs.008.001.08 (FI-to-FI). Rulepack проверяет XSD, CBPR+ адрес, Purp/Ustrd, ChrgBr — детерминированно, без LLM на critical path.

Блок MXКлючевые элементыЗачем банку
GrpHdrMsgId, CreDtTm, NbOfTxs, IntrBkSttlmAmtЗаголовок пакета — audit trail, сумма группы
CdtTrfTxInfPmtId, Dbtr/Cdtr, DbtrAgt/CdtrAgt, RmtInf, PurpТело платежа — то, что проверяет транслятор и корреспондент
PstlAdrStrtNm, BldgNb, PstCd, TwnNm, CtryCBPR+ — главная причина return при MT→MX
IntrmyAgt1FinInstnId/BICFI (optional)Корреспондент — nostro/vostro маршрут
ChrgBrDEBT / CRED / SHARSHA · OUR · BEN — согласованность с Field 71

Correspondent review (guidance): RR03 — адрес получателя · RR02 — отправитель · NARR — нет назначения · RR04 — крупная сумма / cross-border. Сигнал для операционного блока, не AML-вердикт.

AML / CFT: live screening, sanctions lists, PEP — только в банке. ODG-PASS — структура данных и снижение repair; FATF-контур не подменяем.

Клиентские поля (UI) │ ▼ pain.001.001.09 ──► ingest API банка │ ▼ pacs.008.001.08 ──► translator / SWIFT / RTGS │ ├── IntrmyAgt1? (correspondent BIC) └── correspondent review hints (RR03…)

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

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

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

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

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

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.3 · MT→MX bridge · structured data layer