Кабинет организации → инженерный этап
Техническая реализация маршрута организации.
Dev Console продолжает выбранную в кабинете задачу: здесь интегратор и оператор проверяют runtime, API-контракты, технические сценарии, журналы и критерии запуска. Задача сохраняется в адресе, а организация и роли определяются API credential на сервере.
Фактическая среда
Production-код и evidence
Показатели ниже появляются после открытия технической сессии и отражают реализованные capabilities. Для внешнего исполнения capability сначала должна существовать, а затем отдельно активироваться.
PRODUCTION CODEEvidence before execution
Проверяемыйконтур без денег.
CertaRail проверяет допуск, фиксирует факт движения и собирает evidence-пакет. Identity, provider и reporting fixtures доступны без внешних вызовов. Provider Sandbox/read-only adapters требуют активации; production execution, OIDC, ЕСИА, СБП/НСПК, custody/KYT adapters и официальный transport Банка России ещё не реализованы.
Термины можно нажимать. Откройте простое объяснение, пример и нужный раздел документации.
- Fail-closed
- Append-only evidence
- Без движения средств
Пример связанного evidence-контура
От решения до evidence draft
organization:current / asset:BTC
MOCK-ПУТЬ РЕАЛИЗОВАН · REAL EXECUTION ЗАКРЫТО
decision → receipt → observation → draftDecision telemetry
Распределение решений
- ALLOW
- —
- REVIEW
- —
- DENY
- —
Platform coverage
Готовность модулей
Откройте рабочую сессию, чтобы загрузить фактические состояния.
Evidence rail
Состояние асинхронного контура
- Pending
- —
- Processing
- —
- Quarantine
- —
- Admission
- —
Outbox state не является сигналом Kafka health; broker проверяется отдельным эксплуатационным контуром.
Фактическое состояние
Границы production-кода
После открытия технической сессии здесь появятся фактические capability- и activation-границы, которые вернул API.
Откройте рабочую сессиюПосле подключения здесь появятся фактические capability- и activation-границы.
Public forms · durable delivery
Недоставленные обращения
Payload-free проекция показывает только opaque reference, correlation, тип, состояние и delivery evidence. Исходные контактные данные в браузер не передаются.
- Pending
- —
- Delivering
- —
- Auto retry
- —
- Dead-letter
- —
- Самое старое
- —
Alerts появятся после загрузки snapshot.
| Reference / correlation | Тип | Состояние | Попытки | Следующая попытка | Recovery |
|---|---|---|---|---|---|
| Требуется рабочая API-сессия | |||||
Crypto Checkout · operator projection
Timeline покупательской сессии
Введите opaque session ID из partner backend. Console читает tenant-scoped статус, независимые оси, append-only timeline и подписанные synthetic webhook deliveries; customer credential сюда не передаётся.
Сессия ещё не выбрана.
Текущая проекция
Checkout
Safe timeline
Webhook deliveries
Remediation в P0 только read-only. Append-only delivery и deal evidence нельзя переписать из браузера; requeue/maker-checker actions появятся лишь вместе с отдельным безопасным command API.
17 / Executable product tour
Проверить ключевые сценарии.
Увидеть доказательства.
Раздел проверяет ключевые пути production-кода: от eligibility, trade и movement evidence до Policy Studio, лимитов, REVIEW cases, Travel Rule, depository, wallet-design и provider workbenches. Открыть технический сценарий
- opaque refs
- production code
- fail-closed checks
Основной acceptance launchpad
Один запуск — ключевые сценарии production-кода
Каждый шаг проверяет ожидаемый HTTP-контракт и сохраняет только безопасные evidence ID, коды и длительность. Bearer-токен в отчёт не попадает.
Дополнительные рабочие модули10 специализированных контуров с фактическими статусами capabilitiesПоказать каталогСкрыть каталог
Capability workbenches
Рабочие модули — с фактическим статусом реализации
Статусы загружаются из /v1/platform/overview. Кнопки запускают только реализованные non-monetary команды и выводят IDs, digests и закрытые внешние gates в протокол проверки.
Policy Studio
Откройте рабочую сессию для проверки lifecycle и capability boundary.
REVISION_LIFECYCLE · IMPACTРеестр лимитов
Откройте рабочую сессию для проверки exact-value reservation evidence.
CONFIGURE · RESERVE · FINALIZEREVIEW case desk
Откройте рабочую сессию для проверки append-only case evidence.
OPEN · ASSIGN · RESOLVETravel Rule evidence router
Откройте рабочую сессию для assessment-проверки без передачи ПДн.
RULESET · DIRECTORY · ASSESSDigital Depository Book of Record
Откройте рабочую сессию для проверки точных atomic-unit записей.
ASSET · ACCOUNT · OPERATION · EXTRACTWallet provisioning registry
Откройте рабочую сессию для проверки evidence без ключей и адресов.
CONTRACT · ADDRESS INTENT · SUBJECT READAssetLink journey evidence
Откройте рабочую сессию для проверки PURCHASE/TRANSFER intent и одноразовой ссылки без исполнения.
PURCHASE · TRANSFER LINK · RESOLVE · CONFIRM · CANCELProvider conformance
Откройте рабочую сессию для contract evaluation.
VENUE · CUSTODY · KYT · PAYMENTCross-border data-pack
Откройте рабочую сессию для gap matrix без legal assurance.
CORRIDOR DRAFT · DATA GAPS · DIGESTPortable evidence verifier
Откройте рабочую сессию для загрузки статуса verifier tool.
CREATE PACK · VERIFY · OPTIONAL ED2551904 / Policy decision
Предторговый контроль
Детерминированное решение по заверенным фактам организации. HTTP 200 используется для ALLOW, REVIEW и DENY; исполнение отделено от оценки.
Пояснить все поля и результаты
Контекст операции
Все ссылки — opaque, без ПДнDecision trace
Ожидает запускаГотово к проверке
Запустите сценарий: здесь появятся outcome, применённые правила и криптографические доказательства.
Результат политики
ALLOW
РЕШЕНИЕ СОХРАНЕНО · REAL EXECUTION ЗАКРЫТО———Control trace
— / —Криптографическое доказательство развернуть
- Input SHA-256
- —
- Policy SHA-256
- —
- Audit SHA-256
- —
05 / Trade control
Торговый контур.
От допуска до сверки.
Рабочее место связывает eligibility decision, durable order record и сохранённые mock fill observations. MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН: контролируемая quote/fill-проверка и расчётная проекция без денег. ТРЕБУЕТ АКТИВАЦИИ: доступ к реализованным Provider Sandbox и read-only public market-data adapters. ЕЩЁ НЕ РЕАЛИЗОВАНО: production order execution, authoritative funds, custody, P&L и full trading adapter.
Проверить market mock-сценарий · Пояснить order, venue и fill
01 / Organization-attested intent
Торговое поручение
02 / Evidence before command
Ворота исполнения
Сначала нужно решение
Откройте рабочую сессию и проверьте поручение. Ни один provider command не формируется до сохранённого decision.
—
- Decision ID
—- Policy
—- Audit receipt
—- Input digest
—
- 01Eligibility decisionОжидает проверкиWAITING
- 02Резерв средствВладелец — ledger организацииORG-OWNED
- 03Maker-checkerApproval flow организации реализован; production OIDC, MFA и step-up binding ещё не реализованыРЕАЛИЗОВАНО
- 04External providerMock path доступен в Verification. Для готового adapter нужны credentials и network route; отсутствующий adapter сначала реализуется.CATALOG-DEPENDENT
Сохраняется только внутреннее поручение.Durable order не вызывает биржу и не меняет деньги или активы.
03 / Durable lifecycle
Что произошло с последней командой
- 01Decision committedЕщё не order
- 02Order persistedPostgreSQL transaction
- 03External venuePROVIDER SANDBOX ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION VENUE ЕЩЁ НЕ РЕАЛИЗОВАН · external calls = 0
- 04Fill evidenceOperator-created fixture only
- 05ReconciliationMOCK CURSOR РЕАЛИЗОВАН · PROVIDER SANDBOX STATEMENT ТРЕБУЕТ АКТИВАЦИИ · AUTHORITATIVE VENUE/CUSTODY STATEMENTS ЕЩЁ НЕ РЕАЛИЗОВАНЫ
—Monetary —External calls —Production enforceable —04 / Durable order register
Order blotter
Состояние PostgreSQL; ни одна строка не является live venue order.| Создан | Client order | Инструмент | Поручение | Decision | Command | Venue | Filled | Evidence |
|---|---|---|---|---|---|---|---|---|
| Авторизуйтесь для загрузки order blotter | ||||||||
05 / Selected order
Fill observation и cancel
Выберите строку blotter. Fill observation запишет durable non-monetary факт; это не рыночное исполнение.
- Order ID
—- Status / venue
- —
- Filled
—- Evidence
—
06 / Derived position projection
Позиции и сверка
Это не ledger организации и не custody balance.MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН: проекция по внутренним fill observations выбранного portfolio. ЕЩЁ НЕ РЕАЛИЗОВАНО: authoritative valuation, account mapping и P&L.
| Актив | Portfolio | Exact quantity | Источник | Сверка |
|---|---|---|---|---|
| Позиция не загружена: требуется рабочая сессия | ||||
Mock cursor и break queue реализованы. Доступ к Provider Sandbox statement требует активации; authoritative venue/custody statements, ledger организации, SLA и независимый close отсутствуют.
07 / Operational risk
Аварийная остановка и следующий gate
Non-monetary команды сохраняются. Provider Sandbox/public-data transport требует активации; production execution connector ещё не реализован.
ПРОВЕРЕННАЯ ГРАНИЦАMock stop-gate проверяется локально; production scopes должны блокировать submit, сохраняя read, cancel и reconciliation.
ЕЩЁ НЕ РЕАЛИЗОВАНОMock lifecycle проверяет command boundary; production требует market data, tick/lot validation, expiry, slippage controls и best-execution evidence.
ЕЩЁ НЕ РЕАЛИЗОВАНОMock fill projection доступна; production требует account mapping, custody snapshots, GL posting и end-of-day close.
ЕЩЁ НЕ РЕАЛИЗОВАНО06 / Asset movement evidence
Журнал движения активов
Append-only факты в atomic units. Смена статуса создаёт новую запись; этот API не является withdrawal или order endpoint.
Пояснить типы, поля и статусы
Последние движения
SESSION REQUIRED| Время | Тип | Актив | Количество | Статус | Evidence |
|---|---|---|---|---|---|
| Авторизуйтесь для загрузки журнала | |||||
Записать новое наблюдение · требуется сохранённый decision
Записать наблюдение
Связано с eligibility decision11 / Asset reference
Каталог активов
Это справочный UI-каталог исходных значений, а не authoritative effective policy. Реальный допуск всегда заново проверяет серверный eligibility API.
Разобрать активы, сети и atomic units
Не использовать как реестр листингаКаталог не синхронизирован с policy deployment или базой scale registry. Кнопки только открывают формы и ничего не подставляют; сервер остаётся единственным источником решения.
| Актив | Классификация | Сеть / scale | Операции | Режим | Действие |
|---|
Код актива должен присутствовать в effective policy bundle; неизвестные активы не получают ALLOW.
Первая запись фиксирует scale asset/network; конфликт decimals отклоняется без изменения журнала.
Versioned policy approval и разделение ролей реализованы. Для конкретного актива нужны юридическое заключение, risk owner и production activation record.
03 / Organization integration blueprint
Как организация подключает
цифровые активы
Организация сохраняет пользователя, деньги, идентификацию и право финального одобрения. CertaRail принимает заверенные факты, проверяет допустимость операции и связывает её с воспроизводимым evidence.
Открыть коммерческую версию схемы
Это схема capability- и activation-границ, а не карта активных production-подключений.MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН: identity/funds/venue/custody/reporting путь без внешних эффектов. ТРЕБУЕТ АКТИВАЦИИ: готовые Provider Sandbox и read-only public-data adapters. ЕЩЁ НЕ РЕАЛИЗОВАНО: OIDC/ЕСИА, production execution, custody/KYT/НСПК adapters, blockchain broadcast и официальный transport Банка России. Открыть интеграционный mock →
Integration picture / ownership first
Кто находится в системе и где проходит граница
Пользователи работают в каналах организации. Организация передаёт в CertaRail непрозрачную ссылку на пользователя, проверенные факты и намерение. CertaRail принимает решение, фиксирует evidence и в целевой архитектуре обращается к отдельно активируемым провайдерам.
Пользователи
Организация
CertaRail
Внешний мир
- 01 / INTENTПользователь подтверждает операцию в организацииОрганизация знает пользователя и формирует заверенный контекст.
- 02 / CONTROLCertaRail фиксирует решениеReason codes, policy version, digest и audit receipt.
- 03 / MOCK EXECUTIONБезопасная команда и mock-факты исполняютсяDurable journal, hold, fill и custody receipt; Provider Sandbox venue требует активации, production execution ещё не реализован.
- 04 / EVIDENCEФакт возвращается организацииObservation, Kafka event и evidence draft; authoritative production reconciliation ещё не реализована.
Responsibility register
Кто за что отвечает
Граница поставки остаётся модульной: организация может заменить канал или провайдера, не перенося policy и evidence-логику в каждую интеграцию.
| Сущность | Организация | CertaRail | Провайдер / регулятор |
|---|---|---|---|
| Клиент и UX | ВладеетКанал, сессия, ПДн, disclosure | Не забираетТолько opaque refs и необходимые facts | Не видит каналПолучает минимальную команду по контракту |
| Допуск операции | Поставляет фактыKYC, категория, лимиты, согласия | Решает и доказываетOutcome, trace, version, receipt | Не переопределяетИсполняет только активированную команду |
| Деньги и активы | АвторизуетСчёт, резерв, approvals, договор | Не хранитНормализует command и evidence | Исполняет / хранитVenue, custodian, СБП в своей роли |
| Отчётность | РеспондентПроверяет, подписывает и отвечает | Готовит draftManifest, digest, evidence root | ПринимаетТолько после реализации official schema и transport; активация — отдельный последующий gate |
ADVANCED EXPLORER · BUY · BTC / RUB · 8 ИСХОДОВ
Техническая карта операции
Экран предназначен для детального сравнения модулей, исходов, ошибок восстановления и target-состояний. Каждый сценарий остаётся внутри технического контура.
ALLOW разрешает продолжить процесс, но не отправляет ордер автоматически.Организация отдельно подтверждает средства и право исполнения. CertaRail не является биржей, кошельком, custodian или стороной сделки.
Кто за что отвечаетОбщая модель: шесть зон ответственности
Одна операция · шесть зон ответственности
От намерения клиента до проверяемого evidence
- 01 · ПОЛЬЗОВАТЕЛЬВыбирает BTC и сумму в RUBВ канале организации
- 02 · BACKEND ОРГАНИЗАЦИИПодтверждает KYC, screening и средстваБез передачи сырых ПДн
- 03 · CERTARAILВозвращает ALLOW, REVIEW или DENYПричины + policy version + receipt
- 04 · ОРГАНИЗАЦИЯОтдельно одобряет исполнениеFiat hold и maker-checker — под контролем организации
- 05 · MOCK VENUE / CUSTODYВозвращают контролируемые fill и receiptPROVIDER SANDBOX · ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION EXECUTION / CUSTODY · ЕЩЁ НЕ РЕАЛИЗОВАНЫ
- 06 · EVIDENCEСвязывает решение с внешним фактомFill, fee, movement и reconciliation
BUY / ALLOW
Организация покупает BTC за рубли
Организация передаёт заверенные факты, CertaRail выполняет безопасный mock DealFlow и возвращает aggregate evidence. ТРЕБУЕТ АКТИВАЦИИ: Provider Sandbox venue. ЕЩЁ НЕ РЕАЛИЗОВАНО: production execution, authoritative funds и custody transports.
STOP GATE · PROVIDERОбъяснение без терминов API: данные, решение и исполнение
Без терминов API
Кто что передаёт, решает и исполняет
Opaque subject_ref, BTC, сумма в RUB и свежие заверенные статусы — без ФИО, паспорта и access token организации.
ALLOW / REVIEW / DENY, понятные причины, версия правил и audit receipt. Решение сохраняется до любого внешнего действия.
Рубли и ledger — у организации; рыночный order — у venue; ключи и хранение — у custodian; on-chain риск — у KYT.
Показать поля и детали APIФорма пользователя → заверенные факты организации → versioned CertaRail contractОТКРЫТЬСКРЫТЬ
Payload boundary
Что ввёл пользователь — и что добавила организация
Пользователю не показывают техническую анкету CertaRail. Он заполняет форму организации; backend организации добавляет только заверенные факты и непрозрачные ссылки.
Вводит сам
Добавляет автоматически
Получает на границе
Синтетическая схема · external_calls=0
Куда идёт операция и какие модули срабатывают
Последовательность шагов от интерфейса организации через backend организации, CertaRail, внешнего провайдера и обратно в evidence-контур. Каждый шаг открывается кнопкой.
Показ схемы объясняет последовательность; запросы и внешние команды не выполняются.
ПОЛЬЗОВАТЕЛЬ · ORG-OWNED
Выбирает актив и сумму
- Что пришло
- Что сделал модуль
- Что сохранилось
- Что вышло
- Владелец данных
Все шаги в таблице: входы, решения, выходы, evidence и recovery
| Шаг | Владелец | Вход | Действие | Выход | Evidence | Статус и восстановление |
|---|
Command / evidence loop
Что CertaRail делает с биржей
Не «передаёт BUY и надеется», а защищает уникальность команды и связывает каждый внешний исход с исходным решением.
- 01Committed decisionALLOW + audit receipt
- 02Резерв организацииproduction gate организации
- 03Immutable commandcommand_id + canonical hash
- 04Mock venue pathРЕАЛИЗОВАНО · PROVIDER SANDBOX ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION VENUE ЕЩЁ НЕ РЕАЛИЗОВАН
- 05ACK / UNKNOWNACK ещё не fill
- 06Inbox + lookuplookup first, no blind retry
- 07Fill observationappend-only evidence
Не биржа.CertaRail не создаёт ликвидность и не держит клиентский счёт.
Заменяемый adapter.Core не знает vendor-specific API.
Timeout ≠ отказ.Сначала lookup и reconciliation, затем решение оператора.
Реализованная граница.Submit-once работает без движения денег; HTTP к Provider Sandbox требует активации, production execution transport ещё не реализован.
Other operation shapes
Чем отличаются остальные операции
СБП и blockchain не вставляются в каждую покупку автоматически: это отдельные rails со своими доказательствами финальности.
| Операция | Что резервируется | Нужен внешний rail | Какой факт сохраняется | Статус capability |
|---|---|---|---|---|
| BUY | Mock RUB hold | Mock venue; СБП только для отдельного funding | BUY_FILL + fee + custody evidence | MOCK FLOW РЕАЛИЗОВАНProvider Sandbox venue требует активации; production funds/execution/custody ещё не реализованы |
| SELL | Позиция актива | Venue + fiat settlement | SELL_FILL · asset debit · fiat credit | ЕЩЁ НЕ РЕАЛИЗОВАНОpolicy и settlement path отсутствуют |
| DEPOSIT | Ничего до finality | Custody address + blockchain + KYT | DEPOSIT after confirmations | ЕЩЁ НЕ РЕАЛИЗОВАНОесть только fixture observations |
| WITHDRAWAL | Актив + network fee | KYT + Travel Rule + custody broadcast | WITHDRAWAL + tx confirmations | ЕЩЁ НЕ РЕАЛИЗОВАНОsigning/broadcast отсутствуют |
| EXCHANGE | Исходный актив | Venue; две legs и fees | SWAP_LEG observations | ЕЩЁ НЕ РЕАЛИЗОВАНОpolicy, two-leg atomicity и settlement отсутствуют |
| СБП FUNDING | Mock payment limit | Mock СБП fixture; adapter НСПК отсутствует | Final mock payment status, не QR | MOCK РЕАЛИЗОВАНЕЩЁ НЕ РЕАЛИЗОВАНО: НСПК adapter |
Why organizations choose CertaRail
Какую проблему решает платформа
- Правила дублируются в mobile, web, B2B и у каждого провайдера.
- Один versioned intent и один policy contract для всех каналов.
- Timeout способен породить повторный order или потерянный side effect.
- Durable command identity и lookup-first recovery без слепого повтора.
- Fill, fee и custody movement трудно связать с причиной допуска.
- Decision → command → observation → digest образуют единую доказуемую цепь.
- Сверка и отчётность собираются вручную постфактум.
- Append-only evidence, outbox и воспроизводимый JSON draft с явным stop gate.
02B / Архитектура системы
Архитектура CertaRail
Техническая схема показывает, где работает CertaRail, какие данные и полномочия остаются у организации, как отделена внешняя командная граница и какие профили размещения рассматриваются.
Три контура
Решение, полномочия организации и внешнее исполнение разделены.
- 01
Контур организацииПользователь, UX, KYC/KYB, деньги, лимиты и approvals
- 02
Контур CertaRailDecision engine, evidence, authoritative state и outbox
- 03
Внешний контурVenue, custody, KYT, платёжные и регуляторные rails
Архитектура / владение контурами
Контуры системы и границы команд
Канал организацииORG-OWNED
- Клиентисточник подтверждённого намерения операции
- Mobile / web / B2Bорганизация владеет UX, сессией и disclosure
- Backend организациипроверяет KYC/KYB, счёт, лимит и funds hold
Не выходит из организации: ФИО, паспорт, реквизиты, биометрия, пароль, access token и KYC/KYB-документы.
Контур CertaRailВНУТРИ КОНТУРА ОРГАНИЗАЦИИ
CertaRail получает: opaque customer ref, facts version, нормализованные статусы, intent и ссылки на evidence.
Внешние провайдерыВНЕШНЯЯ КОМАНДНАЯ ГРАНИЦА
- Venue / brokermock order, ACK, fills, fees; Provider Sandbox adapterMOCK РЕАЛИЗОВАН · PROVIDER SANDBOX ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION EXECUTION ЕЩЁ НЕ РЕАЛИЗОВАНО
- Custody / KYTmock receipt/screening fixtures; provider adapters отсутствуютMOCK РЕАЛИЗОВАН · REAL ЕЩЁ НЕ РЕАЛИЗОВАН
- СБП / НСПКmock link/status/refund recovery; НСПК adapter отсутствуетMOCK РЕАЛИЗОВАН · REAL ЕЩЁ НЕ РЕАЛИЗОВАН
- Банк Россииmock report sink / evidence draft; official transport отсутствуетMOCK РЕАЛИЗОВАН · OFFICIAL НЕДОСТУПЕН
Владелец внешней интеграции: организация. Граница CertaRail — контракт адаптера и evidence conformance-тестов.
Текстовый реестр всех компонентов и владельцев
| Компонент | Владелец | Назначение | Статус и граница |
|---|
Профили размещения
Варианты инфраструктурного контура
Это сравнение технических профилей, а не этапы внедрения. Выбирается среда, которую организация уже умеет безопасно эксплуатировать.
| Профиль | Статус | Что разворачивается | Кому подходит | Ограничение |
|---|---|---|---|---|
| Compose verification profile | РЕАЛИЗОВАНО | Nginx, API ×2, migrator, PostgreSQL, Redis/Valkey, Kafka, outbox | Discovery, contract и fault checks | Single-node stateful services; не production topology |
| Изолированный pilot contour | ТРЕБУЕТ АКТИВАЦИИ | Тот же application bundle + IdP и provider environments организации | Интеграционный UAT без реальных денег | Требует landing zone, PKI и подготовленные данные |
| OCI / VM on-prem | ТРЕБУЕТ АКТИВАЦИИ | Immutable API/outbox images; managed PostgreSQL, Kafka, Vault/KMS организации | Первый production-профиль организации | Signed OCI/SBOM и HA/DR остаются gate |
| Kubernetes / private cloud | CONDITIONAL | Отдельные API, outbox и workflow deployments; managed stateful layer | Организация с действующим platform standard | Service mesh и Temporal — только по измеримому триггеру |
08 / План внедрения
План внедрения CertaRail
Путь начинается не с развёртывания и не с биржи. Организация сначала фиксирует один криптовалютный сценарий, владельцев и границы риска, затем проверяет его в изолированном контуре и только после этого допускает внешние rails.
Логика допуска
Семь этапов. Следующий открывается только после evidence предыдущего.
- 01
Сначала — границы и владельцыОдин сценарий, юридическая роль, RACI и целевой контур
- 02
Затем — изолированный контур и UATКонтракты, изоляция и отказные сценарии без реальных денег
- 03
Только после gate — внешние railsОфициальный контур приёмки, согласование организации и отдельная активация
Семь этапов
От одного сценария до контролируемого запуска
Это последовательность gate, а не список технологий. В каждой строке видно, кто делает работу, что становится результатом и почему следующий этап пока закрыт.
01Сценарий и владельцыЗафиксировать один понятный криптовалютный use case и ответственность сторон.
FIRST STEP
Что делает организация
Определяет юрлицо и роль, сценарий BUY / RUB / RU, актив и сеть, профиль пользователя, владельцев Product, Legal, Compliance, Security и Operations.
Что поставляет CertaRail
Шаблон паспорта сценария, data-flow, RACI, capability matrix, blocker register и план приёмки.
Критерий перехода
Письменно согласованы scope, правовая граница, состав данных, владельцы решений и список систем организации.
02Целевой контур и безопасностьMock-профиль доступен; production размещение и trust boundaries активируются с организацией.
MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН
Что делает организация
Выбирает landing zone и профиль размещения; владеет IdP, PKI, сетью, Vault/KMS, классификацией данных, managed stores, retention и RTO/RPO.
Что поставляет CertaRail
Целевую topology, data-flow и threat model, RBAC/RLS plan, перечень портов, capacity assumptions и границы эксплуатационной ответственности.
Критерий перехода
Architecture, Security и Privacy утвердили topology, trust boundaries, среды и владельцев ресурсов организации.
03Production-контракты и evidence coreПринять поведение API и evidence на подготовленных данных.
РЕАЛИЗОВАНО
Что делает организация
Маппит KYC/KYB, категорию, consent и лимитные факты в opaque references; прогоняет contract suite на подготовленных обезличенных данных.
Что поставляет CertaRail
Versioned OpenAPI, AsyncAPI и schemas, reason codes, idempotency и failure semantics, production-код policy decisions, limits, audit, outbox и evidence pack.
Критерий перехода
Contract и fault tests приняты; повтор и conflict 409 воспроизводимы; evidence подтверждает external_calls = 0 и monetary = false.
04Интеграция с организацией и UATMock backend подключается в non-monetary контуре; production UAT требует активации.
MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН
Что делает организация
Поднимает IdP/PKI контура приёмки и network route, настраивает gateway и consumers, назначает rule owners и проводит UAT одного BUY-сценария.
Что поставляет CertaRail
Конфигурацию pilot contour, identity-derived tenant boundary, интеграцию rule pack и limits, negative tests, recovery и проверяемое UAT evidence.
Критерий перехода
Пройдены ALLOW/REVIEW/DENY, replay/409, cross-tenant isolation, concurrent limits, privacy и recovery tests.
05Изолированный контур провайдераАктивировать отдельное окружение выбранного контрагента.
ТРЕБУЕТ АКТИВАЦИИ
Что делает организация
Выбирает разрешённого провайдера, владеет договором, получает официальный контур приёмки и выдаёт ограниченные credentials через Vault/KMS с согласованными лимитами.
Что поставляет CertaRail
Монтирует production-код Deal Core, Provider Operations и ledger seams, связывает adapter с durable command, callback/inbox и reconciliation.
Критерий перехода
Пройдены signature, duplicate, timeout, UNKNOWN → lookup, gap/backfill, rate-limit, revocation и reconciliation fault tests.
06Preproduction и приёмкаДоказать безопасность, эксплуатацию и восстановление поставки.
MANDATORY GATE
Что делает организация
Проводит vendor assessment, pentest, capacity test, backup/restore и failover drills, CAB, DLP review и on-call rehearsal.
Что поставляет CertaRail
Signed OCI/SBOM/provenance, migrations и rollback, SLO, runbooks, dashboards, WORM/SIEM plan и offline verification bundle.
Критерий перехода
Security, HA/DR, capacity, observability и incident evidence приняты; владельцы подписали точные hashes конфигурации и релиза.
07Ограниченный productionЭтап закрыт, пока нет полного provider/custody/reporting контура и всех approvals.
НЕДОСТУПНО В ТЕКУЩЕЙ ПОСТАВКЕ
Что делает организация
Подписывает versioned activation record: одно юрлицо, один сценарий и provider, один актив/сеть, малый cohort, низкие лимиты, kill switch, rollback и владельцев 24×7.
Что поставляет CertaRail
Поддерживает утверждённую версию, evidence и reconciliation controls, L3 и проверяемую границу доступа без привилегий сотрудников по умолчанию.
Критерий перехода
Одновременно закрыты право, provider contract, controls и approval; подтверждены custody/KYT/ledger и денежная сверка.
Граница продукта
С какого состояния начинается этот план
Go API, две stateless-реплики, PostgreSQL, optional Redis, outbox, Kafka, policy decisions, authoritative limits, audit, movement evidence и report draft.
OIDC/ЕСИА, custody, KYT и СБП/НСПК adapters, production tenant mapping, managed HA/DR, signed release bundle, WORM anchor и provider workers.
Только готовые adapters, например Provider Sandbox и read-only public-data contracts, переходят сюда до account, credentials, сети и приёмки.
Mainnet-трансфер и официальная отправка в Банк России отсутствуют и заблокированы; это не activation toggle.
RACI / ownership
Кто отвечает за каждую часть
CertaRail отвечает за качество поставки и contracts. Организация остаётся accountable за пользователя, деньги, ключи, провайдеров, production activation и регуляторную отправку.
| Работа | Организация | CertaRail | Внешний участник | Приёмочное evidence |
|---|---|---|---|---|
| Пользователь, KYC/KYB и ПДн | Владеет и утверждает | Принимает только opaque facts | Не получает сессию организации | Data map + privacy review |
| IAM, PKI и tenant | Владеет IdP/keys | Реализует verifier и RBAC | Выдаёт свои provider certs | Claims contract + isolation tests |
| Деньги и funds hold | Владеет core posting | Связывает opaque funds_hold_ref | Исполняет settlement в своей роли | End-to-end reconciliation |
| Policy и лимиты | Утверждает правила | Версионирует и исполняет | Не меняет решение организации | Rule pack + maker-checker receipt |
| Инфраструктура и HA | Эксплуатирует | Поставляет topology и runbooks | Отвечает за свой SLA | Restore/failover drill |
| Provider contract | Выбирает и заключает | Реализует adapter contract | Выдаёт test/prod entitlement | Conformance + fault report |
| Отчётность | Официальный респондент | Готовит проверяемый пакет | Регулятор принимает или отклоняет | Schema, УКЭП, receipt, correction flow |
| Production activation | Финальный accountable | Подписывает release facts | Подтверждает rail readiness | Versioned activation record |
Acceptance package
Что организация получает и принимает
Это целевой реестр поставки. Наличие строки не означает, что артефакт уже production-ready; фактический статус закрывается evidence конкретного внедрения.
Governanceuse-case passport · legal memo · RACI · provider due diligence
ORGANIZATION + CERTARAILContractsOpenAPI · AsyncAPI · JSON Schema · reason codes · failure semantics
VERSIONEDSecurityThreat model, scoped FORCE RLS и security gates реализованы; production PKI/HSM/pentest требуют приёмки.
РЕАЛИЗОВАНОOperationsHealth/readiness, observability, reconciliation и runbooks реализованы; production SLO/restore drills требуют приёмки.
РЕАЛИЗОВАНОReleaseOCI digest, CycloneDX SBOM и unsigned evidence bundle реализованы; trusted signing/provenance ещё не реализованы.
РЕАЛИЗОВАНОAcceptanceUAT · isolation · performance · chaos · privacy · security evidence
ORG APPROVALActivationpolicy hash · endpoint/certificate set · cohort · limits · rollback plan
DEFAULT DENYImplementation, environment, activation, external effect и production readiness загружаются только из certarail.capability-surface.v1. Legacy adapter catalogue остаётся runtime-входом для mock tools, но не отображается как capability status.
Пояснить оси статуса
Implementation stateНасколько capability реализована и проверена кодом и тестами
Activation stateРазрешён ли внешний production-контур фактически
Откройте рабочую сессию, чтобы загрузить фактические implementation и activation states.
07 / Evidence package
Регуляторный draft
MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН: воспроизводимый JSON-пакет и mock receipt из append-only журнала. Схема V0 не является официальной формой Банка России; ЕЩЁ НЕ РЕАЛИЗОВАНО: official schema, УКЭП, transport и receipt ingestion.
Проверить reporting mock → · Пояснить состав, digest и blockers
Как формируется draft: факты, схема, digest, review и закрытая отправка
- 01Journal factsPostgreSQL
- 02Normalizeschema V0
- 03DigestSHA-256
- 04Reviewevidence only
- 05SubmissionCLOSED
Параметры снимка
CBR movement draft
CBR_CRYPTO_MOVEMENT_DRAFT_V0- Источник
- PostgreSQL movement evidence
- Результат
- JSON + digest + evidence root
- Network
- NONE
Evidence document
Пакет ещё не сформирован
После формирования здесь появятся период, полнота, digest, evidence root и блокирующие условия.
10 / Production gates
Матрица готовности
Readiness и blockers отображаются из тех же canonical capability records, что `/status`, marketing и API. Ни один внешний контур не считается подключённым без owner-approved evidence.
Пояснить каждый production gate
—INACTIVE / UNKNOWN
—DESIGN_ONLY
—NOT_IMPLEMENTED
Это счётчик независимых canonical axes, а не процент production readiness.
Capability boundaries
Активные предупреждения
- Откройте рабочую сессию для загрузки предупреждений.
Авторизуйтесь, чтобы увидеть фактические capability- и activation-границы.
13 / Developer Console · Getting Started
Первый проверяемый запрос
Откройте API-сессию и пройдите пять шагов: запрос, решение, безопасный повтор, доказательства и тестовое событие.
Все разделы доступны для просмотра. Для запросов к данным организации откройте API-сессию.
Runtime map
Что доступно в этой сессии
Показатели ниже заполняются только canonical contracts и текущим platform overview.
Runtime components
Наблюдаемый контур
- Откройте API-сессиюНЕ ЗАГРУЖЕНО
Security posture
Credential boundary
- Bearer credentialMemory only
- Checkout grantRunner scope only
- Arbitrary URLЗапрещён
- Safe JSON exportRedacted
Guided path
Начать интеграцию
Статус каждого шага выводится из server overview и фактических запусков текущей вкладки.
- 01Подключить sandboxMemory-only credential и server-derived tenantТРЕБУЕТСЯ СЕССИЯ
- 02Выполнить первый запросQuickstart сохраняет safe request/response recordНЕ ЗАПУСКАЛСЯ
- 03Запустить BUY-сценарийHEADLESS non-monetary lifecycleНЕ ЗАПУСКАЛСЯ
- 04Настроить webhookВстроенный signed Inbox; внешний transport остаётся заблокированНЕ ПРОВЕРЕН
- 05Проверить evidenceCorrelated timeline и safe exportНЕТ ЗАПИСЕЙ
- 06Изучить production readinessОбязательные gates и конкретные blockersТРЕБУЕТСЯ СЕССИЯ
Getting Started · 5 verified steps
Первый безопасный sandbox flow
- 01Connect sandboxОЖИДАНИЕ
GET /v1/platform/overview · memory-only bearer - 02Run eligibilityОЖИДАНИЕ
HEADLESS session + POST /preflight · HAPPY_PATH - 03Replay safelyОЖИДАНИЕ
Те же body и Idempotency-Key · без повторного эффекта - 04Inspect evidenceОЖИДАНИЕ
GET /v1/checkout/sessions/{session_id}/timeline - 05Send test webhookОЖИДАНИЕ
Signed checkout.test · IN_PROCESS_INBOX · external_calls=0
One-time response · memory only
Сохраните signing secret сейчас
После подтверждения значение будет стёрто из DOM и памяти страницы. Оно не входит в run log или evidence export.
Redacted run log
Результаты Getting Started
Запуск ещё не выполнялся.
API Explorer доступен в любое время. Подтверждённые шаги показывают прогресс первого запроса.
OpenAPI-driven
API Explorer
Метод и path нельзя ввести вручную: список строится из canonical OpenAPI. Запрос всегда отправляется только на текущий origin.
Redacted inspector
Request / response
{
"status": "Запрос ещё не выполнялся"
}
Детали запроса и источник
Safe opaque IDs появятся после запроса.
Server-owned catalog
Executable acceptance scenarios
Server-owned catalog загружается после открытия API-сессии…
Контролируемый запуск
Протокол сценария
Выберите сценарий и настройте запуск. Здесь откроются prerequisites, сумма и протокол; запросы начнутся после явного запуска.
AsyncAPI + Checkout
Webhooks, events и реальный BUY-контур
Runner создаёт HEADLESS session, выполняет exact replay, scoped bootstrap, preflight, quote и confirm, затем читает operator timeline и проверяет подписанный envelope.
Canonical event channels
AsyncAPI catalog
Контракт событий загружается…
Durable PostgreSQL Scenario Run
Запуск не выбран
Run details появятся после backend commit или при прямом открытии URL.
Source · developer_scenario_runs
Requests
Durable run projection не загружен.
Source · developer_evidence_packs
Evidence
Latest Evidence Pack не загружен.
Source · checkout timeline
Logs
Authoritative timeline не загружен.
Source · checkout webhook journal
Webhooks
Delivery journal не загружен.
Timeline
- Timeline не загружен.
Assertions
Assertions не загружены.
Independent state axes
Authoritative projection
Identifiers
Safe evidence references
Operator evidence
Timeline and deliveries
Tenant-scoped TEST runtime
Webhook Inbox endpoint lifecycle
Create → verify → activate, pause/reactivate, secret rotation, revoke и tombstone delete выполняются через bearer API текущего server-derived tenant. Delivery signature verify остаётся отдельной evidence-операцией.
- Environment binding
- TEST_ONLY
- Transport
- IN_PROCESS_INBOX
- External
- external_calls=0
- Money
- monetary=false
- Authority
- production_enforceable=false
- LIVE authority
- ЕЩЁ НЕ РЕАЛИЗОВАНО
List + read
Sandbox subscriptions
Append-only projection
Delivery journal
Выберите active Inbox.
Signed delivery evidence
Delivery operations
Transport attempts
0 / 0- Transport attempts отсутствуют.
Manual replay receipts
0 receipts- Manual replay ещё не выполнялся.
Raw delivery JSON
Delivery не выбран.
Honest product boundary
Что sandbox Inbox не доказывает
- BLOCKED_EXTERNALexternal HTTPS transport и реальная доступность endpoint · ЕЩЁ НЕ РЕАЛИЗОВАНО
- BLOCKED_EXTERNALproduction webhook subscription authority · ЕЩЁ НЕ РЕАЛИЗОВАНО
- BLOCKED_EXTERNALproduction signing-key custody / rotation · ЕЩЁ НЕ РЕАЛИЗОВАНО
- BLOCKED_EXTERNALproduction retry policy и operator authority · ЕЩЁ НЕ РЕАЛИЗОВАНО
Canonical Capability Status
Implementation, environment, activation и effect отдельно
Статусы поступают только из overview.capability_status; legacy adapter data используется ниже только для server-side sandbox binding.
Durable organization bindings · sandbox only
Identity → Payment → Venue → Custody
Откройте memory-only API-сессию с ролью developer:admin.
Credential отсутствует; binding administration не выполняется.
Activation сохраняет versioned MOCK connection, configuration digest, actor и PostgreSQL time. Raw provider secrets не принимаются; production authority, external calls и monetary effect не создаются.
Published registry
Capability records и blockers
Registry не заменяет exact organization binding: Scenario Runner повторно проверяет оба server-side источника до первой мутации.
Откройте API-сессию, чтобы загрузить canonical capability_status.
Current tab + operator reads
Logs & Evidence
Portable Evidence Pack · backend generated
Evidence Pack не выбран
Verified означает только криптографическую целостность sandbox-пакета.
Проверена криптографическая целостность sandbox-пакета. Это не подтверждает реальное движение средств, сертификацию или юридическую силу.
Pack не загружен.
Graph не загружен.
Manifest не загружен.
Verification не загружена.
Exact canonical bytes выбранного artifact декодируются из canonical_base64 без JSON reserialization.
Artifact не выбран.
Независимая проверка тем же portable contract:
certarail-evidence-verify -pack ./certarail-evidence-pack.jsonCorrelation и core opaque IDs индексируются в PostgreSQL только как SHA-256; raw reference не сохраняется. Для recent request/report aliases backend явно показывает bounded scope и truncation. Экспорт исключает bearer, URL query credentials, session_token, session_credential, Authorization и cookies.
Opaque IDs появятся после первого safe record.
Append-only view
Evidence stream
Нет evidence в текущей вкладке.
Canonical registry
Production readiness по capability
Каждая запись содержит независимые axes, evidence, владельца и owned blockers. Общий процент намеренно отсутствует.
Откройте API-сессию: readiness публикуется в canonical capability_status.
Откройте API-сессию для загрузки canonical readiness records.
Interactive reference
Generated operations и session evidence
Long-form architecture, API semantics, errors, auth и environments вынесены в Developer Portal. Здесь остаются generated переходы в Explorer и сценарии текущей сессии.
OpenAPI 3.1
Загрузка canonical JSON…
AsyncAPI
Загрузка canonical JSON…
Long-form explanations живут в Developer Portal. Console сохраняет только generated operation register, переходы в Explorer и session-derived scenario evidence.
Generated from state.operations
OpenAPI operation register
operationId, method/path, security и error statuses отражают текущий canonical JSON. Кнопка открывает ту же операцию в Explorer.
Canonical OpenAPI загружается…
Generated from server-owned scenario catalog
Scenario documentation register
До запуска примеры честно помечены NOT_RUN. После запуска request/response/error evidence открывается из durable Scenario Run.
Каталог сценариев загружается…
14 / Identity boundary
Доступ и сессия
API-сессия использует tenant-bound bearer. Credential хранится только в памяти текущей вкладки и стирается при отключении, перезагрузке или закрытии.
Открыть auth и authority documentation
Browser session
Рабочая сессия не открыта
Введите API credential; он не попадёт в cookie, URL, cache, localStorage или sessionStorage.
Server-derived tenant, principal, organization и roles работают с memory-only credential. ЕЩЁ НЕ РЕАЛИЗОВАНО: Authorization Code + PKCE и service mTLS adapter.
Generic identity fixture доступен отдельно. ЕСИА adapter, регистрация ИС, scopes, ГОСТ и ПДн-проект ещё не реализованы.
Проверить identity fixture →API кабинета организации выводит роли из credential, запрещает self-approval и сохраняет независимое approval evidence. Production IdP, MFA и step-up binding ещё не реализованы.