latam-fintech-synthetic-data
latam-synth
Privacy-safe synthetic financial data for Latin American fintech — available through Python, CLI, REST, Apify Actor, and Model Context Protocol (MCP) for AI agents.
Synthetic generator of financial savings behavior data, calibrated with the statistical distributions of 506,311 real records from a LatAm savings app (2015–2024): 305,808 transactions, 108,570 savings goals and 91,933 users from Mexico, Colombia, Argentina, Peru, Chile and more.
The output is 100% synthetic: no record derives from a real user, only from aggregate distributions. No PII and no re-identification risk.
Model Context Protocol (MCP)
LatAm Synth is available to AI agents as an MCP tool through two independent paths:
Remote (hosted): the Apify MCP Server exposes the
active_yardstick/latam-synthActor as a callable MCP tool over Streamable HTTP. Nothing to install.Local (stdio):
latam-synth-mcp, shipped in this repository, runs the generator in-process without calling Apify. For local MCP clients and containerised catalog checks.
Both paths return the same tables with the same referential integrity, because both are thin adapters over the same SyntheticGenerator.
MCP details
MCP capability: Tools
Transport: Streamable HTTP (remote) / stdio (local)
Hosted MCP server: Apify MCP Server
Local MCP server:
latam-synth-mcp(extra[mcp], SDKmcp>=2,<3)Actor exposed as tool:
active_yardstick/latam-synthAuthentication: Apify OAuth or Bearer token
Official MCP Registry name:
io.github.jmendozapuche/latam-fintech-synthetic-dataRegistry metadata:
server.jsonApify Actor: https://apify.com/active_yardstick/latam-synth
MCP endpoint
https://mcp.apify.com?tools=active_yardstick/latam-synthThe tools parameter restricts the Apify MCP Server to the LatAm Synth Actor, making it directly discoverable and callable by compatible AI agents.
Example MCP configuration — OAuth
{
"mcpServers": {
"latam-synth": {
"url": "https://mcp.apify.com?tools=active_yardstick/latam-synth"
}
}
}On first connection, a compatible MCP client can open the Apify OAuth flow so the user can authorize access without placing an API token directly in the configuration.
Example MCP configuration — Bearer token
{
"mcpServers": {
"latam-synth": {
"url": "https://mcp.apify.com?tools=active_yardstick/latam-synth",
"headers": {
"Authorization": "Bearer <APIFY_TOKEN>"
}
}
}
}Replace <APIFY_TOKEN> with an Apify API token.
What AI agents can do with LatAm Synth
An MCP-compatible agent can invoke LatAm Synth to generate:
synthetic financial users
linked savings goals
deposit and withdrawal transactions
country-filtered Latin American datasets
reproducible datasets using a random seed
realistic fintech test data without exposing personally identifiable information
Typical agent use cases include:
evaluating financial AI agents
generating test fixtures on demand
creating synthetic datasets for demos and POCs
testing recommendation or savings assistants
bootstrapping ML and data-pipeline experiments
LatAm Synth currently exposes its functionality through MCP Tools. It does not currently expose MCP Resources or Prompts.
How MCP is implemented
The remote path does not require an MCP transport server inside this repository: Apify hosts it. The local path does ship one (src/latam_synth/mcp_server.py), for clients that prefer to run the generator themselves — no token, no network, no per-run cost.
The architecture is:
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 provides the hosted MCP server and authentication layer. The LatAm Synth Actor provides the executable tool functionality and structured input/output.
Local MCP server (stdio)
pip install -e ".[mcp]"
latam-synth-mcp # entry point
python -m latam_synth.mcp_server # equivalentConfiguration for a local MCP client (Claude Desktop / Claude Code):
{
"mcpServers": {
"latam-synth": {
"command": "latam-synth-mcp"
}
}
}Exposed tools:
Tool | What it does |
| Generates users + goals + transactions. Args: |
| Returns schema, goal categories, available countries and the privacy policy. No arguments. |
Both are annotated read_only and idempotent: nothing is written and the same
seed returns the same dataset. The 200-user cap per call keeps responses small
enough for an agent context — for larger volumes use the CLI or the Actor.
Deployment detail, Docker image and Glama configuration: docs/mcp_local.md.
Related MCP server: LiveDataLink
What it's for
Fintech testing and QA: realistic fixtures for payment pipelines, budgeting apps and goal engines.
Demos and POCs: dashboards with plausible LatAm data that can be shown publicly.
ML training: bootstrapping data for churn, recommendation and segmentation models with real patterns such as seasonality, abandonment rates and goal categories.
AI agents: on-demand generation of synthetic financial datasets through MCP.
Education: unlimited datasets for data science courses with real business narrative.
Quick usage
CLI
pip install -e .
latam-synth generate --users 5000 --seed 42 --format csv --out ./outputMexico and Colombia only, 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()What makes this generator faithful
The calibration was verified against real data. See:
docs/validation_report.txtThe generator incorporates:
lognormal amount distributions by transaction type
real monthly seasonality
January post-resolutions peak and December valley
8 goal categories with their own amounts and horizons
observed achievement and abandonment rates
73.8% of goals past due
shared goals uplift
correlated user scores
Gaussian copula with ρ=0.89 for discipline-achievement
coherent temporal trajectories per goal
referential integrity between users, goals and transactions
Apify Actor
LatAm Synth is also available as a hosted Apify Actor:
active_yardstick/latam-synthActor page:
https://apify.com/active_yardstick/latam-synthThe Actor can be called directly from Apify, through the Apify API, or exposed to AI clients through the Apify MCP Server.
Example input:
{
"users": 1000,
"seed": 42,
"countries": ["Mexico", "Colombia"],
"format": "csv",
"push_to_dataset": true,
"start_date": "2023-01-01",
"end_date": "2024-12-31"
}The seed parameter makes generation reproducible. The same seed and configuration produce the same synthetic output.
Where to find your output (Apify)
Every run writes output to two places.
Key-value store — all three tables
Open the run in Apify Console and click the Storage tab.
Click Key-value store.
Download the generated files:
users.csv— one row per synthetic usergoals.csv— savings goals linked to userstransactions.csv— deposit/withdrawal transactions linked to goalsOUTPUT— always present; JSON summary of the run, including parameters, row counts and downloadable keysif
format: jsonwas selected,OUTPUT_DATAcontains all three tables in a single JSON file instead of the three CSV files
Click the download icon next to each key to save the file.
Dataset — transactions
By default (push_to_dataset: true), all transactions are also pushed to the run's Dataset.
This allows you to:
export as JSON, CSV, or Excel directly from the Dataset tab
connect native Apify integrations to the Dataset output
consume transactions programmatically
To disable this for very large runs where only the key-value-store files are needed, set:
{
"push_to_dataset": false
}The run log prints exact file names and row counts at the end of execution.
Local REST API
Install the API dependencies:
pip install -e ".[api]"
uvicorn latam_synth.api:app --port 8000Generate JSON with the three tables:
curl -s -X POST http://localhost:8000/generate \
-H "Content-Type: application/json" \
-d '{"users": 100, "seed": 42, "countries": ["Mexico", "Colombia"]}' | jq .metaExample metadata response:
{
"users": 100,
"goals": 121,
"transactions": 453
}Download transaction CSV directly:
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"
}Local REST API limits:
Rate limit: 10 requests/min per IP
Maximum: 50,000 users per request
Privacy
The generated datasets are designed for development, testing, demos, experimentation and education without requiring production PII.
Key properties:
100% synthetic records
no row is copied from a real user
no names, emails, IDs or other direct PII are reproduced from the calibration dataset
generation is based on aggregate statistical distributions
synthetic tables preserve realistic relationships between users, goals and transactions
Development
pip install -e ".[dev]"
pytestMCP registry metadata
This repository includes server.json for MCP registry discovery.
Current server identity:
io.github.jmendozapuche/latam-fintech-synthetic-dataThe registered remote MCP endpoint is:
https://mcp.apify.com?tools=active_yardstick/latam-synthChangelog
v0.2
lognormal mixture (KS=0.032)
snap to round values (69.5% on grid)
coherent temporal trajectories per goal
100% of transactions within the
[created_at, deadline]windowFastAPI API
Apify Actor
MCP exposure through the hosted 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.
Maintenance
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.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
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
- AlicenseNot gradedqualityAmaintenance62 real-time data tools for AI agents via MCP. Finance, crypto, FMCSA, sanctions, courts, weather, vehicles, cybersecurity. One bearer token, one bill. Free tier available.MIT
- 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.-