Form CFPORTAL Files Dataset

The Form CFPORTAL Files dataset is the EDGAR-resident collection of every Form CFPORTAL and Form CFPORTAL/A submission filed by funding portals registering, or amending their registration, with the SEC under Section 4A(a)(1) of the Securities Act and Rule 400 of Regulation Crowdfunding. One record corresponds to one EDGAR accession — either an initial funding-portal registration application (CFPORTAL) or an amendment to a previously filed registration (CFPORTAL/A) — packaged as the canonical primary_doc.xml payload, a sec-api metadata.json envelope, the EDGAR XSL-rendered XHTML companion, and any PDF exhibits attached to the filing. The legal filer is the funding portal entity itself, the intermediary category created by Title III of the JOBS Act and defined in Exchange Act Section 3(a)(80); principals, control persons, and owners named inside the form are subjects of the disclosure rather than separate filers. Records are organized inside monthly ZIP containers under a YYYY/YYYY-MM.zip path. Coverage begins on January 29, 2016, the date Form CFPORTAL became available on EDGAR with the effective date of Regulation Crowdfunding's funding-portal regime, and runs to the present.

Dataset APIs

Dataset Files

What This Dataset Contains

The dataset captures the full population of EDGAR submissions accepted under submission types CFPORTAL and CFPORTAL/A since the form went live on January 29, 2016. Form CFPORTAL itself is the registration application a funding portal files with the SEC under Section 4A(a)(1) of the Securities Act and Rule 400 of Regulation Crowdfunding — the gating registration an entity must complete to act as an intermediary in Regulation Crowdfunding offerings without registering as a broker-dealer. The form mirrors a paper "Form Funding Portal" with a fixed set of named sections and four supporting schedules (A, B, C, D). EDGAR transports the form as a single XML document, primary_doc.xml, conforming to the SEC's crowdfunding schema, plus a stylesheet view rendered from that XML. The form has no inline XBRL component; the structured data is the form XML itself.

The amended form, CFPORTAL/A, uses the identical schema and root element. The differences relative to an initial filing are that <submissionType> carries CFPORTAL/A rather than CFPORTAL; <formData>/<identifyingInformation> includes an <amendmentExplanation> free-text block describing what changed; the principal roster is conveyed via <scheduleB> deltas rather than (or in addition to) a fresh <scheduleA>; and a withdrawal amendment carries <scheduleD>. Withdrawals of registration are not a separate dataset — they arrive as CFPORTAL/A submissions whose substantive payload is <scheduleD>. The dataset is distributed as monthly ZIP containers; record contents are XML, JSON, and PDF.

Content Structure of a Single Record

What one record is

One record in the Form CFPORTAL Files dataset corresponds to one EDGAR submission of either Form CFPORTAL or Form CFPORTAL/A. The unit of observation is the EDGAR accession number: every accession that EDGAR has accepted under submission types CFPORTAL or CFPORTAL/A is represented by exactly one record, and every record represents exactly one accession.

Physically, each record is one folder inside a monthly ZIP container. The folder is named with the 18-digit accession number with dashes stripped (the EDGAR accession 0001683168-25-007136 becomes the folder 000168316825007136), and the monthly ZIPs are organized inside the dataset under a YYYY/YYYY-MM.zip path so the unzipped tree is YYYY-MM/<accession>/.... Inside each accession folder the dataset places, at minimum, a sec-api metadata.json envelope, the canonical primary_doc.xml payload that EDGAR received, and an EDGAR XSL-rendered XHTML companion located at xslCFPORTAL_X01/primary_doc.xml. PDFs may also appear when the submission attaches an Exhibit C opinion of counsel under the nonresident-portal rules. Image files originally attached to the EDGAR submission are excluded from the dataset.

Files inside one record

Each per-accession folder contains the following artifacts:

• metadata.json — sec-api filing-level envelope describing the EDGAR submission header and enumerating the documents that were part of the original SGML wrapper.
• primary_doc.xml — the canonical Form CFPORTAL payload, an <edgarSubmission> XML document in the SEC crowdfunding namespace.
• xslCFPORTAL_X01/primary_doc.xml — the EDGAR XSL-rendered XHTML view of the same payload. The file extension is .xml but the body is <!DOCTYPE html> XHTML with embedded <style> rules and image references to /Images/box-checked.jpg and /Images/radio-unchecked.jpg. It carries no information beyond what is already in the raw XML.
• Optional PDF attachment(s) — present for nonresident funding portals that attach the opinion of counsel called for under Schedule C; otherwise absent.

The complete-submission .txt SGML wrapper that EDGAR also produces for the filing is referenced from metadata.json.documentFormatFiles[] and metadata.json.linkToTxt but is not redistributed inside the per-accession folder. The EDGAR -index.htm page is referenced from metadata.json.linkToHtml but likewise not bundled.

The metadata.json envelope

metadata.json is a flat JSON object derived from the EDGAR submission header. The keys carry the following meanings:

