Перейти до вмісту
XSIS
Офісні вежі у фінансовому районі

Галузі

Фінтех і фінансові послуги

Банкінг, платежі та облікові книги, зʼєднані для точності в реальному часі й готовності до регуляторного нагляду.

Чому фінансові продукти ламаються на зʼєднаннях

Фінансовий продукт рідко складається з однієї системи. Він охоплює ядро облікової книги, обробку карток, перевірку особи, скринінг шахрайства, платіжні рейки й ERP за ними. Найскладніше в ньому: зʼєднання між цими системами й те, що відбувається, коли одна з них дає збій. Ми проєктуємо ці зʼєднання першими й письмово описуємо шлях збою.

  • Жорсткі регуляторні строки

    Вимоги електронного фактурування, як-от друга фаза ZATCA в Саудівській Аравії та PINT-AE в ОАЕ, а також правила стійкості, як-от DORA, набувають чинності у фіксовані дати.

  • Дані, які не можуть вийти назовні

    Регульовані банки не можуть надсилати записи про клієнтів чи фінансові дані до публічних сервісів ШІ за кордоном.

  • Ручне звіряння

    Пакетні файли й електронні таблиці досі стоять між банками, процесорами та ERP.

Що змінюється

  1. Точність облікової книги в реальному часі

    Кожне проведення, комісія та розрахунок звіряються автоматично, а винятки передаються людям.

  2. Готовність до регуляторного нагляду

    Доступ обмежений і журналюється, а кожна зміна простежувана ще до запуску.

  3. Суверенний ШІ

    ШІ для документів і помічники, що працюють у вашому власному середовищі, не виводячи дані за його межі.

Панорама Дубая в сутінках, вигляд із водного каналу

Наш провідний напрям

Фінтех є нашою провідною галуззю. Ми створюємо й інтегруємо програмне забезпечення, на якому працюють банки, платіжні компанії, кредитори, компанії з управління капіталом, страховики й постачальники гаманців, і знаємо стандарти, якими говорять ці системи: ISO 20022, ISO 8583, EMV, API відкритого банкінгу та формати файлів, від яких банки досі залежать.

Ми проєктуємо для регульованих середовищ. Доступ обмежений і журналюється, чутливі дані не потрапляють туди, де вони не потрібні, а кожна зміна простежувана. Ваші команди відповідності й ризиків бачать, як працює система, до запуску, а не після.

Банківський службовець рахує готівку за стійкою разом із клієнтом

Де ми працюємо

Що ми створюємо

  • Застосунки й портали цифрового банківництва для роздрібних і бізнесових клієнтів
  • Сервіси, що обгортають і розширюють основну банківську систему через API замість її заміни
  • Корпоративні канали для платіжних файлів, затверджень, виписок і залишків грошових коштів
  • Інструменти бек-офісу для операцій, розслідування платежів і обслуговування клієнтів
  • Технології ісламських фінансів і розширення ядра облікової книги

Типові інтеграції

  • Основні банківські системи через їхні API, черги повідомлень або пакетні інтерфейси

Що ми створюємо

  • Платіжна оркестрація, що спрямовує кожну транзакцію до потрібного шлюзу, еквайра або платіжної рейки
  • Онбординг торговців, портали та звітність
  • Послуги розрахунків, обчислення комісій і виплат
  • Звіряння, що зіставляє транзакції, розрахунки та банківські виписки

Що ми створюємо

  • Видача кредитів: заявки, збирання документів і процеси ухвалення рішень
  • Ухвалення кредитних рішень із правилами й пояснюваними моделями, які можуть переглядати кредитні команди
  • Обслуговування кредитів: графіки, платежі, заборгованість і стягнення
  • Портали брокерів і партнерів

Типові інтеграції

  • Кредитні бюро, дані рахунків open banking і перевірка особи
  • Облікові книги банківської системи чи кредитів, а також стягнення платежів прямим дебетуванням або карткою

Що ми створюємо

  • Клієнтські портали й застосунки з портфелями, транзакціями та документами
  • Звітність за портфелями й клієнтами на основі даних кастодіанів і ринку
  • Онбординг із анкетами відповідності й ризикового профілю
  • Інструменти радників для зустрічей із клієнтами, пропозицій і ребалансування

Типові інтеграції

  • Кастодіани, брокери й постачальники ринкових даних
  • Системи управління портфелями та CRM

Що ми створюємо

  • Сценарії розрахунку вартості й купівлі полісу для клієнтів і брокерів
  • Розширення адміністрування полісів для продуктів, додаткових угод і поновлень
  • Приймання страхових вимог із ШІ для документів, сортуванням і відстеженням статусу
  • Конвеєри даних ціноутворення й ризиків

