Control seller releases without losing reserve, return, or ledger state.
Connect processor events, bank returns, ledger reserves, payout approvals, and exception ownership before seller funds leave.
Review marketplace flowFinance operations infrastructure
RunFin
Control payment operations from request to close.
State, evidence, ownership, and close context stay attached to every money movement.
Payout releaseReady
ScopedApprovedMatched
Review fitHigh signal
Qualified operating review
Worth a call when payment work becomes control work.
Bring one live payout, settlement, balance, or close path and the evidence already slowing the team down.
Release riskApprover, rail, reserve, bank proof.
State ambiguityOwner, account, and movement state.
Proof packetState path, close inputs, launch gates.
01Policy-aware initiation
Payment requests carry the entity, rail, counterparty, and approval evidence needed for review.
02Ledger-first state
Expected, pending, settled, failed, and reversed events stay connected to the same movement record.
03Exception ownership
Finance, product, and support teams work from one queue with clear severity and resolution trails.
Implementation blueprint
Map the operating file before build work starts
Use the first review to turn a live payment path into artifacts finance, product, and implementation owners can approve together.
01 InputsAccounts, rails, systems, files, owners, and current exceptions.
02 State modelDraft, approved, released, settled, failed, reversed, and matched paths.
03 Control designApproval policy, evidence fields, access boundary, and exception queue.
04 Launch packetIntegration contract, rollback route, close criteria, and first surface.
Account readinessCommercial wallet
Bank package82%
Review needed
Two owners missing approval policy and signatory evidence.
evt_4312approved$124,000
The problem
Teams grow faster than their finance workflows.
Bank onboarding, payment review, exception handling, and ledger updates often live in separate tools. RunFin gives operations teams a shared source of truth before volume turns into cleanup work.
- Route payments by rail, account, entity, and policy.
- Keep approval evidence attached to every movement.
- Reconcile settlement, bank activity, and ledger state daily.
The solution
Launch with controls already wired in.
Start with a pragmatic operating model: account inventory, approval paths, transaction state, and exception queues. Add direct bank or payment provider integrations as the business matures.
Map your workflowpayment.createledger.postreconcile.match
{
"entity": "us-marketplace",
"rail": "ach",
"amount": 48000,
"approval_policy": "dual-control",
"ledger_event": "seller_payout"
}Control plane
Operational state that finance and product can both trust.
Account inventoryCounterparty profilePayment orderApproval policyLedger eventReconciliation match
Solution workflows
Operating models for teams moving customer money
RunFin is most useful when finance has to explain ownership, release policy, rail state, and close evidence across more than one system.
Workflow fitStart with the path where release, balance, and close evidence break apart.
Each review maps the operating model, systems involved, control pressure, and first artifact a team can approve before implementation work expands.
Map your operating modelMarketplacesSeller payouts, reserve release, bank returns, and processor settlement.Reserve and return exposure
SaaS platformsBilling collections, refunds, vendor payouts, cash application, and revenue close.Collection and refund ownership
Lending operationsLoan disbursements, repayment files, investor waterfalls, and borrower exceptions.Funding and repayment traceability
Payroll and freightBatch releases, prefunding, contractor settlement, remittance files, and returns.Batch approval and prefund risk
Keep billing, refunds, vendor payouts, and cash application in one evidence path.
Give revenue, finance operations, and product teams one record for collection state, refund approval, bank activity, and close inputs.
Map SaaS money flowsTrace funding, repayment, servicing, and investor movement from one state model.
Document disbursement approval, repayment files, bank activity, investor waterfall logic, and borrower exception queues before scale.
Review lending workflowSeparate batch approval, prefunding, settlement, remittance, and return review.
Make batch release, account funding, bank confirmation, contractor remittance, and exception ownership visible before cutoff pressure hits.
Review batch releaseBefore releaseValidate account, rail, counterparty, limits, and approval evidence.
During movementTrack initiated, approved, released, settled, failed, and reversed states.
Before closeMatch bank activity, processor events, settlement files, and ledger posts.
RunFin modules
Clean operating surfaces for money movement teams
Payment release, treasury review, exception ownership, and close evidence without operational sprawl.
ReleaseApproval state
TreasuryBalance owners
ExceptionsOwned queues
CloseMatched evidence
Account control
Ownership, limits, rail eligibility, and review history in one account record.
Owner matrixRail limitsReview cadence
Map account structureSettlement orchestration
Approval, release, bank confirmation, and ledger posting on one movement path.
Release policyBank fileLedger reserve
Review settlement pathsTreasury workspace
Balances, pending releases, owners, and API events in one clean workspace.
Balance ownersHeld releasesAPI event trail
Design the workspaceException command center
Move failed payments, stale settlements, missing remittance data, and unusual counterparties into owned queues with evidence attached.
SLA ownerSeverityEvidence trail
Structure exception reviewReconciliation engine
Compare expected settlement, bank activity, processor events, and ledger entries before unresolved differences become month-end work.
Match ruleSource registerClose export
Review matching logicAPI surface
Implementation contracts finance teams can read
Model accounts, counterparties, movements, approvals, ledger events, and reconciliation matches in a schema your finance and product teams can both understand.
Movement stateApproval evidenceLedger eventBank activityMatch ruleException owner
Contract reviewState model, evidence fields, source systems, and owners before build work.
Access boundaryRead-only files and sample events first; controlled write paths require launch approval.
Review outputEndpoint map, field inventory, exception ownership, and first integration backlog.
API previewmovement
Start postureSample data and read-only events before production access.
Evidence contractState, requester, approver, rail, ledger, and bank inputs stay attached.
Operating ownerEvery movement names the team responsible for exception review.
POST /v1/movements
{
"entity": "marketplace_us",
"source_account": "operating_cash",
"destination_account": "seller_wallet",
"counterparty": "cp_8Kf91",
"amount": 48210,
"currency": "USD",
"policy": "marketplace_payout",
"controls": [
"dual_approval",
"balance_check",
"ledger_reserve"
]
}State pathdraft -> approved -> released -> matched
Evidencerequester, approver, limit, rail, memo
Close inputsbank line, processor event, ledger post
Exception ownertreasury_ops
validatedapprovedreleasedsettledmatched
Operating assurance
Built for teams that have to explain every dollar
RunFin is designed around traceability, ownership, and daily close discipline so payment operations can scale without creating a second reconciliation project.
Approvals stay attached
Every release keeps the policy, requester, approver, rail choice, counterparty, and supporting context with the movement record.
Limits are visible before funds move
Teams can see account ownership, payment thresholds, review paths, and unresolved exceptions before production volume increases.
Daily matching becomes measurable
Expected settlement, bank activity, processor files, and ledger posts share one state model for faster close and cleaner escalation.
Control environment
Designed to fit the reviews finance teams already run
RunFin should make diligence easier, not create another black box. The operating model is organized around access boundaries, approval evidence, integration scope, and exportable review artifacts.
Least-privilege accessSegregation of dutiesRead-only first integrationsExportable audit evidence
Public deliveryCloudflare Pages and strict security headers.
Script postureSelf-hosted assets; no third-party scripts.
First reviewNo production credentials or write access.
Review surfaceEvidence-ready
Access modelRoles scoped by entity, account, rail, and workflow.Mapped
Approval trailRequester, approver, policy, limit, and release context stay attached.Traceable
Integration boundaryBank, processor, ledger, and file inputs can start read-only.Scoped
Close evidenceSettlement, bank activity, ledger posts, and exceptions export cleanly.Reviewable
Review packetArtifacts finance, product, and implementation owners can inspect together.
Request operating reviewAccess map
Entity, account, rail, workflow, and owner boundaries documented before permissions expand.
Roles exportApproval evidence
Requester, approver, policy, limit, supporting context, and release decision attached to movement records.
Movement sampleIntegration inventory
Bank, PSP, ledger, file, and API sources listed with read-only or controlled-write posture.
Source registerClose packet
Settlement files, bank activity, ledger posts, match rules, and unresolved exceptions grouped for review.
Reconciliation exportData postureDefine the boundary before the integration expands.
Read-only firstStart from exports, files, API events, and sample workflows before release controls move into production.
Classify inputsIdentify bank data, ledger events, remittance fields, and operational notes before connecting systems.
Write path reviewControlled-write paths require named owners, approval policy, rollback plan, and exception routing.
Review exportsPackage roles, movement evidence, integration scope, and close results for finance review.
Vendor diligenceMake the review package concrete before procurement has to chase it.
Request diligence packetFirst packet includesSecurity notes, data field inventory, access model, integration boundary, and launch runbook.
Not needed to startProduction credentials, bank logins, customer secrets, write access, or funds movement authority.
Application and hosting posture
Document Cloudflare Pages delivery, CSP, no third-party scripts, dependency surface, and production access path.
Security notesInputs before retention
List bank files, ledger events, processor rows, workflow notes, and which fields are needed for the first review.
Field inventoryOwners before permissions
Show entity, account, workflow, approval, and export owners before any controlled-write path is considered.
Owner matrixRunbook before scale
Define escalation owners, launch gates, rollback route, export cadence, and unresolved exception review.
Launch runbookEngagement model
Commercial scope follows the workflow carrying risk
RunFin starts with a concrete operating review, then prices the implementation around workflows, integrations, entities, approval paths, and production volume.
Workflow countEntities and accountsBank and PSP inputsApproval policiesReconciliation sourcesProduction volume
ProposalNo fee or build commitment
SprintScope and launch gates.
ProductionNo live credentials, bank logins, or funds movement authority
Next stepStart with the no-commitment operating review.
The first call turns one workflow into scope drivers, evidence needs, launch gates, and the commercial path that fits the risk.
No fee or build commitmentEvidence and owner listScope drivers before pricing
Start operating reviewOperating Review
Work through the money movement, systems, approval gaps, and close risk before any implementation commitment.
- Workflow and account map
- Control and evidence gaps
- Recommended first surface
Readiness Sprint
Turn the review into an implementation blueprint that engineering, finance, and operations can approve.
- State model and data contract
- Approval and exception design
- Launch backlog and owners
Production Layer
Configure the operating surface, integration boundaries, dashboards, queues, and launch controls for first live volume.
- Scoped platform configuration
- Read-only or controlled write paths
- Go-live support and handoff
Operating Program
Extend the control model as new entities, currencies, bank partners, products, and review requirements arrive.
- Quarterly workflow reviews
- New rail and partner rollout
- Close and control reporting
Production readiness
A launch path finance can approve before volume moves
RunFin should enter production with evidence already organized: the workflow state model, integration contract, approval owners, close criteria, and rollback path are reviewed before the first live release.
Named ownersRelease criteriaClose thresholdsRollback path
Readiness filerunfin_launch_042
01Workflow state modelapproved
Draft, approved, released, settled, failed, reversed, and matched states mapped to owners.
02Integration contractscoped
Bank, processor, ledger, file, and API inputs documented with read-only or controlled-write posture.
03Exception operating modelready
Severity, owner, SLA, required evidence, customer impact, and escalation route defined.
04Close acceptance criteriareview
Daily match rate, unresolved exposure, bank cutoff, and export package checked before expansion.
ArtifactAccount and rail map
ArtifactApproval and access matrix
ArtifactData contract and field inventory
ArtifactException and rollback runbook
Decision questions
Clear answers before the first call
RunFin is strongest when the team already has meaningful money movement and needs a cleaner way to control, review, and reconcile the operating state around it.
Does RunFin replace our bank, PSP, ERP, or ledger?
No. RunFin sits above those systems as the operating layer that connects movement state, approval evidence, reconciliation inputs, and exception ownership.
Can the first phase avoid production write access?
Yes. Teams can start with read-only exports, files, API events, and workflow samples before deciding where direct write paths or release controls belong.
What should we bring to the operating review?
Bring the payment flow, account inventory, approval policy, bank or processor files, ledger examples, and the exceptions that slow down close.
How does evidence stay defensible?
Each movement keeps the requester, approver, policy, rail, counterparty, limit context, bank activity, ledger event, and reconciliation result together.
Who should join the first conversation?
The highest-signal group is usually finance operations, a controller or treasury owner, a product/payment lead, and the technical owner for integrations.
When is RunFin not the right first step?
If the team has one account, one rail, low volume, and clean monthly reconciliation, the immediate value is probably limited until complexity grows.
Operator dossiers
Workflow evidence before implementation risk
Each scenario starts as a reviewable operating file: systems involved, pressure points, control checks, and the first output a team can approve.
Scenario reviewBring one payout, settlement, or close path.
Systems involvedControl pressureFirst output
Map this scenarioMarketplace payout teams keep approval policy, rail choice, ledger state, and bank confirmation on one movement record.
Marketplace payoutsSeller releases, reserves, and bank return review
Review dossierReserve leakage risk
SystemsProcessor events, bank returns, ledger, reserve policy
Control checkRelease path proves approver, rail, reserve, and bank confirmation.
First outputPayout release map and exception queue owners.
RequestApproveReleaseMatch
Operating review
Map one live money movement
Bring the workflow carrying release, balance, exception, or close risk. The first review returns the state path, evidence matrix, and implementation boundary.