Bank & regulator pack · Stage 2 groundwork

Bank safety: technical groundwork before regulatory approval

This pack explains how ODG-PASS forms correct structured data at client initiation, where data flows, and how the bank deploys the module inside its own perimeter. Suitable for IT, information security, and supervisory review at pilot stage.

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 terminal	Mode 2 · Bank Connector
Назначение	Мост MT→MX · канал для клиентов, пока интернет-банк ещё на старом формате	Validation API в периметре банка · встраивание в ДБО
Где выполняется	Браузер + публичный API `/validate`	Сервер/VM банка (Docker)
Банковские секреты	Не запрашиваются	Только внутри банка
Исполнение платежа	Нет · только данные и MX	Нет · только структура; исполнение в ядре банка
Монетизация	Публичный доступ / repair-fee (отдельно)	Годовая лицензия на ПО
Статус	LIVE	PRE-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.

MVP validate API — structured check result for bank IT (field hints, ready flags, audit id). Full connector contract is shared under pilot / NDA — see Support or cover letter.
Validation service — ядро ISO 20022 / SWIFT CBPR+ + rulepack, без LLM в критическом пути.
Admin API — GET /v1/admin/audit · журнал проверок (IBAN маскируется).
Sandbox adapter — следующий этап: URL и credentials банка только внутри периметра.
License module — следующий этап: heartbeat / JWT.
Отчёты — структурированный сигнал для compliance (не блокировка платежа).

Поставка: 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	Ключевые элементы	Зачем банку
GrpHdr	MsgId, CreDtTm, NbOfTxs, IntrBkSttlmAmt	Заголовок пакета — audit trail, сумма группы
CdtTrfTxInf	PmtId, Dbtr/Cdtr, DbtrAgt/CdtrAgt, RmtInf, Purp	Тело платежа — то, что проверяет транслятор и корреспондент
PstlAdr	StrtNm, BldgNb, PstCd, TwnNm, Ctry	CBPR+ — главная причина return при MT→MX
IntrmyAgt1	FinInstnId/BICFI (optional)	Корреспондент — nostro/vostro маршрут
ChrgBr	DEBT / CRED / SHAR	SHA · 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

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

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

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

Tester checklist → Cover letter (EN+AR) Support Request pilot Security Appendix → Open payment check

ODG-PASS Innovation LLC · Bank technical pack · structured data layer · client → bank