Merchant Underwriting: Each Application Decided on Its Own Packet and Test Charges

Applications that look alike and a category table that moves

Underwriting a merchant is a sequence of checks with a fixed precedence. Is this a duplicate of another application? Does screening return a hit? Is the business category allowed? Do the packet and the test charges match what the merchant says it sells? Does the category table call for a rolling reserve? The first check that fails decides the outcome, and every later check still matters once that first one clears.

Applications arrive as HubSpot tickets. Packets with registration documents, bank statements and processing history sit in Box, the merchant's test charges are visible in Stripe, and the policy, category table and draft reserve schedule are in Google Drive. When compliance sends a screening batch or risk revises the electronics table, every affected application should be re-run from the top, and that is the step that gets skipped.

Who works in the room

Nova takes anything unaddressed in the underwriting room, since most messages there are about a single application. Ryan owns allocation and the reserve schedule, so a question about who has capacity or what a reserve line says goes to it. Fin drafts every email a merchant or the verification provider will read. When Nova proposes approval for an application that needs a reserve, it mentions Ryan with the amount and the table row, and Ryan adds the line to the proposed schedule.

The underwriting week

Precedence is written into the room guidelines, so a re-run always starts from the first check, not from the one that changed.

When a duplicate turns out to be two businesses

Two applications share a director and a similar trading name, so the first pass marks the second as a duplicate. Midweek, the verification provider confirms they are separate businesses with separate bank accounts. Nova does not simply lift the duplicate flag. It runs the second application from the first check, through screening, category and reserve, and proposes a decision on its own evidence.

The electronics revision is wider. Risk raises the reserve for one band of the category table, so every electronics application is re-run under full precedence, including ones already approved. Ryan recalculates each reserve line from the new table, and any application still held at the end of the week is marked with the week it carries to, so the next queue picks it up.

What the checks catch

• A duplicate flag lifted without re-running the application through every other check
• Reserve schedule lines that were never approved, or the same merchant listed twice
• Electronics applications left on the old table because they were decided before the revision
• A reserve amount computed from the wrong band after a chargeback correction
• Held applications closed out without a note saying which week they carry to

What stays with people

• Approving every decision and every reserve line before HubSpot is updated
• Deciding what a screening hit means, together with the compliance analyst
• Sending every email to a merchant, which Fin drafts in Gmail
• Signing the closeout notes for each category

Integrations in this workflow

Kylon is not an underwriting or risk engine and it does not replace one. It works across the ticket queue, the packets and the payment data the team already has, and keeps each decision next to its evidence.

• Box
• Gmail
• Google Drive
• HubSpot
• Slack
• Stripe

• HubSpot holds the application tickets, decisions, assignments and closeout notes
• Box holds each merchant's packet with registration, bank statements and processing history
• Stripe shows the merchant's test charges and descriptors, which Nova reads as evidence only
• Gmail carries merchant correspondence and the verification provider's replies, answered through drafts a person sends
• Google Drive keeps the policy, the category table and the draft reserve schedule
• Slack is where compliance posts screening batches and underwriters flag capacity

Where to start

Run one week's queue. Connect HubSpot and the Box folder where packets land, put the category table and the reserve schedule in Drive, and write the precedence and one rule into the room guidelines: agents propose decisions and reserves, and the underwriting manager approves every one before a ticket is closed or a merchant is told.

“When a flag clears, the application goes back to the first check, not to the last decision.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.