fin-risk-models: a catalogue of SQL detection rules for lending fraud

What the repository actually is: numbered directories of detection logic

fin-risk-models describes itself as open-source SQL and AI-based models for financial risk detection, fraud analytics and regulatory compliance. The structure is unusually transparent, because the top-level entries are one directory per model, each named with a date and a short slug. There is a 2025-07-29_multi-secondhand-mortgage directory, a 2025-09-05_concentrated-loan-proceeds directory, a 2025-12-12_mortgage-expiry-gap directory, a 2026-04-14_multiple-principals-same-borrower directory, and about two dozen more, running from July 2025 to October 2026. Each directory carries a README, and the repository also has a LICENSE file. There is no package manifest, no build system, no test harness and no code, which is an important thing to know before you clone it. You are not installing a library, you are reading SQL and adapting it.

The five risk domains the catalogue covers

The README groups the models into five domains, and the domain list is the best summary of what is here. Fraudulent lending behaviour is one. Anti-money laundering is another. Credit risk concentration is a third. Transaction network anomalies is a fourth. And graph-based customer relationship risk is the fifth. Every model in the repository falls under one of those headings, and the last one explains a recurring pattern in the model names, several of which look for several accounts converging on one counterparty. The catalogue is not a general fraud detection framework, it is a set of specific, named detection scenarios, and the value of the collection is the breadth of the scenarios more than any single rule being novel.

What every model directory contains

The README states what each model includes, and this list is the contract you get with every directory. Well-documented SQL logic or an algorithm. A sample use case or detection scenario. Parameters you can adjust. And an English markdown explanation, with citations optionally included. That last combination is the reason the repository is worth reading rather than just copying. A detection rule with SQL and no scenario is a query you cannot evaluate, and a scenario with no parameters is a rule that cannot be tuned to your portfolio. Several model titles also include a domain qualifier in parentheses, for example a discount financing model focused on the CRC correction category, which tells you the detection is tied to a specific regulatory classification rather than a generic behaviour.

The lending fraud models, in the order they were written

Reading the model titles as a timeline shows the detection thinking evolve. The earliest flags suspicious clusters where many borrowers share the same recipient account, described as a red flag for organised fraud. Next comes a branch-level model for personal loans where multiple loans are funneled into the same counterparty, useful for spotting fund-pooling, straw-buyer rings or collusion. Then a conflict-of-interest model that flags loans where employees act on their own loan workflows, which is an internal-control detection rather than an external fraud one. After that comes a first-year delinquency model for personal business loans, framed as a key indicator for underwriting and channel risk, and a quarter-end origination model that flags loans repaid at the start of the next quarter as potential window dressing. The catalogue then turns to structural risks: a mortgage model that flags sizable card instalments in the ninety days before interest starts, and a corporate loan model where the mortgage contract expires before the loan matures, leaving part of the loan uncovered.

Trade bills, green classification and asset quality

A large group of the models concerns trade bills, which is where the repository's banking focus shows most clearly. One matches corporate loans within a number of days before a bill maturity, for the same company, where the loan amount approximates the bill amount, and signals liquidity recycling. Another aggregates and flags abnormal corporate bill issuance against loan exposure or historical trends, and an SME version flags small and micro enterprises with abnormal bill issuance volume or ratios against exposure. A further model detects bills redeemed through third-party or bank advance payments before maturity, indicating hidden rollover risk. Two models touch asset quality and regulation. One detects enterprises whose green classification is inconsistent with their financing behaviour, especially discount flows contradicting a stated green use of funds. Another extracts and profiles non-performing-loan classified e-collateral quick loans for asset-quality monitoring, and a separate model matches corporate loan notes with abnormal provisioning changes for accounting risk review.

The later models: borrower behaviour and operational control

The 2026 entries widen the lens from transaction patterns to borrower behaviour and internal process. One identifies performing SME borrowers with external fraud, litigation or dishonesty events as early warning signals, which is the closest the catalogue comes to using outside data. One measures the time from origination to non-performing status for SME corporate loans as a time-to-default measure, pointing at underwriting or fraud risk. Another looks at SME borrowers whose pre-origination operating inflows are predominantly sourced from related enterprises, which is a business-independence and cash-flow authenticity question. Then there are the operational models, which are really about the bank rather than the customer: a review population of corporate loans with selected interest-period configurations that exposes pricing, overdue-interest, repayment and agreement-linkage fields for detecting interest collection anomalies, and a set of credit operations alerts where investigation or feedback handling exceeds the required response period, which is an SLA monitoring model. The newest entry, on potential non-compliant entrusted payments, compares contractual payment instructions against actual transfers and post-disbursement balances.

Why the SQL is a starting point rather than a drop-in

There is no install step and no dependency to pull. The repository is a licence file, a readme and a set of dated directories, and the practical workflow is to pick the directory whose scenario matches a risk you care about, read its README for the rationale and the assumptions, then rewrite the SQL against your own tables. Two things follow from the SQL and AI-based framing in the project description. The SQL is written against a lending data model, with loan contracts, branches, officers, bill maturities, repayment plans, mortgage terms and provisioning flags, and that vocabulary is specific to one kind of bank. And the catalogue is a starting point for analysts, not a validated model, because nothing in the repository states false positive rates, sample sizes or backtest results, and the parameters are documented as adjustable rather than calibrated. The Apache-2.0 licence lets you take the logic into a closed source model without attribution obligations beyond the notice, and the repository is not archived, with the last push on 2026-10-11 and the newest model dated the same day.

Editorial conclusion

fin-risk-models fits a risk team or data analyst who needs detection logic for lending fraud and credit concentration and wants to read the reasoning before running it against production data. It does not fit a team whose data model is unrelated to Chinese bank lending, because the fields, the entity types and the regulatory framing are all specific to that setting, and it does not fit anyone who needs a validated model with documented false positive rates. Verify first which table and column names your warehouse actually uses, since the SQL is written against a schema the repository does not fully specify, and read the parameter documentation in each model directory before running it on live data.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. ZhangLixin0714/fin-risk-models on GitHub