navk8690/paymind-reference-data-v2

PayMind Synthetic Payment Dataset — V4

Synthetic payment-routing data for developing, training and benchmarking PayMind.

This dataset provides the V4 synthetic training environment for PayMind, an open-source payment intelligence connector.

It is designed for three predictive responsibilities:

The dataset is fully synthetic.

It does not contain real customer transactions, proprietary gateway performance data, personal information, cardholder data, or production payment records.

Important: Synthetic provider behaviour in this dataset must not be interpreted as the real-world performance of any payment provider.

Dataset Overview

Why This Dataset Exists

Payment routing is a difficult open-source ML problem because useful production datasets are generally private.

Real payment histories can contain commercially sensitive information and may include:

• —transaction information;
• —provider performance;
• —approval behaviour;
• —geographic patterns;
• —commercial relationships;
• —settlement characteristics;
• —internal routing decisions.

Publishing such data is usually inappropriate.

PayMind therefore uses a synthetic payment environment for its public reference implementation.

The goal is not to reproduce a specific company's payment history.

The goal is to provide a sufficiently structured environment for developing and testing:

route selection
      +
success prediction
      +
settlement prediction
      +
multi-model inference
      +
payment-route ranking

V4 Design

V4 was created after earlier synthetic iterations revealed that several important relationships were either too weak, too imbalanced, or difficult for the models to learn.

The V4 environment places greater emphasis on:

• —balanced deposits and withdrawals;
• —balanced success and failure behaviour;
• —broader geographic variation;
• —broader currency/country combinations;
• —meaningful amount-band behaviour;
• —success/failure variation across both low and high amounts;
• —more instant and near-instant settlement;
• —structured slower-tail settlement conditions;
• —learnable route suitability;
• —meaningful reliability differences;
• —stronger settlement-time signal.

The intention is to create a useful synthetic ML environment, not artificially perfect model performance.

Dataset Structure

The dataset is separated by predictive responsibility.

A typical repository layout is:

training/
├── payment_method.csv
├── success.csv
└── arrival.csv

benchmark/
├── payment_method.csv
├── success.csv
└── arrival.csv

README.md

The exact directory structure may vary slightly between releases.

1. Candidate Generator Dataset

The candidate dataset supports PayMind's Candidate Generator.

Its objective is to learn:

Given this transaction context, which payment route is most relevant?

The target is a payment-route/payment-method class.

Typical contextual features include information such as:

transaction type
currency
amount
country / geographic context
hour
day of week
weekend status
cross-border status
application / channel context

The model learns a multiclass probability distribution across candidate routes.

Conceptually:

Transaction
    │
    ▼
Candidate Generator
    │
    ├── Route A    0.31
    ├── Route B    0.24
    ├── Route C    0.18
    └── ...

Candidate probability represents route relevance, not PayMind's final routing recommendation.

Candidate Evaluation

Candidate models can be evaluated using metrics such as:

The frozen V4 CatBoost reference model achieved:

These results are provided only as a reference for the PayMind V4 synthetic environment.

2. Reliability Dataset

The reliability dataset supports the Reliability Engine.

Its objective is to estimate:

How likely is this transaction to succeed through this payment route?

This is a binary classification / probability-prediction problem.

Conceptually:

Transaction
    +
Candidate Route
    │
    ▼
Reliability Engine
    │
    ▼
P(success)

The V4 environment intentionally contains success and failure outcomes across different transaction contexts.

Success behaviour is not intended to be determined simply by whether an amount is high or low.

Instead, synthetic reliability can vary through combinations of factors such as:

• —transaction type;
• —amount;
• —route;
• —geography;
• —currency;
• —cross-border context;
• —time context;
• —other synthetic interaction effects.

Reliability Evaluation

Typical metrics include:

V4 reference ROC-AUC:

The similar performance across three different boosting implementations suggests that V4 contains learnable synthetic reliability structure rather than signal available only to one model family.

