跳至主要内容
XSIS
金融区的写字楼

行业

金融科技与金融服务

银行、支付与总账连接,实现实时准确性与监管审查。

金融产品为何在连接处失败

金融产品很少是单一系统。它由核心总账、银行卡处理、身份核验、欺诈筛查、支付通道以及背后的 ERP 组成。难点在于它们之间的连接,以及其中一个失败时会发生什么。我们先设计这些连接,并写明失败路径。

  • 严格的监管截止日期

    沙特 ZATCA 第二阶段、阿联酋 PINT-AE 等电子发票强制要求,以及 DORA 等韧性规则,都有固定生效日期。

  • 不能外流的数据

    受监管银行不能将客户或财务记录发送至境外的公共 AI 服务。

  • 手工对账

    银行、处理器与 ERP 之间仍依赖批量文件和电子表格。

带来什么变化

  1. 实时总账准确性

    每笔记账、费用与结算自动对账,异常转交人工。

  2. 做好监管审查准备

    上线前即限制并记录访问,所有变更可追溯。

  3. 主权 AI

    在您自有环境中运行的文档 AI 与助手,数据不出境。

从水运河眺望黄昏时的迪拜天际线

我们的重点业务领域

金融科技是我们的重点行业。我们构建并集成银行、支付公司、信贷机构、财富管理机构、保险公司与钱包服务商所运行的软件,并熟悉这些系统使用的标准:ISO 20022、ISO 8583、EMV、开放银行 API,以及银行仍依赖的文件格式。

我们为受监管环境构建系统。访问受限并记录,敏感数据不进入不需要它的地方,所有变更均可追溯。您的合规与风险团队在系统上线前就能了解其运作方式,而不是事后。

一名银行柜员在柜台与客户一起清点现金

我们的工作地点

我们构建什么

  • 面向零售与企业客户的数字银行应用与门户
  • 通过 API 封装并扩展核心银行系统的服务,而非替换核心
  • 用于付款文件、审批、对账单与现金头寸的企业渠道
  • 用于运营、支付调查与客户服务的后台工具
  • 伊斯兰金融技术与核心总账扩展

典型集成

  • 核心银行系统,通过其 API、消息队列或批量接口

我们构建什么

  • 支付编排,将每笔交易路由至正确的网关、收单机构或通道
  • 商户入驻、门户与报表
  • 结算、费用计算与付款服务
  • 对账,匹配交易、结算与银行对账单

我们构建什么

  • 授信发起:申请、文档收集与决策工作流
  • 信用决策,采用信贷团队可审核的规则与可解释模型
  • 贷后服务:还款计划、还款、逾期与催收
  • 经纪商与合作伙伴门户

典型集成

  • 征信机构、开放银行账户数据与身份核验
  • 核心银行或贷款总账,以及通过直接借记或银行卡收款

我们构建什么

  • 含投资组合、交易与文档的客户门户与应用
  • 基于托管机构与市场数据的投资组合及客户报告
  • 含适当性与风险画像问卷的入驻
  • 用于客户评审、方案与再平衡的顾问工具

典型集成

  • 托管机构、经纪商与市场数据提供商
  • 投资组合管理与 CRM 系统

我们构建什么

  • 面向客户与经纪商的报价与购买旅程
  • 面向产品、批单与续保的保单管理扩展
  • 含文档 AI、分诊与状态跟踪的理赔受理
  • 定价与风险数据管道

典型集成

  • 保单管理与理赔系统
  • 保费收取、退款与总账

我们构建什么

  • 支持充值、转账、账单支付与商户支付的钱包应用
  • 采用复式记账与每日平衡的钱包总账
  • 用于移动支付的发卡与令牌化银行卡
  • 运营团队可自行调整的限额、费用与忠诚度规则

典型集成

  • 发卡处理器与令牌化服务

我们构建什么

  • 用于金融仿真的大型定量模型(LQM)
  • 高频交易(HFT)系统
  • 实时欺诈、反洗钱与行为异常检测

典型集成

  • 市场数据提供商与交易场所

