Orquestación de pagos con IA agéntica

Traducción de mensajes basada en datos

Los sistemas heredados suelen codificar de forma rígida la lógica de traducción; por ejemplo, "campo 4 está relacionado con campo 32A". Esta solución almacena reglas de traducción y metadatos en MongoDB junto con los datos, haciendo que la lógica de traducción sea guiada por datos.

En lugar de recompilar el código para cambiar un mapeo, se actualiza un documento de configuración en MongoDB. El servicio de conversión lee estas normas de forma dinámica—extrayendo patrones, mapeo de campos y rutas para la salida—con el fin de normalizar mensajes ISO 8583 o SWIFT MT entrantes al formato canónico JSON.

Transformación impulsada por configuración:

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

Algunos campos resisten patrones regex como el campo SWIFT 70 (información de remesas), que puede contener propósitos de pago en texto libre, referencias de facturas e instrucciones distribuidas en varias líneas. La configuración marca estos campos para el procesamiento de IA ("ai": "remesa"), y el LLM extrae datos estructurados del texto no estructurado. Este enfoque mantiene reglas determinísticas para la mayoría de los campos, pero gestiona el resto complejo a través de la inferencia.

Se habilitan nuevos formatos de mensaje mediante inserciones de documentos: el código del conversor permanece sin cambios, manteniendo la lógica de traducción fuera del ciclo de implementación.

Conversión adaptativa potenciada por IA genérica

Con las reglas y los metadatos históricos almacenados en la base de datos, puedes usar IA generativa (LLMs) para acelerar la incorporación de nuevos formatos de pago.

Para agregar soporte para un nuevo tipo de mensaje, proporcione un mensaje de muestra. El Servicio de Aprendizaje Adaptativo carga todas las configuraciones de conversión existentes desde MongoDB y extrae los campos utilizando un análisis específico del formato. Coincide los ID de campo detectados con las asignaciones de las configuraciones existentes. Por ejemplo, si el campo "32A" existe en MT103_to_JSON, ese mapeo exacto se reutiliza.

Para los campos que no se encuentran en ninguna configuración existente, un LLM sugiere asignaciones que se pueden revisar y refinar. Esto genera una configuración de borrador lista para la revisión e implementación humanas. Los carriles de pago que antes tardaban meses en integrarse ahora pueden incorporarse más rápido.

Aprendizaje adaptativo con agregación y 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")

El pipeline de agregación crea una búsqueda de mapeo de campo a campo a partir de todas las configuraciones en una sola query. Los campos conocidos obtienen coincidencias instantáneas. Los campos desconocidos reciben sugerencias de LLM restringidas por los campos compatibles con el formato de destino.

Reparación Agéntica de Pagos

Los pagos transfronterizos suelen fallar debido a requisitos de compensación local, como códigos faltantes, scripts incorrectos o datos institucionales incompletos. Los sistemas tradicionales ponen estas excepciones en cola para su revisión manual, lo que a menudo lleva días resolverlas.

El agente de resolución gestiona estas excepciones utilizando herramientas que el LLM selecciona de manera autónoma en función de docstrings e indicaciones del sistema. El patrón guía al LLM hacia opciones más económicas y rápidas en primer lugar.

Selección de herramienta del agente de resolución:

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

El LLM lee los docstrings de las herramientas y las indicaciones del sistema para determinar qué herramienta llamar. Atlas Search gestiona búsquedas exactas y coincidencias tolerantes a errores ortográficos. Búsqueda vectorial maneja la clasificación semántica cuando las palabras clave no coinciden pero el significado sí. Para ilustrar estas capacidades en la práctica, considere los siguientes escenarios de pago:

• Japón (Transliteración en Katakana): Un pago a Tokio requiere el nombre del beneficiario en el script Katakana, pero el mensaje entrante contiene caracteres latinos (por ejemplo, Heinrich Mueller). El agente primero revisa el bank_details Colección de una traducción conocida. Si no lo encuentra, utiliza Atlas Search para las coincidencias aproximadas. Como alternativa, llama a un LLM para transliterar el nombre a Katakana ("ハインリッヒ・ミュラー").

• India (Búsqueda de códigos IFSC): Un pago a India requiere un código IFSC para encaminarlo a la sucursal correcta, pero el remitente solo proporciona el nombre del banco y la ciudad. El agente query la colección ifsc_codes para obtener una coincidencia exacta. Si la entrada contiene errores tipográficos (por ejemplo, "HDFC Connaught" en lugar de "Connaught Place"), Atlas Search gestiona la búsqueda difusa para encontrar el código correcto.

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

Extensibilidad multi-Rail: Ejemplo de liquidación en blockchain

El modelo JSON canónico proporciona una abstracción interna estable para integrar múltiples canales de pago al normalizar la intención de pago principal, como participantes, activos, montos e instrucciones, en una estructura única y coherente. Al utilizar el modelo orientado a documentos polimórfico de MongoDB, los detalles de ejecución específicos de Rail y los metadatos se almacenan junto a campos canónicos sin requerir esquemas o modelos de datos separados. Esto mantiene la complejidad del protocolo fuera de los sistemas ascendentes y descendentes mientras permite que diferentes vías consuman la misma representación de pago.

La demostración muestra este patrón en acción con una integración de Solana: los pagos que contienen campos de liquidación en criptomonedas se dirigen a un servicio de Solana que ejecuta transferencias reales en devnet.

Integración de servicios de 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"
        }

A diferencia de los sistemas de pago tradicionales, blockchain proporciona una prueba incorporada de liquidación. Cada transferencia devuelve una URL del Explorer de Solana donde los usuarios verifican el remitente de la transacción en la cadena, el receptor, la cantidad, la marca de tiempo y el estado de confirmación. Esta transparencia no está disponible con SWIFT ni con redes de tarjetas, donde la prueba de liquidación requiere conciliación en la oficina administrativa.

La demostración se ejecuta en la red de desarrollo Solana, que utiliza el mismo protocolo que la red principal: las transacciones se firman criptográficamente, se propagan a los validadores y se registran de forma permanente.