Skip to main content
Glama
latam-fintech-synthetic-data

latam-fintech-synthetic-data

latam-synth

Datenschutzfreundliche synthetische Finanzdaten für lateinamerikanische Fintechs – verfügbar über Python, CLI, REST, Apify Actor und Model Context Protocol (MCP) für KI-Agenten.

Generator für synthetische Daten zum Finanzsparverhalten, kalibriert mit den statistischen Verteilungen von 506.311 echten Datensätzen einer lateinamerikanischen Spar-App (2015–2024): 305.808 Transaktionen, 108.570 Sparziele und 91.933 Nutzer aus Mexiko, Kolumbien, Argentinien, Peru, Chile und weiteren Ländern.

Die Ausgabe ist zu 100 % synthetisch: Kein Datensatz stammt von einem echten Nutzer, sondern nur aus aggregierten Verteilungen. Ohne PII und ohne Reidentifikationsrisiko.


Model Context Protocol (MCP)

LatAm Synth ist für KI-Agenten über zwei unabhängige Wege als MCP-Tool verfügbar:

  • Remote (gehostet): Der Apify MCP Server stellt den active_yardstick/latam-synth-Actor als aufrufbares MCP-Tool über Streamable HTTP bereit. Nichts muss installiert werden.

  • Lokal (stdio): latam-synth-mcp, das in diesem Repository enthalten ist, führt den Generator prozessintern aus, ohne Apify aufzurufen. Für lokale MCP-Clients und containerisierte Katalogprüfungen.

Beide Wege liefern dieselben Tabellen mit derselben referenziellen Integrität, da beide nur dünne Adapter über demselben SyntheticGenerator sind.

MCP-Details

  • MCP-Fähigkeit: Tools

  • Transport: Streamable HTTP (remote) / stdio (lokal)

  • Gehosteter MCP-Server: Apify MCP Server

  • Lokaler MCP-Server: latam-synth-mcp (Extra [mcp], SDK mcp>=2,<3)

  • Als Tool bereitgestellter Actor: active_yardstick/latam-synth

  • Authentifizierung: Apify OAuth oder Bearer-Token

  • Offizieller MCP-Registry-Name: io.github.jmendozapuche/latam-fintech-synthetic-data

  • Registry-Metadaten: server.json

  • Apify-Actor: https://apify.com/active_yardstick/latam-synth

MCP-Endpunkt

https://mcp.apify.com?tools=active_yardstick/latam-synth

Der Parameter tools schränkt den Apify MCP Server auf den LatAm-Synth-Actor ein, sodass er für kompatible KI-Agenten direkt auffindbar und aufrufbar ist.

Beispiel-MCP-Konfiguration – OAuth

{
  "mcpServers": {
    "latam-synth": {
      "url": "https://mcp.apify.com?tools=active_yardstick/latam-synth"
    }
  }
}

Bei der ersten Verbindung kann ein kompatibler MCP-Client den Apify-OAuth-Ablauf öffnen, damit der Nutzer den Zugriff autorisieren kann, ohne ein API-Token direkt in der Konfiguration zu hinterlegen.

Beispiel-MCP-Konfiguration – Bearer-Token

{
  "mcpServers": {
    "latam-synth": {
      "url": "https://mcp.apify.com?tools=active_yardstick/latam-synth",
      "headers": {
        "Authorization": "Bearer <APIFY_TOKEN>"
      }
    }
  }
}

Ersetzen Sie <APIFY_TOKEN> durch ein Apify-API-Token.

Was KI-Agenten mit LatAm Synth tun können

Ein MCP-kompatibler Agent kann LatAm Synth aufrufen, um Folgendes zu generieren:

  • synthetische Finanznutzer

  • verknüpfte Sparziele

  • Ein- und Auszahlungstransaktionen

  • nach Ländern gefilterte lateinamerikanische Datensätze

  • reproduzierbare Datensätze mithilfe eines Zufalls-Seeds

  • realistische Fintech-Testdaten ohne Offenlegung personenbezogener Daten

Typische Anwendungsfälle für Agenten sind:

  • Bewertung finanzieller KI-Agenten

  • bedarfsgerechte Erzeugung von Test-Fixtures

  • Erstellung synthetischer Datensätze für Demos und POCs

  • Testen von Empfehlungs- oder Sparassistenten

  • Bootstrapping von ML- und Data-Pipeline-Experimenten

LatAm Synth stellt seine Funktionalität derzeit über MCP-Tools bereit. Derzeit werden keine MCP-Ressourcen oder -Prompts bereitgestellt.

Wie MCP implementiert ist

Der Remote-Pfad erfordert keinen MCP-Transportserver in diesem Repository: Apify hostet ihn. Der lokale Pfad enthält jedoch einen (src/latam_synth/mcp_server.py) für Clients, die den Generator lieber selbst ausführen – ohne Token, ohne Netzwerk, ohne Kosten pro Lauf.