3. Settlement Dataset

The settlement dataset supports Settlement Intelligence.

Its objective is to learn transaction arrival/settlement behaviour.

PayMind models:

• —P50 settlement
• —P90 settlement

rather than relying on a single average settlement time.

P50

P50 represents approximately the median expected settlement time.

For example:

P50 = 3 minutes

represents a prediction of typical settlement behaviour.

P90

P90 provides a more conservative view of slower-tail settlement.

For example:

P50 = 3 min
P90 = 40 min

describes a transaction that is usually fast but has meaningful slower-tail risk.

That distinction is important for payment-routing systems where settlement speed matters.

Speed-First V4 Environment

Settlement behaviour was an important focus of V4.

The synthetic environment contains significantly more:

• —instant settlement;
• —near-instant settlement;
• —fast electronic settlement.

At the same time, settlement is not uniformly instant.

Structured slower-tail conditions remain so that the models can learn meaningful differences.

Synthetic tail behaviour can be associated with combinations involving:

• —cross-border activity;
• —withdrawals;
• —higher-value transactions;
• —weekends;
• —banking-hour effects;
• —bank-transfer-style routes;
• —geographic/corridor context;
• —route-specific synthetic behaviour.

These relationships are generated for ML development.

They do not represent measured behaviour from real payment providers.

Settlement Evaluation

The V4 CatBoost reference baseline achieved:

Coverage is a calibration target.

For P90, a result close to 90% is generally more meaningful than simply maximizing the percentage.

Training Data vs Canonical Benchmark

PayMind intentionally separates training data from the canonical benchmark.

Synthetic Environment V4
        │
        ├──────── Training
        │           │
        │           ▼
        │       Model fitting
        │
        └──────── Canonical Benchmark v1
                    │
                    ▼
               Model evaluation

The training environment contains:

200,000 synthetic transactions

Canonical Benchmark v1 contains:

50,000 separate synthetic transactions

The benchmark should not be used for model fitting.

Why the Benchmark Is Frozen

A fixed benchmark makes model experiments comparable.

Suppose both the model and evaluation data change:

new model
    +
new benchmark
    =
unclear source of improvement

Instead, PayMind V4 establishes:

Synthetic Environment V4
Canonical Benchmark v1

as a frozen reference foundation.

Future experiments can then change:

• —hyperparameters;
• —CatBoost configuration;
• —LightGBM configuration;
• —XGBoost configuration;
• —calibration;
• —ensemble weights;
• —inference strategy;

while continuing to evaluate against the same benchmark.

A benchmark reset should be an explicit versioned project decision.

Multi-Model Development

The dataset is designed to support multiple model families.

PayMind currently evaluates:

Using multiple implementations makes it possible to investigate whether different models learn complementary aspects of the same synthetic environment.

Future ensemble experiments can conceptually evaluate:

ensemble =
    w_cb × CatBoost
  + w_lgbm × LightGBM
  + w_xgb × XGBoost

where the weights are selected using fixed-benchmark evidence.

What Is Not Learned From This Dataset

PayMind deliberately separates predictive modelling from decision policy.

The dataset trains models to estimate:

route relevance
success probability
settlement behaviour

It does not establish universal answers for:

how important speed should be
how important fees should be
how important reliability should be
which industry should prioritize which signal

Those belong to PayMind's Ranking Engine.

This allows future work to develop policies for environments such as:

• —trading / brokerage;
• —e-commerce;
• —remittance;
• —marketplaces;
• —general payments;

without changing the frozen V4 predictive foundation.

Fee Data

PayMind's Fee Engine is deterministic.

Fees are configuration-driven rather than learned as an ML target from this synthetic dataset.

This is intentional.

Commercial fee assumptions should remain explicit, inspectable and replaceable.

Example Usage

The CSVs can be loaded using standard Python tooling.

import pandas as pd