我们构建、连接与保障什么

  • 数字渠道

    Web 与移动银行、钱包与投资应用,面向客户设计,并按发薪日与月末的负载构建。

  • 核心扩展

    围绕核心银行或总账系统的服务,在不进行高风险替换的前提下增加产品与渠道。

  • 支付编排

    跨网关、收单机构与支付通道的路由、重试与故障转移,每次尝试均有记录。

  • 入驻与 KYC

    客户与企业入驻,含身份核验、筛查与文档采集,并有清晰的人工审核路径。

  • 欺诈与交易监控

    在交易发生时评分的规则与机器学习模型,暂留可疑交易待审。

  • 对账与财务

    跨总账、处理器、银行与 ERP 的匹配,使财务基于可信数据结账。

  • 银行连接

    通过 host-to-host 通道、EBICS 或银行 API,以 ISO 20022 与 MT 格式收发支付与对账单。

  • 银行卡处理

    通过 ISO 8583 或 API 连接收单机构、处理器与发卡平台,门店使用 EMV 终端,线上使用 3-D Secure。

  • 开放银行

    通过受监管的银行 API 与聚合平台获取账户信息并发起支付,妥善处理授权。

  • 身份、KYC 与反洗钱

    身份核验、制裁与政治公众人物筛查、负面媒体核查,所有结果留存备查。

  • ERP 与总账

    记账、费用与结算带入 ERP,使财务与运营看到相同数字。

  • 银行卡数据与 PCI DSS

    我们尽量通过令牌化与托管支付字段,让银行卡数据不进入您的系统,从而缩小 PCI DSS 范围。必须处理银行卡数据时,我们按您的评估机构将测试的控制要求构建。

  • 强客户认证

    我们构建支付与银行规则要求的身份验证流程,例如双因素登录与交易签名,仅使用您的风险团队允许的豁免。

  • KYC 与反洗钱控制

    入驻与监控保留合规团队所需的证据:检查了什么、何时、由哪个服务商、由谁做出决定。

  • 数据保护

    工作开始前我们商定个人与财务数据可存储和处理的地点,并在适用时按 GDPR 以及阿联酋 PDPL、沙特 PDPL 等当地法律设计。

  • 审计追踪与韧性

    对资金、限额与权限的每次变更均记录并可追溯,系统按运营韧性规则的要求构建为可安全失败并恢复。

我们的工作方式

  1. 评审就绪度

    首席工程师评审范围、系统、数据与监管需求。

  2. 设计连接

    首先设计集成层、其失败路径与审计追踪。

  3. 交付与运行

    在验收门禁后分阶段发布,随后按约定服务水平进行托管运营。

数字金融产品,端到端银行或钱包应用与一个 API 层通信。其背后是身份核验、银行卡处理与核心总账。交易发生时即被筛查,任何可疑交易都会被暂留,交由人工复核。人员客户服务银行或钱包应用Web 与移动端XSISAPI 层身份验证、限额与审计日志第三方KYC 与反洗钱服务商入驻与筛查网关银行卡处理器发卡与授权银行核心银行或总账账户、余额与记账服务欺诈与交易监控规则与模型人员合规与运营团队审核暂留与转介12REST/JSON · OAuth 2.03REST/JSONwebhook4REST/JSON · ISO 200225REST/JSON6ISO 8583789

数字金融产品,端到端

银行或钱包应用与一个 API 层通信。其背后是身份核验、银行卡处理与核心总账。交易发生时即被筛查,任何可疑交易都会被暂留,交由人工复核。

  • 主流程
  • 异步
  • 异常路径
9 步流程

流程逐步说明

  1. 从客户到银行或钱包应用:注册、支付与转账(主流程)。
  2. 从银行或钱包应用到API 层:请求,经由REST/JSON · OAuth 2.0(主流程)。
  3. 从API 层到KYC 与反洗钱服务商:身份与筛查核验,经由REST/JSON · webhook(主流程)。
  4. 从API 层到核心银行或总账:记账与余额,经由REST/JSON · ISO 20022(主流程)。
  5. 从API 层到银行卡处理器:发卡与控制,经由REST/JSON(主流程)。
  6. 从银行卡处理器到核心银行或总账:银行卡交易,经由ISO 8583(异步)。
  7. 从API 层到欺诈与交易监控:待筛查交易,以事件流形式(异步)。
  8. 从欺诈与交易监控到合规与运营团队:暂留待审(异常路径)。
  9. 从KYC 与反洗钱服务商到合规与运营团队:失败或不明核验转介(异常路径)。