Типові інтеграції

  • Системи адміністрування полісів і врегулювання збитків
  • Збір премій, повернення й головна книга

Що ми створюємо

  • Застосунки гаманців із поповненням, переказами, оплатою рахунків і платежами торговцям
  • Книга гаманця з подвійним записом і щоденним балансуванням
  • Випуск карток і токенізовані картки для мобільних платежів
  • Ліміти, комісії та правила лояльності, які операційні команди можуть змінювати самостійно

Типові інтеграції

  • Обробники випуску карток і послуги токенізації

Що ми створюємо

  • Великі кількісні моделі (LQM) для фінансового моделювання
  • Системи високочастотної торгівлі (HFT)
  • Виявлення шахрайства, AML і поведінкових аномалій у реальному часі

Типові інтеграції

  • Постачальники ринкових даних і торгові майданчики

Що ми будуємо, зʼєднуємо й захищаємо

  • Цифрові канали

    Веб- і мобільний банкінг, застосунки гаманців та інвестицій, спроєктовані для клієнтів і розраховані на навантаження дня зарплати й кінця місяця.

  • Розширення ядра

    Сервіси навколо основної банківської системи чи облікової книги, що додають продукти й канали без ризикованої заміни.

  • Платіжна оркестрація

    Маршрутизація, повторні спроби й перемикання між шлюзами, еквайрами та платіжними рейками з фіксацією кожної спроби.

  • Онбординг і KYC

    Онбординг клієнтів і бізнесу з перевірками особи, скринінгом і збором документів та чітким шляхом до ручного перегляду.

  • Моніторинг шахрайства й транзакцій

    Правила й моделі машинного навчання, що оцінюють транзакції в момент здійснення й утримують підозрілі для перегляду.

  • Звіряння й фінанси

    Зіставлення між обліковими книгами, процесорами, банками та ERP, щоб фінансова команда закривала період на даних, яким довіряють.

  • Підключення до банків

    Платежі та виписки у форматах ISO 20022 і MT через канали host-to-host, EBICS або банківські API.

  • Обробка карток

    Еквайри, процесори й платформи випуску через ISO 8583 або API, з терміналами EMV у магазині та 3-D Secure онлайн.

  • Відкритий банкінг

    Інформація про рахунки та ініціювання платежів через регульовані банківські API й агрегатори з належною обробкою згоди.

  • Ідентифікація, KYC та AML

    Перевірка особи, скринінг санкцій і політично значущих осіб та перевірка негативних згадок у медіа із збереженням кожного результату для аудиту.

  • ERP і головна книга

    Проведення, комісії та розрахунки переносяться в ERP, щоб фінанси бачили ті самі цифри, що й операції.

  • Карткові дані та PCI DSS

    Ми проєктуємо так, щоб за можливості тримати карткові дані поза вашими системами через токенізацію й розміщені платіжні поля, що зменшує периметр PCI DSS. Там, де карткові дані потрібно обробляти, ми будуємо за механізмами контролю, які перевірятиме ваш аудитор.

  • Посилена автентифікація клієнта

    Ми створюємо процеси автентифікації, яких вимагають платіжні й банківські правила, як-от двофакторний вхід і підписування транзакцій, лише з винятками, дозволеними вашою командою ризиків.

  • Механізми KYC та AML

    Онбординг і моніторинг зберігають докази, потрібні вашій команді відповідності: що перевірялося, коли, яким провайдером і хто ухвалив рішення.

  • Захист даних

    Ми погоджуємо, де можуть зберігатися й оброблятися персональні та фінансові дані, до початку робіт, і проєктуємо з урахуванням GDPR і місцевих законів, як-от PDPL ОАЕ та PDPL Саудівської Аравії, де вони застосовуються.

  • Аудиторський слід і стійкість

    Кожна зміна, що стосується грошей, лімітів і дозволів, журналюється й простежується, а системи будуються так, щоб безпечно зазнавати збоїв і відновлюватися, як того очікують правила операційної стійкості.

Як ми працюємо

  1. Оцініть готовність

    Головний інженер перевіряє обсяг, системи, дані й регуляторні вимоги.

  2. Спроєктуйте зʼєднання

    Інтеграційний шар, його шляхи збою й аудиторський слід проєктуються першими.

  3. Виконайте й експлуатуйте

    Поетапні релізи з контрольними точками приймання, далі керована експлуатація за узгодженими рівнями обслуговування.

