ВНЕШНИЕ ВЫЗОВЫ · 0

Инженерный этап кабинета организации

Сводка среды

ВНЕШНЕЕ ИСПОЛНЕНИЕ НЕ ПОДКЛЮЧЕНО
API · проверка Store · проверка Snapshot · нет

Кабинет организации → инженерный этап

Техническая реализация маршрута организации.

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 ЗАКРЫТО
Decisionpolicy + reason codes
РЕАЛИЗОВАНО
Audit receiptimmutable evidence
РЕАЛИЗОВАНО
Movementobservation only
РЕАЛИЗОВАНО
Outboxhandoff boundary
ЗАПИСАННЫЙ ФАКТ
Report draftdigest + evidence root
НЕ ОТПРАВЛЯЕТСЯ
Identity организацииРЕАЛИЗОВАНО · SERVER-DERIVED MOCK IDENTITYOIDC / ЕСИА · ЕЩЁ НЕ РЕАЛИЗОВАНО VenueРЕАЛИЗОВАНО · БЕЗОПАСНЫЙ MOCK-СЦЕНАРИЙPROVIDER SANDBOX / PUBLIC DATA · ТРЕБУЕТ АКТИВАЦИИPRODUCTION EXECUTION · ЕЩЁ НЕ РЕАЛИЗОВАНО СБП / custody / KYTРЕАЛИЗОВАНО · БЕЗОПАСНЫЕ FIXTURESРЕАЛЬНЫЕ ADAPTERS · ЕЩЁ НЕ РЕАЛИЗОВАНЫ ReportingMOCK-СЦЕНАРИЙ РЕАЛИЗОВАН · EVIDENCE REPORT / DRAFTOFFICIAL OUTBOUND · НЕДОСТУПЕН
PostgreSQL хранит факты и evidencedecision → receipt → observation → draft
Решения · 24ч
—ожидает авторизации
Движения · 24ч
—ожидает авторизации
Outbox backlog
—ожидает авторизации
Отправка в Банк России
НЕДОСТУПНОOfficial schema, роль респондента, УКЭП и transport отсутствуют; outbound hard-disabled

Decision telemetry

Распределение решений

SESSION REQUIRED
—SESSION REQUIRED
ALLOW
—
REVIEW
—
DENY
—

Platform coverage

Готовность модулей

TRUTHFUL STATUS
Матрица возможностей закрыта

Откройте рабочую сессию, чтобы загрузить фактические состояния.

Evidence rail

Состояние асинхронного контура

SESSION REQUIRED
PostgreSQLOutboxKafka handoff
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. Исходные контактные данные в браузер не передаются.

DELIVERED = внутренняя рабочая очередь. Это не подтверждение CRM, email, ответа команды или обработки человеком. Manual replay доступен только после dead-letter и требует operator-роли.

Откройте рабочую API-сессию для загрузки delivery snapshot.

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 сюда не передаётся.

Поиск требует рабочей bearer-сессии организации и не поддерживает cross-tenant lookup.

Сессия ещё не выбрана.

17 / Executable product tour

Проверить ключевые сценарии.
Увидеть доказательства.

Раздел проверяет ключевые пути production-кода: от eligibility, trade и movement evidence до Policy Studio, лимитов, REVIEW cases, Travel Rule, depository, wallet-design и provider workbenches. Открыть технический сценарий

Исполняемый безопасный mock-контурMOCK-СЦЕНАРИИ РЕАЛИЗОВАНЫ: venue/СБП recovery, BUY, AssetLink, blockchain-confirmation fixture и reporting receipt. ТРЕБУЕТ АКТИВАЦИИ: Provider Sandbox venue. ЕЩЁ НЕ РЕАЛИЗОВАНО: production execution, НСПК adapter, mainnet broadcast и официальная отправка в Банк России.
  • opaque refs
  • production code
  • fail-closed checks

Основной acceptance launchpad

Один запуск — ключевые сценарии production-кода

Каждый шаг проверяет ожидаемый HTTP-контракт и сохраняет только безопасные evidence ID, коды и длительность. Bearer-токен в отчёт не попадает.

Готово к запуску0 / 20
0 из 20
Дополнительные рабочие модули10 специализированных контуров с фактическими статусами capabilitiesПоказать каталогСкрыть каталог

Capability workbenches

Рабочие модули — с фактическим статусом реализации

Статусы загружаются из /v1/platform/overview. Кнопки запускают только реализованные non-monetary команды и выводят IDs, digests и закрытые внешние gates в протокол проверки.

01
GOVERNANCE

Policy Studio

Откройте рабочую сессию для проверки lifecycle и capability boundary.