• formType — "CFPORTAL" or "CFPORTAL/A".
• accessionNo — accession with dashes (e.g. 0001683168-25-007136); the folder name is the same value with dashes stripped.
• effectivenessDate — ISO date of effectiveness as recorded by EDGAR.
• filedAt — ISO-8601 timestamp with timezone offset, e.g. 2025-09-19T10:55:10-04:00.
• description — the EDGAR description label, e.g. "Form CFPORTAL/A - [Amend]".
• id — sec-api internal 32-character hex identifier for the record.
• linkToFilingDetails — URL of the rendered xslCFPORTAL_X01/primary_doc.xml on sec.gov.
• linkToTxt — URL of the EDGAR .txt complete-submission wrapper.
• linkToHtml — URL of the EDGAR -index.htm page.
• linkToXbrl — empty string for this form type.
• documentFormatFiles[] — array of per-document descriptors, each with sequence, size (string, may be a single space when EDGAR did not record a byte size), documentUrl, type, and an optional description. For CFPORTAL filings this typically lists the rendered XML, the raw XML, and the .txt complete-submission file.
• dataFiles[] — empty for this form type (no XBRL or other supplementary data files).
• seriesAndClassesContractsInformation[] — empty for this form type.
• entities[] — one entry per filer with the EDGAR header fields: companyName (often suffixed with a role tag such as (Filer)), cik (unpadded), irsNo (digits-only EIN), fileNo (the SEC funding-portal file number, format 007-NNNNN), filmNo, stateOfIncorporation (two-letter code), fiscalYearEnd (MMDD), act ("34", the Exchange Act under which the funding-portal file number is issued), and type (echoes formType).

Cross-file identifier formatting differs predictably between the JSON envelope and the XML payload: entities[*].cik is unpadded while the same identifier appears zero-padded to ten digits inside the XML at headerData/filerInfo/filer/filerCredentials/filerCik; entities[*].irsNo is digits-only while formData/identifyingInformation/irsEmployerIdNumber carries the dashed NN-NNNNNNN form; entities[*].fileNo matches the value(s) inside formData/identifyingInformation/secFileNumbers.

The primary_doc.xml payload

The root element is <edgarSubmission> declared in the SEC crowdfunding namespace http://www.sec.gov/edgar/crowdfunding, with the com: prefix bound to http://www.sec.gov/edgar/common for shared address and person-name structures. Two siblings hang off the root: <headerData> (submission envelope) and <formData> (the substantive registration content). The same root element and namespace are used for both CFPORTAL and CFPORTAL/A; only the <submissionType> value and the schedules populated under <formData> differ.

<headerData> — submission envelope

• <submissionType> — string, CFPORTAL or CFPORTAL/A.
• <filerInfo>/<filer>/<filerCredentials> — the credentials used to submit on EDGAR: <filerCik> (zero-padded ten-digit CIK) and <filerCcc> (the CIK Confirmation Code, redacted as XXXXXXXX in archived public copies).
• <filerInfo>/<flags> — submission-level booleans <returnCopyFlag> and <overrideInternetFlag>.

<formData> — substantive registration content

<formData> contains a sequence of named sections that mirror the paper Form Funding Portal. The order below matches the schema and the rendered form. Not every section is populated in every filing; presence depends on filing context (initial vs. amendment, domestic vs. nonresident, ongoing vs. withdrawal, clean vs. disclosure-bearing). A parser should treat the children of <formData> as an open set rather than a fixed list, because the Disclosure Reporting Pages (DRPs) only appear when triggered by the <disclosureAnswers> matrix.

<identifyingInformation>

Identifies the portal and its primary contact. Children include:

• <nameOfPortal> — the funding portal's legal name as registered.
• <otherNamesAndWebsiteUrls> — one or more <webSiteOfPortal> URLs operated by the portal.
• <irsEmployerIdNumber> — formatted NN-NNNNNNN.
• <legalNameChange> — Y/N; when Y, <prevNamesAndWebsiteUrls> carries <prevWebSiteUrls> listing prior names and URLs.
• <portalAddress> and <portalMailingAddress> — built from com:street1, com:street2, com:city, com:stateOrCountry, com:zipCode, governed by a <mailingAddressDifferent> boolean that signals whether the mailing block is meaningful or echoes the principal address.
• <portalContact> — phone and email for the portal's primary contact channel.
• <contactEmployeeName> — com:firstName, com:middleName, com:lastName, accompanied by <contactEmployeeTitle>.
• <fiscalYearEnd> — month name (e.g. December); note that metadata.json.entities[*].fiscalYearEnd carries the same fact in MMDD form.
• <anyPreviousRegistrations> — Y/N, with <secFileNumbers> listing prior 007-NNNNN numbers when Y.
• <anyForeignRegistrations> — Y/N indicating non-U.S. regulatory registrations.
• <amendmentExplanation> — present only on CFPORTAL/A filings; free-text narrative describing what changed from the prior registration.

<formOfOrganization>

Captures legal form. Children: <legalStatusForm> (e.g. Limited Liability Company, Corporation, Limited Partnership), <jurisdictionOrganization> (state or country code), and <dateIncorporation> formatted MM-DD-YYYY.

<successions>

<isSucceedingBusiness> (Y/N); when Y, additional successor-entity detail elements appear identifying the predecessor and describing the succession event.

<controlRelationships>

One or more <fullLegalNames>/<fullLegalName> entries naming persons or entities that control or are controlled by the funding portal. The list is name-only; ownership percentages and titles are conveyed in Schedule A.

<disclosureAnswers>

A four-group Yes/No disclosure matrix. Every leaf is a Y/N flag; a Y answer triggers a corresponding DRP (Disclosure Reporting Page) under <formData>.

• <criminalDisclosure> — <isConvictedOfFelony>, <isChargedWithFelony>, <isConvictedMisdemeanor>, <isChargedMisdemeanor>.
• <regulatoryActionDisclosure> — seventeen flags covering SEC, CFTC, state, foreign, and SRO actions: <isMadeFalseStatement>, <isViolatedRegulation>, <isCauseOfDenial>, <isOrderAgainst>, <isImposedPenalty>, <isUnEthical>, <isFoundInViolationOfRegulation>, <isFoundInCauseOfDenial>, <isOrderAgainstActivity>, <isDeniedLicense>, <isFoundMadeFalseStatement>, <isFoundInViolationOfRules>, <isFoundInCauseOfSuspension>, <isDisciplined>, <isAuthorizedToActAttorney>, <isRegulatoryComplaint>.
• <civilJudicialActionDisclosure> — <isEnjoined>, <isFoundInViolationOfRegulation>, <isDismissed>, <isNamedInCivilProceeding>.
• <financialDisclosure> — <hasSubjectOfBankruptcy>, <hasTrusteeAppointed>, <hasBondDenied>, <doesAppHaveLiens>.

