Review business onboarding (KYB) applications

Grayson reviews a small business's application for card processing, checks that the business is real and sells what it says, scores shell, impersonation and bust-out risk, and picks approve, approve with limits, request documents or decline.

Grayson reviews a business's application the way an underwriter would: whether it is a real, operating business applying through its own owners, whether it sells what it says under your prohibited and restricted lists, how likely the application is a shell, an impersonation or a bust-out, and whether to approve, approve with a reserve or limits, ask for documents, or decline. It reads the results your registry, TIN, identity, website, bank-link, device and earlier-application checks already return, and costs about $0.34 to $0.60 per 1,000 decisions.

  • Decides: Approve, approve with limits, request documents or decline a business applying for card processing or another business product.
  • Call it: When a business application's automated KYB checks are back
  • Questions: 1 yes/no, 2 choice, 1 score
  • Cost: $0.00034 to $0.00060 per decision ($0.34 to $0.60 per 1,000) for these examples' 9,813 to 17,045 input tokens
  • Latency: 190 to 231 ms for these examples, the median of 5 calls each through api.finic.ai from US-West

Examples

Three applications to the same payment facilitator, each with everything underwriting has at submission: the state registry record, the IRS TIN match, the owners' identity checks, a crawl of the website, reviews, the previous processor's statements, the payout account with 90 days of transactions, the form session and any links to earlier applications. They are a three-week-old LLC applying from the device that boarded a bust-out merchant, a 14-year-old HVAC contractor whose rule hits all have explanations, and a real supplement brand with an undeclared free-trial page.

Open in Playground

Open in Playground

Open in Playground

A yes/no answer is Grayson's probability that it's true. A choice answer is the top option and Grayson's confidence: 0% when every option is equally likely, 100% when one option has all the probability. A score answer is the expected level, numbering the levels in its criteria from 0, with its confidence measured the same way and, when no level reaches 70%, each level's probability. A multiple-choice answer lists the options at 50% or more.

  • decision routes the application: decline only when decline clears a high bar, and send request_documents and a close call between approve_with_limits and decline to an underwriter.
  • fraud_likelihood orders the underwriting queue: add the "Likely" and "Very likely" probabilities and sort on the sum.
  • line_of_business picks the follow-up: riskier_than_stated usually means a reserve or removing an offer before go-live, and prohibited a decline or a written commitment to stop selling it.

Call it from your code

Save an example as request.json, such as ambiguous.json, and send it with your API key in GRAYSON_API_KEY:

curl https://api.finic.ai/v1/decide \
  -H "Authorization: Bearer $GRAYSON_API_KEY" \
  -H "Content-Type: application/json" \
  --data @request.json

The problem

Fraudulent businesses pass the checks rules rely on: a Wyoming LLC with a matching EIN and a real owner verifies in minutes. What gives them away is spread across the record, such as a store built two weeks ago, policy text copied from a merchant you already closed, or a device you have seen before. Rules that flag a new domain or a payout account in a trade name also hold up good businesses for days.

What to send

Send the application with everything your checks return, with dates. The examples send 10,000 to 17,000 input tokens each.

  • The registry record and its history. Formation date, status changes, registered agent, officers and trade names show whether the entity is new, lapsed or the one the applicant names.
  • Owners' identity results. Whether each owner's name, SSN and date of birth match, how long their phone and email have existed, and other businesses they run.
  • What the website really sells. A crawl of every page, including ones not in the menus, finds pre-orders, trials and claims the application left out.
  • Processing statements. Volume, refunds, chargebacks with reason codes, reserves and why the previous processor is ending the relationship.
  • The payout account. The owner name the bank returns, when it was opened and 90 days of transactions: a real business pays suppliers, payroll and rent.
  • Device, session and links to earlier applications. A device, website text or bank account shared with a merchant you closed is often the strongest evidence you have.

Add your own policy

Which risky lines of business you accept, and on what terms, is a policy choice, so put yours in the request and Grayson applies it. This one stops boarding any merchant that runs a free or reduced-price trial that converts to recurring billing.

Your trial-offer policy adds this to the state of the ambiguous example:

{
  "trial_offer_policy": "Underwriting policy update, effective for applications received from 2026-10-01 (replaces the restricted-list entry for trials): we no longer board merchants that sell, or have run in the last 6 months, any free or reduced-price trial that converts to recurring billing, on any page, whatever the disclosure, reserve or chargeback history. Treat such an offer as prohibited and decline the application; the merchant may reapply 6 months after the offer is removed. Subscriptions without a trial (the first charge at full or discounted price, cancel anytime) stay allowed."
}
QuestionWithoutWith your trial-offer policy
real_business99% trueOver 99% true
line_of_businessriskier_than_stated, confidence 72%prohibited, confidence 30%
fraud_likelihood0.03 of 4, confidence 97%0.03 of 4, confidence 98%
decisionapprove_with_limits, confidence 68%decline, confidence 91%

In the ambiguous example, the supplement brand runs an unlinked free-trial page that converts to a $79.95 monthly plan. Under this policy that offer is grounds to decline, so the decision moves from approve_with_limits to decline and line_of_business shifts toward prohibited, while real_business and fraud_likelihood stay the same.

Where to call it

  • When automated checks finish, before an underwriter opens the application, to approve clean ones and order the rest.
  • Again when documents arrive, with the new evidence added to the same state.
  • At a merchant's first payout or a sudden jump in volume, when a bust-out starts to show.

Cost and latency

ExampleInput tokensPer decisionPer 1,000 decisionsLatency
Obvious9,813$0.00034$0.34190 ms
Legitimate15,744$0.00055$0.55230 ms
Ambiguous17,045$0.00060$0.60231 ms

You pay only for input tokens, at $0.035 per million, and each request is rounded up to the next millionth of a dollar, so a request with a larger state costs proportionally more; every response reports its size in usage.input_tokens. Latency is the median of 5 calls each through api.finic.ai from US-West, and grows with the number of input tokens. Add your own network time to api.finic.ai.

Evaluate on your own data

Score Grayson on your own past cases before you use it: a CSV with one row per case and a column with the right answer to each question. Every other column is sent as the case.

pipx install https://docs.finic.ai/downloads/grayson_cli-0.4.0-py3-none-any.whl
grayson eval my-cases.csv --questions https://docs.finic.ai/recipes/business-onboarding-kyb/questions.json --label real_business=<column> --label line_of_business=<column> --label fraud_likelihood=<column> --label decision=<column>

Each --label names the column with that question's right answer:

  • real_business: true or false
  • line_of_business: as_stated, riskier_than_stated, prohibited
  • fraud_likelihood: a level, such as "Very likely (over 90%)"
  • decision: approve, approve_with_limits, request_documents, decline

Or run grayson on its own to set up your questions step by step. You get each question's accuracy and a CSV with Grayson's answer next to yours for every case.

FAQ

Does it check the registry, the IRS or the website itself?

No. Grayson reads the results your checks return and decides; it doesn't call registries, the IRS or your website crawler. Send their results as they come back, with dates, as in the examples. The more of the record you send, the less its answers rest on any single check.

Can it catch a real business being impersonated?

Often, when the state shows what the impersonator can't copy: a phone or email that isn't the one the business has used for years, a payout account opened last week, a device far from the business, or an owner who isn't on the registry record. When those conflict with a real business's record, expect request_documents, and verify by calling the phone number the business lists publicly, not the one on the application.

How should we use it with our own prohibited and restricted lists?

Send your lists in the state, as the examples do, and send changes to them as a policy statement like the one above. Grayson judges what the business really sells against your lists, so the same application can be approved on one platform and declined on another.

On this page