REVISION_LIFECYCLE · IMPACT
SESSION REQUIRED
02
CONTROL

Реестр лимитов

Откройте рабочую сессию для проверки exact-value reservation evidence.

CONFIGURE · RESERVE · FINALIZE
SESSION REQUIRED
03
COMPLIANCE

REVIEW case desk

Откройте рабочую сессию для проверки append-only case evidence.

OPEN · ASSIGN · RESOLVE
SESSION REQUIRED
04
COMPLIANCE

Travel Rule evidence router

Откройте рабочую сессию для assessment-проверки без передачи ПДн.

RULESET · DIRECTORY · ASSESS
SESSION REQUIRED
05
LEDGER

Digital Depository Book of Record

Откройте рабочую сессию для проверки точных atomic-unit записей.

ASSET · ACCOUNT · OPERATION · EXTRACT
SESSION REQUIRED
06
CUSTODY CONTRACT

Wallet provisioning registry

Откройте рабочую сессию для проверки evidence без ключей и адресов.

CONTRACT · ADDRESS INTENT · SUBJECT READ
SESSION REQUIRED
07
ORCHESTRATION

AssetLink journey evidence

Откройте рабочую сессию для проверки PURCHASE/TRANSFER intent и одноразовой ссылки без исполнения.

PURCHASE · TRANSFER LINK · RESOLVE · CONFIRM · CANCEL
SESSION REQUIRED
08
OPERATIONS

Provider conformance

Откройте рабочую сессию для contract evaluation.

VENUE · CUSTODY · KYT · PAYMENT
SESSION REQUIRED
09
REPORTING

Cross-border data-pack

Откройте рабочую сессию для gap matrix без legal assurance.

CORRIDOR DRAFT · DATA GAPS · DIGEST
SESSION REQUIRED
10
EVIDENCE

Portable evidence verifier

Откройте рабочую сессию для загрузки статуса verifier tool.

CREATE PACK · VERIFY · OPTIONAL ED25519
SESSION REQUIREDCLI · без browser mutation

04 / Policy decision

Предторговый контроль

Детерминированное решение по заверенным фактам организации. HTTP 200 используется для ALLOW, REVIEW и DENY; исполнение отделено от оценки.
Пояснить все поля и результаты

Контекст операции

Все ссылки — opaque, без ПДн
Пользователь и факты организации
Transaction intent
Investor controls

Оценка не исполняет операцию

Decision trace

Ожидает запуска
AUDIT RECEIPT

Готово к проверке

Запустите сценарий: здесь появятся outcome, применённые правила и криптографические доказательства.

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

EligibilityРЕАЛИЗОВАНОДетерминированный BUY-control
Mock order + fillРЕАЛИЗОВАНОDurable PostgreSQL · non-monetary evidence
Provider Sandbox + public dataТРЕБУЕТ АКТИВАЦИИAccount или network route, credentials и UAT
Production execution + fundsЕЩЁ НЕ РЕАЛИЗОВАНОTrading, authoritative ledger и custody bindings отсутствуют

01 / Organization-attested intent

Торговое поручение

PRODUCTION CODE
Пользователь и заверенные факты организации

Стабильная непрозрачная ссылка связывает order с тем же клиентом, которого проверил eligibility. Это не ФИО, телефон, паспорт или другой идентификатор ПДн.

Поручение и control cap

Max notional — верхняя граница команды, равная сумме eligibility. Это не котировка и не цена исполнения.

Реализованная policy поддерживает только BUY.

Реализованный контракт поручения
SideBUY
Order typeMARKET
Time in forceIOC
QuoteRUB
Provider scope и ссылки организации

MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН: correlation fixture и corporate maker-checker. PROVIDER SANDBOX ENTITLEMENT ТРЕБУЕТ АКТИВАЦИИ. PRODUCTION IAM И EXECUTION ЕЩЁ НЕ РЕАЛИЗОВАНЫ.

02 / Evidence before command

Ворота исполнения

SESSION REQUIRED

Сначала нужно решение

Откройте рабочую сессию и проверьте поручение. Ни один provider command не формируется до сохранённого decision.

  1. 01
    Eligibility decisionОжидает проверки
    WAITING
  2. 02
    Резерв средствВладелец — ledger организации
    ORG-OWNED
  3. 03
    Maker-checkerApproval flow организации реализован; production OIDC, MFA и step-up binding ещё не реализованы
    РЕАЛИЗОВАНО
  4. 04
    External providerMock path доступен в Verification. Для готового adapter нужны credentials и network route; отсутствующий adapter сначала реализуется.
    CATALOG-DEPENDENT

