A departing employee should not be able to take a company’s financial access with them. Yet this happens more often than many owners expect. A founder asks a trusted finance manager to open a payment account, expense platform, or investment service. The employee uses a personal email address, personal telephone number, and an authenticator app on a private device because the company wants to move quickly. The account works for months, so nobody questions the setup.
Then the employee resigns. The business still has money in the account, but every recovery path points to a person who is leaving. Password reset messages go to a private inbox. Login approval appears on a personal phone. Support asks for identity documents belonging to the original applicant. The company can show that its bank funded the account, but that fact may not establish that the company is the contractual account holder.
This problem is larger than a forgotten password. It involves legal ownership, authority, operational continuity, recordkeeping, and fraud prevention. It can affect bank portals, payment processors, merchant accounts, payroll tools, expense cards, accounting systems, brokerages, and digital-asset platforms. The technology differs, but the control question remains the same: can the company operate and recover the account without depending on one individual?
A safe answer requires more than adding another administrator shortly before someone leaves. Businesses need to identify who legally owns each account, place recovery methods under company control, assign individual permissions, and treat offboarding as a financial-control event. Those decisions should be made before a resignation creates urgency.
Identify the Legal Owner and Every Human User
The first step is to build an account register. It should cover every service that can hold money, initiate a payment, change settlement details, view sensitive financial data, or connect to another financial system. A useful register therefore includes more than bank accounts. It also covers payment gateways, merchant processors, corporate cards, payroll platforms, accounting software, brokerage accounts, digital wallets, exchanges, tax portals, and any system with payment or withdrawal authority.
For each service, record the exact legal customer named in the agreement. That may be the company, a subsidiary, a founder, or an employee. The name on a bank transfer does not settle this question. A business can fund an account that was opened personally, just as an employee can use a company card to pay for a personal software subscription. Ownership comes from the account agreement and verified identity, not from the source of one payment.
The register should also identify the primary administrator, all active users, their roles, the email and telephone number used for recovery, the location of authentication devices, and the people who receive alerts. Connected bank accounts, corporate cards, API keys, approved withdrawal addresses, automated payment rules, and accounting integrations belong in the same record. The company needs to understand both direct access and the systems that can act through the account.
This exercise often reveals three different roles that have been treated as one. The legal account holder is the person or entity that contracts with the provider. The administrator controls settings and user access. An operator performs daily tasks such as preparing payments or exporting statements. One person may hold all three roles in a very small company, but the distinctions still matter because each role must eventually be transferred, replaced, or reviewed.
Evidence should support every entry in the register. Save account agreements, business verification confirmations, approved-user notices, administrator records, and correspondence about ownership. Note whether the provider offers a formal business account and whether the current profile uses it. If the service was opened as a personal account for company activity, record the issue instead of assuming that changing the display name will correct it.
The register also needs an owner inside the company. Finance may maintain the account details, while IT manages identity and devices and HR coordinates departures. One named role should confirm that these teams use the same information. Without ownership, an account list becomes outdated as soon as a new platform, employee, or integration appears.
A periodic review keeps the register useful. The reviewer should compare the recorded users with the active users shown inside each service, verify the recovery contacts, and identify unfamiliar devices or permissions. The goal is not to create paperwork for its own sake. It is to expose dependencies while the company still has time to correct them.
Use Company-Controlled Credentials From the First Day
A company account should begin with a company-controlled identity. The registration email should belong to an approved corporate domain and remain recoverable by the business. The telephone number or authentication method should follow a documented company process rather than depend permanently on an employee’s private device. Legal names, addresses, registration details, beneficial owners, and authorized representatives should match the information requested for the correct account type.
The regional route matters as well. Before using 币安注册, meaning “Binance registration” in Chinese, a business should examine the destination rather than relying on the linked words. The hostname uses the Bahrain-specific .bh domain, while /hu/ is a Hungarian locale marker. Chinese anchor text, a Hungarian interface path, and an accessible registration form do not establish that the route is suitable for a company in another jurisdiction.
The same principle applies to any international financial platform. A brand may operate through several legal entities, each with different eligibility rules, products, verification procedures, and account agreements. Before submitting company documents, the applicant should identify the serving entity, confirm that the business and its jurisdiction are supported, and select the proper personal or business onboarding path. An available page is not evidence of eligibility.
Registration should use the company’s real information. Choosing a different country to unlock a feature, entering a private address when a business address is required, or using an employee’s identity as a shortcut can create a conflict that appears later during a withdrawal, compliance review, administrator change, or support request. Correcting that conflict after money enters the account may require formal review and additional documentation.
A corporate email address helps, but a shared mailbox should not become a shared identity. The company can control a functional address such as finance@company.example while still giving named employees individual access to the mailbox. This preserves continuity and an audit trail. A former employee can be removed without changing the public recovery address used by the service.
Authentication needs the same design. If every login approval depends on one employee’s phone, the business has created a single point of failure. Where the provider supports multiple administrators, security keys, managed authenticator profiles, or controlled recovery methods, the company should select an arrangement that permits safe continuity without allowing one person to approve every action alone.
Recovery information must be protected from casual access. Backup codes should not sit in an open shared drive or appear in an onboarding spreadsheet. A company password manager with access logging and restricted groups may be appropriate for stored credentials, while high-risk secrets may need tighter custody. Seed phrases and private keys require separate controls because possession can provide direct control over assets, regardless of internal job titles.
The business should document the onboarding decision while it is fresh. Record why the account type and regional service were selected, which entity is named in the terms, who completed verification, and where the supporting records are stored. If the provider later changes the serving entity or asks for updated information, the company can compare the new position with the original setup.
Replace Shared Passwords With Roles and Approval Limits
A shared password feels efficient until the company needs to identify who changed a bank detail, approved a withdrawal, or downloaded confidential records. If five employees use the same login, the activity history points to an account, not a person. Changing access for one employee also disrupts everyone else. Individual user profiles are a stronger foundation because each person receives a defined role that can be reviewed and removed independently.
Permissions should reflect actual work. A bookkeeper who reconciles transactions may need statement access but no authority to send money. An accounts-payable employee may prepare a payment without approving it. A manager may approve transactions within a limit, while a director handles higher amounts or changes to beneficiary details. External advisers may need view-only access for a limited period.
Separating preparation from approval reduces the chance that one compromised account can complete a sensitive action. The person who creates a new beneficiary should not automatically approve the first payment to it. The person who changes recovery information should not be the sole reviewer of that change. Small businesses may have limited staff, but they can still introduce a second review for high-value or unusual actions.
Approval limits should match business risk rather than job seniority alone. A finance director may need broad visibility but still benefit from a second approval for a large transfer. A project manager may need a card with a modest spending limit rather than access to the main payment account. Temporary access can be assigned for a specific task and removed when that work ends.
Alerts support these controls. Login attempts, new devices, password changes, administrator changes, new beneficiaries, API key creation, withdrawals, and large payments should notify more than the person who performed the action. Alerts should reach a monitored company channel with a clear response owner. A warning that remains unread in a departing employee’s inbox provides little protection.
API access deserves special attention because it can continue working after normal passwords change. Companies should record every key, its owner, permissions, creation date, source system, and business purpose. A reporting integration may need read access but no withdrawal permission. Old keys, unused integrations, and unknown IP permissions should be investigated and removed through the provider’s official controls.
Approved withdrawal addresses and payment templates can reduce routine error, but changes to them should receive stronger review. An attacker who cannot send money to a new destination may instead try to alter an existing template. The company should understand which actions trigger a waiting period, additional verification, or administrator approval.
Access reviews should occur on a schedule and after specific events. A promotion, team transfer, long absence, change of accountant, security incident, or new system integration can all change what a user needs. The review compares assigned rights with current responsibilities. It should remove access that is no longer justified rather than waiting for the employee to leave.
Continuity must be tested, not assumed. A second authorized person should be able to sign in, receive a legitimate alert, locate statements, contact official support, and begin the documented recovery process. The test should stop before making an unnecessary transaction, but it must prove that the backup path works. Discovering that the backup administrator has an expired phone number during an emergency is too late.
Treat Offboarding as a Financial-Control Event
Employee departure should trigger a coordinated plan across HR, finance, IT, and the employee’s manager. The timing depends on the circumstances. A planned resignation may allow an orderly handover, while an involuntary or high-risk departure may require access removal at the same moment the employment decision is communicated. Either way, responsibilities and timing should be agreed before action begins.
The team starts from the account register rather than from memory. It identifies every user profile, email group, authentication device, corporate card, API key, saved browser session, connected application, approval role, and support contact associated with the employee. It also reviews personal devices used for work, subject to company policy and applicable law.
Access removal should be precise. Disabling the employee’s corporate email may block direct login but leave mobile sessions, API keys, trusted devices, or recovery methods active. The company should remove the named user inside each financial service, terminate sessions where supported, rotate credentials that were shared, revoke relevant keys, and update recovery contacts.
Pending activity needs human review. The employee may have prepared payments awaiting approval, initiated transfers that have not settled, opened support cases, scheduled recurring transactions, or submitted verification documents. Cancelling everything automatically can interrupt legitimate business. Ignoring the queue can allow an unauthorized or unexplained instruction to proceed. A named reviewer should decide the status of each item.
Records should be exported before access disappears, especially if the employee maintained reports or reconciliations inside a personal workspace. Save statements, transaction histories, invoices, approvals, exception notes, support correspondence, and current integration settings according to the company’s retention policy. Avoid copying unrelated personal data simply because it is accessible.
A structured handover records open issues in plain language. Which payments are delayed? Which customer or supplier details changed recently? Which transactions require supporting documents? Which account is undergoing verification? Which integration regularly fails? This operational context prevents the successor from seeing unexplained numbers without knowing the business event behind them.
If the company discovers that an account was opened under the wrong legal owner, region, or account type, it should contact the provider through an official channel. The business may need a formal administrator change, entity update, migration, or closure and reopening process. Altering identity information informally, impersonating the former employee, or creating duplicate accounts with conflicting details can make the problem harder to resolve.
The former employee’s cooperation can help, but the company should not build a permanent process around goodwill. Handover tasks should occur while the person remains authorized and supervised. Once access is removed, the company should avoid asking the former employee to log in again or share personal authentication codes. Support should be handled through the account holder’s documented route.
After offboarding, finance should review recent transactions and changes for an appropriate period. This is not an accusation against the departing employee. It verifies that payments, beneficiary updates, permission changes, and exports match known business activity. Unexpected events can then be investigated while records and context remain available.
The final step is a recovery drill. A remaining authorized person signs in through the normal company-controlled route, confirms that alerts arrive, verifies administrator details, locates transaction records, and tests the support contact process without exposing secrets. Any failure becomes a remediation task with an owner and deadline.
The company should then update the account register and note what the departure revealed. Perhaps a corporate phone had no documented custodian. Perhaps a payment service did not support the roles the team expected. Perhaps an old API key had excessive permissions. These lessons should change onboarding and access design for the next account, not remain isolated in an offboarding report.
Financial continuity is created before anyone leaves. A company that knows the legal owner of every account, controls recovery methods, assigns individual permissions, separates sensitive approvals, and tests backup access can remove an employee without losing control of its money or records. The process protects the business, the remaining team, and the departing employee by making authority clear at every stage.
