Orquestração de pagamentos alimentada por IA da Agentic

Tradução de mensagens baseada em dados

Os sistemas legados geralmente codificam lógica de tradução (por exemplo, "o campo 4 mapeia o campo 32A"). Essa solução armazena regras e metadados de tradução no MongoDB junto com os dados, tornando a lógica de tradução orientada por dados.

Em vez de recompilar o código para alterar um mapeamento, você atualiza um documento de configuração no MongoDB. O serviço de conversor lê essas regras dinamicamente — extrair padrões, mapeamentos de campo e caminhos de saída — para normalizar mensagens ISO 8583 ou SWIFT MT de entrada no formato JSON canônico.

Transformação orientada por configuração:

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

Alguns campos resistir a padrões de regex, como o campo SWIFT 70 (informações de remessa) podem conter fins de pagamento de texto livre, referências de faturas e instruções em várias linhas. A configuração marca esses campos para processamento de IA ("ai": "remessa"), e o LLM extrai dados estruturados do texto não estruturado. Essa abordagem mantém regras determinísticas para a maioria dos campos, mas lida com o restante complexo por inferência.

Novos formatos de mensagem são habilitados por meio de inserções de documento — o código do conversor permanece inalterado, mantendo a lógica de tradução fora do ciclo de implantação.

Conversão adaptativa alimentada por IA da Geração

Com regras e metadados históricos armazenados no banco de dados, você pode usar a IA generativa (LLMs) para acelerar a integração de novos formatos de pagamento.

Para adicionar suporte para um novo tipo de mensagem, forneça uma mensagem de exemplo. O Adaptive Learning Service carrega todas as configurações de conversão existentes do MongoDB e extrai campos usando análise específica do formato. Ele compara os IDs de campo detectados com os mapeamentos das configurações existentes. Por exemplo, se o campo "32A" existir em MT103_to_JSON, esse mapeamento exato será reutilizado.

Para campos não encontrados em qualquer configuração existente, um LLM sugere mapeamentos que você analisa e refina. Isso gera um esquema de configuração pronto para revisão e implantação humanos. Os fluxos de pagamento que antes levavam meses para serem integrados agora podem ser integrados mais rapidamente.

Aprender adaptável com aggregation e 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")

O agregação pipeline cria uma pesquisa de campo para mapeamento a partir de todas as configurações em uma query. Campos conhecidos obtêm correspondências instantâneas. Campos desconhecidos obtêm sugestões de LLM limitadas pelos campos compatíveis do formato de destino.

Reparação de pagamento Agentic

Os pagamentos transnacionais frequentemente falham devido aos requisitos de compensação local, como códigos ausentes, scripts incorretos ou dados corporativos incompletos. Os sistemas tradicionais enfileiram essas exceções para análise manual, geralmente levando dias para serem resolvidas.

O agente de resolução lida com essas exceções usando ferramentas que o LLM seleciona automaticamente com base em docstrings e prompts do sistema. O padrão orienta o LLM para opções mais baratas e rápidas primeiro.

Seleção de ferramenta do agente de resolução:

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])

O LLM lê docstrings de ferramentas e prompts do sistema para determinar qual ferramenta chamar. O Atlas Search lida com pesquisas exatas e correspondência tolerante a erros de digitação. O Vector Search lida com a classificação semântica em que as palavras-chave não correspondem, mas o significado corresponde. Para ilustrar esses recursos na prática, considere os seguintes cenários de pagamento:

• Japão (transliteração katakana): um pagamento para Tóquio exige o nome do destinatário na escrita katakana, mas a mensagem recebida contém caracteres latinos (por exemplo, Heinhard Mueller). O agente primeiro verifica a bank_details coleção em busca de uma tradução conhecida. Se não for encontrado, ele usará o Atlas Search para correspondência difusa. Como contingência, ele chama um LLM para transliterar o nome para o katakana ("jato , ,,,,,,,,,,,,,,,")).

• Índia (pesquisa de código IFSC): um pagamento para a Índia requer um código IFSC para ser encaminhado para a agencia correta, mas o remetente fornece apenas um nome de banco e uma cidade. O agente consulta a ifsc_codes collection em busca de uma correspondência exata. Se a entrada contiver erros de digitação (por exemplo, "HDFC Connout" em vez de "Connutil place"), o Atlas Search lidará com a correspondência difusa para encontrar o código correto.

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

Extensibilidade multi-rail: exemplo de acordo com blockchain

O modelo JSON canônico fornece uma abstração interna estável para integrar várias ferrovias de pagamento, normalizando a principal intenção de pagamento – como partes, ativos, valores e instruções – em uma estrutura única e consistente. Usando o modelo de documento polimórfico do MongoDB , detalhes de execução e metadados específicos do Rail são armazenados lado a lado com campos canônicos sem exigir esquemas ou modelos de dados separados. Isso mantém a complexidade do protocolo fora dos sistemas upstream e downstream, permitindo que diferentes Rails consumam a mesma representação de pagamento.

A demonstração mostra esse padrão em ação com uma integração Solana: pagamentos contendo campos de eliminação de criptomoedas são roteados para um serviço Solana que executa transferências reais em devnet.

Integração com o Solana Service:

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

Ao contrário dos caminhos de pagamento tradicionais, a cadeia de blocos fornece prova de compensação integrada. Cada transferência retorna um URL do Solana Explorer em que os usuários verificam o emissor, o receptor, o valor, o timestamp e o status de confirmação da transação na cadeia. Essa Transparência não está disponível com SWIFT ou redes de cartão, onde a prova de acordo requer reconciliação de back-escritório.

A demonstração é executada no Solana devnet, que usa o mesmo protocolo da rede principal: As transações são assinadas criptograficamente, propagadas para validadores e registradas permanentemente.