Сохраняется только внутреннее поручение.Durable order не вызывает биржу и не меняет деньги или активы.

03 / Durable lifecycle

Что произошло с последней командой

NO COMMAND
  1. 01Decision committedЕщё не order
  2. 02Order persistedPostgreSQL transaction
  3. 03External venuePROVIDER SANDBOX ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION VENUE ЕЩЁ НЕ РЕАЛИЗОВАН · external calls = 0
  4. 04Fill evidenceOperator-created fixture only
  5. 05ReconciliationMOCK CURSOR РЕАЛИЗОВАН · PROVIDER SANDBOX STATEMENT ТРЕБУЕТ АКТИВАЦИИ · AUTHORITATIVE VENUE/CUSTODY STATEMENTS ЕЩЁ НЕ РЕАЛИЗОВАНЫ
Environment —Monetary —External calls —Production enforceable —

04 / Durable order register

Order blotter

Состояние PostgreSQL; ни одна строка не является live venue order.
SESSION REQUIRED
Durable order records текущей организации
СозданClient orderИнструментПоручениеDecisionCommandVenueFilledEvidence
Авторизуйтесь для загрузки order blotter

05 / Selected order

Fill observation и cancel

NO SELECTION

Выберите строку blotter. Fill observation запишет durable non-monetary факт; это не рыночное исполнение.

06 / Derived position projection

Позиции и сверка

SESSION REQUIRED · NOT AUTHORITATIVE

Это не ledger организации и не custody balance.MOCK-СЦЕНАРИЙ РЕАЛИЗОВАН: проекция по внутренним fill observations выбранного portfolio. ЕЩЁ НЕ РЕАЛИЗОВАНО: authoritative valuation, account mapping и P&L.

Неавторитетная проекция позиций
АктивPortfolioExact quantityИсточникСверка
Позиция не загружена: требуется рабочая сессия
ЕЩЁ НЕ РЕАЛИЗОВАНО

Mock cursor и break queue реализованы. Доступ к Provider Sandbox statement требует активации; authoritative venue/custody statements, ledger организации, SLA и независимый close отсутствуют.

07 / Operational risk

Аварийная остановка и следующий gate

REAL EXECUTION · НЕДОСТУПНО
NOWBuild-time hard stop

Non-monetary команды сохраняются. Provider Sandbox/public-data transport требует активации; production execution connector ещё не реализован.

ПРОВЕРЕННАЯ ГРАНИЦА
GATEProduction kill switch

Mock stop-gate проверяется локально; production scopes должны блокировать submit, сохраняя read, cancel и reconciliation.

ЕЩЁ НЕ РЕАЛИЗОВАНО
GATELIMIT / GTC / FOK

Mock lifecycle проверяет command boundary; production требует market data, tick/lot validation, expiry, slippage controls и best-execution evidence.

ЕЩЁ НЕ РЕАЛИЗОВАНО
GATEAuthoritative positions

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 decision
SESSION REQUIRED
Дополнительные evidence refs

ПДн и ключи не принимаются

11 / Asset reference

Каталог активов

Это справочный UI-каталог исходных значений, а не authoritative effective policy. Реальный допуск всегда заново проверяет серверный eligibility API.
Разобрать активы, сети и atomic units

Не использовать как реестр листингаКаталог не синхронизирован с policy deployment или базой scale registry. Кнопки только открывают формы и ничего не подставляют; сервер остаётся единственным источником решения.

Активы в интерфейсе1справочный BTC
Базовая операцияBUYне гарантия policy admission
Form default scale8сервер проверит asset/network pair
Governance workflowРЕАЛИЗОВАНОVersioned Policy Studio + maker-checker; legal listing активируется отдельно
Справочный реестр активов и сетей
АктивКлассификацияСеть / scaleОперацииРежимДействие
01
Policy admission

Код актива должен присутствовать в effective policy bundle; неизвестные активы не получают ALLOW.

EXECUTABLE
02
Atomic precision

Первая запись фиксирует scale asset/network; конфликт decimals отклоняется без изменения журнала.

EXECUTABLE
03
Production listing

Versioned policy approval и разделение ролей реализованы. Для конкретного актива нужны юридическое заключение, risk owner и production activation record.

ТРЕБУЕТ АКТИВАЦИИ

03 / Organization integration blueprint

Как организация подключает
цифровые активы

Организация сохраняет пользователя, деньги, идентификацию и право финального одобрения. CertaRail принимает заверенные факты, проверяет допустимость операции и связывает её с воспроизводимым evidence.
Открыть коммерческую версию схемы

