利用智能体式 AI、基于 JSON 的规范模型和 MongoDB Atlas,实现支付现代化,连接 ISO 20022、ISO 8583 与稳定币。
行业: 金融服务
产品和工具: MongoDB Atlas、MongoDB Atlas Vector Search、MongoDB Atlas Search
合作伙伴: Amazon Bedrock、LangChain、LangGraph
解决方案概述
当今的支付处理商面临互操作性问题。他们必须处理旧版卡消息(ISO 8583)、现代富数据标准(ISO 20022)以及不断发展的加密支付轨道。传统系统依赖于僵化的提取、转换、加载 (ETL) 管道,当新字段出现或本地法规发生变化时,这些管道就会中断。
为了连接旧版基础设施和金融的未来,JSON 原生的规范支付模型充当了现代编排的基本基础。在后 ISO 20022 环境中,它解决了在不同实现(如 CBPR+ 和 FedNow)中出现的语义方言碎片化问题。它可以防止 SWIFT 识别的数据截断风险,即旧版内部系统由于缺乏存储扩展字段的功能而剥离丰富的 ISO 20022 数据。由于该模型以灵活的 JSON 格式捕获完整的消息深度,系统在转换过程中不会丢失任何数据。
与通用 API 抽象相结合,该平台使 IT 团队能够从不透明的二进制位图和碎片化标准迁移到对开发者友好的环境。该环境允许加速开发和重用,因为新的支付轨道——从印度的 UPI 到稳定币——可以作为模块化扩展集成,而无需重写核心代码。
除了开发速度外,这种模式还能建立集中的支付方案和数据治理,实现单点更新,即新的监管字段只需定义一次,并在所有转换逻辑中继承。这种从僵化的 SQL 模式到灵活的文档模型的转变,消除了传统中心典型的技术债务和维护负担。通过在生命周期的早期将数据规范化为真正标准化和一致的数据模型,该模型有助于早期合规互动和主动的动态修复。最终,它提供了在诸如加密资产市场 (MiCA) 等新法规下不断发展的多轨道世界中所需要的明确治理和运营敏捷性。
以下视频给出了一个从德国到日本的跨境支付示例,其中包含智能体驱动的债权人姓名日文片假名音译:
该解决方案演示了带有 Agentic AI 的规范支付模型如何重新定义支付处理。通过从僵化的 SQL 模式转向灵活的、基于 JSON 的规范模型,金融机构可以授权 AI 智能体自主地跨任何支付轨道(例如 SWIFT 电汇或公共区块链上的 USDC 转账)进行数据摄取、规范化、路由和修复交易。
JSON 基础
基于 JSON 的数据模型是多支付轨道处理系统的关键基础,因为它具有以下属性:
API 原生:现代支付,尤其是在加密货币和金融科技领域,使用 API 驱动的通信(REST/GraphQL/RPC),这本身就是基于 JSON 的。原生格式可降低转换延迟和复杂性。
模式灵活性:JSON 处理通用字段(金额、发送方),同时容纳特定轨道的字段(例如,加密货币的 Gas 限制、日本的 Zengin 代码、ISO 20022 的汇款信息),而不会破坏核心模式。
AI 就绪:LLM 在代码和 JSON 上进行训练。智能体可以直接分析数据结构,检测异常并执行复杂的映射,比使用不透明的二进制位图或僵化的 SQL 表更有效。
参考架构
此支付处理演示包含一个支付处理平台,该平台处理从格式接入到执行和修复的完整交易生命周期。该架构将特定职责委派给专门的组件:
构建
配置构建器:在开发期间加速格式接入。聚合管道从现有配置中提取字段映射,而 LLM 为未知字段建议映射。曾经需要数月才能集成的新格式,现在可以在数周内完成配置。一旦配置就绪,平台即可处理实时交易处理。
执行
消息转换服务:传入消息通过一个配置驱动的处理系统。大多数字段遵循存储在 MongoDB 中的确定性规则,这些规则是在前面描述的构建过程中构建的。复杂的非结构化字段(如汇款信息)会路由到由 Claude 驱动的 AI 通道。
智能体解析服务:一个修复验证失败交易的多智能体系统。一个监督者将任务路由给专门的智能体:解析智能体为缺失或无效字段查找正确的值(使用数据库查找、Atlas Search 或 AI 推理),执行智能体应用已批准的更改并记录审核跟踪。
图 1. 支付处理平台架构,展示了使用 MongoDB Atlas 的消息转换、规范 JSON 路由和智能体解析
如架构图所示,MongoDB 充当操作数据层 (ODL)。该系统将每笔交易存储为单个文档,其中包含规范化的规范 JSON 以及智能体决策的完整审核跟踪。转换配置位于单独的集合中,使格式更改成为数据驱动。这种结构提供了法规遵从性所需的可审核性。
核心功能
该演示展示了 MongoDB 灵活模式和 Agentic AI 改变支付操作的四项核心功能。
数据驱动消息翻译
旧版系统通常硬编码转换逻辑(例如,“字段 4 映射到字段 32A”)。该解决方案将转换规则和元数据与数据一起存储在 MongoDB 中,使转换逻辑成为数据驱动。
无需重新编译代码来更改映射,只需更新 MongoDB 中的配置文档即可。转换器服务会动态读取这些规则(提取模式、字段映射和输出路径),将传入 ISO 8583 或 SWIFT MT 消息规范化为规范的 JSON 格式。
配置驱动的转换:
# Load config from MongoDB config = db.conversion_configs.find_one({"_id": "MT103_to_JSON"}) # Extract fields using patterns from config["extract"] for field_id, pattern in config["extract"].items(): extracted[field_id] = re.search(pattern, message).group(1) # Transform using rules from config["map"] for mapping in config["map"]: value = extracted[mapping["from"]] if "ai" not in mapping: # RULES lane output[mapping["to"]] = value else: # AI lane ai_fields.append({"value": value, "field_type": mapping["ai"]})
某些字段无法用正则表达式处理,例如 SWIFT 字段 70(汇款信息)可能包含自由文本的付款用途、发票参考和多行指示。配置将这些字段标记为 AI 处理(“ai”:“remittance”),LLM 从非结构化文本中提取结构化数据。这种方法对大多数字段保持确定性规则,但通过推理处理复杂的剩余部分。
通过插入文档即可启用新消息格式——转换器代码保持不变,使转换逻辑脱离部署周期。
由生成式 AI 驱动的自适应转换
由于规则和历史元数据存储在数据库中,您可以使用生成式 AI (LLM) 来加速新支付格式的接入。
要添加对新消息类型的支持,请提供一个示例消息。自适应学习服务从 MongoDB 加载所有现有的转换配置,并使用特定格式的解析来提取字段。它将检测到的字段 ID 与现有配置中的映射进行匹配。例如,如果字段 ”32A“ 存在于 MT103_to_JSON 中,则会重复使用该精确映射。
对于在任何现有配置中未找到的字段,LLM 会建议映射,供您审查和优化。这将生成一个准备就绪、供人工审查和部署的配置草案。曾经需要数月才能集成的支付轨道,现在可以更快地接入。
使用聚合和 LLM 的自适应学习:
# Aggregation pipeline: extract field mappings from ALL existing configs pipeline = [ {"$addFields": {"extract_array": {"$objectToArray": "$extract"}}}, {"$unwind": "$map"}, {"$project": {"field_id": "$map.from", "mapping": "$map", "source_config": "$_id"}}, {"$group": {"_id": "$field_id", "mapping": {"$first": "$mapping"}}} ] field_lookup = {doc["_id"]: doc for doc in db.conversion_configs.aggregate(pipeline)} # Match detected fields against learned patterns for field_id in detected_fields: if field_id in field_lookup: matched[field_id] = field_lookup[field_id]["mapping"] else: unknown.append(field_id) # For unknown fields: LLM suggests mappings constrained by format spec suggestions = bedrock.invoke_claude(f"Map {unknown} to {target_format} fields")
聚合管道在一次查询中从所有配置构建字段到映射的查找。已知字段可立即匹配。未知字段获得的 LLM 建议受目标格式支持字段的限制。
智能体支付修复
跨境支付经常因本地清算要求而失败,例如缺少代码、脚本不正确或机构数据不完整。传统系统将这些异常排队等待人工审核,通常需要数天才能解决。
解析智能体会使用 LLM 根据文档和系统提示自主选择的工具来处理这些异常。该模式引导 LLM 优先选择更便宜、更快的选项。
解析智能体工具选择:
from langchain_core.tools import tool from langgraph.prebuilt import create_react_agent def atlas_search(collection: str, query: str, search_fields: list, fuzzy: bool = True) -> dict: """Search MongoDB using Atlas Search. Use fuzzy=False for exact match first.""" pipeline = [{"$search": { "index": f"{collection}_search", "text": {"query": query, "path": search_fields, "fuzzy": {"maxEdits": 2} if fuzzy else {}} }}] results = list(db[collection].aggregate(pipeline)) return {"found": bool(results), "top_result": results[0] if results else None} def vector_search(collection: str, query: str) -> dict: """Semantic search using Atlas Vector Search - matches by meaning, not keywords.""" embedding = voyage_client.embed([query], model="voyage-3").embeddings[0] pipeline = [{"$vectorSearch": { "index": f"{collection}_vector", "path": "embedding", "queryVector": embedding, "numCandidates": 100, "limit": 3 }}] results = list(db[collection].aggregate(pipeline)) return {"found": bool(results), "top_result": results[0] if results else None} agent = create_react_agent(model=llm, tools=[atlas_search, vector_search])
LLM 读取工具文档字符串和系统提示,以确定调用哪个工具。Atlas Search 处理精确查找和容错匹配。Vector Search 处理关键词不匹配但语义匹配的分类任务。为了在实践中说明这些功能,请考虑以下支付场景:
日本(片假名音译):向东京付款需要用片假名输入收款人姓名,但传入消息包含拉丁字符(例如,Heinrich Mueller)。智能体首先检查
bank_details集合的已知翻译。如果未找到,则使用 Atlas Search 进行模糊匹配。作为后备方案,它调用 LLM 将名称音译为片假名 (“ ハインリッヒ・ミュラー”)。印度(IFSC 代码查询):向印度付款需要 IFSC 代码以路由到正确的分行,但发送方仅提供银行名称和城市。智能体查询
ifsc_codes集合以获取精确匹配项。如果输入包含拼写错误(例如,“HDFC Connaught”而不是“Connaught Place”),Atlas Search 会进行模糊匹配以找到正确的代码。
人工参与审核
银行在高风险环境中运营,自主更改需要监督。在应用任何修复之前,LangGraph 工作流会使用 interrupt() 机制暂停,并将提议的更改提交给人工批准。
用户看到:
原始值:传入时的字段值(例如,“Heinrich Mueller”)。
建议值:智能体发现的字段值(例如“ハイン リッヒ・ミュラー”)。
推理:使用了哪种工具,以及使用原因。
然后,用户可以:
批准:执行智能体应用更改并将其记录到审核跟踪中。
拒绝:工作流结束,保留原始值。
修改:用户提供更正后的值,系统随后应用该值。
这一流程确保了全面的可审核性——用户在执行之前查看每个智能体决策,系统会记录每个更改以及之前、之后的值和时间戳。
LangGraph HITL 实现:
from langgraph.types import interrupt def human_review_node(state: dict) -> dict: """Pause workflow for human approval.""" # interrupt() halts execution, returns data to caller, waits for resume review_decision = interrupt({ "original_value": state.get("original_value"), "proposed_value": state.get("solution", {}).get("proposed_value"), "confidence": state.get("solution", {}).get("confidence") }) # When resumed: {"approved": True/False, "modified_value": "..."} return {"approved": review_decision.get("approved"), "human_review": review_decision} # Workflow: resolution → human_review → execution workflow.add_edge("resolution", "human_review") # Always review before execution app = workflow.compile(checkpointer=MemorySaver()) # Checkpointer persists state
interrupt() 函数是关键机制。当工作流到达此节点时,它会序列化当前状态,将审核数据返回给 API 调用者,然后等待。前端向用户显示这些数据。当用户提交决策时,API 会恢复工作流,并将决策注入为 interrupt() 的返回值。
多轨道可扩展性:区块链结算示例
规范 JSON 模型通过将核心支付意图(例如参与方、资产、金额和指令)规范化为单一、一致的结构,为集成多个支付轨道提供了稳定的内部抽象。使用 MongoDB 的多态文档模型,特定轨道的执行细节和元数据与规范字段一起存储,无需单独的模式或数据模型。这使协议复杂性远离上游和下游系统,同时允许不同的轨道使用相同的支付表示。
该演示通过 Solana 集成展示了这种模式的实际应用:包含加密结算字段的支付被路由到 Solana 服务,该服务在 devnet 上执行真实转账。
Solana 服务集成:
# Step 1: Convert incoming message to canonical JSON hop1_result = await converter.convert( source_format="pacs.008", # or MT103, ISO8583, etc. target_format="JSON", message=raw_message ) # Step 2: Parse the canonical JSON from conversion result canonical_json = json.loads(hop1_result['converted_message']) # Step 3: Check canonical JSON for crypto settlement fields if canonical_json.get('crypto_blockchain') and canonical_json.get('crypto_receiver_wallet'): # Route to Solana solana_service.transfer( to_pubkey=canonical_json['crypto_receiver_wallet'], amount_sol=50000 ) # step 4: Solana Service Class class SolanaService: def transfer(self, to_pubkey: str, amount_sol: float) -> dict: response = self.client.send_raw_transaction(bytes(tx)) self.client.confirm_transaction(response.value) return { "signature": str(response.value), "explorer_url": f"https://explorer.solana.com/tx/{response.value}?cluster=devnet" }
与传统的支付轨道不同,区块链提供了内置的结算证明。每笔转账都会返回一个 Solana Explorer URL,用户可以在该 URL 上验证交易的链上发送方、接收方、金额、时间戳和确认状态。这种透明度是 SWIFT 或卡网络所不具备的,在这些网络中,结算证明需要后台对账。
该演示在 Solana devnet 上运行,它使用与主网相同的协议:交易经过加密签名、传播给验证者并永久记录。
为什么选择 MongoDB
MongoDB 为整个支付处理平台提供了统一的数据平台——支持单一系统中的开发(格式配置)和运行时(事务处理、代理决策、Atlas 审核跟踪)。
该平台利用多项 MongoDB 核心功能来简化复杂的财务工作流:
模式灵活性:MongoDB 文档模型与规范支付格式自然对齐。开发者可以无需迁移即可演进数据模型,将相关数据(规范的JSON、元数据、审核轨迹)存储在单个文档中,并处理多样化的消息结构而不会产生模式冲突。
Atlas Search 用于容错解析:当精确查找失败时,解析智能体会使用 Atlas Search——容错编辑距离高达 2,跨多个字段的复合查询,无需外部搜索基础设施。
Atlas Vector Search 用于语义匹配:用于超越精确文本的分类——通过语义相似性对支付描述进行分类(例如,“支付工资”映射到用途代码 SALA),内置于 Atlas 中,无需单独的向量数据库。
聚合管道用于自适应学习:自适应学习服务使用
$objectToArray和$unwind,在一次查询中从所有配置构建字段到映射的查找——数据库级别的处理,实现即时模式重用。自动文档更新:单文档原子性确保执行智能体在一次操作中更新支付字段并记录审核轨迹——这对高风险金融服务的合规至关重要。
这些功能使 MongoDB 成为 AI 驱动的支付处理的 ODL,从而支持现代多轨金融的需求。
数据模型方法
MongoDB 存储两种文档,为支付处理管道提供支持。
规范 JSON(支付文档)
{ "transaction_ref": "MED-CH-ZA-2024-001", "value_date": "2024-12-15", "amount": "180000.00", "currency": "CHF", "debtor_name": "SWISS PHARMA INTERNATIONAL AG", "debtor_account": "CH9300762011623852957", "debtor_bank": "UBSWCHZH80A", "creditor_name": "SOUTH AFRICAN HEALTH SUPPLIES PTY LTD", "creditor_account": "ZA123456789012345678901", "creditor_bank": "ABSAZAJJXXX", "remittance_info": "INVOICE MED-ZA-2024-5678", "charge_bearer": "SHA" "metadata": {...} }
这种扁平结构充当通用桥梁,具有以下映射:
MT103 映射到 JSON,JSON 映射到 pacs.008。
MT202 映射到 JSON,JSON 映射到 pacs.009。
一个语义概念对应一个字段名,并且在所有格式中都具有相同的映射关系。每个文档还包含一个 metadata 对象,其中包含处理详细信息,以及一个 audit_trail,用于记录每个代理决策(旧值、新值、使用的工具、时间戳)。
转换配置
系统支持通过 JSON 进行多跳转换,也支持常见路径的直接转换。以下示例显示了一个直接转换配置:
{ "_id": "MT103_to_pacs.008", "extract": { "20": ":20:([^\\n:]+)", "32A": ":32A:([^\\n:]+)", "50K": ":50K:([\\s\\S]*?)(?=:[0-9])" }, "map": [ {"from": "20", "to": ["transaction_ref"]}, {"from": "32A", "to": ["value_date", "currency", "amount"], "split": [6, 9]}, {"from": "50K", "to": ["debtor_account", "debtor_name"], "multiline": true}, {"from": "70", "to": "remittance_info", "ai": "remittance"} ], "output": { "transaction_ref": "Document.FIToFICstmrCdtTrf.CdtTrfTxInf.PmtId.InstrId", "amount": "Document.FIToFICstmrCdtTrf.CdtTrfTxInf.IntrBkSttlmAmt.#text" } }
三个部分定义了转换:
extract:使用正则表达式提取字段。map:转换它们(拆分复合字段、格式化日期、路由到 AI)。output:将值放入目标格式。
文档插入支持新的消息格式,将转换逻辑从部署周期中移除。对于新的支付轨道,规范模型通过充当通用 JSON 集成点来加速连接,确保在您扩展时核心业务逻辑保持不变。
构建解决方案
有关完整实现,请遵循 GitHub 存储库中的说明。
支付处理平台由两个微服务组成:一个通过三通道管道处理格式转换的消息转换服务,包括用于开发时格式接入的配置构建器,以及一个通过使用 LangGraph 多智能体工作流修复无效交易的支付智能体。两个服务共享 MongoDB Atlas 作为其 ODL。
实现支付转换器服务
该转换器使用存储于 MongoDB 中的配置,而非硬编码逻辑,在格式(MT103、ISO 20022、ISO 8583)之间转换消息。
设置转换管道:将提取器配置为根据复杂性路由字段:对于结构化字段(如交易参考号和金额)使用确定性正则表达式模式,对于非结构化字段(如汇款信息)通过 AWS Bedrock 调用 LLM。
将转换配置存储在 MongoDB 中:每个配置文档包含三个部分:
extract(正则表达式模式)、map(字段转换)和output(目标格式路径)。转换器在运行时读取这些内容,无需更改代码以支持新格式。构建输出生成器:构建器接收转换后的字段并构建目标格式。对于 ISO 20022,构建器生成带有正确命名空间的有效 XML。对于 JSON 目标,它输出扁平的规范结构。
使用 LangGraph 实现支付代理
该智能体使用多智能体工作流修复验证失败的交易——缺少 IFSC 代码、脚本不正确、受益人数据不完整。
创建监督智能体:该智能体接收修复任务(示例:“creditor_name 需要片假名以用于日本”),并确定是转到解决智能体进行研究,还是在修复方案已知的情况下直接转到执行智能体。
使用工具构建解析智能体:为其配备三种工具:
atlas_search(精确或模糊匹配的数据库查找)、vector_search(用于分类的语义相似性)和transliterate_text(基于 LLM 的脚本转换)。智能体根据问题上下文确定使用哪个工具。添加人工审核检查点:在应用更改之前,使用 LangGraph 的
interrupt()函数暂停工作流。用户查看原始值、建议的修复、置信度分数和推理。他们可以在工作流恢复之前批准、拒绝或修改。实现执行智能体:批准后,该智能体将更正后的值写入规范 JSON,并将一个包含旧值、新值、使用工具和时间戳的条目附加到审核跟踪中。
为新格式启用自适应学习
在接入新的支付格式时,系统通过从现有模式中学习来自动生成配置。
加载现有配置:自适应学习服务查询 MongoDB 获取所有转换配置,并构建字段 ID 到其规范映射的映射(例如,字段“32A”映射到
value_date、currency和amount)。解析示例消息:通过使用特定格式的提取器(如 SWIFT 标签模式、ISO 8583 字段位置和 XML 路径),该服务可以识别新格式中的所有字段。
匹配已知模式并推断未知字段:对于其他配置中存在的字段,系统会重用精确映射。对于在任何地方都未找到的字段,该服务调用 LLM,并提供有关格式类型的上下文以建议映射。
生成并查看配置:该服务输出一份包含所有映射的配置文档草案。系统会对低于置信阈值的字段进行标记,以供人工审查。一旦获得批准,它会将文档插入 MongoDB——转换器会立即处理它。
关键要点
用于自适应学习的聚合管道:通过使用
$objectToArray和$unwind,在一次查询中从所有现有配置构建字段到映射的查找。已知字段接收自动映射;未知字段接收受格式规范约束的 LLM 建议。Atlas Search 用于容错:当精确数据库查找失败时,使用编辑距离的模糊搜索处理拼写错误(例如,“HDFC Connaught”映射到“HDFC Connaught Place”),而无需回退到较慢的 AI 推理。
配置驱动转换:将提取模式、字段映射和输出路径存储在 MongoDB 文档中,而非应用程序代码。添加新的支付格式只需插入数据库,无需部署。
人参与合规:使用 LangGraph
interrupt()机制,在应用更改前暂停代理工作流程,向用户展示拟议修复,并仅在明确批准后恢复。监督多智能体模式:将研究任务(例如 IFSC 查询和音译)路由到具有数据库工具的解析智能体,将执行任务(例如字段更新)路由到执行智能体。这种分离确保了专注的专业知识和更清晰的审核跟踪。
统一操作数据层:将规范 JSON、转换配置和审核跟踪存储在 MongoDB Atlas 中。这种集中化消除了支付轨道之间的数据孤岛,并提供了智能体所需的完整交易上下文。
作者
Wei You Pan,MongoDB
Kiran Tulsulkar, MongoDB
Ainhoa Múgica, MongoDB
Daniel Jamir, MongoDB