Worked dataset assertion
Records synthetic_001 and synthetic_002 carry the same operation and event IDs. Importing both should make one credit. synthetic_003 is a timeout, so the test should query status rather than assume failure. synthetic_004 has an amount mismatch and should open an exception. synthetic_005 is a late virtual account arrival and should check assignment history. All names, IDs, amounts, and outcomes are invented. The data tests software behavior; it cannot support a claim about how often Nigerian payments fail.
Use the data without confusion
The sample has sixteen invented rows across transfer, USSD, POS, virtual account, payroll, savings, and loan cases. The records exercise different paths and state transitions, not real fraud rates.
Checks to run
- Use the records to test deduplication, reconciliation, and exception handling.
- Keep these invented IDs and amounts out of production logs and reports.
- When adding cases, label the source synthetic and document the expected result.
Expected assertions
The first two rows share an operation and event ID. They should produce one credit. The USSD timeout needs a status query. The POS mismatch and late virtual account event need review. These assertions give researchers a clear baseline when testing a ledger pipeline.
The CC0 license file travels with the CSV. Anyone can extend it, but should mark new rows as synthetic and avoid real-looking identity values. Do not use the dataset to estimate fraud rates.
Run a concrete assertion
Load the CSV into a test database, not production. For each synthetic payment intent, group rows by operation_id and compare committed effect counts with expected_total_effect_count exactly. Then run a query for impossible order: final success followed by a new pending state. Treat the file as test input, not proof of real Nigerian fraud rates. To extend it, create a new version, preserve column meanings, add a case ID and expected outcome, and record the generator seed. The included CC0 license allows reuse without required attribution.
For dataset revision 1.1, check the linked fixture guide before import; it defines opening state, expected total effects, amount checks, and each scenario. field guide and calculation rules.
Assert the supplied state and effect counts
Group rows by operation_id, which is the CSV’s actual key. Before each independent case, create the fixture state named by prior_effect_count; for a sequential redelivery case, retain the prior successful effect. Compare the actual committed effect count with expected_total_effect_count exactly. At most one is too weak for a success row because zero would pass. Compare resulting state with expected_state too: the timeout stays unresolved, the amount mismatch enters review, and the confirmed success stays confirmed on redelivery. The file has no reversal rows. Add a versioned reversal case with a linked original before asserting reversal behavior. Record expected and observed amounts separately.
Primary sources
Download 16-row synthetic fixture.
Next step
Import the synthetic CSV into a test ledger and check the five expected outcomes without real customer records. Read the related guide. For a review of your own system, request a security review.