Die Architektur sieht wie folgt aus:

MCP-compatible AI client
        |
        |  Streamable HTTP
        v
Apify MCP Server
        |
        |  exposes Actor as MCP Tool
        v
active_yardstick/latam-synth
        |
        v
Synthetic users + goals + transactions

Apify stellt den gehosteten MCP-Server und die Authentifizierungsebene bereit. Der LatAm-Synth-Actor bietet die ausführbare Tool-Funktionalität sowie strukturierte Ein-/Ausgaben.

Lokaler MCP-Server (stdio)

pip install -e ".[mcp]"
latam-synth-mcp                    # entry point
python -m latam_synth.mcp_server   # equivalent

Konfiguration für einen lokalen MCP-Client (Claude Desktop / Claude Code):

{
  "mcpServers": {
    "latam-synth": {
      "command": "latam-synth-mcp"
    }
  }
}

Bereitgestellte Tools:

Tool

Funktion

generate_latam_financial_data

Generiert Nutzer + Ziele + Transaktionen. Argumente: users (1-200), seed, countries, start_date, end_date.

describe_latam_synth_dataset

Gibt Schema, Zielkategorien, verfügbare Länder und die Datenschutzrichtlinie zurück. Keine Argumente.

Beide sind als read_only und idempotent annotiert: Es wird nichts geschrieben, und derselbe Seed liefert denselben Datensatz. Das Limit von 200 Nutzern pro Aufruf hält die Antworten klein genug für einen Agentenkontext – für größere Mengen verwenden Sie die CLI oder den Actor.

Bereitstellungsdetails, Docker-Image und Glama-Konfiguration: docs/mcp_local.md.


Related MCP server: Faker MCP Server

Wozu es dient

  • Testing und Fintech-QA: realistische Fixtures für Zahlungs-Pipelines, Budget-Apps und Ziel-Engines.

  • Demos und POCs: Dashboards mit plausiblen LatAm-Daten, die öffentlich gezeigt werden können.

  • ML-Training: Startdaten für Churn-, Empfehlungs- und Segmentierungsmodelle mit echten Mustern wie Saisonalität, Abbrecherquoten und Zielkategorien.

  • KI-Agenten: bedarfsgerechte Generierung synthetischer Finanzdatensätze über MCP.

  • Bildung: unbegrenzte Datensätze für Data-Science-Kurse mit echter Geschäftsnarrative.


Schnellstart

CLI

pip install -e .
latam-synth generate --users 5000 --seed 42 --format csv --out ./output

Nur Mexiko und Kolumbien, Parquet-Format:

latam-synth generate --users 10000 --countries Mexico Colombia --format parquet

Python

from latam_synth import SyntheticGenerator, GeneratorConfig

data = SyntheticGenerator(
    GeneratorConfig(n_users=1000, seed=42)
).generate()

data["transactions"].head()

Was diesen Generator realistisch macht

Die Kalibrierung wurde anhand echter Daten verifiziert. Siehe:

docs/validation_report.txt

Der Generator umfasst:

  • lognormale Betragsverteilungen nach Transaktionstyp

  • echte monatliche Saisonalität

  • Januar-Peak nach den Neujahrsvorsätzen und Dezember-Tal

  • 8 Zielkategorien mit eigenen Beträgen und Zeithorizonten

  • beobachtete Erfolgs- und Abbrecherquoten

  • 73,8 % überfällige Ziele

  • Uplift bei gemeinsamen Zielen

  • korrelierte Nutzer-Scores

  • Gauß-Copula mit ρ=0,89 für Disziplin-Erfolg

  • kohärente zeitliche Verläufe pro Ziel

  • referenzielle Integrität zwischen Nutzern, Zielen und Transaktionen


Apify Actor

LatAm Synth ist auch als gehosteter Apify-Actor verfügbar:

active_yardstick/latam-synth

Actor-Seite:

https://apify.com/active_yardstick/latam-synth

Der Actor kann direkt von Apify aus, über die Apify-API oder über den Apify MCP Server für KI-Clients bereitgestellt werden.

Beispieleingabe:

{
  "users": 1000,
  "seed": 42,
  "countries": ["Mexico", "Colombia"],
  "format": "csv",
  "push_to_dataset": true,
  "start_date": "2023-01-01",
  "end_date": "2024-12-31"
}

Der Parameter seed macht die Generierung reproduzierbar. Derselbe Seed und dieselbe Konfiguration erzeugen dieselbe synthetische Ausgabe.


Wo Sie Ihre Ausgabe finden (Apify)

Jeder Lauf schreibt die Ausgabe an zwei Orte.

