The Form MA-A Files Dataset is a structured archive of every Form MA-A annual update — the firm-level annual amendment to Form MA — filed on EDGAR by registered municipal advisors under Section 15B of the Securities Exchange Act of 1934 and Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. A single record is one EDGAR accession folder representing one Form MA-A submission, packaging the structured XML form, an XHTML rendering, any disclosure-related PDF exhibits, and a JSON metadata envelope. Filers are registered municipal advisor firms required by SEC Rule 15Ba1-5(a)(1) to file within 90 days of each fiscal year end. The dataset begins on January 1, 2015, covering essentially the full EDGAR history of Form MA-A under the permanent municipal advisor registration regime, and is delivered as yearly ZIP containers partitioned into monthly batches with XML, JSON, and PDF file types.
Programmatically retrieve the full list of dataset archive files, download URLs and dataset metadata.
Dataset Index JSON API
Download the entire dataset as a single archive file.
Download Entire Dataset:
Download a single container file (e.g. monthly archive) from the dataset.
Download Single Container:
Form MA-A is the annual amendment to Form MA, the registration application for municipal advisors created under Section 15B of the Securities Exchange Act of 1934 as amended by Section 975 of Dodd-Frank. A municipal advisory firm that has registered on Form MA must file Form MA-A within 90 days of its fiscal year end to refresh the information on its registration record: identification, principal and mailing addresses, control persons, regulatory and disciplinary status, business activities, workforce, and the firm's relationships with the municipal entities and obligated persons it advises. MA-A is filed natively as a structured XML submission against the EDGAR mafiler schema, so the record is not a narrative document but a populated form whose every checkbox, radio button, table row, and disclosure flag corresponds to a typed XML element. Periods of report typically fall on calendar fiscal year-ends (2023-12-31, 2024-12-31), and the same firm accumulates one MA-A record per fiscal year over time.
The dataset is delivered as yearly ZIP archives partitioned into monthly batches. The outer organization is form-maa-files/<year>/<year>-<month>.zip, and each ZIP unpacks into a single dated folder (for example 2025-09/) whose immediate children are the per-accession folders. There is no further nesting between the monthly batch and the accession folder, and there are no cross-record indexes within the ZIP — metadata.json inside each accession folder is the record-local manifest. Image files from the original EDGAR submission are intentionally excluded; every other document in the original submission is preserved. The file types present in the dataset are XML, JSON, and PDF.
Form MA-A has been filed as a structured XML submission since the form's introduction in 2014, and the dataset begins in January 2015. The schema components — the edgarSubmission root, the headerData/formData split, the mafiler and ma_drp namespaces, the schedule and disclosure layouts, the controls block, and the execution page — have been stable across the dataset's coverage window, so historical records share the same parser-friendly shape as recent ones. What changes across records is which optional sub-elements are populated, driven by the flags in the controls block and the answers in disclosureAnswers; the schema itself is essentially constant, with only minor enumeration additions over time. Because the form was born XML-native, there is no ASCII or HTML-only legacy stratum to reconcile.
A single record in the Form MA-A Files Dataset is one EDGAR accession folder representing one Form MA-A submission filed by a registered municipal advisor. The record unit is the accession, not the firm: each annual update is its own record, and a firm that files several back-dated amendments on the same day produces several side-by-side accession folders, each treated as an independent record. The folder name is the 18-digit EDGAR accession number with the two hyphens removed (for example 000094990825000003), and the parent of that folder is a monthly batch directory (YYYY-MM/) inside a yearly ZIP archive (YYYY/YYYY-MM.zip). Within each accession folder the record consists of a small, predictable set of artifacts: a metadata.json envelope wrapping the EDGAR header, a structured primary_doc.xml carrying the authoritative form data, a nested xslFormMA_X01/primary_doc.xml holding the EDGAR XHTML rendering of that same data, and any DRP-triggered PDF exhibits when the filer has reportable disclosure events.
Inside one accession folder there are two structured files plus a presentation rendering, and optionally one or more PDF exhibits:
metadata.json — a flat JSON object that wraps the EDGAR submission header. It carries formType (always "MA-A"), accessionNo in its hyphenated EDGAR form (0001730816-25-000008), filedAt as an ISO-8601 timestamp with timezone, and periodOfReport as the fiscal year-end being amended (2023-12-31). The description field repeats the upstream EDGAR human-readable form name verbatim, including the upstream typo Munipal in "Form MA-A - Annual Update of Munipal Advisor Registration for Business Entities". It also contains linkToFilingDetails, linkToTxt, linkToHtml, and linkToXbrl (the last is an empty string, since MA-A is not an XBRL form), a documentFormatFiles[] array describing each document in the original EDGAR submission with sequence, size, documentUrl, type, and optional description, and an entities[] array with the filer's cik, companyName (suffixed (Filer)), fileNo (the SEC MA file number, prefix 867-), irsNo, stateOfIncorporation, fiscalYearEnd (MMDD), act ("34"), filmNo, and type. seriesAndClassesContractsInformation[] and dataFiles[] are present but empty for MA-A.
primary_doc.xml — the authoritative machine-readable Form MA-A submission. The root element is <edgarSubmission> in the namespace http://www.sec.gov/edgar/mafiler, with companion namespaces common_ma, common, ma_drp, and ma_common_drp for shared element types and the Disclosure Reporting Page schema. All form data lives here.
xslFormMA_X01/primary_doc.xml — despite the .xml extension, this is an XHTML 1.0 Strict document, the human-readable rendering produced by EDGAR's xslFormMA_X01 stylesheet. It declares the MA filing namespaces (m1, ns1, n1, ns2, n2, ns3) and lays the form out with hardcoded labels, instructional copy, checkbox and radio-button images (box-checked.jpg, radio-unchecked.jpg), <input readonly> controls, and fakeBox divs holding the same values present in the structured XML. It contains no data not already in primary_doc.xml and exists for display.
Optional PDF exhibits — supporting documents (court papers, administrative orders, settlement agreements, and similar) attached when the filer has triggered Disclosure Reporting Pages. Routine MA-A filings without disclosure events have no PDFs.
primary_doc.xmlThe structured filing has two top-level children under <edgarSubmission>: <headerData> and <formData>.
<headerData> — the submission envelopeThis block carries routing and notification information rather than substantive form content. It contains <submissionType>MA-A</submissionType>, a <filerInfo> element wrapping a <filer> (with filerId equal to the CIK and filerCcc masked as XXXXXXXX), and <contact> and <contactEmail> elements naming the human EDGAR-filing contact and their phone. An optional <notifications> element holds one or more <internetNotificationAddress> entries listing email addresses that EDGAR notifies on submission events.
<formData> — the body of Form MA-AThis is the core of the record and reflects the printed Form MA-A page-by-page. The notable element groupings, in their schema order, are:
Firm identification — fiscalYearEnd, hasChanges (Y/N flag indicating whether material changes have been made since the prior MA or MA-A), firmName, firmCrdNumber (the MSRB/CRD identifier), irsNum, and an optional previousLegalName when the firm has renamed itself.
Registrations — a registrations block listing the firm's SEC registrations: a maRegistration (with fileNumber and where applicable crdNumber), an optional maTregistration for the legacy temporary Form MA-T registration that preceded permanent registration, and bdRegistration for firms that are also broker-dealers cross-registered on the same record.
Addresses and primary contacts — principalOfficeAddress (street, city, state, zip code, phone), mailingAddressDifferent (the conditional mailing address when the mailing location is not the principal office), primaryWebAddress, a cco block with the chief compliance officer's name, titles, phone, and email, and a contactPerson block for the day-to-day regulatory contact.
Form of organization — formOfOrganization containing a formOrgType/formOrgTypes/<choice> selector (LLC, Corporation, partnership, sole proprietorship, etc.), monthOfFiscalYearEnd, organizedJurisdiction/stateOrCountry, dateOfOrganization, and isPrcApplicant indicating whether the applicant is a "person responsible" for the registration.
Workforce metrics — numberOfEmployees, employeesEngagedInMAA (the count engaged in municipal advisory activities), maaEmployeesRegBD (those also registered as broker-dealer associated persons), maaRegIA (those also registered with an investment adviser), and numberOfSolicitingFirms.
Client and activity profile — clientsServedAsMA, typesOfClients (an enumerated list under clientTypes), counts of solicited municipal entities (numberOfSolicitedME), obligated persons (numberOfSolicitedOP), their total (totalNumberOfSolicitedMEAndOP), typesOfSolicitedPersons with an optional spOtherDescription free-text field for the "other" category, meOrOPCompensationTypes, solicitationCompensationTypes, engagedActivities with optional eaTypeOtherDescription, and otherActivities containing per-activity sub-elements (such as engineering) that each carry isActivelyEngaged and isPrimaryBusiness flags.
Conflicts and other businesses — isEngagedInOtherNonMAABusiness, totalFIAAssociatedPersons, and a participationInterestMACT block of roughly thirteen Y/N booleans describing the advisor's participation interests with respect to its municipal-entity and obligated-person clients (trading, derivatives, discretionary authority, broker-dealer recommendation, referral-compensation arrangements, and similar potential conflict areas).
Miscellaneous narrative — a miscellaneous free-text element carrying optional supplemental disclosure that does not fit elsewhere.
Disclosure answers — disclosureAnswers with three nested sub-blocks: criminalDisclosure, regulatoryDisclosure, and civilDisclosure. Each sub-block is a long set of Y/N flags covering felony charges and convictions, regulatory orders and findings, civil enjoinments, and analogous events for the firm and its associated persons. When any flag is Y, the schema accommodates one or more Disclosure Reporting Pages serialized through the ma_drp and ma_common_drp namespaces. DRPs carry structured fields about the type of action, the initiating authority, the date and resolution, the persons involved, and the current status. They are also the principal trigger for supplementary attachments — when supporting documents are required, they ride along as PDFs in the same accession folder.
Size attestations — hasAnnualReceiptsLessThan7Million and isAffiliatedWithReceiptsMoreThan7Million, which together place the firm in a small/large-entity bucket relevant to certain regulatory thresholds.
Schedule A and Schedule C — control-person rosters serialized as scheduleA and scheduleC. Each contains a persons/person list, where every person carries a name plus a baseInformation element with titleStatus, statusAcquired, ownershipCode, an isControPerson flag (typo preserved upstream), and crdNumber. Schedule A enumerates direct owners and control persons; Schedule C enumerates indirect owners through nested directPersons and indirectPersons groupings, and is conditionally populated based on the firm's ownership structure. Schedule B is referenced only by the hasScheduleB control flag and is not populated for entity filers in this dataset.
Execution page — maExecutionPage containing signature, signerName, title, and date plus the signer's crdNumber. This is the digital analogue of the wet-signature execution page on the printed form.
Controls block — a final controls element listing Y/N booleans that drive conditional schedules and conditional sub-elements throughout the form: isSolePropietor (typo preserved), hasNameChange, hasDBAName, hasMATReg, additionalRegs, additionalOffices, hasMailingAddress, hasAdditionalWebsites, hasBooksRecords, isRegisteredFFRA, isAffiliatedOtherBus, independentBusinessEmployee, receiveCompensationForMAAFromOtherClients, isSucceedingApplicant, isCPForApplicantPolicy, isPRCompanyUnder1215, hasScheduleB, isSection12Or15ReportingCompany, and isOtherNonMAABuisinesssPrimary (typo preserved). These flags function as a manifest of which optional sections and sub-elements elsewhere in the document are populated.
Each record contains the full original EDGAR submission (the structured XML primary document, the XSL-rendered XHTML primary document, and any DRP-triggered PDF attachments) plus the metadata.json envelope. Image files attached to the original submission are deliberately excluded; every other document in the original submission is preserved. The XSL-rendered file is a faithful presentation duplicate and contains no information beyond what is in primary_doc.xml, so structured extraction should target the structured XML and treat the XHTML rendering as optional. Form MA-A is structured natively in its own XML schema rather than in XBRL, so linkToXbrl in metadata.json is empty and no XBRL artifacts appear in the record.
A Form MA-A record corresponds to one fiscal-year update. Because firms must file within 90 days of fiscal year end, records concentrate in the months following common fiscal year-ends (notably the first quarter for December-31 filers). Firms occasionally file multiple back-dated amendments on the same day to correct or update prior annual periods, and these appear as several adjacent accession folders sharing the same CIK but carrying different periodOfReport values; each is an independent record. The hasChanges flag in formData distinguishes substantive amendments from routine reaffirmations, and the previousLegalName element appears only when the firm renamed itself between updates.
A small set of element names and human-readable strings inherited from upstream EDGAR contain typos that consumers must match literally when parsing or querying:
isControPerson (intended "ControlPerson") — appears in baseInformation for every person in Schedule A and Schedule C.isDiscipliend (intended "Disciplined") — appears in disclosure-related flags.isOtherNonMAABuisinesssPrimary (intended "Business" with a single "s" terminus) — appears in the controls block.isSolePropietor (intended "SoleProprietor") — appears in the controls block.Munipal (intended "Municipal") — appears in the description field of metadata.json as part of the human-readable form title.These spellings are upstream from the dataset and must be used exactly as shown. Code that "corrects" them silently will fail to match any data.
metadata.json is the cleanest entry point for indexing and bulk routing: it pre-extracts the accession number, CIK, file number, period of report, and EDGAR URLs, removing any need to parse XML to identify a record.primary_doc.xml; the duplicate under xslFormMA_X01/ is a presentation artifact and can be ignored for data extraction.controls block effectively flags which optional branches of the document are populated. This makes the form well-suited to flat tabular projection, with the disclosure section and the DRP namespace as the principal sources of nested optional content.accessionNo (and where temporal identity matters, on periodOfReport) rather than on CIK alone.previousLegalName and hasChanges fields signal when a given record represents a substantive update versus a routine reaffirmation.Each record is one Form MA-A submitted on EDGAR by a registered municipal advisor firm. The filer is the entity itself, not its employees — Form MA-A is a firm-level annual update, while information about individual municipal advisor professionals is carried on Form MA-I.
The filer population is fixed by Section 15B(e)(4) of the Securities Exchange Act of 1934, which defines a "municipal advisor" as a person (other than a municipal entity or its employee) that:
In practice the universe includes firms advising state and local governments on bond issuance, public pension and retirement systems on plan assets, 529 and ABLE plans, local government investment pools, conduit "obligated person" borrowers (such as 501(c)(3) healthcare and higher-education entities), and third-party solicitors of municipal entities.
Several categories sit outside the definition and therefore generate no Form MA-A records:
Form MA-A is calendar-driven, not event-driven. Under SEC Rule 15Ba1-5(a)(1), every registered municipal advisor must file Form MA-A within 90 days after the end of its fiscal year. The obligation is mandatory and recurring; it applies whether or not anything material changed during the year. A firm with no changes still files to reaffirm the registration record.
Material changes that occur between annual updates are reported promptly on Form MA/A (the interim "other-than-annual" amendment, distinct from Form MA-A) and are then reaffirmed at the next annual update. Each registered firm produces one Form MA-A per fiscal year from its first fiscal year end after initial Form MA registration until it files Form MA-W to withdraw.
Because most municipal advisors operate on a calendar fiscal year, filings cluster in Q1, with a peak around late March (90 days after December 31). Firms with non-calendar fiscal years file on their own 90-day cycle throughout the year.
The municipal advisor registration regime began under Dodd-Frank effective October 1, 2010, initially via temporary Form MA-T. The SEC adopted permanent rules in September 2013 (Release No. 34-70462), with compliance phased in from July 1, 2014, when firms transitioned from MA-T to Form MA on EDGAR. The first wave of Form MA-A filings followed in early 2015 as calendar-year firms hit their first 90-day deadline. The dataset's January 1, 2015 start date therefore covers essentially the full EDGAR history of Form MA-A under the permanent regime; there is no paper or pre-EDGAR predecessor.
Form MA-A sits inside a tightly defined family of municipal advisor registration forms under Section 15B of the Exchange Act and Section 975 of Dodd-Frank. Several neighbors share its schema, registrant population, or regulatory purpose, and the naming conventions are easy to confuse. The comparisons below mark the boundaries.
Form MA (initial registration). Identical XML schema, Schedules A and C, and DRPs. The only differences are trigger and cadence: MA is filed once at first registration; MA-A is filed every fiscal year within 90 days of year-end, regardless of change. Together they form a continuous longitudinal record, but neither substitutes for the other.
Form MA/A (interim amendment, slash). The single most-confused form because of the near-identical label. MA/A is event-driven, filed under Rule 15Ba1-5(b) whenever specific items become inaccurate (new DRP event, change in control persons, change in form of organization). It can be filed multiple times a year or not at all. Form MA-A (hyphen) is calendar-driven and filed exactly once per fiscal year. MA/A captures intra-year transitions; MA-A captures the cumulative year-end state.
Form MA-I (per-individual). Filed at the natural-person level for each associated municipal advisor representative, covering residential history, employment history, exams, and individual DRPs. MA-A is firm-level: Schedule A lists direct owners and executive officers but does not replicate MA-I's personal disclosure depth. Different units of analysis, not substitutes.
Form MA-NR. Procedural one-time filing by non-resident advisors (or non-resident GPs/managing agents) designating a US agent for service of process. No business, ownership, or disciplinary content. Overlaps with MA-A only for the cross-border subset.
Form MA-W. Terminates municipal advisor registration; the closing record of the lifecycle. MA-A documents continued operation; MA-W documents exit. Required for survival or attrition analysis, since MA-A simply stops appearing without identifying the reason.
Form ADV family (ADV, ADV-NR, ADV-W). Filed under the Investment Advisers Act through IARD, not EDGAR. Many MA-A filers are dually registered, and ownership schedules, control person items, and DRPs have direct analogues. The forms are not redundant: ADV covers advisory activity for securities accounts and clients broadly, MA-A covers advice on municipal securities issuance and municipal financial products. Each regime collects items the other does not, and ADV is not part of this dataset.
MSRB Form A-12. The MSRB-side annual registration for regulated entities, filed through MSRB Gateway with its own schema. Identification fields overlap (entity name, CRD/MA numbers), but A-12 lacks MA-A's ownership, control person, and DRP depth, while collecting MSRB-specific designations absent from MA-A. Parallel annual filings, not substitutes; only MA-A is on EDGAR.
FINRA Form BD. Broker-dealer registration via CRD. Relevant only for the dual-registrant subset of MA-A filers; a large share of municipal advisors are non-BD advisory firms. BD covers broker-dealer items (types of business, clearing, FINRA membership) absent from MA-A, and MA-A's municipal-advisor schedules and DRPs are absent from BD. Useful as a cross-reference, not as overlap.
The Form MA-A Files Dataset is the recurring annual, firm-level, structured XML backbone of municipal advisor disclosure on EDGAR. No other single source replicates its scope:
Use MA-A whenever the question requires a consistent annual panel of municipal advisor firm-level registration content; pair it with the relevant neighbor for initial registration, intra-year events, individuals, exits, or cross-regime comparisons.
Form MA-A is the authoritative running record of registered municipal advisors, their control persons, conflicts, and disciplinary history. Different professional groups draw on different sections of the filing for distinct workflows.
Finance directors, county treasurers, debt managers, and procurement teams at states, cities, school districts, transit authorities, and utilities use the dataset to vet MA candidates before issuing RFPs or signing engagement letters for bond, note, or refunding deals. They pull Item 1 (registration status, CRD/SEC numbers), Item 3 (form of organization), Item 7 (control persons and indirect owners), and the full DRP set to surface regulatory actions, civil events, and complaints not disclosed in pitches. Output: documented selection memos and disqualification decisions that withstand audit.
Bond counsel and issuer counsel confirm at deal kickoff that any party advising on structuring, proceeds investment, or escrow is a registered MA, and reconcile the engagement letter against current disclosures. They focus on Item 1 registration status, Item 6 other business activities, Item 8 financial-industry affiliations, and Schedule A/B control persons (so individuals named in the engagement letter match those filed with the SEC). Workflow: closing-opinion diligence and issuer fiduciary documentation.
Chief compliance officers, in-house counsel, and registration specialists at MA firms benchmark peer filings before drafting their own annual update. They examine Item 5 (employee and engagement counts), Item 6 (conflicts), and the DRP archive to see how peers describe similar events. Output: disclosure drafts, written supervisory procedure updates, and board-level compliance reporting.
Firms registered as both IAs and MAs reconcile Form MA-A against parallel Form ADV filings for consistency in control persons, DRPs, conflicts, and ownership. Staff cross-walk Schedule A/B owners, Item 7 control persons, and DRPs against ADV Schedules A/B and Part 2 brochures so contradictions do not become enforcement findings. Workflow: an annual internal reconciliation control.
Examiners, registration analysts, and enforcement attorneys at the federal securities regulator and the municipal SRO use the dataset to risk-rank registrants ahead of cycle exams, flag new or worsening DRPs, detect late or missing annual updates, and track control-person turnover or sudden expansions in business activity. Key fields: full DRP set, Item 7 control persons year over year, Item 5 employee counts, filing-date metadata against the 90-day deadline, and amendment history. Supports exam scoping, sweep selection, deficiency letters, and referrals.
Plaintiffs' attorneys representing issuers, retail muni investors, or whistleblowers pull DRP exhibits to establish prior regulatory and civil events, Item 7 control-person identities to map individual liability, and year-over-year changes to show when a firm knew or should have disclosed a material event. Supports complaint drafting, document requests, and deposition preparation.
Underwriters' counsel and BD compliance staff active in negotiated and competitive municipal deals use the dataset to test the MSRB Rule G-23 boundary between underwriter and MA roles and to confirm whether a third party is acting as a registered advisor. They focus on Item 1 registration status, Item 6 business activities (including third-party and solicitor arrangements), and DRPs touching role-conflict events. Output: G-17 fair-dealing letters and supervisory sign-off.
Researchers at public-policy programs and public-finance research centers use the 2015-to-present time series to study post-Dodd-Frank market structure. They aggregate Item 1 firm counts, Item 3 organizational form, Item 5 workforce and engagement totals, principal-office geography, withdrawn registrations, and DRP frequency to publish on consolidation, fee competition, and small-issuer access. Supports peer-reviewed work and Section 975 policy evaluation.
Data and product teams at regulatory-intelligence vendors ingest the XML schedules and DRP exhibits to build MA registration products, KYC checks, and counterparty due-diligence feeds for issuers, banks, and law firms. They parse Items 1 through 9, normalize control-person identifiers, run change-detection on amendments, and surface DRP events as discrete records served via commercial APIs and screening services.
Reporters covering public finance and government accountability use the dataset to research pay-to-play patterns, undisclosed conflicts, and fiduciary breaches among MAs active in specific states or sectors. They cross-reference Item 7 control persons against public officials and political contributors, mine DRPs for unreported events, and track year-over-year changes signaling restructuring after enforcement. Supports long-form accountability investigations.
Engineers building retrieval-augmented compliance and diligence systems use the dataset as a structured corpus of MA registration text, exhibits, and DRP narratives. They index Item-level XML, DRP free text, and control-person tables to power firm-history Q&A, cross-registrant comparisons, and change-tracking digests inside broader compliance platforms.
Form MA-A users cluster around three workflows: vetting and engaging municipal advisors (issuers, their counsel, underwriters' counsel), supervising and benchmarking the advisory industry (regulators, MA compliance teams, dual-registrant reconciliation), and observing it from the outside (researchers, journalists, data vendors, litigators, AI tooling teams). Control-person schedules, DRP exhibits, business-activity items, and annual-update timing carry most of the analytical weight.
The use cases below are concrete workflows tied to specific elements of the structured XML, the DRP exhibits, and the year-over-year accession panel.
A county debt manager evaluating responses to a bond-advisor RFP loads each respondent's most recent MA-A and pulls firmName, firmCrdNumber, and maRegistration/fileNumber to confirm active registration; the disclosureAnswers block (criminalDisclosure, regulatoryDisclosure, civilDisclosure) plus any DRP PDFs to surface events not mentioned in the pitch; and scheduleA/persons to verify that the individuals named in the engagement letter match the firm's filed control persons. Output: a documented selection memo and, when warranted, a disqualification record that withstands audit.
At deal kickoff, bond counsel cross-checks the engagement letter against the advisor's current MA-A by reading formData/firmName, registrations/maRegistration, scheduleA and scheduleC rosters, and participationInterestMACT flags for conflict items relevant to the transaction (broker-dealer recommendation, referral compensation, derivatives). Workflow: an item in the closing checklist that produces a clean fiduciary-status memo and identifies any signer or control-person discrepancies before the opinion is issued.
Before drafting their own annual update, a CCO at a mid-sized municipal advisor pulls the prior-year MA-A submissions of named peers and compares engagedActivities, typesOfClients, participationInterestMACT boolean patterns, and DRP narrative PDFs from peers with similar event types. Output: redlined disclosure drafts and updated written supervisory procedures that align with industry phrasing on recurring conflict items.
SEC and MSRB examiners build a longitudinal panel keyed on cik and periodOfReport and run change-detection on numberOfEmployees, employeesEngagedInMAA, clientsServedAsMA, scheduleA rosters, hasNameChange, and any flip from N to Y in the disclosureAnswers flags. Late or missing filings are flagged by comparing filedAt against the 90-day deadline implied by fiscalYearEnd. Output: risk-ranked exam targets, sweep candidate lists, and deficiency-letter triggers.
Compliance staff at firms registered as both an investment adviser and a municipal advisor run an annual control that compares Schedule A direct owners and disclosureAnswers/DRP content in MA-A against the parallel Form ADV Schedules A/B and DRPs. The control reads scheduleA/persons/person/baseInformation (including ownershipCode and the upstream-typo isControPerson flag) and the criminal/regulatory/civil DRP set. Output: a reconciliation log that resolves contradictions before they become examination findings.
Regulatory-data vendors ingest the monthly batches, parse metadata.json for routing keys (accessionNo, cik, fileNo, periodOfReport), and normalize fields from primary_doc.xml into firm-, person-, and event-level tables. DRPs PDFs are extracted as discrete events linked to firmCrdNumber and the CRD numbers in Schedule A. Output: commercial KYC APIs, change-alert feeds for issuers and banks, and adverse-media screening lists for municipal-market counterparties.
Public-finance researchers build the 2015-to-present panel and aggregate formOrgType, principalOfficeAddress/state, numberOfEmployees, clientsServedAsMA, hasAnnualReceiptsLessThan7Million, and DRP frequency by year. Comparing entry cohorts (first MA-A per CIK) to firms that disappear from the panel quantifies consolidation, small-firm exit, and geographic concentration. Output: peer-reviewed work and policy briefs evaluating the effect of Section 975 on municipal advisor market structure.
The Form MA-A Files Dataset can be accessed through three endpoints: a JSON index for dataset metadata and container discovery, a full archive download, and individual container downloads for incremental retrieval.
Dataset Index JSON API: https://api.sec-api.io/datasets/form-maa-files.json
Returns the dataset index, including dataset-level metadata (name, description, last updated timestamp, earliest sample date, total records and total size, form types, container format, and file types) along with the full containers array. Each container entry includes its key, size, record count, last updated timestamp, and a direct download URL. This endpoint is well suited for daily monitoring: by polling the index and comparing each container's updatedAt timestamp against a local cache, a client can determine which slices changed in the latest refresh and download only those. This endpoint does not require an API key.
Example response:
1
{
2
"datasetId": "1f13365b-9ae0-695b-95f3-56411f016f40",
3
"datasetDownloadUrl": "https://api.sec-api.io/datasets/form-maa-files.zip",
4
"name": "Form MA-A Files Dataset",
5
"updatedAt": "2026-04-24T03:02:33.115Z",
6
"earliestSampleDate": "2015-01-01",
7
"totalRecords": 9535,
8
"totalSize": 172421714,
9
"formTypes": ["MA-A"],
10
"containerFormat": "ZIP",
11
"fileTypes": ["XML", "JSON", "PDF"],
12
"containers": [
13
{
14
"downloadUrl": "https://api.sec-api.io/datasets/form-maa-files/2026/2026-03.zip",
15
"key": "2026/2026-03.zip",
16
"size": 13818783,
17
"records": 154,
18
"updatedAt": "2026-03-21T02:51:19.000Z"
19
}
20
]
21
}
Download Entire Dataset: https://api.sec-api.io/datasets/form-maa-files.zip?token=YOUR_API_KEY
Returns the complete dataset as a single ZIP archive containing every container from January 2015 onward. Use this for a one-shot bulk load when bootstrapping a local copy. The endpoint supports HTTP Range requests, so interrupted transfers can be resumed with standard tools (such as curl -C - or wget -c). This endpoint requires a valid SEC API key passed as the token query parameter.
Download Single Container: https://api.sec-api.io/datasets/form-maa-files/2026/2026-03.zip?token=YOUR_API_KEY
Returns one container ZIP, typically a monthly slice for recent periods. Pair this with the index API to fetch only the containers that changed in the latest refresh, which keeps incremental syncs small and avoids re-downloading the full archive. Range requests are supported for resumable downloads. This endpoint requires a valid SEC API key.
The dataset covers Form MA-A, the annual update to Form MA, which is the SEC registration application for municipal advisors created under Section 15B of the Securities Exchange Act of 1934 as amended by Section 975 of the Dodd-Frank Act. Form MA-A is filed natively as a structured XML submission against the EDGAR mafiler schema.
One record is one EDGAR accession folder representing a single Form MA-A submission filed by a registered municipal advisor firm. The record unit is the accession, not the firm: a firm filing several back-dated annual updates on the same day produces several side-by-side accession folders, each treated as an independent record keyed on accessionNo and periodOfReport.
Every firm registered as a municipal advisor on Form MA must file Form MA-A within 90 days of its fiscal year end under SEC Rule 15Ba1-5(a)(1). The obligation is calendar-driven, not event-driven — firms file every year regardless of whether anything material changed, and the obligation continues until the firm files Form MA-W to withdraw registration.
Form MA-A (hyphen) is the scheduled annual update under Rule 15Ba1-5(a)(1), filed exactly once per fiscal year. Form MA/A (slash) is an interim, event-driven amendment filed under Rule 15Ba1-5(b) whenever specific items become inaccurate, such as a new disclosure event or a change in control persons. The labels are nearly identical but the trigger and cadence are different.
The dataset is delivered as yearly ZIP archives partitioned into monthly batches at form-maa-files/<year>/<year>-<month>.zip. Each accession folder inside a batch contains XML, JSON, and optionally PDF files: a structured primary_doc.xml, an XHTML rendering under xslFormMA_X01/primary_doc.xml, a metadata.json envelope, and any DRP-triggered PDF exhibits. Image files from the original EDGAR submission are excluded.
The dataset begins on January 1, 2015 and is updated as new Form MA-A filings appear on EDGAR. Because the SEC's permanent municipal advisor registration regime took effect on July 1, 2014, with the first wave of MA-A annual updates following in early 2015, the dataset covers essentially the full EDGAR history of Form MA-A under the permanent regime; there is no paper or pre-EDGAR predecessor.
No. Form MA-A is structured natively in its own XML schema (the EDGAR mafiler schema) rather than in XBRL. The linkToXbrl field in metadata.json is always empty for MA-A records, and no XBRL artifacts appear in the dataset. Structured extraction should target primary_doc.xml directly.