When any flag is Y, the form schema expects a matching DRP element tree under <formData> (Criminal DRP, Regulatory DRP, Civil Judicial DRP, Bankruptcy DRP, Bond DRP, Judgment-Lien DRP) carrying the narrative facts of the disclosed event: dates, jurisdictions, statutes or rules involved, sanctions, and resolution details.

<nonSecuritiesRelatedBusiness>

<isEngagedInNonSecurities> (Y/N) and, when Y, a <nonSecuritiesBusinessDesc> free-text description of the non-securities business activity.

<escrowArrangements>

One or more <investorFundsContacts> blocks naming the qualified third party that holds investor funds. Each block contains <investorFundsContactName>, an <investorFundsAddress> built from the com: address fields, and <investorFundsContactPhone>. A trailing <compensationDesc> free-text element describes how the qualified third party is compensated.

<execution>

The signature block of the form proper. Children: <executionDate> (MM-DD-YYYY), <fullLegalNameFundingPortal>, <personSignature> (an /s/ Name text signature), and <personTitle>.

<scheduleA> — direct owners and executive officers (initial filings)

A repeating <entityOrNaturalPerson> list. Each entry carries <fullLegalName>; <entityType> coded DE (domestic entity), FE (foreign entity), or NP (natural person); <titleStatus> (e.g. President, Managing Member, Director); <dateOfTitleStatusAcquired> formatted MM/YYYY; <ownershipCode> selected from NA, A, B, C, D, E, G corresponding to the form's percentage-ownership bands (NA = no equity; A = under 5%; B = 5–10%; C = 10–25%; D = 25–50%; E = 50–75%; G = 75% or more); a <controlPerson> Y/N flag; and optional identifiers <crdNumber>, <irsTaxNumber>, and <irsEmployerIdNumber> whose population depends on whether the principal is a natural person (CRD/IRS tax number) or an entity (EIN).

<scheduleB> — amendments to Schedule A

Used by CFPORTAL/A filings to record changes to the Schedule A roster. A repeating <amendEntityOrNaturalPerson> element carries the same fields as Schedule A plus a <typeOfAmendment> code:

• A — add a new principal,
• D — delete an existing principal,
• C — change the details of an existing principal.

A single Schedule B can mix all three codes; a single amendment may simultaneously delete a departed officer (D) and add an incoming one (A). Schedule B entries do not replace Schedule A wholesale — they are deltas keyed by <fullLegalName> against the most recently effective principal roster.

<scheduleC> — nonresident funding portal designation

Required for funding portals organized outside the United States; populated to designate a U.S. agent for service of process and to consent to service. Fields include <agentName>, <agentAddress> (using the com: address fields), <personSignature>, <printedName>, <personTitle>, and <signatureDate>. The Exhibit C opinion of counsel that nonresident funding portals must attach is delivered as a separate PDF inside the accession folder rather than inline in the XML. Some domestic filings carry a Schedule C populated with the portal's own U.S. address rather than a true nonresident-agent designation; consumers should confirm against <jurisdictionOrganization> from <formOfOrganization> before treating Schedule C presence as a nonresident signal.

<scheduleD> — withdrawal of registration

Populated when the funding portal is terminating its registration. Carries the withdrawal effective date, the reason for withdrawal, and a signature block. Withdrawals are filed as CFPORTAL/A submissions whose <formData> body is dominated by Schedule D; the submission type alone does not distinguish withdrawals from other amendments — Schedule D presence does.

The XSL-rendered companion

xslCFPORTAL_X01/primary_doc.xml is the EDGAR-side rendering of the same payload, produced by EDGAR's xslCFPORTAL_X01 stylesheet. Despite the .xml extension and folder name, the file body is XHTML beginning with <!DOCTYPE html>. It re-presents <formData> as a screen-readable form mock-up with section headers ("CFPORTAL/A: Identifying Information", "FORM FUNDING PORTAL SCHEDULE A", and so on), checkbox and radio glyphs drawn from /Images/box-checked.jpg and /Images/radio-unchecked.jpg, and embedded <style> rules. It carries no data beyond what is already in the canonical XML and loses some of the typed information (entity-vs-person disambiguation in <entityType>, ownership-band codes, amendment-type codes) that exists in the raw XML. Downstream extraction should always read from primary_doc.xml, not from this rendering.

Included content and excluded content

Each record includes:

• the sec-api metadata.json envelope,
• the canonical primary_doc.xml Form CFPORTAL payload,
• the EDGAR XSL-rendered XHTML view at xslCFPORTAL_X01/primary_doc.xml,
• any PDF attachments associated with the submission (typically the Exhibit C opinion of counsel for nonresident portals).

Each record excludes:

• image files originally attached to the EDGAR submission,
• the .txt complete-submission SGML wrapper (referenced from metadata.json.documentFormatFiles[] and linkToTxt, but not redistributed inside the accession folder),
• the EDGAR -index.htm page (referenced from metadata.json.linkToHtml, but not bundled).

The <filerCcc> element inside <headerData> is redacted as XXXXXXXX, consistent with how EDGAR archives the public copy of the submission.

Structural and regulatory evolution since January 29, 2016

