что такое платежный хаб

Как открытые API меняют облик сферы платежей

Несмотря на определенные преимущества и поддержку на законодательном уровне в ряде стран, концепция открытых API все еще скептически воспринимается многими банками. Особенно это ощутимо в России. Однако сложно отрицать, что такой подход способствует смене самой парадигмы платежных технологий.

Развитие концепции открытых API предвещает серьезные преобразования в платежной индустрии, которые смогут ощутить на себе все конечные пользователи, от частных лиц до глобальных корпораций. Основные движущие факторы, будь то развитие финансовых технологий по всему миру и переход на проведение платежей в реальном времени, или новые законодательные инициативы, такие как директива Европарламента PSD2, делают очевидным тот факт, что движение в этом направлении уже стало необратимым. Как следствие этого использование сторонних приложений, обращающихся напрямую к банковским системам посредством общедоступных API, для получения информации по счетам, формирования и отслеживания платежей вскоре станет нормой. Однако подобные перемены ощутят не только потребители. Не менее серьезными последствия будут и для самих банков не только в плане работы с платежными технологиями, но и в плане изменения позиционирования на рынке.

Интерфейсы программирования приложений (API) — изобретение не новое и не столь сложное, как может показаться по названию. Будучи впервые разработанными 15–20 лет назад в эпоху корпоративных систем и сервис-ориентированной архитектуры (SOA), API тогда были недоступны внешнему миру и для того, чтобы настроить с ними связь требовалось проделать немалую работу по адаптации приложений. Однако сегодня, вместе с появлением открытых API, востребованность этого подхода вышла на совершенно новый уровень.

Большое отличие открытых API от предшественников заключается в том, что они видны «снаружи» и гораздо более доступны. Появление интерфейсов программирования и наблюдаемый на протяжении последнего десятилетия рост их популярности свидетельствует о все возрастающей роли разработчиков в мире корпоративных информационных технологий. В эпоху, когда разработка и внедрение любого ПО в компаниях было одной из основных функций IT-отдела, открытые API появились почти как инициатива на уровне обычных пользователей, желающих получить новые приложения на базе существующих продуктов и платформ. У этого подхода есть свои характерные особенности. В частности, такие интерфейсы ориентированы на разработчиков, создаются на основе веб-технологий, выверены до мелочей и стандартизированы, что позволяет девелоперам пользоваться всеми преимуществами множества API от различных вендоров и добавлять новую функциональность к существующим системам легко и быстро.

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

Факторы, способствующие распространению открытых API

Как для банков, так и для третьих лиц, подключающихся к их системам, этот фундаментальный сдвиг стал возможен благодаря целому ряду движущих сил. Для Европы, а в перспективе, возможно, и для всего мира, катализатором стала вступившая в силу в 2016 году вторая директива Payments Services Directive 2 (PSD2), обязывающая банки открыть доступ к счетам, платежным потокам и данным конечных пользователей для третьих лиц, в случаях, когда пользователи сами одобряют такой доступ. Но даже не принимая в расчет подобные законодательные изменения, есть две основные причины, по которым глобальное движение в сторону API в банкинге уже нельзя остановить.

Первая связана с быстрым формированием глобальной отрасли Финтеха, деятельность которой нацелена на предоставление постоянного потока инноваций для более эффективного оказания финансовых услуг, особенно в таких областях, как платежи, ипотеки и управление финансовыми средствами для малого и среднего бизнеса. Все банковские клиенты, включая крупные корпорации, сейчас заинтересованы в повышении скорости, простоты и удобства работы с платежами, наличными и финансовыми продуктами на уровне современных потребительских приложений и девайсов. Для них нет большого значения, какая именно организация предоставляет эти услуги — банковская или какая-либо сторонняя. И благодаря росту финтех-рынка последнее все чаще становится нормой.