candidate = pd.read_csv("training/payment_method.csv")
reliability = pd.read_csv("training/success.csv")
settlement = pd.read_csv("training/arrival.csv")

print(candidate.shape)
print(reliability.shape)
print(settlement.shape)

For the complete training workflow, use the PayMind project rather than training directly from this dataset card.

PayMind Training Pipeline

The PayMind repository provides a local training pipeline covering stages such as:

input inspection
      ↓
cleaning
      ↓
chronological splitting
      ↓
class-policy checks
      ↓
feature validation
      ↓
Candidate training
      ↓
Reliability training
      ↓
Settlement P50/P90 training
      ↓
multi-model training
      ↓
evaluation

The reference architecture supports CatBoost, LightGBM and XGBoost model members.

Intended Uses

This dataset is intended for:

• —PayMind development;
• —payment-routing ML experimentation;
• —tabular classification research;
• —settlement prediction experiments;
• —multi-model comparison;
• —ensemble research;
• —ranking-system development;
• —synthetic-data experimentation;
• —benchmarking;
• —education;
• —reproducible open-source development.

Out-of-Scope Uses

This dataset should not be used as evidence of:

• —actual payment-provider performance;
• —real gateway success rates;
• —real settlement SLAs;
• —real provider fees;
• —actual provider geographic performance;
• —real payment-method approval rates;
• —commercial provider comparisons;
• —production financial risk.

It should also not be treated as a substitute for production training and validation data.

Synthetic Data Disclaimer

Every transaction in this dataset is synthetic.

The dataset does not represent actual customer transaction history.

Synthetic provider/payment-method classes may be used to make the PayMind demonstration understandable, but generated behaviour must not be interpreted as factual information about those providers.

The dataset does not establish real:

approval rates
failure rates
settlement times
fees
limits
availability
regional performance
commercial relationships

for any provider.

Privacy

The public dataset is designed to avoid distributing:

• —real customer transaction history;
• —cardholder data;
• —personal information;
• —production payment records;
• —API credentials;
• —authentication secrets;
• —proprietary commercial datasets.

Users creating their own PayMind datasets remain responsible for appropriate privacy, security, data-governance and regulatory controls.

Limitations

Synthetic environment

The dataset reflects generated rules rather than observed production payment behaviour.

Distribution shift

Real payment environments may differ significantly from V4.

Simplified relationships

Production payment systems can contain interactions and operational constraints that are not represented by a synthetic generator.

Provider evolution

Real payment-provider performance and commercial terms change over time.

Benchmark scope

Canonical Benchmark v1 is a PayMind synthetic benchmark, not an industry benchmark.

Reference metrics

Published V4 model metrics describe performance only within this synthetic environment.

Versioning

The current foundation is:

Future changes should distinguish between:

data-generation changes
model changes
benchmark changes
ranking-policy changes

so improvements remain attributable and reproducible.

Related PayMind Components

The wider PayMind project includes:

• —Python SDK;
• —FastAPI service;
• —Gradio demo;
• —Candidate Generator;
• —Reliability Engine;
• —Settlement Intelligence;
• —Eligibility Engine;
• —Fee Engine;
• —Ranking Engine;
• —Model Registry;
• —CatBoost models;
• —LightGBM models;
• —XGBoost models;
• —multi-model inference;
• —local training pipeline;
• —benchmark/run comparison tooling.

The reference models should be published separately from this dataset so the project maintains a clear distinction between:

Code       → PayMind repository
Data       → PayMind synthetic dataset
Models     → PayMind reference model repository
Demo       → PayMind Hugging Face Space

License

This dataset is released under the GNU General Public License v3.0 (GPL-3.0), subject to the repository's license terms.

PayMind

PayMind is an open-source payment intelligence connector — not a payment gateway.

This dataset exists to make payment-routing ML development reproducible without publishing production transaction data.

V4 is synthetic. Canonical Benchmark v1 is synthetic. Published model metrics are synthetic benchmark results.