Skip to content

fix(typologies): keep fraud rings on disjoint account ranges#14

Open
akhilesharora wants to merge 1 commit into
SantanderAI:mainfrom
akhilesharora:fix/disjoint-fraud-rings
Open

fix(typologies): keep fraud rings on disjoint account ranges#14
akhilesharora wants to merge 1 commit into
SantanderAI:mainfrom
akhilesharora:fix/disjoint-fraud-rings

Conversation

@akhilesharora

Copy link
Copy Markdown

Summary

Fraud rings were placed on contiguous account ranges with no check against accounts already used by earlier rings, so ranges overlapped and rings that share an account merge into one non-cycle component with ambiguous per-ring labels. This tracks the accounts used so far and retries until a ring's range is disjoint; if no disjoint range is left it stops adding rings rather than emitting an overlapping one.

Type of change

  • feat - new feature
  • fix - bug fix
  • docs - documentation only
  • test - adding or updating tests
  • refactor - code refactoring (no feature/fix)
  • ci - CI/CD changes
  • chore - maintenance

Linked issues

Closes #13

Checklist

  • Commit messages follow Conventional Commits
  • Tests added or updated (pytest tests/ -v --cov=gen_fraud_graph)
  • Coverage stays at or above 80%
  • Lint/format/type pass locally (ruff check . && black --check . && mypy src/)
  • Documentation updated (README, CHANGELOG, docstrings) if behaviour changed
  • I have signed the CLA (the bot will prompt me if not)
  • I agree to follow the project's Code of Conduct

ruff check and black --check pass on the changed files; the new test brings the suite to 43 passed at 98.33% coverage. mypy could not run in my environment (the installed numpy stubs use 3.12+ type syntax that the local mypy rejected under Python 3.14); it is unaffected by this change and runs in CI. CHANGELOG updated; no README change needed (behaviour-only). CLA: I will sign when the bot prompts.

Notes for reviewers

  • Behaviour nuance: if more rings are requested than fit disjointly in the account space, the generator now stops early (emits fewer rings) instead of overlapping. At the documented scales this never triggers (e.g. 50 rings of depth 4-7 need a few hundred accounts out of thousands).
  • The tiny max_account_id < depth + 1 fallback (single ring at the smallest scales) is unchanged.
  • New test test_rings_use_disjoint_accounts asserts disjoint involved_accounts; it fails on the pre-fix code and passes after.

@akhilesharora akhilesharora requested a review from a team as a code owner June 23, 2026 13:51
@github-actions

github-actions Bot commented Jun 23, 2026

Copy link
Copy Markdown

All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.

@akhilesharora

Copy link
Copy Markdown
Author

I have read the CLA Document and I hereby sign the CLA

Each fraud ring picked a contiguous account block without excluding accounts
used by earlier rings, so two rings could share accounts: they merged into one
non-cycle component and their involved_accounts labels overlapped.

Draw all the accounts the rings need up front from one pool of distinct ids,
then hand each ring its own slice. Raise when the rings need more accounts than
exist instead of silently emitting fewer, which also drops the old fallback
that referenced accounts past num_accounts at tiny scale.
@akhilesharora akhilesharora force-pushed the fix/disjoint-fraud-rings branch from bb89ca2 to 2fd4aad Compare June 24, 2026 15:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug]: fraud rings can share accounts, breaking the disjoint-cycle labels

1 participant