에이전틱 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와 같은 다양한 구현에서 볼 수 있는 의미론적 방언 파편화를 해결합니다. 이는 확장된 필드를 저장할 용량이 부족하여 레거시 내부 시스템에서 풍부한 ISO 20022 데이터가 제거되는 SWIFT에서 식별되는 데이터 절단 위험을 방지합니다. 이 모델은 전체 메시지 깊이를 유연한 JSON 형식으로 캡처하기 때문에 번역 중에 데이터가 손실되지 않습니다.
범용 API 추상화와 결합된 이 플랫폼을 통해 IT 팀은 불투명한 이진 비트맵과 파편화된 표준에서 개발자 친화적인 환경으로 전환할 수 있습니다. 이 환경은 가속화된 개발 및 재사용을 지원하므로, 인도의 UPI부터 스테이블코인에 이르기까지 새로운 결제 레일을 핵심 코드 재작성이 아닌 모듈식 확장으로 통합할 수 있습니다.
개발 속도 외에도, 이 모델은 중앙 집중식 결제 체계와 데이터 거버넌스를 구축하여 새로운 규제 분야를 한 번만 정의하고 모든 변환 로직에 적용함으로써 단일 지점 업데이트가 가능하도록 합니다. 경직된 SQL 스키마에서 유연한 문서 모델로의 전환은 레거시 허브에서 흔히 발생하는 기술적 부채와 유지 관리 부담을 없애줍니다. 데이터 수명 주기 초기에 데이터를 진정으로 표준화되고 일관된 데이터 모델로 정규화함으로써, 이 모델은 조기 컴플라이언스 참여와 사전 예방적인 진행 중 수정 작업을 용이하게 합니다. 궁극적으로 이는 암호화폐 시장법(MiCA)과 같은 새로운 규제 하에서 끊임없이 진화하는 다중 레일 환경을 헤쳐나가는 데 필요한 명확한 관리 체계와 운영상의 민첩성을 제공합니다.
다음 동영상은 에이전트가 채권자 이름을 일본어 가타카나 음역으로 번역하여 DE에서 JP로 결제하는 예시를 보여줍니다.
이 솔루션은 에이전틱 AI가 포함된 표준 결제 모델이 결제 처리를 어떻게 재정의할 수 있는지 보여줍니다. 금융 기관은 경직된 SQL 스키마에서 유연한 JSON 기반 표준 모델로 전환하여 AI 에이전트가 모든 결제 레일에서 거래를 자율적으로 수집, 정규화, 라우팅 및 복구할 수 있도록 역량을 강화할 수 있습니다. 설명합니다.
JSON 기초
JSON 기반 데이터 모델은 다음과 같은 속성으로 인해 이러한 다중 결제 레일 처리 시스템의 중요한 기반이 됩니다:
API 네이티브: 특히 암호화 및 핀테크의 최신 결제는 본질적으로 JSON 기반인 API 기반 통신(REST/GraphQL/RPC)을 사용합니다. 네이티브 형식은 번역 지연 시간과 복잡성을 줄여줍니다.
스키마 유연성: JSON 공통 필드(수량, 발신자)를 처리하는 동시에 레일별 필드(예: 암호화폐의 경우 가스 한도, 일본의 경우 젠인 코드, ISO의 경우 송금 정보 20022)를 핵심 스키마를 손상시키지 않고 수용합니다.
AI 준비: LLM은 코드와 JSON을 기반으로 학습합니다. 에이전트는 데이터 구조를 직접 분석하여 이상 징후를 탐지하고, 불투명한 이진 비트맵이나 경직된 SQL 테이블을 사용할 때보다 더 효과적으로 복잡한 매핑을 수행할 수 있습니다.
참조 아키텍처
이 결제 처리 데모에는 형식 온보딩부터 실행 및 복구에 이르는 전체 트랜잭션 라이프사이클을 처리하는 결제 처리 플랫폼이 포함되어 있습니다. 이 아키텍처는 특정 책임을 전문화된 구성 요소에 위임합니다.
빌드
구성 빌더: 개발 중 형식 온보딩을 가속화합니다. 집계 파이프라인은 기존 구성에서 필드 매핑을 추출하고, LLM은 알 수 없는 필드에 대한 매핑을 제안합니다. 한때 통합하는 데 몇 달이 걸렸던 새로운 형식은 몇 주 안에 구성할 수 있습니다. 구성이 완료되면 플랫폼은 실시간 트랜잭션 처리를 처리합니다.
실행
메시지 번역 서비스: 수신 메시지는 구성 기반 처리 시스템을 거칩니다. 대부분의 필드는 앞서 설명한 빌드 프로세스에서 생성되어 MongoDB에 저장된 결정론적 규칙을 따릅니다. 송금 정보와 같은 복잡하고 비정형적인 필드는 Claude가 구동하는 AI 레인으로 라우팅됩니다.
에이전트 해결 서비스: 유효성 검사에 실패한 트랜잭션을 복구하는 멀티에이전트 시스템입니다. 감독자는 전문화된 에이전트에게 작업을 라우팅합니다. 해결 에이전트는 데이터베이스 조회, Atlas Search 또는 AI 추론을 사용하여 누락되거나 잘못된 필드의 올바른 값을 찾고, 실행 에이전트는 승인된 변경 사항을 적용하고 감사 추적을 기록합니다.
그림 1. MongoDB Atlas를 사용하여 메시지 번역, 표준 JSON 라우팅 및 에이전트 해결을 보여주는 결제 처리 플랫폼 아키텍처
아키텍처 다이어그램에서 볼 수 있듯이 MongoDB는 ODL(운영 데이터 계층) 역할을 합니다. 시스템은 각 트랜잭션을 정규화된 표준 JSON과 에이전트 결정에 대한 완전한 감사 추적을 포함하는 단일 문서로 저장합니다. 전환 구성은 별도의 컬렉션에 존재하므로 데이터를 기반으로 형식을 변경할 수 있습니다. 이 구조는 규정 준수에 필요한 감사 기능을 제공합니다.
핵심 기능
이 데모에서는 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": "송금")를 위해 이 필드들을 표시하고, 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컬렉션에서 정확한 일치를 조회합니다. 입력에 오타가 있을 경우(예: "Connaught Place" 대신 "HDFC Connaught"), 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 서비스로 라우팅되어 개발 네트워크에서 실제 전송을 실행합니다.
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을 반환합니다. 이러한 투명성은 결제를 증명하기 위해 백오피스 조정이 필요한 SWIFT나 카드 네트워크에서는 사용할 수 없습니다.
데모는 메인넷과 동일한 프로토콜을 사용하는 Solana devnet에서 실행됩니다. 트랜잭션은 암호학적으로 서명되고 검증자에게 전파되며 영구적으로 기록됩니다.
MongoDB를 선택하는 이유
MongoDB는 전체 결제 처리 플랫폼을 위한 통합 데이터 플랫폼을 제공하여 단일 시스템에서 개발(형식 구성)과 런타임(트랜잭션 처리, 에이전트 의사 결정, 감사 추적)을 모두 지원합니다.
플랫폼은 몇 가지 핵심 MongoDB 기능을 사용하여 이러한 복잡한 금융 워크플로를 간소화합니다.
스키마 유연성: MongoDB 문서 모델은 표준 결제 형식과 자연스럽게 일치합니다. 개발자는 마이그레이션 없이 데이터 모델을 발전시키고, 관련 데이터(표준 JSON, 메타데이터, 감사 추적)를 단일 문서에 저장하며, 스키마 충돌 없이 다양한 메시지 구조를 처리할 수 있습니다.
오타 허용 해결을 위한 Atlas Search: 해결 에이전트는 정확한 조회에 실패할 때 Atlas Search를 사용합니다. 최대 2 편집 거리의 오타 허용, 여러 필드에 걸친 복합 쿼리, 외부 검색 인프라가 필요하지 않습니다.
시맨틱 매칭을 위한 Atlas Vector Search: 정확한 텍스트를 넘어 분류하기 위한 시맨틱 유사성을 제공하는 결제 설명(예시: 'paying scoring'은 목적 코드 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은 pac.008에 매핑됩니다.
MT202 JSON에 매핑되고, JSON은 pac.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 리포지토리의 지침을 따르세요.
결제 처리 플랫폼은 개발 시 형식 온보딩을 위한 구성 빌더를 포함하여 3레인 파이프라인을 통해 형식 변환을 처리하는 메시지 번역 서비스와 LangGraph 멀티에이전트 워크플로를 사용하여 잘못된 트랜잭션을 복구하는 결제 에이전트라는 두 가지 마이크로서비스로 구성됩니다. 두 서비스 모두 MongoDB Atlas를 ODL로 공유합니다.
결제 변환기 서비스 구현
변환기는 하드코딩된 로직 대신 MongoDB에 저장된 구성을 사용하여 메시지를 형식(MT103, ISO 20022, ISO 8583) 간에 변환합니다.
변환 파이프라인 설정: 트랜잭션 참조 및 금액과 같은 구조화된 필드에 대한 결정론적 정규식 패턴, 송금 정보와 같은 비정형 필드에 대한 AWS Bedrock을 통한 LLM 호출 등 복잡성에 따라 필드를 라우팅하도록 추출기를 구성합니다.
MongoDB의 변환 구성 저장: 각 구성 문서에는
extract(정규식 패턴),map(필드 변환),output(대상 형식 경로)의 3가지 섹션이 있습니다. 변환기는 런타임에 이를 읽으므로 새 형식에 대한 코드 변경이 필요하지 않습니다.출력 빌드 생성기: 빌더는 변환된 필드를 이용하여 대상 형식을 구성합니다. 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: 정확한 데이터베이스 조회가 실패할 경우, 편집 거리를 사용한 퍼지 검색은 느린 AI 추론으로 되돌아가지 않고 오타를 처리합니다(예: "HDFC Connaught"를 "HDFC Connaught Place"로 매핑).
구성 기반 변환: 추출 패턴, 필드 매핑 및 출력 경로를 애플리케이션 코드가 아닌 MongoDB 문서에 저장합니다. 새 결제 형식을 추가하면 배포가 아니라 데이터베이스 삽입물이 됩니다.
휴먼 인 더 루프 컴플라이언스: LangGraph
interrupt()메커니즘을 사용하여 변경 사항을 적용하기 전에 에이전트 워크플로를 일시 중지하고, 제안된 수정 사항을 사용자에게 제시한 다음, 명시적 승인을 받은 후에만 재개합니다.감독자 다중 에이전트 패턴: IFSC 조회 및 음역과 같은 조사 작업은 데이터베이스 도구를 갖춘 해결 에이전트로, 필드 업데이트와 같은 실행 작업은 실행 에이전트로 라우팅합니다. 이러한 분리는 전문성을 집중시키고 더욱 명확한 감사 추적을 보장합니다.
통합 운영 데이터 계층: 표준 JSON, 변환 구성 및 감사 추적을 MongoDB Atlas에 저장합니다. 이러한 중앙 집중화는 결제 레일 간의 데이터 사일로를 제거하고 에이전트에게 필요한 완전한 트랜잭션 컨텍스트를 제공합니다.
작성자
Wei You Pan, MongoDB
Kiran Tulsulkar, MongoDB
Ainhoa Múgica, MongoDB
다니엘 자미르, MongoDB