Цифровий фінансовий продукт від початку до кінцяБанківський застосунок або гаманець звертається до одного шару API. За ним стоять перевірки особи, обробка карток і облікова книга. Транзакції перевіряються в момент здійснення, а все підозріле утримується для перегляду людиною.ЛюдиКлієнтСервісБанківськийзастосунок абогаманецьВеб і мобільніпристроїXSISШар APIАвтентифікація,ліміти й журналаудитуТретя сторонаПостачальник KYCта AMLОнбординг іскринінгШлюзКартковийпроцесорВипуск іавторизаціяБанкЯдро банківськоїсистеми абооблікова книгаРахунки, баланси тапроведенняСервісМоніторингшахрайства йтранзакційПравила й моделіЛюдиКомандавідповідності йопераційПереглядаєутримання йпередані випадки12REST/JSON · OAuth 2.03REST/JSONwebhook4REST/JSON · ISO 200225REST/JSON6ISO 8583789

Цифровий фінансовий продукт від початку до кінця

Банківський застосунок або гаманець звертається до одного шару API. За ним стоять перевірки особи, обробка карток і облікова книга. Транзакції перевіряються в момент здійснення, а все підозріле утримується для перегляду людиною.

  • Основний потік
  • Асинхронний
  • Шлях винятків
Потік у 9 кроках

Потік крок за кроком

  1. Від Клієнт до Банківський застосунок або гаманець: Реєструється, платить і переказує (основний потік).
  2. Від Банківський застосунок або гаманець до Шар API: Запити, через REST/JSON · OAuth 2.0 (основний потік).
  3. Від Шар API до Постачальник KYC та AML: Перевірки особи й скринінг, через REST/JSON · webhook (основний потік).
  4. Від Шар API до Ядро банківської системи або облікова книга: Проведення й баланси, через REST/JSON · ISO 20022 (основний потік).
  5. Від Шар API до Картковий процесор: Випуск карток і контроль, через REST/JSON (основний потік).
  6. Від Картковий процесор до Ядро банківської системи або облікова книга: Карткові транзакції, через ISO 8583 (асинхронний).
  7. Від Шар API до Моніторинг шахрайства й транзакцій: Транзакції для перевірки як потік подій (асинхронний).
  8. Від Моніторинг шахрайства й транзакцій до Команда відповідності й операцій: Утримано для перегляду (шлях винятків).
  9. Від Постачальник KYC та AML до Команда відповідності й операцій: Невдалі або нечіткі перевірки передано (шлях винятків).
ERP до банку: платежі назовні, виписки всерединуЗатверджені платежі виходять з ERP підписаними файлами ISO 20022 через канал host-to-host. Звіти про статус і виписки повертаються тим самим шляхом і зіставляються з відкритими позиціями. Відхилення й незіставлені рядки надходять вашій команді із зазначеною причиною.ERPERPПлатіжні цикли,відкриті позиції,головна книгаXSISШар інтеграціїЗіставлення,перевірка,підписування таплануванняШлюзЗахищенийбанківськийканалHost-to-host SFTP,EBICS абобанківський APIБанкБанкПлатежі тауправліннягрошовими коштамиСервісМеханізмзвірянняПравила зіставленнята допустимівідхиленняЛюдиКазначейство йфінансовакомандаПереглядаєвідхилення йрозбіжності1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP до банку: платежі назовні, виписки всередину

Затверджені платежі виходять з ERP підписаними файлами ISO 20022 через канал host-to-host. Звіти про статус і виписки повертаються тим самим шляхом і зіставляються з відкритими позиціями. Відхилення й незіставлені рядки надходять вашій команді із зазначеною причиною.

  • Основний потік
  • Асинхронний
  • Шлях винятків
Потік у 10 кроках

Потік крок за кроком

  1. Від ERP до Шар інтеграції: Затверджений платіжний цикл, через REST/JSON · IDoc (основний потік).
  2. Від Шар інтеграції до Захищений банківський канал: Підписаний і зашифрований платіжний файл, через ISO 20022 pain.001 · OpenPGP (основний потік).
  3. Від Захищений банківський канал до Банк: Доставлено в банк, через SFTP H2H (основний потік).
  4. Від Банк до Захищений банківський канал: Звіти про статус і виписки, через pain.002 · camt.053 · MT940 (асинхронний).
  5. Від Захищений банківський канал до Шар інтеграції: Зібрано й перевірено, через SFTP H2H (асинхронний).
  6. Від Шар інтеграції до Механізм звіряння: Рядки виписки, через camt.053 (асинхронний).
  7. Від Механізм звіряння до ERP: Зіставлені записи проведено, через REST/JSON (основний потік).
  8. Від Шар інтеграції до Казначейство й фінансова команда: Відхилені платежі з кодом причини, через pain.002 RJCT (шлях винятків).
  9. Від Механізм звіряння до Казначейство й фінансова команда: Незіставлені рядки: розбіжність звіряння (шлях винятків).
  10. Від Казначейство й фінансова команда до ERP: Виправлено й подано повторно (шлях винятків).