Банки изо всех сил стремятся как можно скорее поставить эти инновации себе на службу в рамках собственных гибких предложений, направленных на завоевание и сохранение клиентов. Чтобы добиться этого они уходят от модели специализированных, заточенных под определенные кейсы решений к созданию такой среды, в которой они смогут собирать решения по частям, выбирая компоненты самых разных вендоров и используя API для их «склеивания» в единое целое с целью создания в точности того опыта, который нужен тому или иному потребителю. Этот подход обычно включает в себя применение SaaS-платформ, способных легко и просто предоставить целый спектр приложений по низкой цене, с возможностью использовать их тогда, когда это будет необходимо. К примеру, банк, которому нужно добавить на свой веб-сайт калькулятор ипотеки, в настоящее время, скорее всего, встроит с помощью API готовое решение стороннего поставщика, нежели напишет собственное приложение с нуля.

Второй ключевой драйвер распространение открытых API — растущая потребность получать информацию и услуги в реальном времени. Сюда также входит и продолжающееся в настоящее время по всему миру внедрение «мгновенной» платежной инфраструктуры. Эта тенденция говорит о том, что традиционная модель создания файлов пакетных транзакций и их передача по FTP уже не подходит для этих целей, и что организациям и приложениям необходим обмен данными в реальном времени — задача, с которой хорошо справятся именно публично-доступные API. Лидер этой области среди банков — BBVA, фактически опубликовавший всю свою банковскую платформу в Интернете и предоставивший другим организациям возможность использовать ее для собственных инноваций. Этот шаг представляет собой отражение более обширного явления в области разработки и внедрения программного обеспечения — перехода от продуктов к платформам, позволяющим решать задачи быстрее и эффективнее и предлагающим более целостный подход.

Изменения в формате дифференциации банков

На фоне общих тенденций в сферах платежей и банкинга, конкретный уровень прогресса различается от региона к региону. К примеру, Европа быстрее всех вышла вперед в плане схем обработки платежей в реальном времени, а Северная Америка только сейчас начинает ее догонять. Однако несмотря на различные стартовые позиции и скорость прогресса, описанные тренды в общем свидетельствуют о движении в одном направлении: глобальном сближении с новым форматом конкуренции и позиционирования в среде банков.

Исторически сложилось так, что банки конкурировали с другими банками, пытаясь превзойти друг друга в плане эффективности услуг и технологичности своих порталов, которые, до недавнего времени почти во всех случаях целиком разрабатывались и обслуживались ими. Теперь же складывается другая ситуация. Сейчас они оказались в новом мире, где в основе дифференциации лежат два других критерия. Во-первых, главный комплекс операционных услуг и комиссий банка по существу превращается в операционный «движок», в который сторонние компании могут интегрировать свои внешние интерфейсы. И во-вторых, важную роль играет качество открытых API, делающих такую интеграцию возможной для сторонних компаний. В этом контексте, «качество» API сводится к точности, актуальности и полноте информации, которую они могут предоставить. К примеру, может ли клиент с их помощью в реальном времени отследить текущее состояние трансграничной операции?

Фрагментированность операционного отдела может стать препятствием для разработки качественных API

Как бы то ни было, для некоторых банков возможность предложить открытые API, предоставляющие обширную, высококачественную информацию в реальном времени, может быть затруднена используемыми в операционных отделах системами и подходами к работе с данными. Если для фиксирования данных о разных типах платежей банк использует разные системы, то их приведение в единую форму для передачи широкому кругу сторонних партнеров через API может оказаться очень сложной задачей. К тому же ценность и полезность платежного сообщения сегодня все чаще зависят от коммерческой и контекстуальной информации, связанной с основной транзакцией. Например, платеж по услугам здравоохранения может содержать полезную информацию о покрывающих его страховых компаниях.

Все эти факторы заставляют обратить внимание на способность операционных отделов банков поддерживать высококачественные API. Если на стороне «бэк-енда» платежная система напоминает спагетти, то API на «фронт-енде» нужно будет разбираться и упорядочивать данные, чтобы представить их сторонним партнерам в нужном виде. И выполнение этой работы в реальном времени существенно усложняет задачу. Поэтому банкам, стремящимся разработать открытые API нужно как следует проанализировать технологические решения своих операционных отделов и определить, смогут ли они справиться с предоставлением всей необходимой информации в реальном времени.

