Orquestación de pagos impulsada por IA de Agentic

Traducción de mensajes basada en datos

Los sistemas heredados suelen codificar la lógica de traducción (por ejemplo, "el campo 4 se asigna al campo 32A"). Esta solución almacena las reglas de traducción y los metadatos en MongoDB junto con los datos, lo que permite que la lógica de traducción se base en datos.

En lugar de recompilar código para cambiar una asignación, se actualiza un documento de configuración en MongoDB. El servicio de conversión lee estas reglas dinámicamente (extrae patrones, asignaciones de campos y rutas de salida) para normalizar los mensajes entrantes ISO 8583 o SWIFT MT al formato JSON canónico.

Transformación basada en 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 no se ajustan a los patrones de expresiones regulares, como el campo SWIFT 70 (información de remesa), que puede contener texto libre con propósitos de pago, referencias de facturas e instrucciones en varias líneas. La configuración marca estos campos para el procesamiento de IA ("ai": "remittance"), y el LLM extrae datos estructurados del texto no estructurado. Este enfoque mantiene reglas deterministas para la mayoría de los campos, pero gestiona el resto complejo mediante inferencia.

Los nuevos formatos de mensajes se habilitan a través de inserciones de documentos: el código del convertidor permanece sin cambios, lo que mantiene la lógica de traducción fuera del ciclo de implementación.

Conversión adaptativa impulsada por inteligencia artificial

Con reglas y metadatos históricos almacenados en la base de datos, puede utilizar IA generativa (LLM) para acelerar la incorporación de nuevos formatos de pago.

Para añadir compatibilidad con un nuevo tipo de mensaje, proporcione un mensaje de ejemplo. El Servicio de Aprendizaje Adaptativo carga todas las configuraciones de conversión existentes de MongoDB y extrae los campos mediante análisis específico del formato. Compara los ID de campo detectados con las asignaciones de las configuraciones existentes. Por ejemplo, si el campo "32A" existe en MT103_to_JSON, se reutiliza esa asignación exacta.

Para los campos que no se encuentran en ninguna configuración existente, un LLM sugiere asignaciones que usted revisa y perfecciona. Esto genera un borrador de configuración listo para su revisión e implementación. Las vías de pago que antes tardaban meses en integrarse ahora se pueden implementar 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")

La canalización de agregación genera una búsqueda de campo a mapeo a partir de todas las configuraciones en una sola consulta. Los campos conocidos obtienen coincidencias instantáneas. Los campos desconocidos reciben sugerencias de LLM limitadas por los campos compatibles con el formato de destino.

Reparación de pagos de Agentic

Los pagos transfronterizos suelen fallar debido a requisitos de compensación locales, como códigos faltantes, scripts incorrectos o datos institucionales incompletos. Los sistemas tradicionales ponen estas excepciones en cola para su revisión manual, cuya resolución suele tardar días.

El Agente de Resolución gestiona estas excepciones mediante herramientas que el LLM selecciona automáticamente según las cadenas de documentación y las indicaciones del sistema. El patrón guía al LLM hacia opciones más económicas y rápidas primero.

Selección de herramientas 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 las cadenas de documentación de las herramientas y las indicaciones del sistema para determinar qué herramienta llamar. Atlas Search gestiona búsquedas exactas y coincidencias con tolerancia a errores tipográficos. Vector Search gestiona 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 katakana): Un pago a Tokio requiere el nombre del beneficiario en katakana, pero el mensaje entrante contiene caracteres latinos (por ejemplo, Heinrich Mueller). El agente primero verifica la bank_details colección para una traducción conocida. Si no se encuentra, utiliza Atlas Search para realizar coincidencias aproximadas. Como alternativa, llama a un LLM para transliterar el nombre al katakana ("ハインリッヒ・ミュラー").

• India (Búsqueda de código IFSC): Un pago a India requiere un código IFSC para dirigirse a la sucursal correcta, pero el remitente solo proporciona el nombre del banco y la ciudad. El agente consulta la ifsc_codes colección para encontrar una coincidencia exacta. Si la entrada contiene errores tipográficos (por ejemplo, "HDFC Connaught" en lugar de "Connaught Place"), Atlas Search realiza la búsqueda aproximada 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 multirraíl: 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 las intenciones de pago principales (como partes, activos, importes e instrucciones) en una estructura única y consistente. Mediante el modelo de documento polimórfico de MongoDB, los detalles de ejecución y los metadatos específicos de cada canal se almacenan junto con los campos canónicos, sin necesidad de esquemas ni modelos de datos independientes. Esto minimiza la complejidad del protocolo en los sistemas de origen y destino, a la vez que permite que diferentes canales 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 de criptomonedas se enrutan 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 ofrece una prueba de liquidación integrada. Cada transferencia devuelve una URL de Solana Explorer donde los usuarios verifican en la cadena el remitente, el receptor, el importe, la marca de tiempo y el estado de confirmación de la transacción. Esta transparencia no está disponible con SWIFT ni con las redes de tarjetas, donde la prueba de liquidación requiere una conciliación interna.

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.