Compliance by design in payment systems: a policy engine for onboarding, payments and payouts

1Context and motivation

A payment platform operating across several jurisdictions answers the same few questions constantly. May this party be onboarded? May this payment go through? May this payout leave for this bank in this country? In many stacks the answers live in different places: a vendor tool for identity checks, a separate monitor for suspicious activity, hand-written conditions in the payout service, and spreadsheets that analysts consult during review. When rules sit in several places, flows that should behave alike can diverge, teams learn about constraints late, and reconstructing a decision means reading logs from several systems.

The research literature on business process compliance treats this as a design problem rather than an operational one. Control objectives that come from regulation and standards often conflict with the objectives that drive process design, and a systematic approach models those control objectives formally and propagates them onto the process models themselves¹. Compliance can then be stated as a property of execution traces: a process is compliant when its traces satisfy the obligations that apply to it, and obligations come in distinct types with distinct semantics².

We take that view into payment infrastructure. This paper describes a policy engine that holds compliance rules as versioned, testable code over a shared data model, and a decision service that onboarding, payment and payout flows call before they act. We describe the design and the reasons for each part. We do not report its effects, because we have not measured them, and nothing here is legal advice for any jurisdiction.

2Design principles

The design follows six principles.

• Rules are data, not scattered conditions. Each rule is a declarative statement over named entities and attributes, held in one repository, reviewed like code and versioned.
• Obligations have types. A rule states whether it forbids, requires before, or requires within a period, so that compliance can be checked against execution traces rather than read off documentation².
• Constraints are designed in, not added afterwards. Work on safety in complex, software-intensive systems argues that chains of failure events are an inadequate model of how accidents happen, and builds safety into hazard analysis and system design from a systems-theoretic model instead³. We treat a compliance breach the same way: as a hazard the design of each flow has to address, not a defect to be caught after release.
• Learned models rank; rules decide. Models may score, prioritise and propose. They do not override a hard rule.
• Every decision is explainable to the party it affects. A decision returns its outcome, the rules that produced it, and what would have to change for a different outcome.
• Collect and keep only what a rule needs. Data minimisation is a design input, not a later review.

3Architecture

The design has six parts.

3.1Policy model

A shared model names the entities rules talk about (party, merchant, account, transaction, payout, jurisdiction, licence) with their attributes (country, risk tier, verification status, activity type) and relations (a merchant operates in a region, a transaction moves funds from one account to another). Every rule refers to this model, so a rule about payouts and a rule about onboarding use the same definition of, for example, a verified merchant.

3.2Policy as code

Rules are written in a declarative language over the policy model. Illustrative forms are: a transfer from jurisdiction A to jurisdiction B above an amount T requires enhanced checks; a product feature is available only to merchants whose business verification is complete and who hold licence L in region R; customer funds may not be held longer than N days without payout in jurisdiction J. Rules are layered: a global base set, with a regional overlay for each jurisdiction and a product overlay where a product carries its own obligations. Each rule has an owner, a citation to the source text it implements, tests, and a version.

Rules as code can be checked before release. Engineers working on large production distributed systems have used formal specification in TLA+ to keep serious but subtle design bugs from reaching production⁴. We use the same idea at smaller scale: the rule set is checked for contradictions (two rules that require and forbid the same action for the same case) and for gaps (a case no rule covers) before a new version is deployed.

3.3Decision service

The decision service answers a single question for each request: is this action permitted here, and on what conditions. Its response has three parts: an outcome (allow, deny, allow after a named step, refer to review), the identifiers and versions of the rules that produced it, and the actions required next. Onboarding, payment and payout flows call it synchronously where the action cannot be undone, such as releasing a payout, and asynchronously where a later control can catch the case, such as periodic review of an active merchant.

3.4Detection and prioritisation

Some obligations cannot be met by deterministic rules alone. Suspicious activity has to be detected in transaction patterns, and statistical and machine-learning methods have been applied to fraud and money laundering detection for decades, partly because fraudsters adapt to whatever prevention is in place⁵. Surveys of machine learning for suspicious transaction detection group the methods into typology matching, link analysis, behavioural modelling, risk scoring and anomaly detection⁶. Graph models of payment flows between accounts have been explored too, though on one public labelled data set a random forest outperformed graph convolutional networks⁷.

In our design these models produce scores and rankings, not decisions. Their role is to order the review queue so that analysts see the cases most likely to matter first. That role follows from a constraint documented in fraud detection: only a small share of transactions can be checked by investigators in time, the labels that come back are delayed and partial, and the data drift as behaviour changes⁸. A model that ranks within that capacity is useful; a model that silently clears cases is not, because the cases it clears never receive a label.

3.5Integration with payment flows

Every flow that moves money or changes a party's status calls the decision service before it acts. Where a rule requires a step (an extra verification, a hold, a report), the flow receives that step as part of the response and cannot proceed without completing it. Some rules are marked as not overridable by any score or operator, for example a match against a sanctions list.

3.6Audit record

Each call writes a record with the request, the policy version, the rules evaluated, the outcome and the reviewer if one acted. A new policy version first runs in shadow, evaluating live requests without acting on them, so the difference between the old and new outcomes can be reviewed before the switch.

Table 1 summarises the components, the problem each addresses and the published work each rests on.

Component	Problem it addresses	Evidence
Formal model of control objectives	Regulatory controls conflict with process goals and are applied unevenly	1
Typed obligations checked on traces	Compliance cannot be verified from documentation alone	2
Compliance treated as a design hazard	Controls added after release miss how failures arise	3
Pre-release checks of the rule set	Contradictory or missing rules found only in production	4
Minimise, separate and demonstrate in data handling	Identity and transaction data collected beyond need	9
Learned ranking of review queues	Investigator capacity covers only a fraction of cases; labels arrive late	8, 6
Interpretable models for high-impact scores	Black boxes explained after the fact in high-stakes decisions	10
Counterfactual reasons in decisions	Affected parties cannot see what would change the outcome	11
Error-rate parity checks across groups	Learned rules inherit historical exclusion	12, 13

