Docs Menu
Docs Home
/

Agentic AI- Powered Payments 오케스트레이션

JSON 기반 표준 모델인 Agentic AI 와 MongoDB Atlas 로 결제를 현대화하여 ISO 20022, ISO 8583, Stablecoins를 연결하세요.

사용 사례: 인공 지능, 결제

산업: 금융 서비스

제품 및 도구: MongoDB Atlas, MongoDB Atlas Vector Search, MongoDB Atlas Search

파트너: Amazon 기반암, LangChain, LangGraph

오늘날 결제 프로세서는 상호 운용성 문제에 직면해 있습니다. 레거시 카드 메시지(ISO 8583), 최신 리치 데이터 표준(ISO 20022) 및 진화하는 암호화폐 결제 레일을 처리하다 해야 합니다. 기존 시스템은 새로운 필드 나타나거나 로컬 규정이 변경될 때 중단되는 엄격한 ETL(추출, 변환 및 로드) 파이프라인에 의존합니다.

레거시 인프라와 금융의 미래를 연결하기 위해 JSON 네이티브 표준 결제 모델은 최신 오케스트레이션의 필수 기반 역할을 합니다. ISO 20022 이후 환경에서는 CBPR+ 및 Fednow와 같은 다양한 구현에서 볼 수 있는 시맨틱 방언 파편화를 해결합니다. 레거시 내부 시스템이 확장된 필드를 저장 용량 부족하여 풍부한 ISO 데이터를 제거하는 SWIFT에서 식별한 데이터 잘림 위험을 방지합니다. 20022 이 모델은 유연한 JSON 형식으로 전체 메시지 깊이를 캡처하기 때문에 시스템은 번역 중에 데이터가 손실되지 않습니다.

범용 API 추상화와 결합된 이 플랫폼을 통해 IT 팀은 불투명한 바이너리 비트맵과 파편화된 표준에서 개발자 친화적인 환경으로 이동할 수 있습니다. 이 환경에서는 인도의 UPI부터 스테이블 코인에 이르기까지 새로운 결제 레일을 핵심 코드 재작성이 아닌 모듈식 확장으로 통합할 수 있으므로 개발 및 재사용을 가속화할 수 있습니다.

개발 속도 외에도 이 모델은 중앙 집중식 결제 체계와 데이터 거버넌스 설정하여 새로운 규제 필드 한 번 정의되면 모든 변환 로직에 상속되는 단일 지점 업데이트를 가능하게 합니다. 엄격한 SQL 스키마에서 유연한 문서 모델 로의 이러한 전환은 레거시 허브의 일반적인 기술적 부채와 유지 관리 부담을 없애줍니다. 이 모델은 라이프사이클 초기에 데이터를 표준화되고 일관적인 데이터 모델 로 정규화함으로써 조기 컴플라이언스 참여 와 사전 예방적 진행 중 수리를 용이하게 합니다. 궁극적으로 암호화 자산 시장(MiCA)과 같은 새로운 규정에 따라 끊임없이 진화하는 멀티레일 세계를 탐색하는 데 필요한 정의된 스튜어드십과 운영 민첩성을 제공합니다.

다음 동영상은 에이전트 중심의 일본어 가타카나로 채권자 이름을 음역하는 국가간 DE에서 JP로 결제하는 예시 를 보여줍니다.

이 솔루션은 Agentic AI 를 사용한 표준 결제 모델이 결제 처리 재정의할 수 있는 방법을 보여줍니다. 금융 기관은 엄격한 SQL 스키마에서 유연한 JSON 기반 표준 모델로 전환함으로써 AI 에이전트가 모든 결제 레일에서 거래를 자율적으로 수집, 정규화, 라우팅 및 복구할 수 있도록 역량을 강화할 수 있습니다. 블록체인.

JSON 기반 데이터 모델 다음과 같은 속성 때문에 이러한 다중 결제 철도 처리 시스템의 중요한 기반이 됩니다.

  • API 네이티브: 특히 암호화폐 및 핀테크 분야의 최신 결제는 본질적으로 JSON 기반인 API 기반 통신(REST/ GraphQL /RPC)을 사용합니다. 네이티브 형식은 번역 지연 시간 과 복잡성을 줄입니다.

  • 스키마 유연성: JSON 공통 필드(금액, 발신자)를 처리하는 동시에 핵심 스키마 손상시키지 않고 철로별 필드( 예시 : 암호화에 대한 가스 한도, 일본의 경우 zengin 코드, ISO 의 송금 20022 정보)를 수용합니다.

  • AI 준비성: LLM은 코드와 JSON 에 대해 교육합니다. 에이전트는 데이터 구조를 직접 분석 불투명한 바이너리 비트맵이나 경질 SQL 테이블보다 더 효과적으로 이상 징후를 감지하고 복잡한 매핑을 수행할 수 있습니다.

