What Banks Look for on Your Company Website During Onboarding

Key takeaway
Your website does not need to look expensive. It needs to make the business easy to understand, show which legal entity is behind it, and match the story you are giving the bank or EMI. A vague, unfinished or contradictory website creates extra questions. In some cases, it can also expose an activity the provider will not accept.

When a compliance analyst opens your website, they are usually not judging the design. They are trying to reconcile what they see online with the onboarding file in front of them.

That is why a website comes up so often in corporate onboarding. Customer due diligence requires financial institutions to understand the customer, the nature of the business, and the purpose and intended nature of the relationship.[1] The website is one of the easiest external places to sense-check that picture.

There is no single set of website requirements for every business bank account application. What matters is whether the site supports the business you are asking the provider to onboard.

Do you need a website to open a business bank account?

Not in every case.

Some providers accept other evidence when a company does not have a traditional website. Published guidance includes business social profiles, e-commerce pages, contracts, invoices, company presentations and other evidence of trading activity.[2][3]

Still, no website often leads to a very predictable question: how does the company find customers and operate without one?

For a new business, answer that question instead of trying to hide the gap. If clients come through LinkedIn, referrals, a marketplace or a booking platform, show that. If the company is newly incorporated and has little trading history, a business plan can also help explain the planned activity, customer base and expected account use. See What Banks Expect to See in a Business Plan.

One point matters more than it seems: do not rush a half-built website live just for the application. Revolut Business says an under-construction website cannot be used as proof of nature of business.[2] If the site is not ready, it is usually cleaner to say so and provide alternative evidence than to send a reviewer to broken pages and placeholder text.

What should a company website show for bank onboarding?

A reviewer should be able to answer a few basic questions without guessing:

• Who is the company behind the site?
• What does it actually sell or provide?
• Who buys from it?
• Where does it operate?
• How does the business make money and deliver the product or service?

That sounds obvious, but this is where many websites fail. They describe an industry rather than a business.

The second version gives the reviewer something concrete: services, customer type, geography and delivery model. For a more detailed framework, see How to Describe Your Business Activity for Bank or EMI Onboarding.

A small consultancy can have a simple website. It just cannot be so generic that the reviewer has to reconstruct the business from the application form.

Your website and your bank onboarding application need to match

This is the check we would prioritise before submission.

If the application says the company provides IT consulting but the website promotes a different group of services, expect a clarification request. The same applies when the website points to one market while the onboarding form describes another.

Compare the two side by side and check the legal company name, trading name, services, customer profile, countries served, contact information, addresses and email domain.

The brand name on the homepage does not have to be identical to the registered company name. But the link between the two should be visible. In practice, the legal name can sit in the footer or on the contact page with the relevant company details.

We have also seen surprisingly basic identity checks create questions. If you are emailing the provider from one domain while the website sits on another and neither clearly connects to the legal entity, the reviewer may ask why.

In payment onboarding, website checks can become more specific. Documented issues include mismatches in the legal company name, industry or registration address, as well as missing contact information or checkout functionality.[4]

A note on the domain itself

Some KYB systems also look at signals around the website rather than only the visible copy: whether the site is live, whether SSL works, whether the submitted domain matches the business, whether the email domain aligns, and whether the age of the domain fits the history being claimed.[8]

These are not universal bank rules. A new company can quite reasonably have a new domain. The issue is inconsistency — for example, presenting a business as long-established while every visible digital signal appeared last week.

Higher-risk activities deserve an extra website check

For an ordinary service company, a website mismatch often means another question. For restricted or higher-risk activities, it can change whether the provider wants the business at all.

Risk appetite varies by institution, but categories such as gambling, adult services, certain crypto activities and higher-risk financial services are commonly restricted or prohibited by some providers.[9][10] Drop shipping and certain trading or forex-related models can also receive tighter scrutiny depending on the provider.[10]

This is why the website should be reviewed before the application is sent. A company may describe itself in the form as a software or consulting business while the public website prominently markets crypto brokerage, investment services or another restricted activity. At that point the problem is not wording. The provider may simply be the wrong fit.