Form CFPORTAL became available on EDGAR on January 29, 2016, the effective date for funding-portal registration under Regulation Crowdfunding. The XML schema, the root element <edgarSubmission> in http://www.sec.gov/edgar/crowdfunding, and the section layout under <formData> (identifying information, form of organization, successions, control relationships, the four-group disclosure matrix, non-securities-related business, escrow arrangements, execution, and Schedules A through D) have been stable across the dataset's history. The amendment mechanism — <submissionType> toggling to CFPORTAL/A, an <amendmentExplanation> narrative under <identifyingInformation>, and Schedule B deltas with A/D/C type codes — has been the same throughout. The dataset consequently has a substantially uniform internal record shape across all years; cross-filing comparisons rarely need version-specific handling at the schema level.

Interpretation and extraction notes

• Accession-folder naming. The folder name is the dashless 18-digit accession; metadata.json.accessionNo keeps the dashes. Convert by stripping -.
• CIK formatting. The XML at headerData/filerInfo/filer/filerCredentials/filerCik is zero-padded to ten digits; metadata.json.entities[*].cik is unpadded. Match by left-stripping zeros.
• EIN formatting. The XML at formData/identifyingInformation/irsEmployerIdNumber uses NN-NNNNNNN; metadata.json.entities[*].irsNo is digits-only.
• File-number formatting. The funding-portal file number 007-NNNNN appears in metadata.json.entities[*].fileNo and inside the XML at formData/identifyingInformation/secFileNumbers. The leading 007- segment is the SEC file-number prefix assigned to funding portals.
• Open-content <formData>. When any flag in <disclosureAnswers> is Y, expect additional DRP element trees as siblings under <formData>. Parsers should not hard-code the child set of <formData>.
• Amendments are deltas, not replacements. A CFPORTAL/A typically carries Schedule B rather than Schedule A; reconstructing a portal's current principal roster requires walking the chain of amendments and applying A/D/C deltas in filing order against the original Schedule A. Matching is by <fullLegalName>, so name normalization (whitespace, suffixes, capitalization) matters.
• Schedule C interpretation. Treat Schedule C as a nonresident-agent designation only when <jurisdictionOrganization> indicates a non-U.S. jurisdiction; some domestic filings populate Schedule C with the portal's own U.S. address.
• Withdrawal records. A funding-portal withdrawal arrives as a CFPORTAL/A whose substantive content is <scheduleD>. Distinguish withdrawals from ordinary amendments by Schedule D presence, not by submission type.
• Rendered file is derivative. The xslCFPORTAL_X01/primary_doc.xml rendering is for human display; field extraction should always operate on the canonical XML to avoid losing typed values such as <entityType> (DE/FE/NP), <ownershipCode> (NA/A/B/C/D/E/G), and <typeOfAmendment> (A/D/C).
• Shared com: namespace. Address blocks (portal, mailing, escrow contact, Schedule C agent) and person-name blocks (com:firstName/com:middleName/com:lastName) all use the common http://www.sec.gov/edgar/common namespace, so a single helper can extract any of them.
• No XBRL. metadata.json.linkToXbrl is empty and dataFiles[] is empty; the XML payload itself is the structured data.
• Date-format heterogeneity. Within one record, dates appear in three forms: YYYY-MM-DD (metadata.json.effectivenessDate), ISO-8601 with offset (metadata.json.filedAt), MM-DD-YYYY (<dateIncorporation>, <executionDate>, <signatureDate>), MM/YYYY (<dateOfTitleStatusAcquired>), and a textual month name (<fiscalYearEnd>). A normalizer should branch on field name rather than attempting a single date parser.

Who Files or Publishes This Dataset, and When

Who files

Each record in the Form CFPORTAL Files dataset is filed by a funding portal registering, or amending its registration, with the SEC. A funding portal is the intermediary category created by Title III of the Jumpstart Our Business Startups Act of 2012 (the JOBS Act) and defined in Exchange Act Section 3(a)(80) (15 U.S.C. § 78c(a)(80)): an entity that intermediates offers and sales under Securities Act Section 4(a)(6) (the Regulation Crowdfunding exemption) but is statutorily prohibited from offering investment advice or recommendations, soliciting purchases, compensating employees on transaction-based metrics, or holding investor funds or securities.

The legal filer is the portal entity itself, not an issuer, investor, or broker-dealer. Principals, control persons, executive officers, direct or indirect owners, and other associated persons named inside the form are subjects of the disclosure, not filers; they do not appear as separate EDGAR filers in this dataset.

Filing population

The population is narrow and well-defined:

• Non-broker-dealer crowdfunding intermediaries. Only entities seeking to intermediate Section 4(a)(6) offerings without broker-dealer registration file Form CFPORTAL. Broker-dealers that perform the same role remain registered on Form BD and do not appear here.
• FINRA members or applicants. Securities Act Section 4A(a)(1) and Rule 400(a) of Regulation Crowdfunding (17 CFR § 227.400(a)) require a funding portal to be a member of a national securities association registered under Exchange Act Section 15A. FINRA is the only such association; FINRA membership status is itself a Form CFPORTAL disclosure item.
• Domestic entities. Rule 400(a)(3) bars non-resident funding portals absent specific conditions, so the population is overwhelmingly U.S.-organized entities with U.S.-resident principals.

Issuers conducting Regulation Crowdfunding offerings (Form C, Form C/A, Form C-U, Form C-AR), purchasing investors, and broker-dealer crowdfunding intermediaries (Form BD) are excluded.

Triggering events

Two triggers produce records, matching the two form types in the dataset.

