Orquestração de pagamentos com IA agêntica

Tradução de mensagens orientadas por dados

Os sistemas legados frequentemente codificam a lógica de tradução (por exemplo, "o campo 4 é mapeado para o campo 32A"). Essa solução armazena regras de tradução e metadados no MongoDB junto com os dados, fazendo com que a lógica de tradução seja orientada por dados.

Em vez de recompilar o código para alterar um mapeamento, basta atualizar um documento de configuração no MongoDB. O serviço conversor lê essas regras dinamicamente, extraindo 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 resistem a padrões regex, como o campo SWIFT 70 (informações de remessa), que pode conter finalidades 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": "remittance"), 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 meio de inferência.

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

Conversão adaptativa orientada por IA generativa

Com regras e metadados históricos armazenados no banco de dados, você pode usar 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 amostra. O Serviço de Aprendizagem Adaptativa carrega todas as configurações de conversão existentes do MongoDB e extrai campos usando uma análise específica do formato. Ele combina os IDs de campo capturados 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 nenhuma configuração existente, um LLM sugere mapeamentos que você pode revisar e refinar. Isso gera uma configuração de rascunho pronta para revisão manual e implantação. As redes de pagamento que antes levavam meses para serem integradas agora podem ser conectadas muito mais rapidamente.

Aprendizagem adaptativa com agregação 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 pipeline de agregação constrói uma consulta de correspondência de campo para mapeamento a partir de todas as configurações em uma única consulta. Campos conhecidos obtêm correspondências instantâneas. Os campos desconhecidos recebem sugestões do LLM limitadas aos campos suportados pelo formato de destino.

Agentic Payment Repair

Os pagamentos transfronteiriços frequentemente falham devido a requisitos de compensação locais, como códigos ausentes, scripts incorretos ou dados institucionais incompletos. Os sistemas tradicionais colocam essas exceções em fila para análise manual, o que geralmente leva dias para serem resolvidas.

O agente de resolução lida com essas exceções utilizando ferramentas que o LLM seleciona autonomamente com base em docstrings e prompts do sistema. O padrão orienta o LLM primeiramente para opções mais econômicas e rápidas.

Seleção da ferramenta de 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ê as docstrings da ferramenta e os prompts do sistema para determinar qual ferramenta chamar. O Atlas Search lida com pesquisas exatas e correspondências com tolerância a erros de digitação. A pesquisa vetorial lida com a classificação semântica em que as palavras-chave não correspondem, mas o significado sim. Para ilustrar essas funcionalidades na prática, considere os seguintes cenários de pagamento:

• Japão (transliteração do Katakana): um pagamento para Tóquio exige o nome do beneficiário no script do Katakana, mas a mensagem recebida contém caracteres latinos (por exemplo, Heinrich Mueller). O agente primeiro verifica a coleção bank_details em busca de uma tradução conhecida. Se não for encontrado, ele usará o Atlas Search para correspondência aproximada. Como alternativa, ele chama um LLM para transliterar o nome para Katakana ("ハインリッヒ・ミュラー").

• Índia (pesquisa de código IFSC): um pagamento para a Índia requer um código IFSC para ser encaminhado à agência correta, mas o remetente fornece apenas o nome do banco e a cidade. O agente consulta a coleção ifsc_codes para obter uma correspondência exata. Se a entrada contiver erros de digitação (por exemplo, "HDFC Connaught" em vez de "Connaught 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 de vários trilhos: exemplo de liquidação de blockchain

O modelo JSON canônico fornece uma abstração interna estável para integrar múltiplos trilhos de pagamento, normalizando a intenção central de pagamento, como partes, ativos, valores e instruções, em uma única estrutura consistente. Usando o MongoDB polymorphic document model, detalhes e metadados específicos de execução para trilhos são armazenados junto com campos canônicos, sem necessidade de esquemas ou modelos de dados separados. Isso mantém a complexidade do protocolo fora dos sistemas upstream e downstream, ao mesmo tempo em que permite que diferentes trilhos consumam a mesma representação de pagamento.

A demonstração mostra esse padrão na prática com uma integração Solana: os pagamentos contendo campos de resolução de criptomoedas são roteados para um serviço Solana que executa transferências reais no devnet.

Integração de serviços 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"
        }

Ao contrário das plataformas de pagamento tradicionais, a blockchain fornece prova de liquidação integrada. Cada transferência retorna um URL do Solana Explorer onde os usuários verificam o remetente da transação on-chain, o destinatário, o valor, o carimbo de data/hora e o status de confirmação. Essa transparência não está disponível com SWIFT ou redes de cartões, onde a prova de liquidação exige reconciliação de back office.

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