Source: our design, with the works cited in the table.

4A worked review queue model

The value of ranking depends on review capacity. Table 2 is a worked model with hypothetical inputs, to show the arithmetic a deployment would need to fill in with measured values.

Quantity	Value	Kind
Alerts raised per day	2,000	Input (hypothetical)
Analysts on shift	10	Input (hypothetical)
Minutes per review	15	Input (hypothetical)
Review minutes per analyst per day	360	Input (hypothetical)
Reviews possible per day	240	Computed: 10 × 360 / 15
Share of alerts reviewed the same day	12%	Computed: 240 / 2,000
Alerts left for later or never reviewed	1,760	Computed: 2,000 minus 240

Source: Worked model; inputs in the table.

Under these inputs, the order in which alerts are reviewed decides which 12% receive attention that day. If alerts are reviewed in arrival order, the reviewed set is a sample of whatever arrived first. If they are ranked by a model, the reviewed set is concentrated where the model places risk, and the cases it ranks low may never be labelled, which biases the next training round toward what was reviewed. The design therefore reserves a small random share of review capacity for unranked alerts, so that the model's errors in the low-scored tail can be seen. The size of that share is a parameter we leave open.

5Explanation and fairness

When a party is refused onboarding or a payout is held, the decision affects their access to money. For decisions of that weight, we prefer models that are interpretable by construction over black-box models explained after the fact, because trying to explain a black box after the fact, rather than using a model that is interpretable in the first place, can perpetuate bad practice in high-stakes settings¹⁰. Where a learned score feeds a decision, the decision service reports a counterfactual reason: the smallest change in the inputs that would have changed the outcome. Explanations of this kind can tell an affected person why a decision was reached, give grounds to contest it, and say what would need to change for a different result, without opening the black box¹¹.

Compliance controls can exclude people as well as protect them. Data-mining methods trained on historical decisions can reproduce earlier patterns of exclusion without anyone intending it, and the resulting discrimination is hard to locate¹². Anti-money laundering controls themselves carry costs and can drive financial exclusion for people at the socioeconomic and international margins⁷. The design monitors error rates by group: where a protected attribute is available for audit, false positive and true positive rates are compared across groups, following the equalised odds criterion, which asks that a predictor's error rates not depend on group membership given the true outcome¹³. A gap above a set threshold sends the responsible rule or model to review. The protected attribute is used for this audit only, not as a decision input.

6Data protection

Identity documents, business records and transaction histories are sensitive, and a compliance system collects more of them than most parts of a platform. We apply the eight privacy design strategies (minimise, hide, separate, aggregate, inform, control, enforce, demonstrate) as a checklist during rule design⁹. In practice that means each rule declares the attributes it reads; attributes no rule reads are not collected; identity data are stored apart from transaction data and joined only inside the decision service; and the audit record is the means by which the platform demonstrates which data were used for which decision.

7Illustrative scenarios

The scenarios below are hypothetical. They show how the parts would interact; they are not results.

A new payment method in one region. A team adding an account-to-account method in one region would query the decision service for the rules that apply to that method and region before building. The regional overlay would supply the authentication and verification steps; the base set would supply sanctions and reporting rules. Shadow mode would show how many live requests the new rules would refer to review before any customer saw the change.

Cross-border payouts. A payout to a corridor with its own licensing limits would be checked against the corridor's overlay. If the merchant's licence did not cover the corridor, the response would deny the payout and name the missing licence, rather than leaving the payout service to fail on a hard-coded condition.

Whether the design reduces breaches, review volume or time to launch is for a measured pilot to show.

8Evaluation protocol

Before any outcome could be claimed, a deployment would need to measure, against a period or a set of flows without the engine: the number of breaches found after the fact, per thousand decisions; review queue volume and the share of reviewed alerts that lead to action; time from a change in a source rule to a deployed policy version; the time needed to answer an audit question about a past decision; and error-rate gaps across groups. We have no baselines to report.

9Limitations

• No measurements. We have not measured the effect of this design on any outcome. Every benefit implied here is a hypothesis.
• Translation from law to code. Rules encode an interpretation of legal text. The interpretation can be wrong, and a formally consistent rule set can still be an incorrect reading of the law. Legal review of each rule remains necessary.
• Coverage. Typed obligations and trace checks cover rules that can be stated over observable events. Obligations that depend on judgement (for example, whether a business is what it says it is) remain with people.
• Label feedback. Ranking models learn mainly from reviewed cases, so their errors on unreviewed cases are hard to see. The random review share in the worked model mitigates this; it does not remove it.
• Fairness audit data. Error-rate parity checks need protected attributes, which a platform often does not hold and may not be allowed to collect. Where they are absent, the audit cannot be run as described.
• Regulatory change. Rules change, sometimes faster than they can be encoded and tested. The design makes change traceable; it does not make it fast.
• Concentration risk. A single decision service is a single point of failure; it needs regional isolation and a defined behaviour when unavailable.

10Conclusion

We have described a design that holds payment compliance rules as typed, versioned policy over a shared model, checks the rule set before release, and calls one decision service from every flow that moves money or changes a party's status. Learned models rank review work within known capacity limits and never override hard rules; decisions carry their reasons; error rates are audited across groups; and data collection follows the rules that need it. Each part rests on published work, summarised in Table 1. What the design lacks is evidence of its own effect. The next step is a pilot on one flow, payouts in a single region, measured with the protocol above.