Form CFPORTAL (initial registration). Triggered when an entity applies to operate as a Regulation Crowdfunding funding portal. Securities Act Section 4A(a)(1) (15 U.S.C. § 77d-1(a)(1)) and Rule 400(a) of Regulation Crowdfunding require any intermediary in a Section 4(a)(6) transaction to register with the Commission as a broker or as a funding portal. Form CFPORTAL is the SEC-side mechanism by which a non-broker-dealer satisfies that obligation. Registration becomes effective on the later of (i) SEC grant and (ii) FINRA membership.

Form CFPORTAL/A (amendment). Rule 400(c) requires a registered funding portal to keep its registration current. Amendments are triggered by:

• material changes to previously disclosed information (business operations, principals, control affiliates, direct or indirect owners, disciplinary history, FINRA membership status), filed promptly,
• annual updates of designated items (within 30 days of fiscal year-end under Rule 400(c)), and
• corrections of inaccurate information.

A CFPORTAL/A is an update by an existing registrant, not a new registration. Withdrawal is filed separately on Form CFPORTAL-W and is outside the CFPORTAL / CFPORTAL/A pair captured in this dataset.

Statutory and regulatory authority

• JOBS Act, Title III ("Crowdfunding"), Pub. L. 112-106 (April 5, 2012) — created the funding portal concept and the Section 4(a)(6) exemption.
• Securities Act Section 4A(a)(1) (15 U.S.C. § 77d-1(a)(1)) — requires intermediaries in Section 4(a)(6) transactions to register as a broker or funding portal.
• Securities Act Section 4(a)(6) — the substantive crowdfunding exemption.
• Exchange Act Section 3(a)(80) (15 U.S.C. § 78c(a)(80)) — defines "funding portal" and its prohibited activities.
• Exchange Act Section 3(h) — authorizes the Commission to conditionally exempt funding portals from broker registration under Section 15(a)(1).
• Regulation Crowdfunding, 17 CFR Part 227, Subpart C, Rules 400-404 — the funding portal rules. Rule 400 governs registration and prescribes Form Funding Portal (Form CFPORTAL); Rule 401 sets the conditional broker-dealer exemption; Rule 402 imposes conduct requirements; Rule 403 governs investor education and communications; Rule 404 imposes recordkeeping. Rule 400(a)-(c) is the immediate hook for every record in the dataset.
• FINRA Funding Portal Rules / Form FP — a parallel FINRA filing required for membership; Form CFPORTAL is the SEC-side companion, but only the SEC submission generates an EDGAR record.

Form CFPORTAL is not an Exchange Act periodic report (10-K, 10-Q, 8-K), not a Securities Act offering document (S-1, Form C), and not an investment-management form (Form ADV, Form N-PORT). It is a registration application sui generis to the Regulation Crowdfunding intermediary regime.

Timing and deadline logic

Form CFPORTAL is event-driven, not periodic:

• EDGAR availability. Form CFPORTAL became available for electronic filing on January 29, 2016, when Regulation Crowdfunding's funding portal registration regime took effect. No records predate that day; the dataset's earliest sample date of 2016-01-01 reflects the opening of the filing window.
• Initial filing. Submitted when an entity applies to register. Effectiveness requires both SEC action and FINRA membership; the two processes typically run in parallel.
• Amendments. Rule 400(c)(1) requires prompt amendment on Form CFPORTAL/A whenever previously reported information becomes inaccurate. Specified items also require an annual update within 30 days after fiscal year-end. There is no quarterly cadence.
• Withdrawal. Handled on Form CFPORTAL-W, outside this dataset.

Per-portal volume varies: an active portal may produce one initial CFPORTAL and several CFPORTAL/A amendments over its lifetime; a short-lived portal may produce a single record.

Important distinctions

• Funding portals vs. broker-dealers. Both may intermediate Regulation Crowdfunding offerings, but only funding portals file Form CFPORTAL. Broker-dealers stay on Form BD and are not in this dataset.
• Funding portals vs. issuers. Crowdfunding issuers file Form C (offering), Form C/A (amendments), Form C-U (progress updates), and Form C-AR (annual reports) — separate EDGAR series, not part of this dataset.
• SEC Form CFPORTAL vs. FINRA Form FP. Funding portals register with both regulators. Form CFPORTAL is the SEC filing on EDGAR; Form FP is the FINRA filing and does not appear in EDGAR.
• Filer vs. disclosed persons. The legal filer is the portal entity. Principals, officers, directors, control persons, and direct or indirect owners named in the form are subjects, not separate EDGAR filers, even when their names, CRD numbers, and affiliations appear in the XML.
• CFPORTAL/A is amendment, not re-registration. A CFPORTAL/A reflects an update by an existing registrant; distinguishing it from CFPORTAL is essential when counting unique portals versus filings.
• No pre-EDGAR history. The regime did not exist before Regulation Crowdfunding's January 29, 2016 effective date, so every record in the filing universe was, from inception, an electronic EDGAR submission.

How This Dataset Differs From Similar Datasets or Filings

Form CFPORTAL is the SEC's intermediary-side registration record for funding portals operating under Section 3(h) of the Exchange Act and Regulation Crowdfunding. Several adjacent forms cover related populations or related disclosures, but each answers a different question. The comparisons below clarify which form to reach for in each scenario.

Form C, C-U, C-AR, C-TR (issuer-side Regulation Crowdfunding filings)

The Form C family is the issuer-side mirror of CFPORTAL. Form C is filed by the issuer raising capital under Reg CF; Form C-U reports progress against the target; Form C-AR is the post-raise annual report; Form C-TR terminates that annual reporting obligation. All four are filed by the company selling securities, not by the platform.

The overlap is regime-level only: Form C filings reference the funding portal through which the offering runs, but the data captured is fundamentally different. CFPORTAL captures the intermediary itself (identity, ownership, control persons, employee composition, FINRA membership). The Form C family captures the offering (issuer business, target amount, financial statements, ongoing disclosure).

