Complete Legal Entity & Compliance Requirements for Developers
This document covers everything a developer (client) needs to know to onboard their legal entity with Fin and begin using the orchestration platform APIs.
1. Onboarding Overview
What Is This Process?
For a developer to gain production access to Fin’s orchestration APIs, their legal entity must first successfully complete and be approved through Fin’s KYB process. As a licensed and regulated platform, Fin has a regulatory mandate to verify the identity, legitimacy, and compliance posture of every business utilizing its infrastructure for money movement.
Who Needs to Be Onboarded?
The legal entity that will be the contracting party with Fin. This is the company that signs the agreement, holds the API keys, and is responsible for transactions processed through the platform. If the developer operates through multiple entities (e.g., a holding company and an operating company), the operating entity that will directly use the APIs is the one that must be onboarded.
What Does the Process Look Like?
The onboarding process has three phases:
Phase 1 — Entity Documentation: The developer submits corporate documents, beneficial ownership information, and business details about their company.
Phase 2 — UBO / Shareholder Verification: Fin verifies the identity of the individuals who ultimately own or control the entity.
Phase 3 — Business & Compliance Review: Fin reviews the developer’s intended use case, the jurisdictions they will operate in, their licensing status, and their own end-user compliance processes.
Once all three phases are complete and approved, the developer receives production API access.
2. Documents Required for Developer Onboarding
2.1 Corporate / Entity Documents
These documents establish that the legal entity exists, is in good standing, and is authorized to do business.
| Document | Description | Required For | Notes |
|---|
| Certificate of Incorporation / Registration | Official government-issued document proving the entity was legally formed | All entity types | Must be from the jurisdiction of incorporation. If the entity has re-domiciled, provide both original and current certificates |
| Articles of Association / Operating Agreement / Bylaws | The governing document that defines how the entity is structured and managed | All entity types | For LLCs: Operating Agreement. For Corporations: Articles | Bylaws. For Partnerships: Partnership Agreement |
| Certificate of Good Standing / Certificate of Incumbency | Confirms the entity is active and in compliance with its jurisdiction’s requirements | All entity types | Must be dated within the last 6 months. Some jurisdictions call this a “Certificate of Existence” or “Letter of Good Standing” |
| Business Registration / Trade License | Local business registration or trade license if required by the entity’s operating jurisdiction | Where applicable | Required in jurisdictions like UAE (trade license), Singapore (ACRA BizFile), EU countries (commercial register extract) |
| Registered Address Proof | Document confirming the entity’s registered office address | All entity types | Acceptable: utility bill, bank statement, lease agreement, or official registry extract showing address. Must be dated within last 3 months |
| Operating Address Proof (if different from registered) | Document confirming where the business actually operates | If operating address differs from registered address | Same acceptable documents as registered address proof |
| Tax Identification Number (TIN) / EIN | The entity’s tax identification number issued by relevant tax authority | All entity types | US entities: EIN. EU entities: VAT number or local TIN. Other jurisdictions: equivalent local tax ID |
| Organizational Chart | Visual representation of the entity’s corporate structure showing parent companies, subsidiaries, and ownership percentages | Required if entity is part of a group structure | Must clearly show the chain of ownership up to the Ultimate Beneficial Owners (individuals) |
| Board Resolution / Letter of Authorization | Formal authorization from the entity’s board (or equivalent) authorizing the company to enter into an agreement with Fin and designating authorized signers | All entity types | Must be signed, dated, and reference Fin or the orchestration services specifically |
| Power of Attorney (if applicable) | If someone other than a director or officer is signing on behalf of the entity | Only if the signer is not a director / officer | Must be notarized and specifically authorize the signer to enter into financial services agreements |
2.2 UBO / Shareholder Documents
Fin is required to identify and verify all Ultimate Beneficial Owners (UBOs) — the individuals who ultimately own or control the entity. This is a core anti-money laundering (AML) requirement.
Who qualifies as a UBO?
Any individual who directly or indirectly owns or controls 25% or more of the entity, OR any individual who exercises significant control over the entity (e.g., a CEO, managing director, or equivalent) even if they don’t meet the 25% ownership threshold.
For each UBO, the following is required:
| Document / Information | Description | Notes |
|---|
| Full Legal Name | As it appears on government-issued ID | Must match ID exactly — no nicknames or abbreviations |
| Date of Birth | | |
| Nationality / Citizenship | All nationalities if dual/multi-national | |
| Residential Address | Current home address | PO Boxes not accepted |
| Government-Issued Photo ID | Passport, national ID card, or driver’s license | Passport preferred. Must be valid (not expired). Both sides required for ID cards and driver’s licenses |
| Proof of Residential Address | Utility bill, bank statement, or government correspondence | Must be dated within the last 3 months. Must show the UBO’s name and address |
| Ownership Percentage | The percentage of the entity directly or indirectly owned by this individual | If ownership is indirect (through other entities), the full ownership chain must be documented |
| Source of Wealth Declaration | Brief description of how the UBO acquired their wealth | Required for UBOs with significant ownership. Can be a simple written statement (e.g., “salary from employment,” “proceeds from sale of business,” “inheritance”) |
| Politically Exposed Person (PEP) Declaration | Whether the UBO is or has been a PEP, or is a close associate or family member of a PEP | A PEP is someone who holds or has held a prominent public function (e.g., head of state, senior politician, senior military official, senior judicial figure). Must be declared honestly — Fin screens against PEP databases and discrepancies will delay onboarding |
2.3 Business & Use Case Documentation
These documents help Fin understand what the developer is building, who they serve, and how they manage compliance for their own customers.
| Document / Information | Description | Notes |
|---|
| Business Description | Detailed description of the developer’s business: what they do, what product/service they provide, who their customers are | Not a one-liner. Fin needs to understand the full business model. Include: what problem the developer solves, how money flows through their product, who pays whom |
| Intended Use Case with Fin | Specific description of how the developer will use Fin’s APIs | E.g., “We will use Fin’s orchestration APIs to enable our users to convert USD to USDC and send cross-border payments to recipients in Brazil who off-ramp to BRL via PIX.” Be specific about corridors, currencies, and flows |
| Target Jurisdictions | List of countries where the developer’s end-users are located | Fin must confirm that all target jurisdictions are supported and not restricted |
| Expected Transaction Volume | Estimated monthly transaction volume (count and value) at launch and at 6/12 months | Helps Fin assess risk and ensure appropriate monitoring thresholds |
| End-User Type | Whether the developer’s customers are individuals (consumers), businesses, or both | Affects compliance requirements |
| End-User KYC/AML Policy | The developer’s own policy for verifying and onboarding their end-users | Fin needs to confirm that the developer’s end-user verification meets minimum requirements. Provide the actual policy document, not just a summary |
| End-User Terms of Service | The developer’s terms of service that their end-users agree to | Must include appropriate disclosures about stablecoin/digital asset usage |
| Privacy Policy | The developer’s privacy policy | Must comply with applicable data protection regulations (GDPR, CCPA, etc.) |
| Licensing Documentation (if applicable) | Any financial services licenses held by the developer | See Section 3 below for details on licensing requirements |
| AML/CFT Compliance Program | The developer’s anti-money laundering and counter-terrorist financing program | Required if the developer is a regulated entity or if their use case involves direct custody or transmission of funds on behalf of end-users |
| Sanctions Screening Process | How the developer screens their end-users and transactions against sanctions lists | Fin performs its own screening, but needs to understand the developer’s processes as well |
| Website / App URL | The developer’s live product or a staging/demo environment | Fin may review the product to confirm it aligns with the stated use case and meets disclosure requirements |
3. Licensing Requirements
Am I Required to Have a License?
It depends on your use case and the jurisdictions you operate in. There is no single universal answer — licensing requirements vary by country and by what the developer is doing with the money.
General guidance:
You likely need a license if: you are holding, transmitting, or custodying funds on behalf of your end-users (e.g., you operate a wallet, a neobank, a remittance service, or a payment platform where user funds pass through your control). In most jurisdictions, this activity requires a money transmitter license (US), electronic money institution (EMI) license (EU/UK), payment services license (Singapore, etc.), or equivalent.
You may not need a license if: you are acting purely as a technology provider or marketplace that connects users to Fin’s services, and funds flow directly between the end-user and Fin without passing through your control. However, this depends heavily on how the product is structured, and regulatory interpretations vary.
Fin’s role: Fin holds its own licenses and regulatory approvals to provide orchestration services. However, Fin’s licenses do not cover the developer’s activities. If the developer’s business model requires licensing, the developer must obtain their own licenses independently.
What Fin needs from you:
| Scenario | What to Provide |
|---|
| Developer holds relevant licenses | Copies of all licenses, the issuing authority, license number, jurisdictions covered, and expiration date |
| Developer is in the process of obtaining a license | Proof of application, expected timeline, and interim operating authority (if any) |
| Developer believes no license is required | A written explanation of why, ideally supported by a legal opinion from qualified counsel in the relevant jurisdiction |
| Developer is unsure | Fin’s compliance team can provide general guidance on whether the intended use case typically requires licensing, but cannot provide legal advice. The developer should consult with their own legal counsel |
4. Restricted & Prohibited Jurisdictions
Jurisdictions Where Fin Cannot Onboard Entities
Fin cannot onboard legal entities that are incorporated, domiciled, or primarily operated from the following jurisdictions. This is driven by sanctions, regulatory restrictions, and banking partner limitations.
Prohibited — OFAC Comprehensively Sanctioned Countries:
These jurisdictions are universally restricted across the financial services industry. Fin cannot onboard entities from, or process transactions involving, these countries under any circumstances. The list can be found here.
Important Nuances on Jurisdiction
Entity jurisdiction vs. end-user jurisdiction: The restrictions above apply to where the developer’s legal entity is incorporated or operated from. Separate restrictions may apply to where the developer’s end-users are located. For example, a developer incorporated in the US may not be able to serve end-users in certain countries even though the developer itself is in an unrestricted jurisdiction.
Corridor-specific restrictions: Some corridors (country-to-country payment routes) may have restrictions even if neither country is fully prohibited. For example, certain currency pairs or payment rails may not be supported. The CSM will confirm supported corridors during onboarding.
The Russian company example : A company incorporated in Russia that serves British customers cannot be onboarded by Fin, because the entity’s jurisdiction of incorporation is restricted. The location of the entity’s customers does not override the restriction on the entity itself.
Dual-jurisdiction entities: If the developer has entities in multiple jurisdictions (e.g., a holding company in a restricted jurisdiction but an operating subsidiary in an unrestricted jurisdiction), the operating subsidiary may be eligible for onboarding, but Fin’s compliance team will review the full corporate structure and may apply additional due diligence. The fact that a parent company is in a restricted jurisdiction does not automatically disqualify a subsidiary, but it does trigger enhanced review.
5. Complete Document Checklist — Summary
For the Legal Entity:
- Certificate of Incorporation / Registration
- Articles of Association / Operating Agreement / Bylaws
- Certificate of Good Standing (dated within 6 months)
- Business Registration / Trade License (where applicable)
- Registered Address Proof (dated within 3 months)
- Operating Address Proof (if different — dated within 3 months)
- Tax Identification Number (TIN / EIN)
- Organizational Chart (if part of a group structure)
- Board Resolution / Letter of Authorization
- Power of Attorney (if applicable)
For Each UBO (25%+ owners and key controllers):
- Full Legal Name
- Date of Birth
- Nationality / Citizenship (all)
- Current Residential Address
- Government-Issued Photo ID (valid, unexpired)
- Proof of Residential Address (dated within 3 months)
- Ownership Percentage and ownership chain documentation
- Source of Wealth Declaration
- PEP Declaration
Business & Compliance Documentation:
- Business Description (detailed)
- Intended Use Case with Fin (specific API flows, corridors, currencies)
- Target Jurisdictions (end-user countries)
- Expected Transaction Volume (launch and 6/12 month projections)
- End-User Type (consumers, businesses, or both)
- End-User KYC/AML Policy
- End-User Terms of Service
- Privacy Policy
- Licensing Documentation (or explanation of why not applicable)
- AML/CFT Compliance Program (if regulated entity)
- Sanctions Screening Process
- Website / App URL
6. Onboarding SLA & Timeline
Standard Timeline
| Phase | SLA | Notes |
|---|
| Document Submission | Developer-dependent | Fin provides the checklist within 24 hours of kickoff. How quickly the developer submits is up to them |
| Initial Compliance Review | 1 business days from receipt of complete documentation | ”Complete” means all required documents received and readable — if documents are missing or illegible, the clock resets when the complete set is received |
| RFI (Request for Information) | 1 business day from identifying an issue during review | The developer’s response time to RFIs is the single biggest variable in onboarding speed |
| RFI Response Review | 2 business day from receipt of the developer’s response | |
| Final Approval | 1 business day after all RFIs resolved and review complete | |
All timelines are indicative and apply to standard-risk cases. Cases requiring enhanced due diligence (EDD), complex ownership review, PEP escalation, sanctions review, novel use cases, or banking partner clearance may require additional review time. Fin reserves the right to extend review timelines where required to meet regulatory obligations.
Typical End-to-End Timelines
Fast track (simple entity, clean documentation, no RFIs)— 1 business day
Standard (some RFIs, typical entity structure)— estimated 1–2 business days.
Complex (multi-jurisdiction entity, novel use case, multiple RFI rounds)— can extend to 10–30+ business days.
What Slows Down Onboarding — Common Delays
Incomplete documentation: The #1 cause of delay. If documents are missing, expired, or don’t match the information provided, the review cannot proceed. Developers should double-check that every item on the checklist is provided, current, and legible before submitting.
Slow RFI responses: When Fin’s compliance team asks follow-up questions, every day of delay on the developer’s side adds a day to the timeline. Developers should designate a single point of contact who can respond to RFIs within 1–2 business days.
Complex ownership structures: Entities with multiple layers of holding companies, trusts, or cross-border ownership chains require additional documentation and review at each level. Simplify or document the structure clearly upfront.
Restricted or high-risk indicators: If the developer’s entity, UBOs, or intended use case triggers enhanced due diligence (EDD) — for example, a UBO who is a PEP, or a use case involving high-risk corridors — additional review steps apply, which extend the timeline.
Unclear use case: If Fin’s compliance team cannot clearly understand how money will flow through the developer’s product, they will ask for clarification. Developers should provide a detailed flow-of-funds diagram as part of their business description.
7. Frequently Asked Questions
Q: Can I start integrating in the sandbox while my compliance review is in progress? A: Yes. Sandbox access does not require compliance approval. Developers are encouraged to begin integration immediately so that technical readiness and compliance approval complete around the same time.
Q: What happens if my entity structure changes after onboarding (e.g., new UBOs, change of jurisdiction)?
Ans: The developer must notify Fin of any material changes to their entity structure, ownership, or licensing status. Changes may trigger a re-review. Failure to notify may result in suspension of API access.
Q: Can I onboard multiple entities under one account?
Ans: Each legal entity that will use Fin’s APIs must be onboarded separately with its own KYB review. However, if multiple entities are part of the same group, the CSM can coordinate the onboarding to streamline overlapping documentation.
Q: What if I don’t have all the documents ready — can I submit partially?
Ans: Fin strongly recommends submitting a complete package. Partial submissions will not enter the review queue until all required documents are received. The compliance review SLA begins only when the complete set is submitted.
Q: My entity was recently incorporated and I don’t have a Certificate of Good Standing yet. What should I do?
Ans:For newly incorporated entities (typically less than 6 months old), a Certificate of Good Standing may not yet be available in certain jurisdictions. In such cases, Fin may accept:
- Certificate of Incorporation / Registration
- A recent official registry extract confirming the entity is active and in good standing
- Proof of registered address (if not reflected in the registry extract)
- Tax registration confirmation (if applicable)
Fin reserves the right to request a Certificate of Good Standing once it becomes available in the ordinary course.
Q: Do I need to provide documents in English?
Ans: All documents must be provided in English. If the original document is in another language, a certified English translation must be provided alongside the original.
Q: What format should documents be in?
Ans: PDF format is preferred. All documents must be clear, legible, and complete (no cropped pages). Photos of documents are acceptable only if they are high-resolution, fully legible, and show the complete document including all pages.
Q: Will my information be kept confidential?
Ans: Fin handles all KYB documentation in accordance with its privacy policy and applicable data protection regulations. Documents are stored securely and used solely for compliance and regulatory purposes. Fin may share information with regulatory authorities, banking partners, or auditors as required by law.
Q: What if my compliance application is rejected?
Ans: If Fin is unable to approve the developer’s onboarding, the CSM will communicate the decision. Depending on the reason, the developer may be able to address the issue and reapply. In some cases (e.g., entity is in a prohibited jurisdiction, or use case is outside Fin’s risk appetite), the rejection may be final. Fin is not obligated to disclose specific reasons for rejection beyond what is legally required.
Q: I’m a solo developer / freelancer — do I need a legal entity?
Ans: Yes. Fin onboards legal entities, not individuals. The developer must have a registered business entity (LLC, corporation, or equivalent in their jurisdiction) to enter into a commercial agreement with Fin.
8. Flow-of-Funds Diagram Template
Developers should include a diagram like this in their business description to help Fin understand how money moves through their product.
[Developer's End-User]
|
| (1) End-user initiates payment / deposit
↓
[Developer's Platform]
|
| (2) Developer calls Fin API to convert / transfer
↓
[Fin Orchestration Platform]
|
| (3) Fin processes: on-ramp, conversion, transfer, off-ramp
↓
[Recipient / Destination Account]
- What currency / stablecoin is involved at each step
- Whether the developer holds funds at any point (affects licensing requirements)
- What compliance checks the developer performs at step 1 (end-user KYC)
- What happens if a transaction fails at each step
If you have any questions, please reach out to compliance@fin.com or in your dedicated communication channel by tagging @Fin Support and we will get back to you with necessary details.