Платежные хабы как средство устранения препятствий

Нередко они не справляются с этой задачей. Это означает, что банку нужно предпринять некоторые действия. Вероятно, в таких случаях потребуется создание новых платформ, объединяющих разрозненные системы и более полноценно соответствующих требованиям открытых API. Это требование способствует развитию концепции так называемых платежных хабов (payments hubs), позволяющих перевести обработку всех типов платежей на единую платформу. В сочетании с описанным ранее использованием SaaS, потенциал платежных хабов в средах с открытыми API предлагает банкам два возможных практических сценария.

Первый вариант — разработка внутрибанковского решения, когда организация интегрирует нужные API технологии в свою систему, предоставляющую услуги платежного хаба. Эта модель должна идеально и в реальном времени справиться с обработкой поручений и информационных запросов на протяжении всего маршрута их следования по информационному каналу от сторонних приложений конечных пользователей до платежного хаба. Банкам следует также сосредоточиться на создании расширенного набора инструментов, разбитого на множество отдельных мелких сервисов, предназначенных для самых разных целей: от дебетовой авторизации до подсчета комиссий за платежи.

Второй вариант — использование услуг стороннего сервиса, обладающего всеми программными и аппаратными средствами, необходимыми для обработки платежных операций. Поставщик услуг может быть как посредником, осуществляющим поддержку большого количества клиентов, так и заниматься индивидуальным обслуживанием узкого круга клиентов. В мире открытых API, решение должно позволять третьим сторонам — или как они называются в директиве PSD2, поставщикам услуг обработки платежей и информации по счетам — соединяться напрямую с безопасными внутренними API такой инфраструктуры. В идеале выбранное решение должно сочетать в себе преимущества системы «оплаты по мере пользования» лучшими в своем классе технологиями обработки платежей с возможностью в одно действие получить доступ к миру открытых API.

Очевидно, что какой бы подход банки ни выбрали по отношению к открытым API, первостепенную роль здесь будет играть вопрос обеспечения безопасности. В этом отношении все более распространенным в самых разных отраслях становится новый подход: если раньше безопасность означала «защиту», то в современном мире эффективная безопасность может быть достигнута только с помощью «коллективного обмена информацией». Прекрасный пример этой фундаментальной перемены — революционная технология Блокчейн, в рамках которой высокий уровень безопасности достигается за счет открытости и общего доступа. Поэтому даже несмотря на то, что открытие систем посредством API действительно создает определенные риски, проблема эта вполне поддается решению за счет правильного выбора технологий и коллективного сотрудничества.

Навстречу API-будущему

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

Открытые API развиваются быстро, превращаясь в один из фундаментальных элементов будущего банкинга и платежных услуг. Банкам нужно уже сейчас приступить к их встраиванию в свой бизнесе, или уже в ближайшие годы им придется выступать в роли догоняющих.

Источник

«Диасофт» представила функциональность Payment Hub в решении по расчетам

«Диасофт» выпустила новую версию решения для автоматизации расчетной деятельности банка. Разработчики предлагают клиентам принципиально новые функциональные возможности, которые являются инновационными не только для российских, но и для международных банков. Такой инновацией стало построение архитектуры платежного контура банка в виде платежного хаба, или Payment Hub.

Архитектура Payment Hub подразумевает создание единой централизованной автоматизированной системы, занимающейся процессингом всех платежных документов банка. Такая система как конвейер проводит необходимое обогащение данных, проверку плательщиков и получателей, выполняет внутри- и межбанковскую маршрутизацию данных и другие шаги, ранее реализуемые в каждой из продуктовых систем банка по отдельности. По окончании действий процессинга платежей Payment Hub централизованно взаимодействует с различными компонентами системы («Главная книга», «Расчетный центр», «Отчетность» и пр.) с учетом всех необходимых регламентов.

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

