Rules, not a black box
Fraud rules are records, not code. An analyst adds one, adjusts a weight, or disables it from the console — the next transaction is evaluated against the change, with no deploy.
Risk · Fraud controlsEvery decision
Every decision
carries its reason.
A transaction is evaluated against a rule set your analysts control. The score is the sum of what matched, and every rule that contributed returns the field it read and the value it saw — so a decision can be explained, replayed, and corrected at the rule.
What a decision carries
ScoreNought to one hundred, the sum of what matched
BandLow, medium, high or critical
DecisionAllow, challenge, review, hold or block
ReasonsEvery rule that fired, with the value it read
SnapshotThe features the decision was made on
AuditA hash-chained record of the evaluation
Written once and never edited. A re-evaluation supersedes rather than overwrites.
RulesStored, tuned without a deploy
ScoreA sum you can recompute
DecisionsImmutable, and superseded
EnforcementFour modes, per domain
The outcome
The strongest answer wins.
When several rules match, the engine does not take the first, the newest or an average. It takes the most severe action any of them asked for — so adding a cautious rule can never weaken a decision another rule already reached.
- AllowNothing matched that asks for more
- ReviewQueued for an analyst to look at
- Require MFAA second factor is demanded
- HoldParked rather than refused
- BlockRefused outright
Whether the chosen action is actually applied is a separate question, answered by the enforcement mode below. In shadow, the decision is reached and recorded and nothing is applied.
The evaluation
Signal to decision.
Five stages, all of them inspectable. Nothing in this path is inferred — each step is arithmetic over values that were read from the account.
- FeaturesComputedCounts and averages read from the account’s own history.
- RulesEvaluatedEach configured rule is tested against those features.
- ScoreSummedMatched weights add up and settle into a band.
- DecisionReachedThe strongest action any matched rule asked for.
- AppliedBy modeWhat actually happens depends on the enforcement mode.
Enforcement
You decide what it may do.
Scoring and acting are separate concerns. The engine always evaluates; how much of that evaluation is allowed to touch a payment is a setting, changeable per domain at runtime.
Shadow is the default. BINK does not claim to block fraud out of the box — the engine detects and records, and a team turns enforcement on deliberately.
- Shadow
- Everything is evaluated and recorded, and nothing is applied. This is where a deployment starts, so a rule set can be tuned against real traffic before it affects a single payment. It is also the default.
- Review only
- Decisions reach the analyst queue, but no transaction is stopped. The team works real cases before the engine is given the ability to act.
- Selective
- Only the decisions you nominate are applied. A team can enforce blocks while still merely recording holds and challenges.
- Enforce
- Every decision is applied. Blocks stop the transaction, holds park it, and challenges demand a second factor.
What the engine does
Auditable by construction.
A fraud decision that cannot be defended afterwards is a liability. Everything here exists so that a decision can be reconstructed months later, exactly as it was made.
Reasons with evidence
A score is never a bare number. Each contributing rule returns its category, its severity, the field it examined and the value it actually observed.
Decisions are immutable
A decision is never edited. Re-evaluating writes a new record that supersedes the old one, so the history shows what was known at the time rather than what was concluded later.
Idempotent evaluation
A retried payment returns its original decision rather than being scored a second time — a network retry cannot talk its way into a different answer.
A real case workflow
Cases open, are assigned, investigated, escalated and resolved as confirmed or false positive, on a state machine that refuses transitions that are not permitted.
Holds you can unwind
Holds apply to a transaction, an account, a settlement, a payout or a merchant, and carry review and escalation — including partial release rather than all-or-nothing.
Operational detail
How it behaves.
- What is evaluated
- Features derived from the account itself — transaction counts over a window, the deviation of an amount from that account’s own recent average, how many cards and wallets it holds, and how old it is.
- How a score forms
- Every rule that matches contributes its weight. The total is clamped to a hundred and falls into one of four bands. There is no model and no inference — the arithmetic is inspectable.
- Terminology
- BINK does not describe this as artificial intelligence or machine learning, because it is neither. It is a deterministic rule engine, which is also why every decision can be explained exactly.
- Thresholds
- The rules are real and configurable, but the values at which they fire are not published. Naming the exact amount or frequency that trips a rule is instruction for evading it.
- Failure behaviour
- If the evaluation itself errors, the transaction is not stopped. Availability is chosen over an unproven refusal, and the failure is recorded rather than swallowed.
- Merchant checkout
- Card acceptance carries its own set of checks — duplicate and repeated-amount detection, checkout and address velocity, refund and dispute ratios — and these do stop a checkout at a sufficient score.
- Screening honesty
- Where a name cannot be screened against an authoritative source, the result is recorded as unscreened and treated as a blocker for approval, rather than being quietly passed as clear.
Integration
What this looks like to build against.
A risk layer sits directly in the path of a payment, so how it behaves when it is unsure — or unavailable — matters as much as how it behaves when it is right.
- Evaluation is synchronous
- Scoring happens before the operation proceeds, so the decision is available at the moment it matters rather than arriving afterwards.
- It will not strand you
- If evaluation itself errors, the transaction is not stopped. Availability is chosen over an unproven refusal, and the failure is recorded rather than swallowed.
- Retries are honest
- A repeated attempt returns the original decision rather than being scored again, so a network retry cannot produce a different answer to the same question.
- Reasons travel with it
- A decision carries the rules that matched and what each observed, so a support conversation about a refusal does not require a database query.
In practice
What the controls are for.
Tune against real traffic
Run in shadow while rules are adjusted, watching what would have happened before anything is allowed to act on a payment.
Escalate instead of refusing
Ask for a second factor or park a payment for review rather than declining it, so a false positive costs a delay and not a customer.
Answer a chargeback
Reconstruct the decision exactly as it was made, with the features it was made on, months after the fact.
Fix the rule, not the case
When a decision is wrong, correct the rule that caused it and have the change apply to the next transaction — no retraining, no release.
Related
Where this sits.
Fraud control is one part of a wider posture, most of which is attested rather than described.
Risk and security
Every surface.
Fraud controls
Explain any decision you make.
Rules your team owns, reasons attached to every score, and a record that survives the question asked a year later.