使用基于JSON的规范模型 Agentic AI和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原生规范支付模型是现代编排的重要基础。在后 ISO20022 环境中,它解决了 CBPR+ 和 FedNow 等不同实施中出现的语义方言碎片化问题。它可以防止 SWIFT 识别的数据截断风险,即传统内部系统会删除丰富的 ISO20022 数据,因为它们缺乏存储扩展字段的容量。由于该模型以灵活的JSON格式捕获完整的消息深度,因此系统在转换过程中不会丢失任何数据。
与通用API抽象相结合,该平台使 IT 团队能够从不透明的二进制位图和分散的标准转向开发人员友好的环境。这种环境可以加速开发和重用,因为从印度的 UPI 到稳定币的新支付轨道可以作为模块化扩展进行集成,而不是重写核心代码。
除了开发速度之外,该模型还建立了集中式支付方案和数据管理,从而实现了单点更新,其中新的监管字段只需定义一次即可在所有转换逻辑中继承。这种从严格的SQL模式到灵活文档模型的转变消除了传统中心典型的技术债务和维护负担。通过在生命周期的早期将数据规范化为真正标准化和一致的数据模型,该模型有助于及早合规互动和主动进行中修复。最终,它提供了在加密资产市场 (MiCA) 等新法规下不断发展的多轨世界所需的明确管理权和操作敏捷性。
以下视频给出了从德国到日本的跨境付款示例,其中包含由代理驱动的债权人姓名的日文片假名音译:
该解决方案演示了采用 Agentic AI 的规范支付模型如何重新定义支付处理。通过从严格的SQL模式转向灵活的、基于JSON 的规范模型,金融机构可以授权AI代理跨任何支付通道自主摄取、规范化、路由和修复交易,例如公共网络上的 SWIFT 电汇或 USDC 转账。区块链。
JSON基础
基于JSON 的数据模型具有以下属性,是此类多重支付通道处理系统的关键基础:
API Native:现代支付,尤其是加密货币和金融科技领域的支付,使用API驱动的通信 (REST/ GraphQL/RPC),而这种通信本质上是基于JSON 的。原生格式可减少转换延迟和复杂性。
模式灵活性: JSON可以处理常见字段(金额、发件人),同时容纳特定于铁路的字段(示例,加密货币的 Gas 限制、日本的 zengin 代码、ISO20022 的汇款信息),而不会破坏核心模式。
AI就绪:法学硕士使用代码和JSON进行训练。与不透明的二进制位图或严格的SQL表相比,助手可以直接分析数据结构,从而更有效地检测异常并执行复杂的映射。
参考架构
该支付处理演示包括一个支付处理平台,该平台处理从格式启动到执行和修复的整个ACID 事务生命周期。该架构将特定职责委托给专门的组件:
构建
配置生成器:在开发过程中加快格式加载速度。聚合管道从现有配置中提取字段映射,而 LLM 则为未知字段建议映射。曾经需要数月时间才能集成的新格式现在只需数周即可完成配置。配置完成后,平台将进行实时ACID 事务处理。
执行
消息翻译服务:传入消息通过配置驱动的处理系统。大多数字段都遵循存储在MongoDB中的确定性规则,这些规则是在前面描述的构建进程中构建的。复杂的非结构化字段(例如汇款信息)会路由到由...提供支持的AI通道。
代理解析服务:用于修复未通过验证的事务的多代理系统。主管将任务路由给专门的代理:解析代理找到缺失或无效字段的正确值(使用数据库查找、 Atlas Search或AI推断),执行代理应用已批准的更改并记录Atlas 审核跟踪。
图 1。支付处理平台架构,显示消息转换、规范JSON路由和使用MongoDB Atlas进行代理解析
如架构图所示, MongoDB充当操作数据层 (ODL)。系统将每个ACID 事务存储为单个文档,其中包含规范化的规范JSON以及代理决策的完整Atlas 审核跟踪。转换配置位于单独的集合中,使格式更改由数据驱动。这种结构提供了合规合规所需的可审核性。
核心能力
该演示展示了MongoDB灵活模式和代理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”:“汇款”),法学硕士从非结构化文本中提取结构化数据。这种方法保留了大多数字段的确定性规则,但通过推断处理复杂的余数。
通过文档插入启用新的消息格式 — 转换器代码保持不变,从而将转换逻辑排除在部署周期之外。
Gen AI驱动的自适应转换
通过数据库中存储的规则和历史元数据,您可以使用生成式AI (LLM) 来加速采用新的支付格式。
要添加对新消息类型的支持,请提供示例消息。自适应学习服务从MongoDB加载所有现有转换配置,并使用特定于格式的解析提取字段。它将检测到的字段ID 与现有配置中的映射进行匹配。示例,如果 MT103_to_JSON 中存在字段“32A”,则会重复使用该精确映射。
对于在任何现有配置中都找不到的字段,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 根据文档字符串和系统提示自主选择的工具来处理这些异常。这种模式引导法学硕士首先选择更便宜、更快的选择。
解析代理工具选择:
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])
法学硕士会读取工具文档字符串和系统提示,以确定调用哪个工具。 Atlas Search处理精确查找和容错匹配。 Vector Search 处理关键字不匹配但含义匹配的语义分类。为了在实践中说明这些功能,请考虑以下支付场景:
日本(片假名音译):向东京付款需要使用片假名脚本的收款人姓名,但传入的消息包含拉丁字符(示例Heinrich Mueller)。代理首先检查
bank_details集合是否有已知翻译。如果未找到,则会使用Atlas Search进行模糊匹配。作为后备方案,它会调用法学硕士将名称音译为片假名 (" ハinrithi·miyura —")。印度(IFSC 代码查找):向印度付款需要 IFSC 代码才能路由到正确的分行,但付款人仅提供银行名称和城市。该代理会查询
ifsc_codes集合的精确匹配项。如果输入包含错别字(示例,“HDFC Connaught”而不是“Connaught Place”), Atlas Search会处理模糊匹配以找到正确的代码。
人在环审核
银行在高风险环境中运营,自主变更需要监督。在应用任何修复之前,LangGraph 工作流会使用 interrupt() 机制暂停,从而提出建议的更改以供人工批准。
用户会看到:
原始值:到达时的字段(示例“Heinrich Mueller”)。
建议值:代理发现的值(示例,"haiin rithi·miyura —")。
推理:使用了哪种工具以及原因。
然后,用户可以:
批准:执行代理应用更改并将其记录到Atlas 审核跟踪中。
拒绝:工作流程结束,保留原始值。
修改:用户提供更正后的值,系统会应用该更正后的值。
此进程确保完全的可审核性 — 用户在执行前查看每个代理决策,系统会记录每个更改以及前后值和时间戳。
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动作展示了这种模式:包含加密货币结算字段的支付被路由到在 devnet 上执行实际传输的 Solana 服务。
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,用户可以在其中验证链上ACID 事务的发送者、接收者、金额、时间戳和确认状态。 SWIFT 或卡网络不具备这种透明度,结算证明需要后台对账。
该演示在 Solana 开发网络上运行,该网络使用与主网相同的协议:事务经过加密签名、传播到验证器并永久记录。
为什么选择 MongoDB
MongoDB为整个支付处理平台提供统一数据平台,支持在单个系统中进行开发(格式配置)和运行时(ACID 事务处理、代理决策、Atlas 审核跟踪)。
该平台使用多个核心MongoDB功能来简化这些复杂的财务工作流程:
模式灵活性: MongoDB文档模型与规范的支付格式自然一致。开发者无需迁移即可演进数据模型,在单个文档中存储相关数据(规范的JSON、元数据、Atlas 审核跟踪),以及在没有模式冲突的情况下处理不同的消息结构。
Atlas Search支持错别字容错解析:当精确查找失败时,解析代理会使用Atlas Search — 容错高达2 编辑距离、跨多个字段的复合查询、无需外部搜索基础架构。
用于语义匹配的Atlas Vector Search :用于精确文本之外的分类 — 语义相似性,用于对付款描述进行分类(示例,“支付工资”映射到目的代码 SALA),内置于Atlas中,无需单独的向量数据库。
用于自适应学习的聚合管道:自适应学习服务使用
$objectToArray和$unwind在一次查询中从所有配置构建字段到映射查找,这是用于即时模式重用的数据库级处理。自动文档更新:单文档原子性确保执行代理在一次操作中更新支付字段并记录Atlas 审核跟踪,这对于高风险金融服务的监管合规性至关重要。
这些功能共同使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,后者映射到 pacs.008。
MT202 映射到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)之间转换消息。
设置转换管道:配置提取器以根据复杂性路由字段:针对结构化字段(例如ACID 事务引用和金额)的确定性正则表达式模式,以及通过 AWS 基岩的 LLM 调用针对非结构化字段(例如汇款信息)。
在MongoDB中存储转换配置:每个配置文档包含三个部分:
extract(正则表达式模式)、map(字段转换)和output(目标格式路径)。转换器会在运行时读取这些数据,无需为新格式更改代码。构建输出生成器:生成器获取转换后的字段并构造目标格式。对于 ISO20022 ,构建器会生成具有适当命名空间的有效 XML。对于JSON目标,它输出平面规范结构。
使用 LangGraph 实施付款代理
代理使用多代理工作流程修复未通过验证的事务,包括缺少 IFSC 代码、不正确的脚本、不完整的受益人数据。
创建主管代理:该代理接收修复任务(示例,“日本的债权人名称需要片假名”),并确定是路由到解析代理进行研究,还是在修复已知的情况下直接路由到执行。
使用工具构建解析代理:使用三个工具 quip 它:
atlas_search(使用精确或模糊匹配的数据库查找)、vector_search(用于分类的语义相似性)和transliterate_text(基于 LLM 的脚本转换)。代理根据问题上下文确定使用哪个工具。添加人工审核检查点:在应用更改之前,使用 LangGraph 的
interrupt()函数暂停工作流程。用户可以查看原始值、建议的修复、置信度分数和推理。他们可以在工作流程恢复之前批准、拒绝或修改。实施执行代理:批准后,该代理会将更正后的值写入规范JSON ,并将包含旧值、新值、使用的工具和时间戳的条目附加到Atlas 审核跟踪。
为新格式启用自适应学习
在采用新的支付格式时,系统会通过学习现有模式来自动生成配置。
加载现有配置:自适应学习服务会查询MongoDB 的所有转换配置,并构建字段ID 与其规范映射的映射(示例,字段"32 A" 映射到
value_date、currency和amount)。解析示例消息:通过使用特定于格式的提取器(例如 SWIFT标签模式、ISO8583 字段位置和 XML 路径),该服务识别以新格式存在的所有字段。
匹配已知模式并推断未知字段:对于其他配置中存在的字段,系统会重复使用精确的映射。对于在任何地方都找不到的字段,该服务会使用有关格式类型的上下文调用 LLM,以建议映射。
生成并查看配置:该服务输出包含所有映射的配置文档草稿。系统会标记低于置信阈值的字段,以供人工查看。一旦获得批准,就会将文档插入MongoDB,转换器会立即对其进行处理。
关键要点
用于自适应学习的聚合管道:使用
$objectToArray和$unwind在单个查询中从所有现有配置构建字段到映射查找。已知字段接收自动映射;未知字段接收受格式规范限制的 LLM 建议。Atlas Search的错别字容忍度:当精确的数据库查找失败时,具有编辑距离的模糊搜索可以处理拼写错误(示例“HDFC Connaught”映射到“HDFC Connaught Place”),而不会回退到较慢的AI推理。
配置驱动的转换:将提取模式、字段映射和输出路径存储在MongoDB文档中,而不是应用程序代码中。添加新的支付格式成为数据库插入,而不是部署。
人机交互合规:使用 LangGraph
interrupt()机制在应用更改之前暂停代理工作流程,向用户提供修复建议,并仅在明确批准后恢复。主管多代理模式:使用数据库工具将研究任务(例如 IFSC 查找和音译)路由到解析代理,并将执行任务(例如字段更新)路由到执行代理。这种分离确保了专业知识的集中和Atlas 审核跟踪的清晰。
统一操作数据层:在MongoDB Atlas中存储规范的JSON、转换配置和Atlas 审核跟踪。这种集中化消除了支付轨道之间的数据孤岛,并提供了代理所需的完整ACID 事务上下文。
作者
Wei You Pan,MongoDB
Kiran Tulsulkar, MongoDB
Ainhoa Múgica, MongoDB
Daniel Jamir, MongoDB