Сергей Добриднюк, руководитель продукта «Расчеты» департамента «Операционная деятельность» компании «Диасофт», отметил: «Смежные продуктовые системы могут при внедрении Payment Hub существенно упроститься, но главное – недостаточное развитие встроенных в них платежных сервисов теперь не будет сдерживающим фактором в комплексном развитии платежных платформ банка».

При построении Payment Hub в сотрудничестве с «Диасофт» банк получает возможность вести параллельную обработку всех звеньев бизнес-процесса для одного платежного документа. Результат обработки также возвращается комплексно, сразу от всех процедур контроля.

«В традиционных банковских системах принято при получении какого-либо предупреждения в ходе проведения платежей останавливать работу и информировать ответственного сотрудника-контролера. Если документ содержал несколько принципиальных ошибок, то на следующем шаге он опять мог вернуться контролеру. Этот процесс был крайне утомителен. Сегодня «ручной контроль» и тысячи банковских сотрудников, занимающихся этой деятельностью, – источник значительных временных и финансовых расходов в любом крупном банке. В случае использования Payment Hub при нашей поддержке, специалисту банка достаточно единожды устранить список замечаний, что будет гарантировать практически на 100% последующее исполнение платежного документа», – сказал Сергей Добриднюк.

Для реализации функционала Payment Hub команда «Диасофт» использовала современные асинхронные механизмы межсервисных коммуникаций. Разработчики «Диасофт» модернизировали технологии событийного информирования, механизмов подписок, распределенных транзакций, включая поддержку современных брокеров сообщений, таких как Apache Kafka и RabbitMQ.

Дополнительно в новой версии решения «Диасофт» модернизированы базовые механизмы централизованного хранения данных. Так, в качестве СУБД поддержана новейшая платформа Oracle 19. «Диасофт» стал первым крупным поставщиком ПО для банков в России, который реализовал платежный компонент на базе СУБД Oracle 19.

«СУБД Oracle 19 позволяет «из коробки» строить гиперконвергентные решения, поддерживает контейнеризацию, повышает информационную безопасность с учетом новых реалий и обеспечивает непрерывность работы с мощной нагрузкой. С таким технологическим подходом без проблем доступен режим работы систем 24*7*365 – как в собственном ЦОД банка, так и в облачной экосистеме. Де-факто СУБД на платформе Oracle являются стандартом финансовых корпоративных систем, и важно поддерживать все актуальные ее доработки», – сказал Сергей Добриднюк.

В марте 2020 года команда «Диасофт» провела нагрузочные испытания своего решения по расчетам на критических объемах и сразу на двух СУБД – Oracle и PostgreSQL. Была смоделирована ситуация обработки более чем 20 млн платежных документов в день в сложной организационной структуре. Результаты испытаний превзошли ожидания команды – несмотря на сверхнагрузку, все регламентные операции были проведены в срок. Замеченные узкие места были оперативно устранены, что дало возможность «Диасофт» выпустить новую версию своего платежного решения, обогащенную как функционально, так и с перспективными скоростными характеристиками.

В «Диасофт» уверены, что Payment Hub открывает большие возможности для выхода банковского расчетного обслуживания на новый уровень. По мнению экспертов компании, задача построения Payment Hub актуальна для всех крупных банков, особенно из числа топ-20, как в России, так и за рубежом.

Источник

Платежный хаб Pay-logic внедрен в МТС-Банке

В январе 2015 года компания МТС-Банк организовала тендер «Платежный Хаб». В тот момент в МТС-Банке были внедрены программные решения большого количества различных поставщиков услуг, что усложняло управление и оптимизацию работы с ними, так как каждый поставщик предлагал собственное решение управления бизнес-процессами, собственный интерфейс, собственные процедуры. Это обстоятельство вызвало определённые трудности в дальнейшем развитии платежных инструментов банка и уменьшало их возможности по извлечению прибыли из всех процессов.

По задумке МТС-Банка новый платежный хаб должен был стать единой точкой входа для всех банковских решений: касс, терминалов и конечно же ДБО.

По результатам тендера компания «Soft-logic» была объявлена победителем, а продукт «Процессинговый центр Pay-logic» признан наиболее подходящим решением для поставленных задач.