Reach for CFPORTAL to map platforms; reach for Form C to map deals, issuers, or raise outcomes.

Form CFPORTAL-W (funding portal withdrawal)

CFPORTAL-W is the deregistration filing that closes a funding portal's SEC registration. CFPORTAL and CFPORTAL/A cover entry and updates; CFPORTAL-W covers exit. To build an active-vs-inactive roster of crowdfunding intermediaries over time, both datasets are required.

Reach for CFPORTAL to see who entered and what they look like; reach for CFPORTAL-W to see who left.

Form BD (broker-dealer registration)

Form BD is the SEC's general broker-dealer registration application. It is the closest structural analog to CFPORTAL: both are intermediary-registration forms covering business operations, ownership, control persons, and regulatory history. The regulatory split is sharp. Section 3(h) of the Exchange Act, added by the JOBS Act, exempts funding portals from broker-dealer registration so long as they limit their activity to Reg CF intermediation. A pure funding portal therefore files CFPORTAL and not BD. A dual-registered broker-dealer that also operates a portal will appear in both datasets.

Reach for Form BD for the full broker-dealer industry; reach for CFPORTAL for Reg CF-only intermediaries operating under the Section 3(h) exemption.

FINRA Form FP (Funding Portal)

Form FP is FINRA's companion registration. Every SEC-registered funding portal must also become a FINRA member and file Form FP, and the two forms ask overlapping questions about ownership, control, and operations. The decisive difference is venue. Form FP is filed with FINRA, lives in FINRA systems, and is not on EDGAR; it is not in this dataset and cannot be retrieved through SEC dataset infrastructure.

Reach for CFPORTAL for the EDGAR-resident, machine-retrievable view of funding portal registration. Form FP is only relevant when the research specifically requires the FINRA-side record.

Form ATS and Form ATS-N (alternative trading systems)

Form ATS and Form ATS-N are filed by alternative trading systems under Regulation ATS. Like CFPORTAL, they are EDGAR-resident, intermediary-registration forms describing a trading venue's business model, operations, and control structure. The economic function is unrelated. ATS/ATS-N venues match orders in already-issued securities, typically for institutional and secondary-market trading; CFPORTAL intermediaries facilitate primary capital formation by small issuers under Reg CF. ATS-N is also a substantially deeper disclosure regime focused on order handling, subscriber access, and conflicts.

Useful as a structural analog for understanding intermediary-disclosure design; not a population overlap.

Form ADV (investment adviser registration)

Form ADV is the registration application for investment advisers under the Investment Advisers Act of 1940. Structurally it resembles CFPORTAL in capturing firm identity, ownership, control persons, disciplinary history, and operations, and it is the highest-volume intermediary-registration form on EDGAR. The regulatory regimes do not overlap. ADV filers provide investment advice for compensation; CFPORTAL filers run Reg CF offering platforms and are explicitly prohibited from providing investment advice. ADV also covers tens of thousands of filers with a deep amendment history, while CFPORTAL covers a small specialized population.

Reach for ADV when the question is about advisers; CFPORTAL is not substitutable.

Boundary summary

CFPORTAL is the EDGAR-resident, intermediary-side registration record for funding portals operating under Section 3(h) and Regulation Crowdfunding. It is distinct from:

• issuer-side Reg CF filings (Form C family) — different filer, different content
• the lifecycle-exit filing (CFPORTAL-W) — same regime, opposite endpoint
• the general broker-dealer regime (Form BD) — mutually exclusive for pure portals
• the FINRA-side companion (Form FP) — parallel content, different venue, off-EDGAR
• unrelated intermediary registrations (ATS/ATS-N, ADV) — structural similarity only

For who the funding portals are, what their ownership and control structure looks like, and how those facts have changed through amendments, CFPORTAL is the primary source. Every other question routes to one of the forms above.

Who Uses This Dataset

A small set of professional users reads Form CFPORTAL filings, each focused on specific record components: Schedule A and B (direct and indirect owners, control persons), the disclosure answers section (regulatory, civil, criminal, and financial history), FINRA membership and CRD identifiers, escrow agents and custody arrangements, address and jurisdiction fields, and the amendment trail in CFPORTAL/A filings.

Portal compliance officers and securities counsel

In-house compliance staff and outside counsel at funding portals use the dataset to draft and maintain their own CFPORTAL filings. They benchmark peer language on business activities, compensation, escrow agents, and conflicts; pattern-match the disclosure answers section for how others phrase regulatory and disciplinary events; and use prior CFPORTAL/A filings as templates when onboarding associated persons or amending after a control change. Disclosure answers also feed supervisory procedures around reportable events such as customer complaints, arbitration awards, and statutory disqualifications.

Examination and policy staff at the funding portal regulator and the Commission

Registration, examination, and policy staff use the full CFPORTAL/CFPORTAL/A series to confirm continuity of disclosure, flag inconsistencies between successive filings, and reconcile against FINRA membership and CRD records. The disclosure answers section, Schedule A and B ownership, and escrow arrangements drive risk-based exam scoping. Policy analysts use the population to track entrants, withdrawals, and disclosure trends informing rulemaking under Section 4A(a)(1).

Reg CF issuer-side counsel and finance leads

Issuers selecting an intermediary read CFPORTAL filings as diligence on the portal itself: registration status, Schedule A principals and control persons, FINRA membership, and any events flagged in the disclosure answers section. Escrow arrangement disclosures matter when negotiating how investor funds will be held during the offering window. Amendment frequency is checked for ownership churn or repeated disclosure restatements that signal instability.