이 결제 처리 데모에는 형식 온보딩부터 실행 및 복구에 이르기까지 전체 트랜잭션 라이프사이클을 처리하는 결제 처리 플랫폼이 포함되어 있습니다. 아키텍처는 특수 구성 요소에 특정 책임을 위임합니다.

  • 구성 빌더: 개발 중 형식 온보딩을 가속화합니다. 집계 파이프라인은 기존 구성에서 필드 매핑을 추출하고, LLM은 알 수 없는 필드에 대한 매핑을 제안합니다. 한 때는 통합하는 데 몇 달이 걸렸던 새로운 형식을 몇 주 만에 구성할 수 있습니다. 구성이 완료되면 플랫폼이 실시간 트랜잭션 처리 처리합니다.

  • 메시지 번역 서비스: 수신 메시지는 구성 기반 처리 시스템을 통과합니다. 대부분의 필드는 앞에서 설명한 빌드 프로세스 에서 구성된 MongoDB 에 저장된 결정론적 규칙을 따릅니다. 송금 정보와 같은 복잡한 비정형 필드는 Claude 기반 AI 레인으로 연결됩니다.

  • Agentic 해결 서비스: 유효성 검사 에 실패한 트랜잭션을 복구하는 멀티에이전트 시스템입니다. 감독자는 작업을 특수 에이전트에게 라우팅합니다: 해결 에이전트는 데이터베이스 조회, Atlas Search 또는 AI 추론을 사용하여 누락되거나 유효하지 않은 필드에 대한 올바른 값을 찾고, 실행 에이전트는 승인된 변경 사항을 적용하고 감사 추적을 기록합니다.

MongoDB Atlas 사용한 메시지 번역, 표준 JSON 라우팅 및 에이전트 해결을 보여주는 결제 처리 플랫폼 아키텍처

그림 1. MongoDB Atlas 사용한 메시지 번역, 표준 JSON 라우팅 및 에이전트 해결을 보여주는 결제 처리 플랫폼 아키텍처

아키텍처 다이어그램에 표시된 대로 MongoDB ODL(Operational Data Layer) 역할을 합니다. 시스템은 각 트랜잭션 정규화된 표준 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': 'remittance')로 표시하고, LLM은 비구조화된 텍스트에서 구조화된 데이터를 추출합니다. 이 접근 방식은 대부분의 필드에 대해 결정론적 규칙을 유지하지만 복잡한 나머지는 추론을 통해 처리합니다.

문서 삽입을 통해 새로운 메시지 형식을 사용할 수 있으므로 변환기 코드가 변경되지 않고 배포서버 에 변환 로직이 필요하지 않습니다.

데이터베이스 에 저장된 규칙 및 기록 메타데이터 통해 생성형 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
@tool
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}
@tool
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 정확한 조회 및 오타 허용 일치를 처리합니다. 벡터 검색은 키워드는 일치하지 않지만 의미는 일치하는 시맨틱 분류를 처리합니다. 이러한 기능을 실제로 설명하기 위해 다음 결제 시나리오를 고려하세요.

  • 일본(가타가나 음역): 도쿄에 결제하려면 가타가나 스크립트 로 된 수취인 이름이 필요하지만, 수신 메시지에는 라틴 문자가 포함되어 있습니다( 예시: 하인리히 뮐러).bank_details 에이전트 먼저 컬렉션 에 알려진 번역이 있는지 확인합니다. 찾을 수 없는 경우 Atlas Search 사용하여 퍼지 매칭을 수행합니다. 대신 LLM을 호출하여 이름을 가타가나(" HAINRIKH, 뮤라")로 음역합니다.

  • 인도(IFSC 코드 조회): 인도로 결제할 때 올바른 지점으로 라우팅하려면 IFSC 코드가 필요하지만, 송금인은 은행 이름과 도시만 제공합니다.ifsc_codes 에이전트 컬렉션 쿼리하여 정확히 일치하는지 확인합니다. 입력에 오타가 포함된 경우( 예시: 'Connaut Place' 대신 'HDFC Connaut'), Atlas Search 퍼지 매칭을 처리하여 올바른 코드를 찾습니다.