Key-Value-Store – alle drei Tabellen

  1. Öffnen Sie den Lauf in der Apify Console und klicken Sie auf den Tab Storage.

  2. Klicken Sie auf Key-value store.

  3. Laden Sie die generierten Dateien herunter:

    • users.csv – eine Zeile pro synthetischem Nutzer

    • goals.csv – mit Nutzern verknüpfte Sparziele

    • transactions.csv – mit Zielen verknüpfte Ein-/Auszahlungstransaktionen

    • OUTPUT – immer vorhanden; JSON-Zusammenfassung des Laufs, einschließlich Parametern, Zeilenzahlen und herunterladbarer Schlüssel

    • wenn format: json ausgewählt wurde, enthält OUTPUT_DATA alle drei Tabellen in einer einzigen JSON-Datei anstelle der drei CSV-Dateien

  4. Klicken Sie auf das Download-Symbol neben jedem Schlüssel, um die Datei zu speichern.

Dataset – Transaktionen

Standardmäßig (push_to_dataset: true) werden alle Transaktionen auch in das Dataset des Laufs geschrieben.

Damit können Sie:

  • direkt als JSON, CSV oder Excel über den Tab Dataset exportieren

  • native Apify-Integrationen mit der Dataset-Ausgabe verbinden

  • Transaktionen programmatisch abrufen

Um dies bei sehr großen Läufen zu deaktivieren, wenn nur die Dateien aus dem Key-Value-Store benötigt werden, setzen Sie:

{
  "push_to_dataset": false
}

Das Laufprotokoll gibt am Ende der Ausführung die genauen Dateinamen und Zeilenzahlen aus.


Lokale REST-API

Installieren Sie die API-Abhängigkeiten:

pip install -e ".[api]"
uvicorn latam_synth.api:app --port 8000

JSON mit den drei Tabellen generieren:

curl -s -X POST http://localhost:8000/generate \
  -H "Content-Type: application/json" \
  -d '{"users": 100, "seed": 42, "countries": ["Mexico", "Colombia"]}' | jq .meta

Beispiel-Metadatenantwort:

{
  "users": 100,
  "goals": 121,
  "transactions": 453
}

Transaktions-CSV direkt herunterladen:

curl -s -X POST http://localhost:8000/generate \
  -H "Content-Type: application/json" \
  -H "Accept: text/csv" \
  -d '{"users": 500, "seed": 7}' \
  -o transactions.csv

Health-Check:

curl http://localhost:8000/health
{
  "status": "ok",
  "version": "0.2.0"
}

Limits der lokalen REST-API:

  • Rate-Limit: 10 Anfragen/min pro IP

  • Maximum: 50.000 Nutzer pro Anfrage


Datenschutz

Die generierten Datensätze sind für Entwicklung, Tests, Demos, Experimente und Bildung konzipiert, ohne dass Produktions-PII erforderlich ist.

Wichtige Eigenschaften:

  • 100 % synthetische Datensätze

  • keine Zeile wird von einem echten Nutzer kopiert

  • keine Namen, E-Mails, IDs oder andere direkte PII aus dem Kalibrierungsdatensatz werden reproduziert

  • die Generierung basiert auf aggregierten statistischen Verteilungen

  • synthetische Tabellen bewahren realistische Beziehungen zwischen Nutzern, Zielen und Transaktionen


Entwicklung

pip install -e ".[dev]"
pytest

MCP-Registry-Metadaten

Dieses Repository enthält server.json für die MCP-Registry-Erkennung.

Aktuelle Server-Identität:

io.github.jmendozapuche/latam-fintech-synthetic-data

Der registrierte Remote-MCP-Endpunkt ist:

https://mcp.apify.com?tools=active_yardstick/latam-synth

Changelog

v0.2

  • Mischung von Lognormalverteilungen (KS=0,032)

  • Anpassung an runde Werte (69,5 % im Raster)

  • kohärente zeitliche Verläufe pro Ziel

  • 100 % der Transaktionen innerhalb des Fensters [created_at, deadline]

  • FastAPI-API

  • Apify-Actor

  • MCP-Bereitstellung über den gehosteten Apify MCP Server

Available Tools

2 tools
describe_latam_synth_datasetA
Read-onlyIdempotent
Inspect

Describe the schema and calibration of the LatAm Synth dataset.

Use this tool to inspect which tables, columns, goal categories and
countries are available before generating data. It performs no generation
and takes no arguments.

Returns:
    Table columns, relationships, goal categories, available countries
    and the privacy policy of the generated data.
NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral context by stating 'performs no generation' and specifying the return items including the privacy policy, which goes beyond what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized, with the purpose front-loaded in the first sentence, usage guidance in the second, and a structured 'Returns' block for the output. Every sentence adds value and there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and an output schema exists, the description is complete. It clearly states what the tool does, when to use it, and what it returns, including a notable privacy policy detail. Nothing essential is missing for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description redundantly states 'takes no arguments', but this reinforces the fact that no input is needed, which is helpful for an agent. No parameter documentation is required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb 'Describe' and a specific resource 'schema and calibration of the LatAm Synth dataset'. It explicitly distinguishes itself from the sibling generate_latam_financial_data by saying 'It performs no generation', making the purpose immediately clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use the tool: 'before generating data' to inspect available tables, columns, goal categories, and countries. It also states exclusions: 'It performs no generation' and 'takes no arguments'. This provides clear context and indirectly points to the generation sibling as the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_latam_financial_dataA
Read-onlyIdempotent
Inspect

Generate privacy-safe synthetic financial data for Latin America.

Use this tool when you need synthetic financial users, savings goals and
transactions for Latin American fintech testing, QA, demos,
machine-learning experiments, data pipelines or agent evaluation. The output
is fully synthetic: it is sampled from aggregate distributions and contains
no personally identifiable information and no real records.

Args:
    users: Number of synthetic users to generate. Use 1 to 200.
    seed: Random seed for reproducible datasets. The same seed and
        parameters always return the same dataset.
    countries: Optional list of Latin American countries to include,
        for example ["Colombia", "Mexico"].
    start_date: Optional ISO start date of the generated period,
        for example "2023-01-01".
    end_date: Optional ISO end date of the generated period,
        for example "2024-12-31".

Returns:
    Synthetic users, linked savings goals, linked transactions,
    and dataset row counts.
NameRequiredDescriptionDefault
seedNo
usersNo
end_dateNo
countriesNo
start_dateNo

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond the annotations: it states the output is 'fully synthetic', 'sampled from aggregate distributions', contains 'no personally identifiable information and no real records', and that 'the same seed and parameters always return the same dataset.' This goes far beyond the readOnlyHint and idempotentHint annotations by explaining what the data actually is and how reproducibility works.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a summary sentence, a usage paragraph, a structured Args list, and a Returns note. It is slightly verbose in the usage paragraph (listing many use cases) but every sentence contributes value, and the most important information (what it does, key constraints) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (five optional parameters, one sibling tool, output schema available), the description is complete. It explains the purpose, when to use it, all parameters with examples, the synthetic nature, and the return shape. There are no obvious gaps that would prevent an agent from invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully carries the burden of explaining all five parameters. It provides detailed meaning and usage for each: users range '1 to 200', seed guarantees reproducibility, countries gives an example list, and both date parameters specify ISO format with examples. This is exemplary compensation for the absence of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear statement of what the tool does: 'Generate privacy-safe synthetic financial data for Latin America.' It then specifies the exact resources produced (financial users, savings goals, transactions), which distinguishes it from the sibling describe_latam_synth_dataset that describes rather than generates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'Use this tool when you need synthetic financial users, savings goals and transactions for Latin American fintech testing, QA, demos...' This provides clear context, but it does not mention any alternative tool or describe situations where it should NOT be used, so it falls just short of full marks.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observeddescribe_latam_synth_dataset
    • First observedgenerate_latam_financial_data

TDQS

A4.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one generates synthetic data, the other describes the dataset schema. No overlap or ambiguity exists.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (generate_..., describe_...). The slight difference in noun phrasing ('financial_data' vs 'synth_dataset') is minor and does not break the pattern.

Tool Count3/5

Only 2 tools is on the thin side. For a data generation server, a generate and describe tool is minimal but arguably sufficient for the core workflow. Still, it barely meets the borderline threshold.

Completeness4/5

The tool surface covers the main lifecycle: generating data and understanding the schema/config. No obvious missing operations for the stated purpose, though there is no tool for exporting or managing datasets, which might be a minor gap.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Hosted MCP endpoint that returns realistic fake data for prototyping agents. Paste one URL into Claude Code, Cursor, or Claude Desktop — 12 pre-built tools covering users, products, orders, events, email, and knowledge base search. No signup, no config, no auth. Built for developers who want to prototype agent workflows before wiring up a real backend.
    MIT
  • F
    license
    A
    quality
    B
    maintenance
    MCP server providing verified Latin American data via x402 micropayments. 4 MCP tools: vera_rates (central bank rates CO/MX/BR/CL/PE), vera_sanctions (OFAC+SARLAFT+CNBV+COAF+UAF screening, EU AI Act Art.13), vera_entity (RUES/CNPJ/RFC enrichment), vera_context (AI market intelligence). $0.02–$0.10 USDC per call.
    4
    -
  • F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to manage personal finances for Brazilian users through MCP tools, including categorizing transactions, reconciling debts, checking cash-flow projections, and adjusting budgets, with integration to Open Finance Brasil via Pluggy.
    2
    -