Первым этапом внедрения стал трудоемкий процесс формирования требований между банком и компанией, который длился около 3 месяцев.
За 8 лет успешной работы на рынке специалисты «Soft-logic» убедились, что правильные коммуникации в начальной стадии проекта и постановка четких задач – основа эффективности дальнейшей работы, оперативного внедрения непосредственных решений и удовлетворения всех требований со стороны клиента в максимально сжатые сроки.
На данном этапе специалисты компании совместно с большой командой заказчика провели слаженную работу по формированию требований и составили планы внедрения проекта, включающие определенные сроки и дальнейшие этапы.

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

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

Владимир Екшибаров, технический директор и руководитель проекта «Платежный хаб» со стороны «Soft-logic» добавляет: «Помимо стратегических задач в ходе работы мы решили ряд тактических вопросов. Например, параллельно с внедрением хаба было изменено терминальное решение для продуктов банка. За столь протяженный период работы наша компания обладает определенным пулом технических подключений с большим количеством поставщиков услуг, что значительно упростило процессы их подключения в новом продукте банка. Мы просто включили их, не было необходимости проводить дополнительные интеграции по каждому поставщику, писать шлюзы под них и тратить время на определение их требований по подключению.

Теперь для контроля процессов, управления доступностью услуги на конкретном канале продаж, установки комиссий, настройки процентов и т.д. для менеджера банка существует единое окно, они выполняют всю работу в одной программе. Дополнительным бонусом для бизнес-отделов банка стала маршрутизация процессов, чего ранее они делать не могли, а также подключение к сервису ГИС ГМП (задолженности по налогам, по штрафам и т.д.), которое мы специально реализовали для них».

Весь рабочий проект условно разделяется на 4 этапа:

На текущий момент успешно реализованы 3 из 4 этапов. Специалисты «Soft-logic» отмечают, что наиболее трудоемким процессом стала миграция существующих провайдеров услуг в количестве 600 штук в новый платежный хаб, что, безусловно, позволяет специалистам гордиться выполненной работой.

Внедрение проекта за счет наличия в составе решения ПО управления терминалами самообслуживания (ТСО) позволило МТС-Банку отключить ТСО Дальневосточного филиала Банка с ПЦ Золотой короны и переключить их на «Платежный Хаб». Сейчас в активной стадии проходит реализация банковского функционала на ПО управления терминалами и переключение всего парка ТСО с карточного Процессингового Центра на «Платежный Хаб» Банка.
Кроме того, реализация этого проекта позволила Банку открыть новое направление платежного бизнеса и начать привлекать новых партнеров (сейчас осуществляется «пробный пилот») в качестве банковских платежных агентов (терминальный бизнес, прием платежей и переводов в торговых точках партнеров).

Источник

Единое решение для приема платежей во всех каналах обслуживания

Payments Hub (платежный хаб) — программный комплекс для централизованной организации приема платежей от физических лиц через любые каналы обслуживания клиентов банка:

Функциональные возможности Payments Hub

Единое решение для приема платежей позволяет реализовать сервис оплаты любых услуг и продуктов: мобильная связь и Интернет, услуги ЖКХ, налоги и штрафы, платежи в бюджет, страховые продукты, обучение; пополнение банковского счета, карт и кошельков других банков, банковских продуктов клиента банка; прием платежей по свободным реквизитам.

Результаты внедрения

Для построения качественного сервиса приема платежей банку требуется специализированное решение, без которого в дистанционных каналах банка клиентам редко доступно более 500 услуг для оплаты.

Payments Hub является централизованным решением для приема платежей. С помощью него банк может предложить клиентам значительно больше сервисов, каждый из которых будет доступен во всех каналах обслуживания. Банки, использующие Payments Hub, принимают платежи в адрес от 1 000 до 10 000 получателей и более.

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

Дополнительно в коробочной версии Payments Hub поддерживается полнотекстовый поиск по названию услуги, разделение услуг по регионам, расчет комиссий в онлайн режиме, ввод показаний счетчиков и приборов учета, шаблоны платежей и многое другое.

