Business Card KYC Requirements and Public Records

Business-card KYC is a private verification process, not a public-record verdict

A bank's application and identity-verification records are private account records, while formation registries expose a separate, state-specific set of searchable facts.

The two record systems can contain overlapping kinds of information without becoming the same record. A business-card application can collect facts about an applicant, a company, an owner, or another account role. A state filing can make a different set of entity facts searchable under that jurisdiction's own registry design. The existence of a public filing does not establish that a bank queried it, relied on it, or reached a particular decision from it.

Collection, verification, retention, sharing, public visibility, and legal access are distinct claims. Collection identifies information that enters a workflow. Verification identifies a stated check. Retention identifies how long a record or category is kept, or which event or criterion governs it. Sharing identifies a permitted recipient or linkage context. Public visibility asks what an ordinary registry user can retrieve. Legal access describes access under a separate authority. One verb cannot substitute for another.

The same separation applies when two records use the same label. A name or address on a bank form and a name or address on a formation filing can have different subjects, purposes, dates, update rules, and access paths. Matching labels alone do not establish that the values match, that one system supplied the other, or that a later account event rechecked an earlier filing. The page keeps each claim attached to the source that actually states it.

This page therefore follows two rails. The private rail starts with the federal bank Customer Identification Program baseline, the legal-entity beneficial-owner and control-person rule, and the published practices of American Express, Chase, and Capital One. The public rail starts with federal beneficial ownership information and state business registries. The BOI and KYC boundary provides the broader system distinction, while this page stays with the business-card workflow.

What the bank CIP baseline requires

The bank Customer Identification Program baseline defines covered-bank identity requirements within its stated scope; it is not a complete description of every issuer's application.

The table keeps the covered-bank scope, required identity elements, verification standard, timing, methods, credit-card timing provision, recordkeeping rule, and limiting text in separate cells. Those are regulatory baseline statements, not a complete description of any one issuer's application. The rule identifies what a covered bank's written program must accomplish at its stated scope. It does not say that every bank uses the same documents, the same non-documentary sources, the same sequence, or only the minimum listed elements. Issuer-specific practices therefore remain in their own cells below.

The retention statement separates identifying information from verification records and carries its own event-based endpoints. It does not establish that every other application, account, transaction, marketing, device, or rewards record follows the same period.

The limitations matter whenever a non-individual customer, an exemption, or a failure to verify changes the path. The baseline answers the covered rule question; it does not replace the narrower issuer and product sources.

Source: 1 rules. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

When legal-entity beneficial-owner and control-person rules apply

The legal-entity customer rule applies only within its stated institution, customer, account-opening, exclusion, and exemption boundaries.

The table keeps the rule's scope, ownership prong, control prong, identifying fields, verification mechanics, repeat-identification conditions, recordkeeping periods, confirmation record, and limitations in separate cells. The identity definitions remain separate from the later relief governing repeat identification and verification.

A prior record is not treated as automatically current. The accepted rule cell states when confirmation can support reliance and when a question about accuracy or risk calls for another step.

The recordkeeping periods attach to the rule's identification, verification, and later-account record categories. They do not become a universal retention schedule for every item an issuer collects.

The relief, base rule, exemptions, and other continuing obligations stay distinct. This page does not convert the legal-entity rule into a claim that every business-card application at every institution follows one identical beneficial-owner workflow.

Source: 1 rules. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

What American Express, Chase, and Capital One publish about collection and verification

The three issuers publish different collection fields and verification events, so each issuer's collection statement must remain separate from its verification statement.

The paired cells prevent a common inference error. A field on an application or account form is evidence of collection at the stated workflow and date. It is not automatically evidence that the issuer checked that field against another source. A verification cell answers the narrower question: which event and method does the issuer's own material describe as a check, confirmation, authentication, verification, or re-verification?

Product and event scope also travel with the answer. An additional-user process cannot silently become a universal rule for an initial business-card application. A login or later account-access check cannot silently become an account-opening step. A privacy-rights request is not a credit decision. Where an issuer source covers more than one event, the rendered cell retains those event boundaries instead of collapsing them into one workflow.

The issuer rows are parallel questions, not normalized workflows. One source may name a form field, another may describe a later account event, and another may publish a broader policy category. Side-by-side placement shows what each accepted source says at the same editorial field grain. It does not erase product qualifiers, convert a general policy into a business-card form, or imply that an issuer omitted a step simply because its public source did not describe it.

The comparison likewise stops short of a bank-decision claim. An issuer can state that it may obtain information from a public or commercial source without establishing that it queried a particular registry for a particular applicant. The public-record section below therefore describes public availability separately. It does not use a state filing as proof of what American Express, Chase, or Capital One collected, verified, retained, shared, or decided in an individual case.

Source: 3 programs. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

What the issuers say they retain, share, and assign to account roles

American Express, Chase, and Capital One publish issuer-specific retention periods or criteria, while their sharing contexts and account-role terms answer separate questions.