Карткові платежі: авторизація на касі, розрахунки пізніше, звіряння в ERPТермінал або оформлення замовлення звертається до шлюзу, шлюз до еквайра, а еквайр маршрутизує до карткової мережі та емітента. Файли розрахунків надходять пізніше й зіставляються з продажами та комісіями в ERP. Тайм-аут запускає скасування, щоб із клієнта ніколи не стягнули двічі.POSТермінал EMV абоонлайн-оформленняЧип, безконтактніплатежі таелектронна комерціяШлюзПлатіжний шлюзТокенізація тамаршрутизаціяБанкЕквайрАвторизація тарозрахункиТретя сторонаКарткова мережа йемітентСхвалює абовідхиляєERPERPПродажі, комісії тавиплатиXSISШар інтеграціїРозбір ізіставленнярозрахунківЛюдиОпераційнакоманда платежівРозбіжності, спорита чарджбеки1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

Карткові платежі: авторизація на касі, розрахунки пізніше, звіряння в ERP

Термінал або оформлення замовлення звертається до шлюзу, шлюз до еквайра, а еквайр маршрутизує до карткової мережі та емітента. Файли розрахунків надходять пізніше й зіставляються з продажами та комісіями в ERP. Тайм-аут запускає скасування, щоб із клієнта ніколи не стягнули двічі.

  • Основний потік
  • Асинхронний
  • Шлях винятків
Потік у 8 кроках

Потік крок за кроком

  1. Від Термінал EMV або онлайн-оформлення до Платіжний шлюз: Запит авторизації, через EMV · REST/JSON (основний потік).
  2. Від Платіжний шлюз до Еквайр: Авторизація, через ISO 8583 (основний потік).
  3. Від Еквайр до Карткова мережа й емітент: Маршрутизовано до емітента, через ISO 8583 (основний потік).
  4. Від Еквайр до Платіжний шлюз: Схвалено або відхилено, через ISO 8583 (асинхронний).
  5. Від Еквайр до Шар інтеграції: Файли розрахунків і комісій, через SFTP (асинхронний).
  6. Від Шар інтеграції до ERP: Розраховані продажі, комісії та виплати, через REST/JSON (основний потік).
  7. Від Платіжний шлюз до Термінал EMV або онлайн-оформлення: Немає відповіді вчасно: автоматичне скасування, через ISO 8583 0400 (шлях винятків).
  8. Від Шар інтеграції до Операційна команда платежів: Розбіжність розрахунків або чарджбек (шлях винятків).
Open banking: дані та платежі за згодою клієнтаКлієнт надає згоду, конектор зберігає токени, а кожен виклик до банку авторизується й журналюється. Коли згода спливає або відкликається, застосунок знову запитує клієнта, а не збоїть мовчки.ЛюдиКлієнтСервісВаш застосунокабо платформаКазначейство,кредитування абобухгалтеріяXSISКонектор openbankingЗгода, токени танормалізація данихБанкБанківські APIабо агрегаторІнформація прорахунки таініціюванняплатежівERPERP або головнакнигаПозиція грошовихкоштів і звіряння12REST/JSON3OAuth 2.0 · FAPI · REST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

Open banking: дані та платежі за згодою клієнта

Клієнт надає згоду, конектор зберігає токени, а кожен виклик до банку авторизується й журналюється. Коли згода спливає або відкликається, застосунок знову запитує клієнта, а не збоїть мовчки.

  • Основний потік
  • Асинхронний
  • Шлях винятків
Потік у 7 кроках

Потік крок за кроком

  1. Від Клієнт до Ваш застосунок або платформа: Надає згоду (основний потік).
  2. Від Ваш застосунок або платформа до Конектор open banking: Запити рахунків і платежів, через REST/JSON (основний потік).
  3. Від Конектор open banking до Банківські API або агрегатор: Авторизовані виклики API, через OAuth 2.0 · FAPI · REST (основний потік).
  4. Від Банківські API або агрегатор до Конектор open banking: Баланси, транзакції та статус платежу, через REST/JSON · webhook (асинхронний).
  5. Від Конектор open banking до ERP або головна книга: Нормалізовані транзакції, через REST/JSON (основний потік).
  6. Від Банківські API або агрегатор до Конектор open banking: Згода спливла або відкликана, через HTTP 401 · 403 (шлях винятків).
  7. Від Конектор open banking до Ваш застосунок або платформа: Клієнта просять поновити згоду (шлях винятків).