Investor-side diligence teams

Family offices, small institutional allocators, and active retail investors deploying capital through Reg CF use the dataset to vet the intermediary alongside the issuer. They focus on control-person identities on Schedule A, compensation and equity arrangements with issuers, conflicts disclosed in the business description, and the disclosure answers section as a portal-level risk overlay on top of Form C issuer diligence.

Corporate development and M&A teams

Corp dev at fintech operators, payments firms, and broker-dealers entering the Reg CF market uses the dataset to build acquisition and partnership pipelines. The registrant list combined with Schedule A and B, business descriptions, and amendment histories segments candidates by ownership and model. The disclosure answers section is screened during preliminary diligence for issues affecting transaction risk and post-closing licensing.

Escrow agent and custodian counterparty teams

Banks and qualified custodians acting as escrow agents for Reg CF offerings use the dataset to confirm they are correctly named in each portal's escrow arrangement disclosures, watch amendments that would change those relationships, and review control-person and disciplinary disclosures as input to KYC and counterparty risk monitoring.

Fintech researchers and academics

Researchers treat the dataset as the authoritative population of registered portals. Address fields map geographic concentration; filing dates track entry and exit; Schedule A and B reveal ownership structures; FINRA flags show overlap with broker-dealer infrastructure. Linked with Form C and Form C-AR, it supports empirical work on intermediary characteristics, market structure, and capital formation outcomes.

Investigative journalists and policy researchers

Reporters covering portal failures or enforcement actions, and policy researchers at think tanks and advocacy groups working on small-business capital formation, follow amendment chains to reconstruct ownership and control changes and mine the disclosure answers section for prior regulatory or criminal events involving principals. When a portal collapses, the CFPORTAL/A trail is the primary public record of what was disclosed and when.

Attention across these users concentrates on the same record components: Schedule A and B, the disclosure answers section, FINRA membership status, escrow and custody arrangements, address and jurisdiction fields, and the amendment trail. The dataset supports drafting, supervision, diligence, market mapping, and accountability work across the Reg CF intermediary regime.

Specific Use Cases

Concrete workflows the Form CFPORTAL Files dataset supports. Each task below names the specific record components that drive it.

Build a current roster of registered funding portals

Iterate every accession folder, group by metadata.json.entities[*].cik, take the most recent filing per CIK by filedAt, and exclude any CIK whose latest primary_doc.xml carries a populated <scheduleD>. The resulting CIK list with <nameOfPortal>, <webSiteOfPortal>, secFileNumbers (007-NNNNN), and <portalAddress> is the active-registrant roster used for market sizing, regulator-side population checks, and downstream linkage to Form C issuer filings.

Reconstruct each portal's principal roster over time

Walk the CFPORTAL/CFPORTAL/A chain for one CIK in filedAt order. Seed the roster from <scheduleA>/<entityOrNaturalPerson> on the initial filing, then apply each <scheduleB>/<amendEntityOrNaturalPerson> delta keyed on <fullLegalName> using the <typeOfAmendment> codes (A add, D delete, C change). The output is a time-stamped principal roster carrying <titleStatus>, <ownershipCode> band (NA/A/B/C/D/E/G), <controlPerson> flag, and <crdNumber> — the input most diligence teams, examiners, and journalists actually want.

Flag portals with disclosed regulatory, criminal, or financial history

Scan <formData>/<disclosureAnswers> across all current filings for any Y flag in the four sub-blocks (<criminalDisclosure>, <regulatoryActionDisclosure> 17 flags, <civilJudicialActionDisclosure>, <financialDisclosure>). For each Y, pull the matching DRP element tree under <formData> for dates, statutes, sanctions, and resolution. The resulting flag table feeds risk-based exam scoping, issuer-side counsel diligence on platform choice, and counterparty KYC files at escrow banks.

Detect withdrawals and build the entry/exit timeline

Filter to CFPORTAL/A submissions where <formData>/<scheduleD> is populated (submission type alone does not distinguish withdrawals from ordinary amendments). Pair the <scheduleD> effective date and reason with the entity's earliest CFPORTAL filedAt to compute portal lifespans, year-over-year entry and exit counts, and the active-vs-inactive split for any historical date.

Map escrow-bank counterparty exposure across the industry

Extract <escrowArrangements>/<investorFundsContacts> blocks from each portal's most recent filing — <investorFundsContactName>, <investorFundsAddress>, and <compensationDesc>. Group by qualified-third-party name to produce a counterparty map showing which banks hold investor funds for which portals, then watch CFPORTAL/A <amendmentExplanation> text for changes that would re-route those flows.

Identify nonresident funding portals and pull opinions of counsel

Select records where <formOfOrganization>/<jurisdictionOrganization> is non-U.S. and <scheduleC> is populated with a U.S. agent for service of process (<agentName>, <agentAddress>, <signatureDate>). For each, retrieve the PDF attachment in the accession folder — the Exhibit C opinion of counsel — to assemble the cross-border portal subset for policy analysis or jurisdictional risk review.

Benchmark peer disclosure language for drafting

Aggregate <nonSecuritiesBusinessDesc>, <compensationDesc>, <amendmentExplanation>, and DRP narrative blocks across peer portals matched on <legalStatusForm> and rough principal-count. Compliance officers and outside counsel use the corpus to pattern-match phrasing when drafting an initial CFPORTAL, an amendment after a control change, or a disclosure narrative for a newly reportable event.

Track ownership churn as an instability signal

Count CFPORTAL/A filings per portal per rolling twelve months and bucket the Schedule B deltas by <typeOfAmendment>. A high A+D rate on <controlPerson>=Y rows, repeated changes to the same <fullLegalName> row, or a cluster of <legalNameChange>=Y events signals ownership instability — a screen used by issuer-side counsel selecting an intermediary and by corp-dev teams pricing acquisition risk.

