Корпоративные системы и интеграции
Банки, казначейство и связность ISO 20022
Платежи наружу, выписки внутрь, автоматическая сверка в любой валюте
Казначейства всё ещё перенабирают платежи и сверяют выписки вручную
Многие казначейские команды вводят платежи в банковские порталы, собирают выписки в разных форматах от каждого банка и сверяют счета в таблицах в конце месяца. Каждый ручной шаг — это задержка, затраты и риск мошенничества или ошибки.
Банки также переходят на ISO 20022, международный стандарт финансовых сообщений, который несёт более богатые структурированные данные, чем прежние форматы SWIFT MT. Системы, которые не умеют формировать и читать его, отстают от своих банков.
Что меняется для вас
Полностью автоматическая обработка (STP)
Утверждённые платёжные реестры покидают ERP в виде подписанных файлов или вызовов API, а выписки возвращаются в форме, которую ERP сопоставляет сама.
Более быстрое закрытие
Мультивалютная сверка, выполняемая ежедневно, вместо ручной загрузки CSV и корректировок в таблицах в конце месяца.
Каждое исключение с ответственным
Отклонённые платежи и несопоставленные строки попадают в очередь исключений с причиной и никогда не теряются в почтовом ящике.
Что мы предоставляем
Прямое подключение к банкам и host-to-host
Подключения через SFTP, EBICS и SWIFT, а также открытые банковские и прямые банковские API, выбираемые для каждого банка и страны.
Формирование платёжных файлов
Платёжные файлы ISO 20022 pain.001, построенные из ваших платёжных реестров, проверенные по варианту каждого банка и подписанные или зашифрованные по его требованиям.
Обработка статусов и отклонений
Отчёты о статусе pain.002 считываются обратно, чтобы каждый платёж отображался как принятый, отклонённый или ожидающий, с кодом причины банка.
Приём выписок
Выписки camt.053 и MT940 на конец дня и внутридневные отчёты собираются, проверяются на пропуски и дубликаты и загружаются в ERP.
Межбанковский обмен сообщениями для банков и финтехов
Сообщения pacs для кредитовых переводов и их статусов между финансовыми учреждениями, подключённые к счетам в АБС.
Мультивалютная сверка
Правила сопоставления, автоматически закрывающие открытые позиции по валютам и счетам и отправляющие остальное в очередь исключений.
Доказательства банковских тестов и регламенты эксплуатации
Тестовые сценарии каждого банка выполняются и фиксируются для ваших аудиторов, а также оповещения о пропущенных файлах, неудачных переводах и истекающих ключах или сертификатах.
Как строится работа
Определите банки и потоки
Мы составляем перечень ваших банков, счетов, типов платежей и текущих ручных шагов и согласуем, какие потоки идут первыми.
Опишите каждый формат
Мы работаем по руководству по внедрению каждого банка и пишем сопоставление, включая подпись, шифрование и именование файлов.
Соберите коннекторы
Мы собираем экспорт платежей, импорт статусов, импорт выписок и сопоставление с автоматическими тестами для каждого формата.
Протестируйте с каждым банком
Мы прогоняем согласованные тестовые сценарии в тестовой среде банка и исправляем всё, что отклоняет его проверка.
Запускайте банк за банком
Мы переключаем по одному банку за раз, оставляя текущий процесс как резерв до подтверждения нового.
Наблюдайте и поддерживайте
Мы следим за переводами, сроками действия ключей и сертификатов и планируем изменения форматов, когда банки о них объявляют.
Прокрутите вбок, чтобы увидеть весь чертёж.
От ERP к банку: платежи наружу, выписки внутрь
Утверждённые платежи выходят из ERP подписанными файлами ISO 20022 по каналу host-to-host. Отчёты о статусе и выписки возвращаются тем же путём и сопоставляются с открытыми позициями. Отклонённые и несопоставленные строки передаются вашей команде с указанием причины.
- Основной поток
- Асинхронный
- Сценарий исключения
Поток из 10 шагов
Поток шаг за шагом
- От ERP к Интеграционный слой: Утверждённый платёжный реестр, по REST/JSON · IDoc (основной поток).
- От Интеграционный слой к Защищённый банковский канал: Подписанный и зашифрованный платёжный файл, по ISO 20022 pain.001 · OpenPGP (основной поток).
- От Защищённый банковский канал к Банк: Передан в банк, по SFTP H2H (основной поток).
- От Банк к Защищённый банковский канал: Отчёты о статусе и выписки, по pain.002 · camt.053 · MT940 (асинхронный).
- От Защищённый банковский канал к Интеграционный слой: Собрано и проверено, по SFTP H2H (асинхронный).
- От Интеграционный слой к Механизм сверки: Строки выписки, по camt.053 (асинхронный).
- От Механизм сверки к ERP: Сопоставленные проводки, по REST/JSON (основной поток).
- От Интеграционный слой к Казначейство и финансовый отдел: Отклонённые платежи с кодом причины, по pain.002 RJCT (сценарий исключения).
- От Механизм сверки к Казначейство и финансовый отдел: Несопоставленные строки: расхождение при сверке (сценарий исключения).
- От Казначейство и финансовый отдел к ERP: Исправлено и отправлено повторно (сценарий исключения).
Прокрутите вбок, чтобы увидеть весь чертёж.
Открытый банкинг: данные и платежи с согласия клиента
Клиент даёт согласие, коннектор хранит токены, а каждый вызов банка авторизуется и протоколируется. Когда согласие истекает или отзывается, приложение снова запрашивает его у клиента, а не сбоит молча.
- Основной поток
- Асинхронный
- Сценарий исключения
Поток из 7 шагов
Поток шаг за шагом
- От Клиент к Ваше приложение или платформа: Даёт согласие (основной поток).
- От Ваше приложение или платформа к Коннектор открытого банкинга: Запросы по счёту и платежам, по REST/JSON (основной поток).
- От Коннектор открытого банкинга к Банковские API или агрегатор: Авторизованные вызовы API, по OAuth 2.0 · FAPI · REST (основной поток).
- От Банковские API или агрегатор к Коннектор открытого банкинга: Балансы, транзакции и статус платежа, по REST/JSON · webhook (асинхронный).
- От Коннектор открытого банкинга к ERP или учётная система: Нормализованные транзакции, по REST/JSON (основной поток).
- От Банковские API или агрегатор к Коннектор открытого банкинга: Согласие истекло или отозвано, по HTTP 401 · 403 (сценарий исключения).
- От Коннектор открытого банкинга к Ваше приложение или платформа: Клиента просят продлить согласие (сценарий исключения).
Стандарты, форматы и каналы
Мы строим по руководству по внедрению каждого банка, а не только по стандарту. Упоминание продукта не означает партнёрства с его вендором.
- Банковские стандарты и каналы
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- Swift
- EBICS
- SFTP (H2H)
- OpenPGP
- PSD2
- Berlin Group NextGenPSD2
- UK Open Banking Standard
- FAPI
Подтверждение в эксплуатации
Для банка из первого эшелона стран Персидского залива и регионального конгломерата мы подключили SAP S/4HANA к региональным банковским рельсам по ISO 20022. Платежи подписываются, исключения попадают в очереди недоставленных сообщений, а сверка по его банковским счетам выполняется автоматически.
Как начать
Понятные требования по банкам и форматам сразу переходят в предложение. Несколько банков, стран или недокументированный унаследованный интерфейс обычно начинаются с Blueprint Studio или с диагностики существующей системы.
Что происходит дальше
Предконсультационная сессия
бесплатная 30-минутная онлайн-сессия предварительного консультирования: мы разбираем ваши цели, системы и ограничения.
Оценка готовности
В рамках бесплатная 48-часовая оценка готовности ведущий архитектор проверяет ваш проект по шести критериям определения готовности и рекомендует подходящий трек.
Выбор трека
Проекты с готовым объёмом работ получают обязывающее предложение в течение 3–5 рабочих дней. Проекты на стадии концепции начинаются в Blueprint Studio. Действующая система, которая сбоит, не документирована или требует интеграции, начинается с диагностики 1–2 недели. У Blueprint Studio и диагностики фиксированная плата, указанная в предложении.
Поставка в пять этапов
Мобилизация, спринты с живыми демонстрациями, интеграция и усиление защиты, приёмка и запуск, затем управляемые услуги. После запуска наступает гарантийный срок, затем дополнительная поддержка и обслуживание.
Проекты с фиксированным результатом и круглосуточные управляемые услуги
Поставка с фиксированным объёмом и этапами под руководством назначенных руководителей, а также круглосуточные управляемые услуги по приложениям под управлением SLA.
Встроенные специалисты и стратегическое усиление
Ведущие инженеры и специалисты в ближнем регионе и на месте, а также встроенные архитекторы решений, трансформации, PQC и интеграций.
Вопросы и ответы
Что такое ISO 20022 и почему это важно?
ISO 20022 — международный стандарт финансовых сообщений. Его XML-сообщения несут структурированные данные, такие как полные имена, адреса и детали платежа, которых не могут передать прежние форматы SWIFT MT. Банки и платёжные системы перешли на него, поэтому платёжные файлы и выписки на его основе лучше сверяются и чаще проходят проверки на соответствие.
С какими банковскими форматами и каналами вы работаете?
Мы используем pain.001 для платежей, pain.002 для статусов, camt.052, camt.053 и camt.054 для отчётов по счетам и сообщения pacs между банками. Мы также читаем выписки MT940 и MT942, которые многие банки по-прежнему отправляют. Транспорт — host-to-host SFTP, EBICS, SWIFT или банковские API. У каждого банка свой вариант каждого формата, поэтому мы строим по его руководству по внедрению.
Какие ERP-системы вы можете подключать к банкам?
SAP S/4HANA, Oracle Fusion Cloud ERP и NetSuite, Microsoft Dynamics 365, Odoo и Sage, а также казначейские и заказные системы. Если у ERP есть собственный модуль банковской связи, мы настраиваем и расширяем его, а не строим в обход.
Как вы обеспечиваете безопасность платёжных файлов?
Платёжные файлы подписываются и шифруются по требованиям каждого банка и передаются только по согласованному каналу. Ключи и сертификаты хранятся в вашем хранилище ключей или аппаратном модуле безопасности и никогда в коде. Файлы проверяются перед отправкой, а каждый перевод журналируется, поэтому можно проследить, кто утвердил и отправил каждый платёж.
Что происходит, если строка выписки не сопоставляется?
Она попадает в список на проверку с вероятными кандидатами и причиной несовпадения, например другой суммой или отсутствующей ссылкой. Ваша команда закрывает её там, а правила можно скорректировать, чтобы тот же случай сопоставлялся в следующий раз. Ничего не проводится в учёте без утверждённого вами сопоставления.
Что определяет темп банковской интеграции?
В основном банк, а не код. Каждый банк задаёт свои шаги подключения, тестовые окна и согласования, а некоторым нужны договоры или обмен ключами до начала тестирования. После этапа сопоставления мы даём план по каждому банку и начинаем тестирование с тем, который готов первым.
Что происходит, когда банк меняет формат?
Банки объявляют изменения форматов заранее, как многие сделали при переходе с SWIFT MT на ISO 20022. Мы отслеживаем такие уведомления для банков, к которым подключены, оцениваем влияние и планируем изменение и его тесты с банком до его срока.
Готовы начать разработку? Запросите предложение.
Пришлите требования или RFP. Наши архитекторы проверят их и вернут обязывающее предложение с фиксированным объёмом.
Что происходит дальше
Оценка готовности
В рамках бесплатная 48-часовая оценка готовности ведущий архитектор проверяет ваш проект по шести критериям определения готовности и рекомендует подходящий трек.
Обязывающее предложение
После валидация архитектуры без затрат вы получаете обязывающее предложение с фиксированным объёмом работ в течение 3–5 рабочих дней: этапы, архитектура, структура команды и SLA. По запросу мы подписываем с вами соглашение о конфиденциальности (NDA) до того, как вы поделитесь требованиями.
Мобилизация
После подписания наши инженерные команды начинают Sprint 0 в течение 5–10 рабочих дней после подписания договора.
Поставка в пять этапов
Мобилизация, спринты с живыми демонстрациями, интеграция и усиление защиты, приёмка и запуск, затем управляемые услуги. После запуска наступает гарантийный срок, затем дополнительная поддержка и обслуживание.