MOCK-КОНТУР РЕАЛИЗОВАН

Это схема 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 →

ПРОБЛЕМА ОРГАНИЗАЦИИ Один клиентский intent проходит через разрозненные контуры. Identity, policy, venue, custody, KYT, fiat, учёт и reporting должны дать согласованный результат — без потери причины решения.
РОЛЬ CERTARAIL Единая контрольная и evidence-граница между организацией и провайдерами. CertaRail не становится биржей или кошельком: он нормализует intent, останавливает недопустимое и собирает доказательства вокруг исполнения.

Integration picture / ownership first

Кто находится в системе и где проходит граница

REQUEST → CONTROL → COMMAND → FACT

Пользователи работают в каналах организации. Организация передаёт в CertaRail непрозрачную ссылку на пользователя, проверенные факты и намерение. CertaRail принимает решение, фиксирует evidence и в целевой архитектуре обращается к отдельно активируемым провайдерам.

01
DEMAND

Пользователи

ORG-OWNED
РозницаЧастный инвесторПокупка, продажа, пополнение, вывод
Private / wealthИнвестиционный клиентПортфель, отчёты, поручения
B2BКорпоративное казначействоПолитики компании и двойное одобрение
Пользователь остаётся в канале организацииCertaRail не получает пароль, сырые ПДн или прямые отношения с пользователем.
02
TRUST OWNER

Организация

ORG-OWNED
КаналыMobile · web · B2B APIUX, сессия, disclosure и подтверждение
IdentityOIDC · KYC · consentЗаверенные факты и opaque customer ref
Money & riskСчёт · лимиты · approvalsФиат, резервы и maker-checker принадлежат организации
Back officeGL · risk · SIEMПолучатели событий и evidence-пакетов
Финальное право исполненияBackend организации вызывает серверную границу; клиентское приложение не обращается к провайдеру напрямую.
03
CONTROL + EVIDENCE

CertaRail

CAPABILITY STATUS
API
Intent gatewayTenant boundary, strict contract, idempotency
РЕАЛИЗОВАНО
POL
Eligibility decisionALLOW / REVIEW / DENY + reason trace
РЕАЛИЗОВАНО
EVD
Evidence railAudit receipt, movement observations, outbox
РЕАЛИЗОВАНО
PRV
Provider command seamSubmit-once и UNKNOWN recovery реализованы; активируется только выбранный готовый provider transport
РЕАЛИЗОВАНО
GOV
Policy + limitsLifecycle и exact-value reservation evidence; без production IAM
РЕАЛИЗОВАНО
CMP
Case + Travel RuleREVIEW и completeness assessment; без provider transport
РЕАЛИЗОВАНО
DEP
Depository intent contractsMock contracts реализованы; production keys, address provisioning и custody execution ещё не реализованы
MOCK РЕАЛИЗОВАН
REP
Regulatory draftsMock draft реализован; official outbound ещё не реализован
MOCK РЕАЛИЗОВАН
PostgreSQLTransactional outboxKafka handoffRedis — только fail-soft cache; не источник истины.
04
REGULATED RAILS

Внешний мир

ACTIVATION GATES
ExecutionБиржа / broker venueMock ACK/fill и UNKNOWN recovery исполняются без сети. Provider Sandbox/public market data требуют активации; production order execution и реальные деньги ещё не реализованы.
MOCK РЕАЛИЗОВАНPROVIDER SANDBOX · ТРЕБУЕТ АКТИВАЦИИPRODUCTION EXECUTION · ЕЩЁ НЕ РЕАЛИЗОВАНО
AssetsCustody / blockchainMock custody receipt связывается с fill; provider adapter, реальные ключи, address, broadcast и transfer capability отсутствуют.
MOCK-ПРОВЕРКА РЕАЛИЗОВАНАЕЩЁ НЕ РЕАЛИЗОВАНО
Проверить custody fixture →
Compliance providerKYT transportЛокальный conformance fixture реализован; vendor adapter, credentials и assessment transport отсутствуют. Travel Rule assessment остаётся внутри CertaRail.
ЕЩЁ НЕ РЕАЛИЗОВАНО
FiatСБП / НСПКNon-monetary link/status/refund fixture и lost-response recovery исполняются; реальный adapter СБП/НСПК отсутствует.
MOCK РЕАЛИЗОВАНЕЩЁ НЕ РЕАЛИЗОВАНО
RegulatorБанк РоссииMock evidence draft и receipt формируются; official schema, УКЭП, transport и receipt ingestion отсутствуют.
MOCK-СЦЕНАРИЙ РЕАЛИЗОВАНOFFICIAL OUTBOUND · НЕДОСТУПНОTRANSPORT · ЕЩЁ НЕ РЕАЛИЗОВАНО
Проверить reporting mock →
Сначала реализация, затем активацияActivation применима только к готовому adapter; отсутствующий код нельзя включить договором или credentials.
ORG-OWNED РЕАЛИЗОВАНО РЕАЛИЗОВАНО ЕЩЁ НЕ РЕАЛИЗОВАНО ТРЕБУЕТ АКТИВАЦИИ НЕДОСТУПНО
  1. 01 / INTENTПользователь подтверждает операцию в организацииОрганизация знает пользователя и формирует заверенный контекст.
  2. 02 / CONTROLCertaRail фиксирует решениеReason codes, policy version, digest и audit receipt.
  3. 03 / MOCK EXECUTIONБезопасная команда и mock-факты исполняютсяDurable journal, hold, fill и custody receipt; Provider Sandbox venue требует активации, production execution ещё не реализован.
  4. 04 / EVIDENCEФакт возвращается организацииObservation, Kafka event и evidence draft; authoritative production reconciliation ещё не реализована.