Dataset Access

The Form CFPORTAL Files dataset is available through three access methods: a metadata index endpoint, a full dataset archive download, and per-container file downloads.

Dataset Index JSON API: https://api.sec-api.io/datasets/form-cfportal-files.json

This endpoint returns dataset-level metadata (name, description, last updated timestamp, earliest sample date, form types, container format, and file types) along with the full list of container files available for download. Each container entry includes its relative key, byte size, record count, last updated timestamp, and a direct download URL. Poll this endpoint to detect which containers were refreshed in the most recent update run and download only the containers that changed. This endpoint does not require an API key.

Example response:

          1
          {
        

          2
            "datasetId": "1f13365b-9ae0-69ac-8d60-609c040e6b42",
        

          3
            "datasetDownloadUrl": "https://api.sec-api.io/datasets/form-cfportal-files.zip",
        

          4
            "name": "Form CFPORTAL Files Dataset",
        

          5
            "updatedAt": "2026-04-15T12:09:13.192Z",
        

          6
            "earliestSampleDate": "2016-01-01",
        

          7
            "totalRecords": 1583,
        

          8
            "totalSize": 66503643,
        

          9
            "formTypes": ["CFPORTAL", "CFPORTAL/A"],
        

          10
            "containerFormat": "ZIP",
        

          11
            "fileTypes": ["XML", "JSON", "PDF"],
        

          12
            "containers": [
        

          13
              {
        

          14
                "downloadUrl": "https://api.sec-api.io/datasets/form-cfportal-files/2026/2026-04.zip",
        

          15
                "key": "2026/2026-04.zip",
        

          16
                "size": 1842560,
        

          17
                "records": 14,
        

          18
                "updatedAt": "2026-04-15T12:09:13.192Z"
        

          19
              }
        

          20
            ]
        

          21
          }
        

Download Entire Dataset: https://api.sec-api.io/datasets/form-cfportal-files.zip?token=YOUR_API_KEY

Downloads the complete dataset as a single ZIP archive covering all CFPORTAL and CFPORTAL/A filings from January 2016 to present. This endpoint requires an API key passed via the token query parameter.

Download Single Container: https://api.sec-api.io/datasets/form-cfportal-files/2026/2026-04.zip?token=YOUR_API_KEY

Downloads one monthly container file instead of the full archive. Substitute the desired containers[].key value from the index JSON response into the path. This endpoint requires an API key passed via the token query parameter.

Frequently Asked Questions

What forms does this dataset cover?

The dataset covers Form CFPORTAL (initial funding-portal registration application) and Form CFPORTAL/A (amendment to a previously filed registration). Withdrawals of registration arrive as CFPORTAL/A submissions whose substantive payload is <scheduleD>. Form CFPORTAL-W is a separate filing series and is not included.

What does one record in this dataset represent?

One record corresponds to one EDGAR accession of either Form CFPORTAL or Form CFPORTAL/A. Physically, it is a folder named with the dashless 18-digit accession number, located inside a monthly ZIP container at YYYY/YYYY-MM.zip, and containing a sec-api metadata.json envelope, the canonical primary_doc.xml payload, an EDGAR XSL-rendered XHTML companion at xslCFPORTAL_X01/primary_doc.xml, and any PDF exhibits.

Who is required to file Form CFPORTAL?

The legal filer is the funding portal entity itself — an intermediary defined in Exchange Act Section 3(a)(80) that intermediates Section 4(a)(6) (Regulation Crowdfunding) offerings without registering as a broker-dealer. Securities Act Section 4A(a)(1) and Rule 400(a) of Regulation Crowdfunding also require funding portals to be members of FINRA. Principals, control persons, and owners named in the form are subjects of the disclosure rather than separate filers.

What time period does the dataset cover?

The dataset covers all CFPORTAL and CFPORTAL/A filings submitted to EDGAR from January 29, 2016 — the date Regulation Crowdfunding's funding-portal registration regime took effect — to the present. The earliest sample date in the dataset metadata is 2016-01-01, reflecting the opening of the filing window. No records predate the regime.

How does this dataset differ from the issuer-side Form C family?

CFPORTAL captures the intermediary itself: identity, ownership, control persons, FINRA membership, escrow arrangements, and disciplinary disclosure. The Form C family (Form C, C/A, C-U, C-AR, C-TR) is filed by the issuer raising capital under Reg CF and captures the offering — issuer business, target amount, financial statements, and ongoing disclosure. Use CFPORTAL to map platforms; use Form C to map deals, issuers, or raise outcomes.

What file formats are inside each record?

Each accession folder contains XML (primary_doc.xml, plus the XSL-rendered XHTML at xslCFPORTAL_X01/primary_doc.xml which uses an .xml extension but an XHTML body), JSON (metadata.json), and optional PDF attachments — typically the Exhibit C opinion of counsel for nonresident funding portals. Image files originally attached to the EDGAR submission are excluded, as are the .txt complete-submission SGML wrapper and the -index.htm page (both referenced from metadata.json but not redistributed).

How do amendments work in this dataset?

A CFPORTAL/A is an update by an existing registrant under Rule 400(c), not a new registration. Amendments use the same <edgarSubmission> schema as the initial filing but carry <submissionType> CFPORTAL/A, an <amendmentExplanation> narrative, and a <scheduleB> delta keyed on <fullLegalName> with <typeOfAmendment> codes A (add), D (delete), or C (change). Reconstructing a portal's current principal roster requires walking the chain of amendments and applying these deltas in filedAt order against the original Schedule A.