은행은 자율적인 변경을 수행하려면 감독이 필요한 고 위험 환경에서 운영됩니다. 수리가 적용되기 전에 LangGraph 워크플로는 interrupt() 메커니즘을 사용하여 일시 중지되어 사람의 승인을 받을 수 있도록 제안된 변경 사항을 제시합니다.

사용자는 다음을 볼 수 있습니다.

  • 원래 값: 도착한 시점의 필드 입니다( 예시: '하인리히 뮐러').

  • 제안 값: 에이전트 발견한 값( 예시: '하인 릭히·뮤라')입니다.

  • 추론: 사용된 도구와 그 이유

그런 다음 사용자는 다음을 수행할 수 있습니다.

  • 승인: 실행 에이전트가 변경 사항을 적용하고 감사 추적에 기록합니다.

  • 거부: 워크플로가 종료되고 원래 값이 유지됩니다.

  • 수정: 사용자가 수정된 값을 제공하면 시스템이 이를 적용합니다.

이 프로세스 완전한 감사 가능성을 보장하므로 사용자는 실행하기 전에 모든 에이전트 결정을 검토 시스템은 전후 값 및 타임스탬프를 사용하여 모든 변경 사항을 기록합니다.

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 다형성 문서 모델 사용하면 별도의 스키마나 데이터 모델 없이 레일별 실행 세부 정보 및 메타데이터 표준 필드와 함께 저장합니다. 이를 통해 업스트림 및 다운스트림 시스템의 프로토콜 복잡성을 제거하면서 서로 다른 레일에서 동일한 결제 표현을 사용할 수 있습니다.

데모는 솔라나 통합에서 이 패턴 어떻게 조치 보여줍니다. 암호화 결제 필드가 포함된 결제는 데브넷에서 실제 송금을 실행하는 솔라나 서비스로 라우팅됩니다.

솔라나 서비스 통합:

# 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"
}

기존 결제 레일과 달리 블록체인은 내장 결제 증명을 제공합니다. 모든 전송은 사용자가 온체인 발신자, 수신자, 금액, 타임스탬프 및 확인 상태 트랜잭션 확인하는 솔라나 탐색기 URL 반환합니다. 결제 증명을 위해 백오피스 조정이 필요한 SWIFT 또는 카드 네트워크에서는 이러한 투명성을 사용할 수 없습니다.

데모는 메인넷과 동일한 프로토콜 사용하는 솔라나 데브넷에서 실행되며, 트랜잭션은 암호화 방식으로 서명되고, 검증자에게 전파되며, 영구적으로 기록됩니다.

MongoDB 전체 결제 처리 플랫폼을 위한 통합 데이터 플랫폼을 제공하며, 단일 시스템에서 개발(형식 구성)과 런타임(트랜잭션 처리, 에이전트 결정, 감사 추적)을 모두 지원합니다.

이 플랫폼은 몇 가지 핵심 MongoDB 기능을 사용하여 이러한 복잡한 금융 워크플로를 간소화합니다.

  • 스키마 유연성: MongoDB 문서 모델 표준 결제 형식에 자연스럽게 부합합니다. 개발자는 마이그레이션 없이 데이터 모델을 발전시키고, 관련 데이터(표준 JSON, 메타데이터, 감사 추적)를 단일 문서 에 저장 , 스키마 충돌 없이 다양한 메시지 구조를 처리하다 .

  • 오타 허용해결을 위한 Atlas Search : 해결 에이전트는 정확한 조회가 실패할 때 Atlas Search 사용합니다(최대 2 편집 거리까지의 오타 허용, 여러 필드에 대한 복합 쿼리, 외부 검색 인프라 필요 없음).

  • 시맨틱 매칭을 위한Atlas Vector Search : 정확한 텍스트 이상의 분류를 위해, 지불 설명을 분류하기 위한 시맨틱 유사성( 예시 : '지급하기'가 목적 코드 SALA에 매핑됨)으로, 별도의 벡터 데이터베이스 없이 Atlas 에 내장되어 있습니다.

  • 적응형 학습을 위한 집계 파이프라인: 적응형 학습 서비스는 $objectToArray 및 를 사용하여 $unwind 하나의 쿼리 로 모든 구성에서 필드-매핑 조회를 빌드 하며, 즉각적인 패턴 재사용을 위한 데이터베이스 수준 처리 .

  • 자동 문서 업데이트: 단일 문서 원자성을 통해 실행 에이전트는 한 번의 작업으로 결제 필드를 업데이트하고 감사 추적을 기록할 수 있으며, 이는 고위험 금융 서비스의 규정 컴플라이언스 에 매우 중요합니다.

