Customer onboarding
Approve new customers with every document checked.
Collect borrower or dealer applications, compare identity and business details across documents and prepare the file for the lender's approval.
Discuss your use case- Legal name
- Fenwick & Rowe LLC p. 1
- Registered office
- 410 Canal St, Albany p. 1
- Formed
- Mar 14, 2019 p. 1
What it handles
New customers checked before they are approved.
Each applicant's documents are read and checked against each other and against your records, and the file moves to approved once a reviewer signs off.
IDs, proof of address and business documents read and cross-checked, with every mismatch shown beside the page it came from.
OnboardingFenwick & Rowe LLCMismatchExtracted4 fields- Legal name
- Fenwick & Rowe LLC p. 1
- Registered office
- 410 Canal St, Albany p. 1
- Formed
- Mar 14, 2019 p. 1
- File number
- 5519-0832 p. 1
Checks- Address matches the applicationApplication lists 12 Pearl St, Troy
- Name matches the bank letter
- Not an existing customer
Request proof of addressApprove with noteEvery application by stage, with missing documents and failed checks called out, so reviewers start with what needs them.
Ask about any applicant and get what was submitted, what was checked and what is still missing, each item cited.
How it fits
From the application to an active customer.
Strive gathers what applicants send, checks it against your records and rules, and writes the approved customer into your systems.
Comes in from
- Application formsSubmitted from your site or portal
- Uploaded documentsIDs, letters and registrations
- Customer recordsExisting customers to check against
- 01ReadIDs, forms and business documents
- 02ExtractNames, addresses and owners, each cited
- 03CheckAcross documents and your records
- 04ReviewA reviewer approves the file
Goes out to
- An onboarding appEvery application by stage
- Requests to applicantsMissing documents, asked for by email
- Into your CRMThe approved customer, written back
What you can do.
Cross-check documents
Names, addresses and owners compared across the application, IDs and registrations.
Catch duplicates
Applicants checked against your existing customers before they are approved.
Ask for what is missing
Missing or expired documents requested from the applicant by email.
Write back when approved
The approved customer written into your CRM or core system over the API.
Apps for this work
Security
Security your IT team will sign off on.
SOC 2 Type II audited controls, encryption everywhere, single sign-on and role-based access. Your data never trains a model.
Security
SOC 2 Type II
Independently audited security controls, tested over time.
Europe
GDPR
Personal data handled under the EU's data protection rules.
California
CCPA
Personal data handled under California's privacy law.
Controls
Encryption
Encryption runs on every layer, built on Google Cloud's security controls. Data is encrypted at rest with keys held in Google Cloud KMS, and every connection is encrypted in transit, including traffic between our own services. The credentials your connections use are encrypted too, and never appear in an app.
- At rest
- AES-256, on Google Cloud.
- Keys
- Held and managed in Google Cloud KMS.
- In transit
- TLS on every connection into the platform.
- Inside the platform
- Traffic between our own services is encrypted too.
- Connection credentials
- Stored encrypted and entered through secure forms. Never shown in apps.
- Exported apps
- Credentials are left out.
No training on your data
Your data is never used to train AI models, and the AI services we use don’t train on it either: we use them on enterprise terms that exclude training. A data processing addendum makes our commitment contractual, and you decide how long your data is kept.
- AI model training
- Your data is never used to train AI models.
- AI services
- Used on enterprise terms, so they don’t train on your data either.
- In writing
- A data processing addendum makes it a contractual commitment.
- Retention
- You decide how long your data is kept.
Single sign-on
People sign in with the identity provider you already use: Google, Microsoft, Okta, or any provider that supports SAML or OpenID Connect. Their groups map to roles in Strive, so the right access follows them in. Systems connect with API keys.
- Providers
- Google, Microsoft, Okta, and any provider that supports SAML or OpenID Connect.
- Protocols
- SAML and OpenID Connect (OIDC).
- Roles
- Groups in your identity provider map to roles in Strive.
- Systems
- API keys.
- Rate limits
- Requests are limited for each organization.
Role-based access
Role-based access control: each person has a role, and the role decides which apps, data and actions they can use. The Assistant works with the same access as the person using it, so it can only see and do what they can.
- Roles
- Assigned to each person, or mapped from groups in your identity provider.
- Apps and data
- A role decides which apps, records and actions a person can use.
- The Assistant
- It has the same access as the person using it, no more.
- Changes it proposes
- They wait for someone with the right role to approve them.
- Actions that cost money
- They ask for confirmation first.
- Organizations
- Each organization's data is kept separate.
Questions
What people ask about customer onboarding.
Does it approve customers on its own?
No. A reviewer signs off on each file before it moves to approved, and can edit any value or reject the file first. Every value points to the exact spot on the page it came from, so the reviewer can check it.
Where does applicant data live?
In Strive Cloud on Google Cloud, with each organization's data kept apart at the database level. On Enterprise, the whole platform can run inside your own cloud account instead.
Can it call our screening or ID verification provider?
Yes, if the provider has a REST API or an MCP server. A workflow step can call it once for each applicant.
Can applicants upload documents themselves?
Yes. The app can include an intake form with uploads, and applications can also come in from your own site or portal over the API.
Can we limit who sees applicants' personal details?
Yes. Each person's role decides which apps, records and actions they can use, and a redact step can mask or remove personal details before anything else sees them.
Which document-heavy job would you hand over first?
Bring one process you want to improve and the information behind it. We build the first version with you in the session, so the first thing you see is your own work, running.
Contact SalesAn hour of your time and a process you know well. That's all it takes.