Путь клиента и архитектура · июнь 2026

Как клиент работает с Plica

Для инвесторов, compliance, юристов и enterprise-пилотов. Что мы продаём, как документ попадает на проверку, как клиент получает результат, где хранятся данные — с честными статусами shipped / roadmap / out of scope.

01 Что мы продаём

PLICA — независимый forensic-слой для изображений и PDF в регулируемых file-workflow.

Мы делаем

Мы не делаем

Доказываем, подделан ли файл (metadata, структура PDF, OCR vs text layer, pixel/GAN)

Hosted KYC / liveness / сессию с камерой

Выдаём evidence: JSON, PDF-отчёт, hash, policy hooks

AML / sanctions / скрининг по реестрам

Встраиваемся в ваш onboarding, claims, underwriting

Замену Sumsub, Onfido, LexisNexis

Chain of custody с момента intake в API

Доказательство «документ был подлинным до того, как попал к вам»

Граница продукта: мы отвечаем на «этот файл технически подделан или синтетичен?» — не на «существует ли компания и верен ли счёт в реальном мире?». Второе — ваши реестры, issuer systems, ручная проверка.

02 Путь клиента (B2B)

┌──────────────┐ ┌──────────────────┐ ┌────────────────┐ ┌─────────────────┐ │ Пилот / │ ─► │ Интеграция API │ ─► │ Production │ ─► │ Аудит / споры │ │ trial /try │ │ + webhook/DPA │ │ auto-policy │ │ PDF + hash │ └──────────────┘ └──────────────────┘ └────────────────┘ └─────────────────┘

Этап	Действия	Артефакты
1. Доступ	Ключ API (sandbox → prod), опционально `/try` для демо	API key, лимиты trial
2. Интеграция	Вызов из CRM / KYC-портала / бота / back-office	`POST /api/v1/verify` (sync) или `POST /api/v1/jobs` (async batch)
3. Решение	Маршрутизация по `policy_actions`: reject / HITL / approve	Webhook в вашу очередь
4. Аудит	Хранение forensic record по DPA	PDF, `analysis_id`, verify URL, hash

Пользователь — compliance / fraud / ops клиента или их система (API-to-API). Конечный клиент банка работает в их UI, не в отдельном «банковском приложении Plica».

03 Как документ попадает на проверку

Основной канал — API (не десктоп, не отдельный портал загрузки для retail):

Upload: multipart — JPEG, PNG, HEIC, WebP, PDF (до лимита сервера)
URL: публичный image_url / file_url (с защитой SSRF)
Контекст: document_type, customer_id, additional_info (JSON дела), product_source
Async batch: POST /api/v1/jobs/batch — до 20 файлов, общий batch_id, poll или webhook_url

Типовые точки входа: клиент загрузил PDF в их onboarding → их backend → Plica API · оператор в back-office → их UI → Plica API · AI-агент / бот → API (agent_fast для ускоренного PDF).

04 Как клиент получает результат

Канал	Содержимое	Статус	Назначение
JSON (sync)	`verdict`, `fraud_score`, `analyst_summary`, `forensic_view` (`claim_lists`, `risk_signals`), `policy_actions`	Shipped	Автоматизация, CRM, rules engine
JSON (async)	`POST /jobs` → poll `GET /jobs/{job_id}` → `GET /jobs/{job_id}/result`	Shipped	Массовая triage, тяжёлые PDF, worker-очереди
PDF	Forensic Authenticity Report + verify link + hash	Shipped	MLRO, юристы, регулятор, споры
Policy webhook	`plica.policy.enforcement` на критичных `policy_actions`	Shipped	HITL-очередь, auto-reject
Job webhook	`plica.analysis.completed` на `webhook_url` job'а	Shipped	Push по завершении файла в batch
Batch export	CSV / zip PDF по `batch_id`	Roadmap	Экспорт для compliance одним кликом

requires_manual_review и HITL — сигнал в ваш процесс, не отдельная «очередь юристов Plica». При definitive reject (напр. Tampered 85/100) отчёт даёт один enforcement path — Reject, без противоречащего «mixed signals».

05 Приложения — что есть и что планируется

Поверхность	Статус	Роль
REST API	Prod	Основной продукт (`/verify`, `/jobs`)
Trial `/try`	Shipped	Пилот, демо, ручная проверка одного файла
PDF-отчёт	Shipped	Compliance, audit trail
B2B-кабинет (ключи, usage, история, retention)	Roadmap	Self-serve управление
Десктоп / mobile SDK	Не в scope	Клиенты не хотят ещё один клиент; KYC — у вендоров

Позиция: API-first. Веб — для trial и лёгкого review, не замена корпоративного портала клиента.

06 Хранение данных

Тип	Где	Принцип
Метаданные анализа	PostgreSQL / SQLite	Scores, verdict, structured JSON
Файлы (опционально)	`data/verify_images/` или object storage	По DPA: срок, регион (EU), право на удаление
Кэш	Redis	Производительность, не долгосрочный архив
Отчёты	On-demand + кэш preview	PDF + hash для независимой верификации

Privacy by design (enterprise):

Tenant-scoped — нет общей cross-tenant fraud-базы с PII
Retention настраивается: только hash + forensic record, без raw file после анализа
Шифрование in transit (TLS) и at rest — по договору

Для юриста: мы храним доказательство того, что было проверено на intake, в объёме, согласованном в DPA — не бессрочный архив всех сканов паспортов.

07 Батчи и несколько субъектов

Батч документов — shipped: POST /api/v1/jobs/batch (до 20 файлов) возвращает общий batch_id и job_id на каждый файл. Poll GET /api/v1/jobs?batch_id=… или GET /api/v1/jobs/{job_id}; полный JSON — GET /api/v1/jobs/{job_id}/result. Передавайте customer_id и additional_info (напр. case_ref) — попадут в отчёт, не влияют на скоринг.

Смысл: массовая triage — какие файлы подозрительны, до ручной проверки критичных полей.

«По реестрам» — не core, возможна оркестрация:

ЕГРЮЛ, LexisNexis, credit bureau — подписка и интеграция клиента
Plica не конкурирует с data vendors: мы ловим подделку файла, они — правду о контрагенте
Опционально позже: webhook «forensic FAIL → не дёргать KYB» или «PASS → продолжить pipeline»

08 Content validation — граница отчёта

В отчёте сегодня

Не в scope без отдельного контракта

Арифметика в тексте (PASS / FAIL)

Существование адреса, поставщика, счёта в реальных реестрах

OCR vs machine-readable text layer (паттерн подмены сумм)

«Здравый смысл» контента против внешних authoritative sources

Barcode / MRZ cross-check (для ID)

Это не обесценивает forensic: подделанный utility bill с OCR 16% и amount drift — ловится до любого LexisNexis.

09 Типовая архитектура интеграции

[Конечный клиент] │ ▼ [Портал клиента: onboarding / claims / CRM] │ upload / subject_id ▼ [Backend клиента] ── sync: POST /api/v1/verify │ async: POST /api/v1/jobs/batch ──► [PLICA API] │ │ │◄── JSON / job_id + poll ─────────────┘ │ ├──► auto-reject (policy_actions) ├──► HITL-очередь клиента (webhook) └──► архив PDF + hash (compliance)

Соседи в стеке (комплементарны, не заменяем): Sumsub / Onfido (identity), LexisNexis / реестры (KYB), core banking. Plica — между файлом на входе и решением.