Як почати

Що буде далі

  1. Узгодження часу

    Наша команда напише вам, щоб узгодити час сесії.

  2. Попередня консультація

    Формат: безкоштовна 30-хвилинна онлайн-консультація перед співпрацею. Ми разом розбираємо ваші цілі, системи й обмеження.

  3. Оцінка готовності

    На кроці «безкоштовна 48-годинна оцінка готовності» головний архітектор перевіряє ваш проєкт за 6 пунктами Definition of Ready і рекомендує відповідний трек.

  4. Вибір треку

    Проєкти з готовим обсягом отримують обовʼязкову пропозицію протягом від 3 до 5 робочих днів. Проєкти на стадії концепції починаються в Blueprint Studio. Робоча система, яка дає збої, не має документації або потребує інтеграції, починається з діагностики тривалістю від 1 до 2 тижнів. Blueprint Studio і діагностика мають фіксовану плату, зазначену в пропозиції.

Найшвидший спосіб почати: пакет Спринт готовності до електронного фактурування й ERP, один із наших пакетів швидкої співпраці.

З чого почати

Запитання й відповіді

Які роботи у фінтеху виконує XSIS?

Фінтех є нашою провідною галуззю. Ми створюємо застосунки цифрового банківництва й гаманців, платіжні та розрахункові сервіси, кредитні платформи, звітність для управління капіталом і шляхи клієнтів у страхуванні та підключаємо їх до банків, карткових процесорів, провайдерів KYC і ERP-систем. Ми не публікуємо назви клієнтів без їхньої згоди, тож показуємо досвід через системи й стандарти, з якими працюємо, і в технічних розмовах із вашими архітекторами.

Чи можете ви працювати в межах наших регуляторних вимог і вимог безпеки?

Так. Ми працюємо в межах ваших політик: ваших правил доступу, середовищ, процесу змін і вимог аудиту. До початку робіт ми погоджуємо, як обробляються дані, до яких середовищ можуть мати доступ інженери і які докази потрібні вашим командам ризиків і відповідності. Ми описуємо застосовувані механізми контролю просто, щоб ваші аудитори могли їх переглянути.

Чи маємо ми замінювати основну банківську систему?

Зазвичай ні. Більшість банків виграють більше, обгортаючи ядро чітко визначеними API й будуючи нові продукти та канали як сервіси навколо нього. Так система обліку залишається стабільною, а клієнтські частини змінюються швидше. Там, де ядро справді треба замінити, ми плануємо міграцію поетапно й звіряємо обидві системи, доки стару не вимкнуть.

Як ви обробляєте карткові дані?

Ми проєктуємо так, щоб якомога менше систем бачили повний номер картки. Розміщені платіжні поля, токенізація й мережеві токени залишають карткові дані в процесора, що зменшує ваш периметр PCI DSS. Там, де система мусить обробляти карткові дані, ми будуємо її за застосовними механізмами PCI DSS і документуємо їх для вашого аудитора.

Чи можете ви підтримувати ISO 20022 та миттєві платежі?

Так. Ми створюємо сервіси, що формують, перевіряють і читають повідомлення ISO 20022 як для корпоративних платежів і звітності, наприклад pain.001 і camt.053, так і для міжбанківських повідомлень, які використовують системи миттєвих і великих платежів. Кожна платіжна схема й кожен банк мають власні правила, тож ми працюємо за їхніми настановами з упровадження й тестуємо в їхніх тестових середовищах.

Чи можете ви створити моніторинг шахрайства й транзакцій?

Так. Ми поєднуємо правила, які ваші аналітики можуть читати й змінювати, з моделями машинного навчання, навченими на ваших даних, і пояснюємо, чому виникло кожне оповіщення. Оповіщення надходять у чергу справ, де аналітики вирішують, а їхні рішення повертаються в правила й моделі. Там, де ви вже використовуєте спеціалізованих постачальників скринінгу, ми підключаємо їх.

Що формує вартість фінтех-проєкту?

Кількість задіяних систем і партнерів, регуляторні механізми контролю, що застосовуються, обсяг і швидкість, які має витримувати система, та обсяг тестування, якого партнери вимагають до запуску. Підключення партнерів, як-от сертифікація в банку чи процесора, часто більше визначає темп, ніж код. Ми оцінюємо після дослідження й ділимо роботу на етапи, які ви можете фінансувати й затверджувати по одному.

Почніть із розмови, а не з договору.

Розкажіть, що вам треба побудувати, зʼєднати чи захистити. Архітектор пройде це з вами, а потім порадить, з чого почати.