이러한 기능이 결합된 MongoDB 최신 멀티레일 금융의 요구 사항을 지원하는 AI 기반 결제 처리 위한 ODL이 되었습니다.

MongoDB 결제 처리 파이프라인 강화하는 두 가지 유형의 문서를 저장합니다.

1
{
"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 도 포함되어 있습니다.

2

이 시스템은 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"
}
}

세 섹션에서 변환을 정의합니다.

  1. extract: 정규식을 사용하여 필드를 가져옵니다.

  2. map: 변환합니다(복합 데이터 분할, 날짜 서식 지정, AI 로 라우팅).

  3. output: 대상 형식으로 값을 배치합니다.

문서 삽입을 통해 새로운 메시지 형식을 활성화 배포서버 주기에서 변환 로직이 필요하지 않습니다. 새로운 결제 레일의 경우, 표준 모델은 범용 JSON 통합 점 역할을 함으로써 연결을 가속화하고, 확장하다 시 핵심 비즈니스 로직이 그대로 유지되도록 합니다.

전체 구현 위해서는 GitHub 리포지토리 의 지침을 따르세요.

결제 처리 플랫폼은 개발 시 형식 온보딩을 위한 구성 빌더를 포함하여 3레인 파이프라인 통해 형식 변환을 처리하는 메시지 번역 서비스와 LangGraph 멀티에이전트 워크플로를 사용하여 유효하지 않은 트랜잭션을 복구하는 결제 에이전트라는 두 개의 마이크로서비스로 구성됩니다. 두 서비스 모두 MongoDB Atlas ODL로 주식 .

1

변환기는 하드 코딩된 로직 대신 MongoDB 에 저장된 구성을 사용하여 형식(MT103, ISO 20022, ISO 8583) 간에 메시지를 변환합니다.

  1. 번역파이프라인 설정: 트랜잭션 참조 및 금액과 같은 구조화된 필드에 대한 결정론적 정규식 패턴, 송금 정보와 같은 구조화되지 않은 필드에 대한 LLM 호출 등 복잡성에 따라 필드를 라우팅하도록 추출기를 구성합니다.

  2. MongoDBextract 변환 구성 저장 : 각 구성 문서(정규식map 패턴),(필드 output 변환),(대상 형식 경로)의 세 섹션이 포함되어 있습니다. 변환기는 런타임에 이를 읽으므로 새로운 형식에 대한 코드를 변경할 필요가 없습니다.

  3. 출력 생성기 빌드: 빌더는 변환된 필드를 가져와서 대상 형식을 구성합니다. ISO 20022 의 경우 빌더는 적절한 네임스페이스가 있는 유효한 XML을 생성합니다. JSON 대상의 경우 평면 표준 구조를 출력합니다.

2

에이전트 멀티에이전트 워크플로를 사용하여 누락된 IFSC 코드, 잘못된 스크립트, 불완전한 수취인 데이터 등 유효성 검사 에 실패한 트랜잭션을 복구합니다.

  1. 슈퍼바이저 에이전트 생성: 이 에이전트 복구 작업 ( 예시: " 일본의 경우 신용도 가타카나 필요 ") 을 받고 조사를 위해 레졸루션 에이전트로 라우팅할지, 수정 사항이 알려진 경우 실행으로 바로 라우팅할지를 결정합니다.

  2. 도구를 사용하여해상도 에이전트를atlas_search 빌드합니다:(정확하거나 퍼지 일치하는 데이터베이스 조회),(분류를vector_search 위한 시맨틱 transliterate_text 유사성),(LLM 기반 스크립트 변환)의 세 가지 도구를 사용하여 해결합니다. 에이전트 문제 컨텍스트에 따라 사용할 도구를 결정합니다.

  3. 인적 검토 체크포인트 추가 :interrupt() 변경 사항을 적용하기 전에 LangGraph의 함수를 사용하여 워크플로를 일시 중지합니다. 사용자는 원래 값, 제안된 수정 사항, 신뢰 점수 및 추론을 볼 수 있습니다. 워크플로가 재개되기 전에 승인, 거부 또는 수정할 수 있습니다.

  4. 실행 에이전트 구현: 승인되면 이 에이전트 수정된 값을 표준 JSON 에 쓰고 이전 값, 새 값, 사용된 도구 및 타임스탬프가 포함된 항목을 감사 추적에 추가합니다.