For corporate service providers, this is an early-routing check: confirm that the public-facing activity fits the provider's risk appetite before spending time on the full file.

For the wider preparation process, see Corporate Bank Account Opening Documents: A Complete Onboarding Checklist.

Service business vs e-commerce: website requirements differ

A consultancy and an online store should not be prepared in the same way.

For a consultancy, agency or IT company, the main job of the website is to explain the services, customer type, legal entity and contact details clearly.

For e-commerce and other online-sales businesses, there is more for the reviewer to inspect. If customers buy on the site, the commercial journey should work: products or services should be clear, prices should be shown where relevant, checkout should function, and the delivery, cancellation and refund information should reflect what actually happens after purchase.[5]

Payment and acquiring providers often go further here than a standard business-account application. That distinction matters. A merchant-acquiring checklist should not be presented as a universal bank requirement.

Legal pages: what is actually required — and what is not

There is no universal rule that every applicant must publish the same Privacy Policy, Terms and Conditions, refund policy, cookie notice and AML Policy.

Start with the basics: the website should identify the company and give customers a sensible way to contact it. Depending on the jurisdiction and business model, that can mean the legal company name, contact details, registered or operating address, and registration information.

Some of these are legal obligations, not banking preferences. UK limited companies, for example, must display specified company information on their websites.[6]

Privacy and cookies work the same way. The requirement comes from the data you collect, the technologies you use and the applicable law — not from a generic “bank website checklist”.[7]

For transactional websites, Terms and Conditions, refund or cancellation terms, delivery information and related customer-facing policies matter more because they describe the real commercial relationship.[5]

There is also a practice point that does not belong on every generic checklist. In regulated or financial businesses, we have seen compliance teams ask for an AML Policy to be added or updated. That makes sense where AML controls are relevant to the activity. It does not make an AML Policy a standard website requirement for every consultancy or trading company.

What happens when the website raises a compliance question?

Usually, it means another round of work.

The reviewer may ask for an explanation, a website update, evidence linking the brand to the legal entity, clarification of the activity, or additional documents. In structured onboarding this often appears as a Request for Information (RFI). Airwallex, for example, uses an ACTION_REQUIRED status when more information is needed and allows certain website-related issues to be corrected and resubmitted.[4]

In practical terms, the sequence is simple:

That extra loop is exactly what you want to remove before submission.

Three examples from onboarding work illustrate the point:

A Privacy Policy needed an update. The website was live and the business itself was understandable, but compliance asked for the privacy documentation to be corrected before the case moved forward.

The email did not clearly connect to the website. The reviewer checked whether the address used for onboarding correspondence belonged to the same business shown online. The mismatch created another question.

The site used a brand name, but the legal company name was hard to find. Adding the legal entity to the contact information and footer made the relationship clear.

None of these issues is complex. They are simply cheaper to fix before the application than after the RFI arrives.

Pre-onboarding website checklist

Before submitting a bank or EMI application, check the website once against the actual onboarding form:

A website review takes far less time than another compliance round. The aim is not to make the business look bigger or more sophisticated than it is. It is to remove avoidable questions before the file reaches the reviewer.

Preparing the whole onboarding case

OnboardOS is being built to help corporate service providers and onboarding teams collect company information, connect it to supporting evidence, identify missing or inconsistent information, and prepare more structured corporate bank and EMI onboarding cases.

If you manage multiple onboarding files and want to follow the product as it develops, request Early Access.

About the author

Alexander Blinov is the founder of OnboardOS. His background includes corporate legal, KYC/AML and bank and EMI onboarding work for international companies. He is building OnboardOS to help corporate service providers collect client information, identify missing evidence and prepare consistent account-opening packages.

This guide provides general information for corporate onboarding preparation. It is not legal advice and does not represent the requirements of every bank, EMI, payment provider or jurisdiction. Requirements and risk appetites vary by provider and business model.