Решение для приема платежей Payments Hub позволяет не только настроить прием платежей по шлюзам в адрес большого количества поставщиков, но и сделать это эффективно с минимумом трудозатрат. В решении реализована функциональность для настройки и управления пулом поставщиков услуг в каждом из каналов обслуживания, централизованной выгрузки проводок в АБС, удобной работы сотрудников банка с потоком платежей, быстрого подключения платежных шлюзов к новым поставщикам и многое другое.

В результате внедрения Payments Hub трудозатраты на поддержку платежного сервиса со стороны сотрудников банка снижаются в 2-10 раз при одновременном увеличении числа сервисов, доступных конечным клиентам.

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

Использование агентской схемы для приема платежей на базе Payments Hub может быть использовано банком для:

Единое решение для платежей Payments Hub позволяет банку реализовать любой из вышеперечисленных вариантов работы с агентами, которым предоставляется веб-кабинет для управления собственной сетью приема платежей и дополнительное ПО для платежных киосков, касс или смартфонов. Все взаимодействие банка с агентами полностью автоматизировано.

Использование Payments Hub позволяет кардинально уменьшить трудозатраты при работе банка с агентами при одновременном улучшении качества взаимодействия.

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

Комиссионный доход банка от приема платежей существенно зависит от размера взимаемой комиссии. Гибкое управление размером комиссии требует специализированных программных решений. Из-за отсутствия технической возможности банк часто не может оптимально управлять размером комиссии и теряет на этом деньги.

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

Имея такие инструменты для управления комиссиями, банк может увеличить комиссионный доход в 2 и более раза при неизменном объеме платежей и без потери лояльности клиентов.

Использование Payments Hub обеспечивает стабильность и работу платежных сервисов банка в режиме 24/7. Добиться таких показателей стабильной работы, не имея единой централизованной системы проведения платежей, невозможно.

Payments Hub имеет развитые механизмы обеспечения надежности и поддерживает режим работы active-active в двух географически распределенных дата-центрах. Все компоненты платежного хаба линейно масштабируются и проблемы с любым из них не должны приводить к остановке сервиса. Дополнительно в решении предусмотрены механизмы маршрутизации, которые обеспечивают отправку платежа альтернативным каналом в случае, если основной канал недоступен.

Современные каналы ДБО предполагают наличие сервиса автоплатежей (Recurring Payments). Без них системы Интернет-банк или Мобильный банк нельзя назвать полноценными. Реализовать у себя сервис автоплатежей банк может различными способами, но удобнее всего это делать в рамках единой системы, которая отвечает в банке за прием платежей. Это упрощает управление сервисом и серьезно сокращает затраты на интеграцию.

С Payments Hub банк из коробки получает сервис автоплатежей в удаленных каналах обслуживания. Это платежи по расписанию, платежи по событию (например, пополнение счета телефона при снижении баланса ниже минимума) и сервисы прямого дебетования по выставленным клиенту счетам.

Сервис автоплатежей может быть реализован банком как отдельная система. Однако, ее функционал наиболее органично вписывается в архитектуру решения Payments Hub, где большая часть этого функционала уже имеется в коробочной версии продукта.

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

В Payments Hub предусмотрен целый набор механизмов для обеспечения безопасности транзакций и защиты от фрода. Решение позволяет обеспечить целостность транзакций, безопасное хранение ключей, парольную политику, аудит действий сотрудников и другие требования безопасности. Данный функционал полностью покрывает все требования информационной безопасности банка.

Также Payments Hub имеет встроенный сервис предотвращения фрода. Он специально предназначен для контроля фрода, который может возникнуть при проведении микро платежей. Это проверки по белым и черным спискам, анализ атрибутов платежа, выявление нетипичных событий и так далее. По нашему опыту при внедрении Payments Hub в банке такого функционала оказывается достаточно. Если у банка есть отдельная система антифрода, в решении предусмотрен стандартный API для интеграции с ней.

Источник