3

새로운 결제 형식을 온보딩하면 시스템이 기존 패턴을 학습하여 구성을 자동으로 생성합니다.

  1. 기존 구성 로드: 적응형 학습 서비스는 모든 변환 구성에 대해 MongoDB 쿼리하고 표준 매핑에 대한 필드 ID 맵을 빌드합니다( 예시: 필드 '32A'가,value_date currency및 에 amount 매핑됨). ).

  2. 샘플 메시지 구문 분석:8583 서비스는 SWIFT 태그를 지정하다 패턴, ISO 필드 위치, XML 경로와 같은 형식별 추출기를 사용하여 새 형식에 있는 모든 필드를 식별합니다.

  3. 알려진 패턴 일치 및 알 수 없는 필드 추론: 다른 구성에 존재하는 필드의 경우 시스템에서 정확한 매핑을 재사용합니다. 어디에서도 찾을 수 없는 필드의 경우, 서비스는 형식 유형에 대한 컨텍스트를 사용하여 LLM을 호출하여 매핑을 제안합니다.

  4. 구성 생성 및 검토: 이 서비스는 모든 매핑이 포함된 구성 문서 초안을 출력합니다. 시스템은 사람이 검토 있도록 신뢰 임계값 미만인 필드에 플래그를 지정합니다. 승인되면 변환기가 문서 MongoDB 에 삽입하고 즉시 처리합니다.

  • 적응형 학습을 위한 집계 파이프라인:$objectToArray 및 를 사용하여 단일 쿼리 로 모든 기존 구성에서 필드-매핑 조회를 $unwind 빌드합니다. 알려진 필드는 자동 매핑을 받습니다. 알 수 없는 필드는 형식 사양에 의해 제한된 LLM 제안을 받습니다.

  • 오타 허용을 위한 Atlas Search: 정확한 데이터베이스 조회가 실패할 경우, 편집 거리가 있는 퍼지 검색 느린 AI 추론으로 돌아가지 않고 맞춤법 오류( 예시 : 'HDFC 코넛'이 'HDFC 코넛 플레이스'에 매핑됨)를 처리합니다.

  • 구성 기반 변환: 애플리케이션 코드가 아닌 MongoDB 문서에 추출 패턴, 필드 매핑 및 출력 경로를 저장합니다. 새 결제 형식을 추가하는 것은 배포서버 아닌 데이터베이스 삽입이 됩니다.

  • 휴먼 인 더 루프 컴플라이언스: LangGraph interrupt() 메커니즘을 사용하여 변경 사항을 적용하기 전에 에이전트 워크플로를 일시 중지하고, 사용자에게 제안된 수정 사항을 제시하고, 명시적 승인 후에만 재개할 수 있습니다.

  • 슈퍼바이저 다중 에이전트 패턴: IFSC 조회 및 음역과 같은 조사 작업을 데이터베이스 도구가 있는 해상도 에이전트로 라우팅하고 필드 업데이트와 같은 실행 작업을 실행 에이전트로 라우팅합니다. 이러한 분리는 집중된 전문성 과 더 깔끔한 감사 추적을 보장합니다.

  • 통합 운영 데이터 계층: MongoDB Atlas 에 표준 JSON, 변환 구성 및 감사 추적을 저장합니다. 이러한 중앙 집중화는 결제 레일 간의 데이터 사일로를 제거하고 에이전트가 필요로 하는 완전한 트랜잭션 컨텍스트를 제공합니다.

  • Wei You Pan, MongoDB

  • Kiran Tulsulkar, MongoDB

  • Ainhoa Múgica, MongoDB

  • 다니엘 자미르, MongoDB

  • RAG 애플리케이션을 위한 통합 인터페이스

  • MongoDB Atlas를 활용한 금융 범죄 대응

  • AI 기반 인터랙티브 뱅킹

돌아가기

RAG 애플리케이션을 위한 통합 인터페이스

이 페이지의 내용