A fixed period, an event-based rule, and a necessity or legal criterion are different kinds of retention answer. The page preserves whichever form the accepted issuer record supplies. It does not turn a criterion into a number, borrow one issuer's period for another issuer, or infer that silence means immediate deletion or permanent retention. The applicable product, record category, jurisdiction, source revision, and exception remain part of the rendered cell.

A retention clause also needs its object. A period for identifying information is not automatically a period for verification results, transaction records, online activity, a rewards balance, or information held by a recipient. An event tied to account closure does not silently attach to every category gathered before or after that event. The page therefore carries the category and trigger beside the duration or criterion instead of extracting a number alone.

Sharing is not retention and is not proof that a transfer occurred. The three issuer cells describe the recipient categories, purposes, or linked contexts their own sources state. A permitted or described context does not establish that information about a specific applicant moved to a recipient. It also does not establish the recipient's retention rule, public visibility, or legal access.

Account roles answer a third question. The issuer terms describe which party controls an account or feature and which party bears a stated contractual responsibility. These terms do not by themselves prove that the issuer verified every named role in the same manner, that each role's records share one retention period, or that contractual responsibility determines a separate statutory question.

Source: 3 programs. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Which entity facts may be visible in public records

Federal beneficial ownership information and state business registries are different systems, and neither system is the same as a bank's private application record.

The current federal beneficial ownership regime is: Federal BOI rule effective for foreign reporting companies; U.S. companies and U.S. persons exempt under the 2026 final rule. source The fields collected in an initial report are: Initial reports collect reporting-company name, trade name, address, jurisdiction, TIN, and beneficial-owner/company-applicant identifying information. source Access is governed separately: BOI reported to FinCEN is confidential except for authorized disclosures in 31 CFR 1010.955. source These cells keep collection, current regime status, and authorized access as three distinct claims. They do not support describing federal beneficial ownership information as an ordinary public registry.

State business registries are jurisdiction-specific public-record systems. The Business Registry Searchability by State matrix preserves current state-cell answers for searches by entity name, officer name, principal address, registered-agent name, and registered-agent address. A searchable field in one state is not a national rule, and a typed unknown is not converted into yes or no.

Searchability and filing requirements are also different questions. A filing form can require a field without the public portal offering a search by that field. A portal can return a field on an entity result without accepting that field as a query. The matrix keeps those query vectors at state grain so the page does not turn a displayed value, a required value, and a searchable value into the same proposition.

Formation-address requirements are a separate field set again. Principal-office, organizer or member, and registered-agent street-address requirements can differ by jurisdiction and role. This page does not flatten those current state cells into a single national answer or reproduce a state matrix inside an issuer explainer. The linked state reference is the place to inspect the jurisdiction-level query vectors; a filing requirement does not, by itself, establish that the same address is searchable.

None of these public-record statements establishes issuer use. A public entity name, officer field, address field, or registered-agent field can exist without evidence that a bank queried it. Conversely, an issuer may collect or verify information that is not publicly visible. A claim that a particular registry record affected a particular business-card application would require a separate accepted issuer record connecting those events.

Limits, evidence status, and corrections

This page reports what the cited rule and issuer sources stated at their recorded dates; it does not report what an issuer did in a particular application or account.

Each rendered cell carries its own source class, source URL, quote, capture or effective date, and narrow scope. A federal rule supports the institution, customer, account, and event boundaries in that rule. An issuer notice, agreement, application guide, or help page supports that issuer and the product or workflow it names at the recorded revision. Neither source type silently expands into an industry-wide workflow. A scope qualifier is part of the answer; removing the qualifier changes the claim rather than simplifying it.

Dates describe the cited source, not a promise that every operational practice changed on that date or stayed unchanged afterward. A capture date records when the source was checked. An effective or revision date records what the source itself publishes. When a source changes, the new statement needs its own evidence record; it is not backdated into the older cell. This keeps a current explanation from erasing the historical scope of the statement it replaces.

The page also preserves unknowns and incomplete answers. If a source gives a retention criterion rather than a fixed duration, the criterion remains the answer. If a current state cell is typed unknown, the unknown remains visible in the state matrix. A missing answer is not rewritten as deletion, permanence, no sharing, no verification, or no public access.

The page makes no personal finding. Application information, an account record, a formation filing, or an authorized-access rule does not by itself prove a person's presence, ownership, conduct, intent, wrongdoing, or receipt of credit. Collection does not prove verification; verification does not prove retention; retention does not prove sharing; sharing does not prove public visibility; public visibility does not prove issuer use; and legal access does not prove that access occurred.

Corrections should identify the issuer or authority, the affected field, the cited source, the recorded revision, and the statement that changed. The methodology and corrections process explains how source dates, typed unknowns, and replacement records are handled.

Frequently asked questions

Related research

• Loyalty Program Identity Verification and Data RetentionThe loyalty-program reference compares documented collection and verification events across nine systems.
• Business Credit Card Authorized Users and Account RolesThe authorized-user guide examines additional-user identity records and responsibility boundaries.