Responsibility register

Кто за что отвечает

Граница поставки остаётся модульной: организация может заменить канал или провайдера, не перенося policy и evidence-логику в каждую интеграцию.

Ответственность организации, CertaRail и внешних провайдеров
СущностьОрганизация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

  1. 01 · ПОЛЬЗОВАТЕЛЬВыбирает BTC и сумму в RUBВ канале организации
  2. 02 · BACKEND ОРГАНИЗАЦИИПодтверждает KYC, screening и средстваБез передачи сырых ПДн
  3. 03 · CERTARAILВозвращает ALLOW, REVIEW или DENYПричины + policy version + receipt
  4. 04 · ОРГАНИЗАЦИЯОтдельно одобряет исполнениеFiat hold и maker-checker — под контролем организации
  5. 05 · MOCK VENUE / CUSTODYВозвращают контролируемые fill и receiptPROVIDER SANDBOX · ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION EXECUTION / CUSTODY · ЕЩЁ НЕ РЕАЛИЗОВАНЫ
  6. 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 организации.

CertaRail решаетРазрешить, отправить на проверку или запретить

ALLOW / REVIEW / DENY, понятные причины, версия правил и audit receipt. Решение сохраняется до любого внешнего действия.

Остаётся снаружиДеньги, одобрение организации и фактическая покупка

Рубли и ledger — у организации; рыночный order — у venue; ключи и хранение — у custodian; on-chain риск — у KYT.

Показать поля и детали APIФорма пользователя → заверенные факты организации → versioned CertaRail contractОТКРЫТЬСКРЫТЬ

Payload boundary

Что ввёл пользователь — и что добавила организация

Пользователю не показывают техническую анкету CertaRail. Он заполняет форму организации; backend организации добавляет только заверенные факты и непрозрачные ссылки.

01 · ПОЛЬЗОВАТЕЛЬ

Вводит сам

02 · BACKEND ОРГАНИЗАЦИИ

Добавляет автоматически

03 · CERTARAIL CONTRACT

Получает на границе

Никогда не передаётся в CertaRailФИОпаспорттелефонпарольaccess token организацииKYC/KYB-документыбиометрияprivate key / seed

Синтетическая схема · external_calls=0

Куда идёт операция и какие модули срабатывают

Последовательность шагов от интерфейса организации через backend организации, CertaRail, внешнего провайдера и обратно в evidence-контур. Каждый шаг открывается кнопкой.

Пользователь организации Backend организации CertaRail Биржа / custody / KYT Back office / reporting

