Bridge
Contact us
Risk & complianceLive

Decide before anything posts.

Allow, review or block before anything posts, with case management.

Talk to us about fraud scoringAPI reference →
Illustrative
Why it matters

What it changes for you.

Most fraud tools look at payments after the money has moved, which leaves you chasing a reversal. On Bridge, every payment is scored before it posts, and the answer is one of three: allow, review or block.

Rules use what Bridge already knows: the customer's history, the device, the beneficiary, the amount and how fast things are happening. You can run a new rule in shadow first, to see what it would have caught before it touches a real payment.

Payments sent for review land in cases with an owner and an outcome, so nothing sits in a queue nobody reads.

How it works

Step by step.

  1. A payment is requested

    Before it posts, the payment and its context go to the fraud engine.

  2. Rules score it

    Your rules weigh the customer, device, beneficiary, amount and velocity, and return allow, review or block.

  3. Allow posts it

    Most payments pass straight through, with the decision recorded.

  4. Review opens a case

    The payment waits while an analyst looks, with everything that triggered the rule in front of them.

  5. Block stops it

    Nothing moves, and the customer is told in plain words.

What you can switch on

Built in, not bolted on.

Allow, review or block

Three clear outcomes on every payment, before posting.

Shadow rules

Run a rule on live traffic without acting on it, and see what it would have caught.

Case management

Every review is a case with an owner, notes and an outcome.

Device and context

Trust grades for the device and session feed the decision.

Watchlists

Accounts, devices and beneficiaries you've blocked stay blocked across products.

Velocity checks

Many small payments in a short time look different from one, and the rules can tell.

  • Every payment scored before it posts: allow, review or block
  • Cases for reviews, with owners and outcomes
  • Rules you can run in shadow first
Use cases

How businesses use it.

Illustrative businesses, not customers. Figures are made up to show the flow.

A neobank in Lagos · Fintechs & neobanks

Stop account-takeover transfers

Fraudsters who get a customer's password log in on a new phone and send everything to a new account within minutes. By the time the customer calls, the money is gone.

  1. A rule flags large transfers to new beneficiaries from new devices
  2. Those payments go to review instead of posting
  3. An analyst calls the customer before releasing
  4. Confirmed fraud blocks the beneficiary everywhere

The transfer that would have emptied the account waits for a person, and the beneficiary is blocked for everyone.

Illustrative

An agent banking network in Kaduna · Banks, MFBs & PSBs

Catch agent float abuse

A few agents split large cash-outs into many small ones to stay under limits. Each looks normal on its own.

  1. A velocity rule counts cash-outs per agent per hour
  2. Patterns above the threshold go to review
  3. Run first in shadow to tune the threshold
  4. Switch to review once the false alarms are low

The network sees the pattern, not just single transactions, and tunes the rule before it affects honest agents.

Illustrative

A marketplace in Ibadan · Marketplaces

Refund scams on a marketplace

Buyers pay, claim the item never arrived, and ask for refunds to a different account. The marketplace refunds by hand and can't see the pattern.

  1. Refunds to accounts other than the payer's go to review
  2. Repeat claimers are added to a watchlist
  3. Analysts see the buyer's history on the case

Refund fraud is caught where the money would leave, with the history to prove it.

Illustrative
Bridge Payments

Fraud checks on every Bridge Payments rail

See Bridge Payments
Who uses it

Built into these products.

Fintechs & neobanks

Launch a full money app without building the plumbing.

Fintechs & neobanks

Banks, MFBs & PSBs

Add offline payments and new products to the channels you already run.

Banks, MFBs & PSBs
For developers

Report fraud on your own account.

Endpoints in the Fraud scoring API reference, with every parameter and response.

State changes arrive as signed webhooks. How webhooks work

POST /fraud/report

curl -X POST "https://api.bridgemoni.com/fraud/report" \
  -H "Authorization: Bearer $BRIDGEMONI_TOKEN" \
  -H "X-Tenant: $BRIDGEMONI_TENANT" \
  -H "X-Environment: $BRIDGEMONI_ENV" \
  -H "Content-Type: application/json" \
  -d '{
    "caseType": "APP_FRAUD",
    "narrative": "March payroll",
    "reportChannel": "text",
    "disputedTransactionReferences": [
      "text"
    ]
  }'

Questions about fraud scoring

Does every payment wait for scoring?

Every payment is scored before it posts. Most are allowed straight away.

Can we write our own rules?

Yes, and run them in shadow first to see what they would catch before they act.

Who works the review cases?

Your team, with every factor that triggered the rule on the case.

Related capabilities

Sanctions screening

Live

Watchlists and screening on customers and payments.

Pricing engine

Live

Fees and taxes quoted before every money call.

Accounts

Live

Multi-currency customer accounts with point-in-time balances, liens and statements.

Bridge for Business

Tell us what you're building.

We'll come back with what's live for you today, and what's next.

Talk to usRead the docs