Configuration

You set what your users are allowed to send and collect. Moov scores what looks suspicious. Those are separate controls.

Limits and groups #

Caps are per transaction, per day, per week, per month, and as a daily send count. You apply them as a provider default, then by group, then by participant override. A new account, a seasoned household, and a private-banking relationship should not share a limit.

Read and update the default policy with GET and PATCH /providers/{providerID}/limits. Create groups, add members, and set per-participant overrides. Effective limits shows what a given user actually has after group and override.

Dimensions in the API:

Dimension	What it caps
`per_transaction_amount`	One payment
`daily_amount` / `weekly_amount` / `monthly_amount`	Trailing-window velocity
`daily_send_count`	How many payments in a trailing day

An example, not a default you are stuck with:

Group	Who	Per transaction	Per day	Per month
New accounts	First 30 days	$100	$250	$1,000
Standard	Most users	$500	$1,000	$5,000
Tenured	Two years or more	$1,500	$2,500	$10,000

You define the groups, the amounts, and who lands in each. Move someone between groups as the relationship changes; the new caps take effect on the next payment.

Start a cohort low when you roll out. Raise limits when the losses you actually see support it. The fraud stack flags a payment; limits keep a flagged pattern from draining an account even if a check misses.

Limits apply to payments (money leaving the account) and to requests (how much a user can collect, and how often they can ask a stranger). You set both as program settings.

Branding #

Three surfaces carry your name:

Surface	What you control	Where
Your app	Your brand color and where the entry point appears	iOS and Android `MoovMoneyConfiguration`
Hosted page	Your name, colors, and logo	Configured with Moov for your program
Notifications	Your brand on RCS and email Moov sends to the other person	Moov sends them; you don’t stand up messaging

The SDK is not a webview of a Moov app. It’s native UI, themed to the color you pass in. On iOS you supply a single brand color and the SDK draws the rest from system semantic colors, so it adapts to light and dark on its own. On Android you supply a light and a dark palette, and the SDK follows the device’s night mode.

Statement descriptor #

On capture, the other person’s card statement shows a dynamic descriptor. You set a shortName (2–12 ASCII letters or digits) and Moov composes it with the user’s name:

ACME*JANE S

Update it with PATCH /providers/{providerID}:

curl -X PATCH "https://api.moov.money/providers/$PROVIDER_ID" \
  -u "$MOOV_API_KEY_ID:$MOOV_API_KEY_SECRET" \
  -H "Content-Type: application/json" \
  --data '{"shortName":"ACME"}'

Pick something a user of yours would recognize on someone else’s statement. A cryptic prefix is how “I don’t know this charge” disputes start.

Features you can have on #

These are program-level. They’re not flags your app toggles per session, except where the SDK is told to collect a signal.

Device intelligence. When it’s on for your institution, the SDK receives a fraud client configuration on the session and collects device signals. A rooted phone, an emulator, or taps that don’t look like a person feed the score you see on authorize. If the section is absent from the session, the SDK proceeds without it.
Contact sync. Users can sync contacts so a mistyped digit is caught before the money leaves. Matching also drives the “in your contacts” / name-mismatch copy in the payment flow.
Passkeys. Offered on the hosted page after a successful claim or payment, so the next visit is Face ID / device unlock instead of a new OTP.
Apple Pay and Google Pay. On the claim page, as disbursement (the recipient receives onto a wallet). On a pay link, as the way the other person pays. Manual debit-card entry is always available as the fallback.

What is not configurable #

A few things are fixed as part of the product, not a setting:

The other person must have an eligible US Visa or Mastercard debit (or prepaid that can receive). Credit cards can’t receive a payment.
Unclaimed payments expire after 10 days. Unpaid requests default to 30 days.
Moov messages the other person. You don’t send the claim or pay link yourself unless you choose to share it in-app as well.
Card data is captured on Moov’s page, never in your app.

Funding sources #

The accounts a user can send from are yours to enumerate. Create them on the participant with POST /providers/{providerID}/participants/{participantID}/funding-sources: a fundingType (card or bank_account), your providerSourceID, and a display name. That id is what you will see again on authorize as fundingSource; Moov treats it as opaque. The SDK reads the list off the session, so there is nothing to pass in. If they have checking and savings, you decide which appear and what they’re called.

Creation is idempotent on (participant, fundingType, providerSourceID). Update display metadata with PATCH; remove a source with DELETE.