Показ схемы объясняет последовательность; запросы и внешние команды не выполняются.

    Зелёный путь реализован; после stop gate отдельно показаны activation gates, отсутствующие capabilities и hard stop.
    01

    ПОЛЬЗОВАТЕЛЬ · ORG-OWNED

    Выбирает актив и сумму

    Что происходит

    При сбое

    Что пришло
    Что сделал модуль
    Что сохранилось
    Что вышло
    Владелец данных
    Все шаги в таблице: входы, решения, выходы, evidence и recovery
    ШагВладелецВходДействиеВыходEvidenceСтатус и восстановление

    Command / evidence loop

    Что CertaRail делает с биржей

    Не «передаёт BUY и надеется», а защищает уникальность команды и связывает каждый внешний исход с исходным решением.

    1. 01Committed decisionALLOW + audit receipt
    2. 02Резерв организацииproduction gate организации
    3. 03Immutable commandcommand_id + canonical hash
    4. 04Mock venue pathРЕАЛИЗОВАНО · PROVIDER SANDBOX ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION VENUE ЕЩЁ НЕ РЕАЛИЗОВАН
    5. 05ACK / UNKNOWNACK ещё не fill
    6. 06Inbox + lookuplookup first, no blind retry
    7. 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
    BUYMock RUB holdMock venue; СБП только для отдельного fundingBUY_FILL + fee + custody evidenceMOCK FLOW РЕАЛИЗОВАНProvider Sandbox venue требует активации; production funds/execution/custody ещё не реализованы
    SELLПозиция активаVenue + fiat settlementSELL_FILL · asset debit · fiat creditЕЩЁ НЕ РЕАЛИЗОВАНОpolicy и settlement path отсутствуют
    DEPOSITНичего до finalityCustody address + blockchain + KYTDEPOSIT after confirmationsЕЩЁ НЕ РЕАЛИЗОВАНОесть только fixture observations
    WITHDRAWALАктив + network feeKYT + Travel Rule + custody broadcastWITHDRAWAL + tx confirmationsЕЩЁ НЕ РЕАЛИЗОВАНОsigning/broadcast отсутствуют
    EXCHANGEИсходный активVenue; две legs и feesSWAP_LEG observationsЕЩЁ НЕ РЕАЛИЗОВАНОpolicy, two-leg atomicity и settlement отсутствуют
    СБП FUNDINGMock payment limitMock СБП fixture; adapter НСПК отсутствуетFinal mock payment status, не QRMOCK РЕАЛИЗОВАНЕЩЁ НЕ РЕАЛИЗОВАНО: НСПК adapter

    Why organizations choose CertaRail

    Какую проблему решает платформа

    Без единого control planeС 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, какие данные и полномочия остаются у организации, как отделена внешняя командная граница и какие профили размещения рассматриваются.

    Три контура

    Решение, полномочия организации и внешнее исполнение разделены.

    1. 01

      Контур организацииПользователь, UX, KYC/KYB, деньги, лимиты и approvals

    2. 02

      Контур CertaRailDecision engine, evidence, authoritative state и outbox

    3. 03

      Внешний контурVenue, custody, KYT, платёжные и регуляторные rails

    Архитектура / владение контурами

    Контуры системы и границы команд

    ЦЕЛЕВОЙ ПРОФИЛЬ РАЗМЕЩЕНИЯ
    01

    Канал организацииORG-OWNED

    1. Клиентисточник подтверждённого намерения операции
    2. Mobile / web / B2Bорганизация владеет UX, сессией и disclosure
    3. Backend организациипроверяет KYC/KYB, счёт, лимит и funds hold

    Не выходит из организации: ФИО, паспорт, реквизиты, биометрия, пароль, access token и KYC/KYB-документы.

    mTLS / JWTRESTrequest → decision
    02

    Контур CertaRailВНУТРИ КОНТУРА ОРГАНИЗАЦИИ

    API Gateway / WAFidentity, tenant, contract version
    API · AstatelessAPI · Bstateless
    Decision enginein-process hot pathPostgreSQL HAauthoritative state
    Outbox workersat-least-onceKafkaconsumers организацииRedis / Valkeyoptional replay hint

    CertaRail получает: opaque customer ref, facts version, нормализованные статусы, intent и ссылки на evidence.

    DURABLE COMMANDASYNCsubmit → lookup → reconcile
    03

    Внешние провайдерыВНЕШНЯЯ КОМАНДНАЯ ГРАНИЦА

    1. Venue / brokermock order, ACK, fills, fees; Provider Sandbox adapterMOCK РЕАЛИЗОВАН · PROVIDER SANDBOX ТРЕБУЕТ АКТИВАЦИИ · PRODUCTION EXECUTION ЕЩЁ НЕ РЕАЛИЗОВАНО
    2. Custody / KYTmock receipt/screening fixtures; provider adapters отсутствуютMOCK РЕАЛИЗОВАН · REAL ЕЩЁ НЕ РЕАЛИЗОВАН
    3. СБП / НСПКmock link/status/refund recovery; НСПК adapter отсутствуетMOCK РЕАЛИЗОВАН · REAL ЕЩЁ НЕ РЕАЛИЗОВАН
    4. Банк Россииmock report sink / evidence draft; official transport отсутствуетMOCK РЕАЛИЗОВАН · OFFICIAL НЕДОСТУПЕН

    Владелец внешней интеграции: организация. Граница CertaRail — контракт адаптера и evidence conformance-тестов.

    Текстовый реестр всех компонентов и владельцев
    КомпонентВладелецНазначениеСтатус и граница
    Главный принцип: ALLOW разрешает организации продолжить процесс, но не отправляет ордер автоматически. Решение и внешнее исполнение — две разные команды с разными правами и evidence.

    Профили размещения

    Варианты инфраструктурного контура

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

    ПрофильСтатусЧто разворачиваетсяКому подходитОграничение
    Compose verification profileРЕАЛИЗОВАНОNginx, API ×2, migrator, PostgreSQL, Redis/Valkey, Kafka, outboxDiscovery, contract и fault checksSingle-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 cloudCONDITIONALОтдельные API, outbox и workflow deployments; managed stateful layerОрганизация с действующим platform standardService mesh и Temporal — только по измеримому триггеру

    08 / План внедрения

    План внедрения CertaRail

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

    Логика допуска

    Семь этапов. Следующий открывается только после evidence предыдущего.

    1. 01

      Сначала — границы и владельцыОдин сценарий, юридическая роль, RACI и целевой контур

    2. 02

      Затем — изолированный контур и UATКонтракты, изоляция и отказные сценарии без реальных денег

    3. 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, среды и владельцев ресурсов организации.

    03

    Production-контракты и 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.

    06

    Preproduction и приёмкаДоказать безопасность, эксплуатацию и восстановление поставки.

    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 и денежная сверка.

    Граница продукта

    С какого состояния начинается этот план

    РЕАЛИЗОВАНОProduction-код готов к проверке

    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 certsClaims 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Отвечает за свой SLARestore/failover drill
    Provider contractВыбирает и заключаетРеализует adapter contractВыдаёт test/prod entitlementConformance + fault report
    ОтчётностьОфициальный респондентГотовит проверяемый пакетРегулятор принимает или отклоняетSchema, УКЭП, receipt, correction flow
    Production activationФинальный accountableПодписывает release factsПодтверждает rail readinessVersioned activation record

    Acceptance package

    Что организация получает и принимает

    Это целевой реестр поставки. Наличие строки не означает, что артефакт уже production-ready; фактический статус закрывается evidence конкретного внедрения.

    01

    Governanceuse-case passport · legal memo · RACI · provider due diligence

    ORGANIZATION + CERTARAIL
    02

    ContractsOpenAPI · AsyncAPI · JSON Schema · reason codes · failure semantics

    VERSIONED
    03

    SecurityThreat model, scoped FORCE RLS и security gates реализованы; production PKI/HSM/pentest требуют приёмки.

    РЕАЛИЗОВАНО
    04

    OperationsHealth/readiness, observability, reconciliation и runbooks реализованы; production SLO/restore drills требуют приёмки.

    РЕАЛИЗОВАНО
    05

    ReleaseOCI digest, CycloneDX SBOM и unsigned evidence bundle реализованы; trusted signing/provenance ещё не реализованы.

    РЕАЛИЗОВАНО
    06

    AcceptanceUAT · isolation · performance · chaos · privacy · security evidence

    ORG APPROVAL
    07

    Activationpolicy hash · endpoint/certificate set · cohort · limits · rollback plan

    DEFAULT DENY

    09 / Provider boundaries

    Интеграционный контур

    Настроить подключения

    Implementation, environment, activation, external effect и production readiness загружаются только из certarail.capability-surface.v1. Legacy adapter catalogue остаётся runtime-входом для mock tools, но не отображается как capability status.
    Пояснить оси статуса

    Implementation stateНасколько capability реализована и проверена кодом и тестами

    Activation stateРазрешён ли внешний production-контур фактически

    EX
    Данные интеграций требуют сессии

    Откройте рабочую сессию, чтобы загрузить фактические 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 и закрытая отправка
    1. 01Journal factsPostgreSQL
    2. 02Normalizeschema V0
    3. 03DigestSHA-256
    4. 04Reviewevidence only
    5. 05SubmissionCLOSED

    Параметры снимка

    CBR movement draft

    CBR_CRYPTO_MOVEMENT_DRAFT_V0
    NOT SUBMITTABLE
    API получит верхнюю границу как начало следующего дня в UTC.
    Источник
    PostgreSQL movement evidence
    Результат
    JSON + digest + evidence root
    Network
    NONE
    Submission gate: CLOSEDHTTP-клиент отправки и реальные сертификаты отсутствуют намеренно

    Evidence document

    Пакет ещё не сформирован

    После формирования здесь появятся период, полнота, digest, evidence root и блокирующие условия.

    10 / Production gates

    Матрица готовности

    Readiness и blockers отображаются из тех же canonical capability records, что `/status`, marketing и API. Ни один внешний контур не считается подключённым без owner-approved evidence.
    Пояснить каждый production gate

    — / —IMPLEMENTED

    —INACTIVE / UNKNOWN

    —DESIGN_ONLY

    —NOT_IMPLEMENTED

    Это счётчик независимых canonical axes, а не процент production readiness.

    Capability boundaries

    Активные предупреждения

    FAIL-CLOSED
    • Откройте рабочую сессию для загрузки предупреждений.
    GT
    Production gates ещё не загружены

    Авторизуйтесь, чтобы увидеть фактические capability- и activation-границы.

    ИсточникCanonical Capability StatusСтатические legacy gates удалены из readiness surface. Полные owner, blockers, timestamps и evidence references загружаются выше из одного registry object.FAIL-CLOSED
    LOCALСреда APIОрганизация и доступ определяются сессией
    Организация
    не подключён
    Сессия
    API-сессия не открыта

    Консоль разработчика

    Первый запрос к API

    Откройте API-сессию и пройдите пять шагов: запрос, решение, безопасный повтор, доказательства и тестовое событие.

    Технические сведения о среде
    Контракты
    Загрузка…
    API-сессия
    Не открыта
    External calls
    external_calls=0 в checkout runner
    Money / assets
    monetary=false
    Authority
    production_enforceable=false

    РЕАЛИЗОВАНО: локальные sandbox-команды и evidence. ЕЩЁ НЕ РЕАЛИЗОВАНО: production authority и внешнее исполнение.

    Все разделы доступны для просмотра. Для запросов к данным организации откройте API-сессию.

    Getting Started · 5 verified steps

    Первый безопасный sandbox flow

    1. 01
      Connect sandboxGET /v1/platform/overview · memory-only bearer
      ОЖИДАНИЕ
    2. 02
      Run eligibilityHEADLESS session + POST /preflight · HAPPY_PATH
      ОЖИДАНИЕ
    3. 03
      Replay safelyТе же body и Idempotency-Key · без повторного эффекта
      ОЖИДАНИЕ
    4. 04
      Inspect evidenceGET /v1/checkout/sessions/{session_id}/timeline
      ОЖИДАНИЕ
    5. 05
      Send test webhookSigned checkout.test · IN_PROCESS_INBOX · external_calls=0
      ОЖИДАНИЕ

    Redacted run log

    Результаты Getting Started

    ОЖИДАНИЕ
    Запуск ещё не выполнялся.

    API Explorer доступен в любое время. Подтверждённые шаги показывают прогресс первого запроса.

    14 / Identity boundary

    Доступ и сессия

    API-сессия использует tenant-bound bearer. Credential хранится только в памяти текущей вкладки и стирается при отключении, перезагрузке или закрытии.
    Открыть auth и authority documentation

    CR

    Browser session

    Рабочая сессия не открыта

    Введите API credential; он не попадёт в cookie, URL, cache, localStorage или sessionStorage.

    ID
    Identity fixture / OIDC boundary

    Server-derived tenant, principal, organization и roles работают с memory-only credential. ЕЩЁ НЕ РЕАЛИЗОВАНО: Authorization Code + PKCE и service mTLS adapter.

    РЕАЛИЗОВАНО · IDENTITY FIXTUREЕЩЁ НЕ РЕАЛИЗОВАНО · OIDC ADAPTER
    ЕС
    ЕСИА / Госуслуги

    Generic identity fixture доступен отдельно. ЕСИА adapter, регистрация ИС, scopes, ГОСТ и ПДн-проект ещё не реализованы.

    Проверить identity fixture →
    ЕЩЁ НЕ РЕАЛИЗОВАНО · ЕСИА ADAPTER
    RB
    RBAC / maker-checker

    API кабинета организации выводит роли из credential, запрещает self-approval и сохраняет независимое approval evidence. Production IdP, MFA и step-up binding ещё не реализованы.

    РЕАЛИЗОВАНОЕЩЁ НЕ РЕАЛИЗОВАНО · PRODUCTION IAM
    Memory onlycredential исчезает при reload
    Tenant boundAPI отклоняет cross-tenant payload
    No PIIформы используют opaque refs
    Fail closedнет credential — нет control API
    CR

    Доступ к API

    Открыть рабочую сессию

    Если доступна кнопка быстрого входа, откройте сессию одним нажатием. Иначе используйте ручной credential: он живёт только в памяти вкладки.

    Расширенные настройки · credential и tenant
    ЕЩЁ НЕ РЕАЛИЗОВАНО: production-аутентификация через OIDC/mTLS организации. Безопасная credential-сессия уже реализована.

    CertaRail command palette

    Только навигация и безопасные non-monetary действия