> ## Documentation Index > Fetch the complete documentation index at: https://docs.synctera.com/llms.txt > Use this file to discover all available pages before exploring further. # Create A Business Customer > On the Synctera platform, the business resource represents an organization that can be an account holder or the owner of another business. A business resource contains identification information such as legal name, Employer Identification Number (EIN), address, phone number, and email address. It also contains status attributes to manage the lifecycle of the object. A business can progress from a prospect to an active business to an inactive former customer. Beneficial owners, accounts, ACH, and cards are all tied to the business resource. This guide walks you through a simple example of creating a business and collecting enough information to run KYB and create accounts for the business. ## Prerequisites Before you start, you should: * Have a **sandbox or production workspace** and API key. See: * [Need to Know – Environments](https://docs.synctera.com/v2/reference/need-to-know#environments) * [Need to Know – Authentication](https://docs.synctera.com/v2/reference/need-to-know#authentication) * Understand the basics of: * [Create a Personal Customer](https://docs.synctera.com/v2/docs/create-a-personal-customer) * [KYC/KYB Verification](https://docs.synctera.com/v2/docs/kyc-kyb-verification) * [Record Disclosure Acceptance](https://docs.synctera.com/v2/docs/record-disclosure-acceptance) \ The curl examples assume you have set up `baseurl` and `apikey` environment variables. ## Business Creation Steps The steps below walk you through creating a business that can transact on the Synctera platform. 1. Create a person acting on behalf of the business. 2. Create the business. 3. Capture ownership and control structure (beneficial owners, managers, owning businesses). 4. Record disclosures, including beneficial ownership certification. 5. Activate the business. 6. Run KYB (Synctera-managed and/or external vendor). 7. Use the business with other APIs. You'll need to collect identity information of the person acting on behalf of the business. Typically this person is a beneficial owner or manager of the business and the one signing up for your product. If they aren't, you'll want to review business documentation to verify their affiliation with the business before creating an account for the business. The following snippet creates a personal customer. One field to note is `is_customer`, here we've set it to false, if you want to enable this customer to also transact on the platform you'll need to set `is_customer` to true. ```shell Shell theme={"system"} curl \ -X POST \ $baseurl/v2/persons \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "first_name": "John", "middle_name": "James", "last_name": "Doe", "dob": "1981-09-14", "email": "john@example.com", "phone_number": "+16055512212", "ssn": "456-78-9999", "legal_address": { "address_line_1": "123 Main St.", "city": "San Francisco", "state": "CA", "postal_code": "94105", "country_code": "US" }, "is_customer": false, "status": "ACTIVE" }' ``` We'll use the `id` from the response to identify the person taking actions on behalf of the business. When initially creating a business customer, you can use the `PROSPECT` status to indicate that it is not yet fully configured. If not all attributes (e.g. addresses) are available, they can be added later. Set `is_customer` to `true` to indicate that this business can be an account holder, rather than just an owner. ```shell Shell theme={"system"} curl \ -X POST \ $baseurl/v2/businesses \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "status": "PROSPECT", "is_customer": true, "entity_name": "Acme Trap Company", "trade_names": [ "Acme", "Acme Corp", "CorporationID#77231" ], "formation_date": "2000-01-01", "formation_state": "NY", "structure": "CORPORATION", "phone_number": "+12124567890", "ein": "12-3456789", "legal_address": { "address_line_1": "50 Main St", "city": "New York", "state": "NY", "postal_code": "12345", "country_code": "US" } }' ``` This will return a response with the created business: ```json JSON theme={"system"} { "creation_time": "2022-04-29T21:12:55.179008Z", "ein": "12-3456789", "entity_name": "Acme Trap Company", "formation_date": "2000-01-01", "formation_state": "NY", "id": "{BUSINESS_ID}", "is_customer": true, "last_updated_time": "2022-04-29T21:12:55.179008Z", "legal_address": { "address_line_1": "50 Main St", "city": "New York", "country_code": "US", "postal_code": "12345", "state": "NY" }, "phone_number": "+12124567890", "status": "PROSPECT", "structure": "CORPORATION", "trade_names": ["Acme", "Acme Corp", "CorporationID#77231"], "verification_status": "UNVERIFIED" } ``` Note the returned `id` attribute. This is used for future `GET`, `PATCH` and `DELETE` requests, as well as to link this business to other objects like disclosures and accounts. You must now capture the ownership structure of the business. This is required for KYB verification and compliance. Federal regulation requires financial institutions to obtain, verify and record information about the beneficial owners of legal entities. #### Beneficial Owners A business can have owners that are people or other businesses. We refer to people that are owners as beneficial owners. Businesses that are owners can in turn have owners and beneficial owners. For this example, we will use the simplest ownership structure: a single beneficial owner. See [KYC/KYB Verification](/v2/docs/kyc-kyb-verification) for more details and complex examples. ### What information do I have to provide? You must provide sufficient information to KYC such as name, address, date of birth and Social Security number (or passport number or other similar information, in the case of foreign persons) for the following individuals (i.e., the beneficial owners): Each individual, if any, who owns, directly or indirectly, 25 percent or more of the equity interests of the legal entity customer (e.g., each natural person that owns 25 percent or more of the shares of a corporation); Note, depending on risk some banks my require information of beneficial owners with a smaller share of the business. And an individual with significant responsibility for managing the legal entity customer (e.g., a Chief Executive Officer, Chief Financial Officer, Chief Operating Officer, Managing Member, General Partner, President, Vice President, or Treasurer). You can use the `id` of the person created in step 1 or add separate personal customers as beneficial owners. Below is a snippet of creating a personal customer resource and adding them as a beneficial owner of the business: ```shell Shell theme={"system"} curl \ -X POST \ $baseurl/v2/persons \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "first_name": "Christopher", "middle_name": "James", "last_name": "Albertson", "dob": "1985-06-14", "email": "chris@example.com", "phone_number": "+16045551212", "ssn": "456-78-9999", "legal_address": { "address_line_1": "456 Main St.", "city": "San Francisco", "state": "CA", "postal_code": "94105", "country_code": "US" }, "is_customer": false, "status": "ACTIVE" }' ``` To add the personal customer as a beneficial owner, we'll take the resource `id` and create a beneficial owner relationship between the person and the business by calling the [POST /relationships](/v2/reference/createrelationship) endpoint specifying relationship type: `BENEFICIAL_OWNER_OF` . ```shell Shell theme={"system"} curl \ -X POST \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ $baseurl/v2/relationships \ --data-binary ' { "from_person_id": "{PERSON_ID}", "relationship_type": "BENEFICIAL_OWNER_OF", "to_business_id": "{BUSINESS_ID}", "additional_data": { "percent_ownership": 100 } }' ``` #### Business Managers KYB also requires capturing at least one Manging Person of the business. A managing person is someone who can exercise significant control over the business such as executive officers or members of the board of directors. Create additional personal customers as necessary, then link them to the business using an `MANAGING_PERSON_OF` relationship. ```shell Shell theme={"system"} curl \ -X POST \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ $baseurl/v2/relationships \ --data-binary ' { "from_person_id": "{PERSON_ID}", "relationship_type": "MANAGING_PERSON_OF", "to_business_id": "{BUSINESS_ID}", "additional_data": { "title": "OFFICER" } }' ``` ### Owning Businesses Lastly, you'll also need to collect information on any businesses that owns more than 25% of the business customer. Create another business resource to represent the owning business, then link the two by creating a `OWNER_OF` relationship. ```shell Shell theme={"system"} curl \ -X POST \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ $baseurl/v2/relationships \ --data-binary ' { "from_business_id": "{OWNING_BUSINESS_ID}", "relationship_type": "OWNER_OF", "to_business_id": "{OWNED_BUSINESS_ID}", "additional_data": { "percent_ownership": 25.1 } }' ``` Once all business ownership information has been added, you'll need to have the agent entering information certify that the information collected is complete and correct. You can do so by displaying the following snippet of text to the agent and recording a `OWNER_CERTIFICATION` [disclosure](#beneficial-ownership-disclosure) upon saving business information. `I certify to the best of my knowledge that the information entered is complete and correct.` The next step when onboarding a business is disclosing information to them, e.g. terms of service. We'll start with tracking the beneficial ownership certification #### Beneficial Ownership Disclosure To create a disclosure record tracking benefical ownership certification, you'll need the personal customer id of the personal customer entering in benefical owner information (Created in [step 1](#1-create-a-person)) and id of the business. The personal customer should be related to the business as a `BENEFICIAL_OWNER` or a `MANAGING_PERSON`. If they aren't you should collect business formation documentation and verify the agent's relationship with the business. If the person entering the information is not an existing customer, first a customer needs to be created that represents the person responsible for entering beneficial owner information. Create a disclosure record with [POST /v2/disclosures](/v2/reference/createdisclosure), passing in the personal customer id, business id and the `OWNER_CERTIFICATION` disclosure type. Here `acknowledging_person_id` and `business_id` are required fields. ```shell Shell theme={"system"} curl \ -X POST \ $baseurl/v2/disclosures \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "acknowledging_person_id": "{PERSON_ID}", "business_id": "{BUSINESS_ID}" "type": "OWNER_CERTIFICATION", "version": "1.0", "event_type": "ACKNOWLEDGED", "disclosure_date": "2022-04-17T02:04:34Z" }' ``` This will respond with a disclosure object: ```json JSON theme={"system"} { "acknowledging_person_id": "{PERSON_ID}", "business_id": "{BUSINESS_ID}", "creation_time": "2022-04-29T21:14:24.953307Z", "disclosure_date": "2022-04-17T00:00:00Z", "event_type": "ACKNOWLEDGED", "id": "{DISCLOSURE_ID}", "last_updated_time": "2022-04-29T21:14:24.953307Z", "type": "OWNER_CERTIFICATION", "version": "1.0" } ``` #### Disclosure records For other disclosure types such as `REG_E` or `ESIGN`, you can create a record using the same [disclosure request](/v2/reference/createdisclosure) with an update appropriate type. You'll need to work with your Synctera partner to determine the type of disclosures that you'll need to record for your business. ```shell Shell theme={"system"} curl \ -X POST \ $baseurl/v2/disclosures \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "business_id": "{BUSINESS_ID}", "type": "REG_E", "version": "1.0", "event_type": "ACKNOWLEDGED", "disclosure_date": "2022-04-17T02:04:34Z", "acknowledging_person_id": "{PERSON_ID}" }' ``` Once you've collected enough information to run KYB and the entity is ready to engage in business activites on your platform, you can update the business to `ACTIVE` using [PATCH /v2/businesses/](/v2/reference/updatebusiness){BUSINESS_ID}: ```shell Shell theme={"system"} curl \ -X PATCH \ $baseurl/v2/businesses/{BUSINESS_ID} \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "status": "ACTIVE" }' ``` While the new business now has a `status` of `ACTIVE`, its `verification_status` is still `UNVERIFIED`, so its will not be able to perform most banking activities. The next step is to verify the business's identity using a *Know Your Business* (KYB) verification. See the [KYC/KYB Verification](/v2/docs/kyc-kyb-verification) section of this guide for more details as well as descriptions of other types of verification and risk checks. Run a verification using [POST /v2/verifications/verify](/v2/reference/verify), e.g.: ```shell Shell theme={"system"} curl \ -X POST \ $baseurl/v2/verifications/verify \ -H "Authorization: Bearer $apikey" \ -H 'Content-Type: application/json' \ --data-binary ' { "customer_consent": true, "customer_ip_address": "{CUSTOMER_IP_ADDRESS}", "business_id": "{BUSINESS_ID}" }' ``` This will return a list of all the verifications that were run, and a result for each. If the verifications passed, the business's `verification_status` will now be `ACCEPTED`. This can be checked by a [GET /v2/businesses/](/v2/reference/getbusiness){BUSINESS_ID}: ```shell Shell theme={"system"} curl \ -H "Authorization: Bearer $apikey" \ $baseurl/v2/businesses/{BUSINESS_ID} ``` which will respond with: ```json JSON theme={"system"} { "creation_time": "2022-04-29T21:12:55.179008Z", "ein": "12-3456789", "entity_name": "Acme Trap Company", "formation_date": "2000-01-01", "formation_state": "NY", "id": "{BUSINESS_ID}", "is_customer": true, "last_updated_time": "2022-04-29T21:19:09.521182Z", "legal_address": { "address_line_1": "50 Main St", "city": "New York", "country_code": "US", "postal_code": "12345", "state": "NY" }, "phone_number": "+12124567890", "status": "ACTIVE", "structure": "CORPORATION", "trade_names": ["Acme", "Acme Corp", "CorporationID#77231"], "verification_last_run": "2022-04-29T21:19:09.432601Z", "verification_status": "ACCEPTED" } ``` An active business can be used with other Synctera APIs: * The [Accounts](/v2/docs/create-accounts-guide) API can create and manage accounts with the business as an account holder. * The [Cards](/v2/docs/personal-cards) API can create and manage credit or debit cards linked to the business. * The [Relationships](/reference/createrelationship) API can link the business to another business as an owner. * The [Watchlists](/reference/verifyadhoc) API can link a business with one or more watchlist monitoring subscriptions so that you can check for a business's presence on security risk watchlists. ## Business Status Attributes The business object contains two status attributes: * `status` is an editable attribute representing the administrative state of the business. The integrator can use this to indicate whether they consider the business to be active, dormant, etc. * `verification_status` is a read-only attribute representing the results of the verification process. This is updated by the Synctera platform when verification actions, e.g. KYB checks, are performed. The ability to participate in money movement transactions, issue cards, etc, is limited by both the `status` and `verification_status` attributes. ### Business Status The business object's status attribute can have the following values. It is up to the integrator to decide what they consider an `ACTIVE`, `FROZEN` or `INACTIVE` business. Note that all states other than `ACTIVE` are restricted and do not allow most banking operations. | Status Value | Description | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | | ACTIVE | An active business | | CANCELLED | The business has filed a cancellation, or has failed to file its periodic report after notice of forfeiture of its rights to do business | | CONVERTED | The business type has changed to another type within the same jurisdiction | | DISSOLVED | The business has filed articles of dissolution or a certificate of termination to terminate its existence | | FROZEN | The business's actions are blocked for security, legal, or other reasons | | INACTIVE | The business is marked as no longer active, e.g. a former customer | | MERGED | The business has ceased to exist by merging into another business entity. | | PROSPECT | A potential business customer, used for information-gathering and disclosures | | SUSPENDED | The business has lost the right to operate in its registered jurisdiction | These states are controlled by the integrator's API client. While there are no restrictions on state transitions, certain fields, e.g. entity\_name, are required by all states except `PROSPECT`. Typical state transitions are: ```mermaid theme={"system"} %%{init: {"fontFamily": "sans-serif"}}%% stateDiagram-v2 [*] --> PROSPECT: Prospect identified PROSPECT --> ACTIVE: Prospect qualified ACTIVE --> INACTIVE: Closed accounts ACTIVE --> FROZEN: Anomalous
activity FROZEN --> ACTIVE: Anomalies
resolved ACTIVE --> CANCELLED ACTIVE --> CONVERTED ACTIVE --> DISSOLVED ACTIVE --> MERGED ACTIVE --> SUSPENDED ``` ### Verification Status In order to initiate transactions, an active business must also pass verification. There are different types of verification, including identity and watchlist checks. Note that all states other than `ACCEPTED` are restricted and do not allow most banking operations. | Verification Status Value | Description | | ------------------------- | ---------------------------------------------------------------------------------------- | | ACCEPTED | The business is successfully verified | | PENDING | The business's verification is in progress | | PROVISIONAL | The business is partially verified or verified with restrictions | | REJECTED | The business was rejected | | REVIEW | The business's verification has run and issues have been identified which require review | | UNVERIFIED | The business's verification has not been completed | See the [KYC/KYB Verification](/v2/docs/kyc-kyb-verification) section of this guide for details on how verfications are performed and the meaning of the results. ## Additional Business Documentation Collection To mitigate fraud and money laundering, we recommend gathering the following documentation. These items can be attached to business using our [documents api](/v2/reference/createdocument). * **Legal entity organization documentation** such as: articles of incorporation, partnership agreement, certificate of organization, operating agreement, etc. * **Money Services Business (MSB) Status** is the legal entity a registered MSB? If so, the entity's FINCEN registration. * **Ongoing re-KYB (e.g. annually or bi-annually)** is required for certain types of higher risk accounts subject to the Sponsor Bank’s policies and if there is any unusual activity that occurs in the account * Examples of higher risk business accounts include cash-intensive businesses, non-US businesses, crypto businesses, MSBs, and marijuana-related businesses. This may be dictated by your Sponsor Bank.