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], SDKmcp>=2,<3)Als Tool bereitgestellter Actor:
active_yardstick/latam-synthAuthentifizierung: Apify OAuth oder Bearer-Token
Offizieller MCP-Registry-Name:
io.github.jmendozapuche/latam-fintech-synthetic-dataRegistry-Metadaten:
server.jsonApify-Actor: https://apify.com/active_yardstick/latam-synth
MCP-Endpunkt
https://mcp.apify.com?tools=active_yardstick/latam-synthDer 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 + transactionsApify 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 # equivalentKonfiguration für einen lokalen MCP-Client (Claude Desktop / Claude Code):
{
"mcpServers": {
"latam-synth": {
"command": "latam-synth-mcp"
}
}
}Bereitgestellte Tools:
Tool | Funktion |
| Generiert Nutzer + Ziele + Transaktionen. Argumente: |
| 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 ./outputNur Mexiko und Kolumbien, Parquet-Format:
latam-synth generate --users 10000 --countries Mexico Colombia --format parquetPython
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.txtDer 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-synthActor-Seite:
https://apify.com/active_yardstick/latam-synthDer 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
Öffnen Sie den Lauf in der Apify Console und klicken Sie auf den Tab Storage.
Klicken Sie auf Key-value store.
Laden Sie die generierten Dateien herunter:
users.csv– eine Zeile pro synthetischem Nutzergoals.csv– mit Nutzern verknüpfte Sparzieletransactions.csv– mit Zielen verknüpfte Ein-/AuszahlungstransaktionenOUTPUT– immer vorhanden; JSON-Zusammenfassung des Laufs, einschließlich Parametern, Zeilenzahlen und herunterladbarer Schlüsselwenn
format: jsonausgewählt wurde, enthältOUTPUT_DATAalle drei Tabellen in einer einzigen JSON-Datei anstelle der drei CSV-Dateien
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 8000JSON 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 .metaBeispiel-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.csvHealth-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]"
pytestMCP-Registry-Metadaten
Dieses Repository enthält server.json für die MCP-Registry-Erkennung.
Aktuelle Server-Identität:
io.github.jmendozapuche/latam-fintech-synthetic-dataDer registrierte Remote-MCP-Endpunkt ist:
https://mcp.apify.com?tools=active_yardstick/latam-synthChangelog
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 toolsdescribe_latam_synth_datasetARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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_dataARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| users | No | ||
| end_date | No | ||
| countries | No | ||
| start_date | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v1.0.0- First observed
describe_latam_synth_dataset - First observed
generate_latam_financial_data
TDQS
Scored across 2 tools
The two tools have completely distinct purposes: one generates synthetic data, the other describes the dataset schema. No overlap or ambiguity exists.
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.
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.
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
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
Brazilian Open Finance MCP — 30+ banks (Itaú, Nubank, etc.) to Claude/Cursor. Read-only.
Verified LATAM data for AI agents: sanctions, entity, rates, KYB. Pay via x402.
Open Finance API and MCP discovery for developers and AI agents building in Brazil.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceHosted 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
- FlicenseNot gradedqualityDmaintenanceGenerates realistic, context-aware synthetic data for AI agents to populate databases, mock APIs, and create test scenarios without exposing real PII.8 npm3-
- FlicenseAqualityBmaintenanceMCP 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-
- FlicenseNot gradedqualityBmaintenanceEnables 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-