ERP 到银行:付款出,对账单入已批准的付款以签名 ISO 20022 文件通过 host-to-host 通道离开 ERP。状态报告与对账单以相同方式返回,并与未清项匹配。拒绝与未匹配行连同原因交予您的团队。ERPERP付款批次、未清项、总账XSIS集成层映射、校验、签名与调度网关安全银行通道host-to-hostSFTP、EBICS 或银行 API银行银行支付与资金管理服务对账引擎匹配规则与容差人员资金与财务团队审核拒绝与差异1REST/JSON · IDoc2ISO 20022 pain.001OpenPGP3SFTP H2H4pain.002 · camt.053MT9405SFTP H2H6camt.0537REST/JSON8pain.002 RJCT910

ERP 到银行:付款出,对账单入

已批准的付款以签名 ISO 20022 文件通过 host-to-host 通道离开 ERP。状态报告与对账单以相同方式返回,并与未清项匹配。拒绝与未匹配行连同原因交予您的团队。

  • 主流程
  • 异步
  • 异常路径
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 中的销售及费用匹配。超时会触发撤销,确保客户不会被重复扣款。POSEMV 终端或在线结账芯片、非接触与电子商务网关支付网关令牌化与路由银行收单机构授权与结算第三方卡组织与发卡机构批准或拒绝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. 从集成层到支付运营团队:结算错配或拒付(异常路径)。
开放银行:经客户授权的数据与支付客户授予授权,连接器保管令牌,每次调用银行 API 均经授权并记录。授权过期或撤回时,应用会再次请求客户授权,而不是悄然失败。人员客户服务您的应用或平台资金管理、信贷或会计XSIS开放银行连接器授权、令牌与数据规范化银行银行 API 或聚合平台账户信息与支付发起ERPERP 或总账现金头寸与对账12REST/JSON3OAuth 2.0 · FAPI · REST4REST/JSON · webhook5REST/JSON6HTTP 401 · 4037

开放银行:经客户授权的数据与支付

客户授予授权,连接器保管令牌,每次调用银行 API 均经授权并记录。授权过期或撤回时,应用会再次请求客户授权,而不是悄然失败。

  • 主流程
  • 异步
  • 异常路径
7 步流程

流程逐步说明

  1. 从客户到您的应用或平台:授予授权(主流程)。
  2. 从您的应用或平台到开放银行连接器:账户与支付请求,经由REST/JSON(主流程)。
  3. 从开放银行连接器到银行 API 或聚合平台:经授权的 API 调用,经由OAuth 2.0 · FAPI · REST(主流程)。
  4. 从银行 API 或聚合平台到开放银行连接器:余额、交易与支付状态,经由REST/JSON · webhook(异步)。
  5. 从开放银行连接器到ERP 或总账:规范化交易,经由REST/JSON(主流程)。
  6. 从银行 API 或聚合平台到开放银行连接器:授权过期或撤回,经由HTTP 401 · 403(异常路径)。
  7. 从开放银行连接器到您的应用或平台:请客户重新授权(异常路径)。

如何开始

后续流程

  1. 约定时间

    我们的团队会通过电子邮件与您约定会谈时间。

  2. 咨询前会谈

    一次免费 30 分钟在线预咨询:我们梳理您的目标、系统与限制条件。

  3. 就绪评估

    在免费 48 小时就绪评估中,首席架构师对照 6 项就绪定义检查您的项目,并推荐合适的路线。

  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),也用于即时与高额支付系统使用的行间报文。每个清算体系与银行都有自己的规则,因此我们依据其实施指南工作,并在其测试环境中测试。

你们能构建欺诈与交易监控吗?

可以。我们将分析师可读取和修改的规则与基于您自有数据训练的机器学习模型结合,并解释每次告警的原因。告警进入案件队列,由分析师决定,其决定再反馈到规则与模型中。若您已使用专业筛查服务商,我们会进行连接。

金融科技项目的成本由什么决定?

涉及的系统与合作伙伴数量、适用的监管控制、系统必须处理的量与速度,以及合作伙伴在上线前要求的测试量。银行或处理器认证等合作伙伴入驻,往往比代码更能决定进度。我们在需求探索后估算,并将工作拆分为可逐项出资和批准的阶段。

从对话开始,而不是从合同开始。

告诉我们您需要构建、连接或保障什么。架构师会与您一起梳理,然后建议从何处入手。