Alphanume

Insights

Build Crypto-Enforcement Event Signals With an API

Alphanume Team · August 17, 2026

Construct a first-known crypto enforcement table from agency publication dates, preserving action type, respondent rows, and date precision.

To build crypto-enforcement event signals with an API, use the agency's publication date as the first-known event clock, retain one row per named respondent, and keep allegations separate from settlements, judgments, pleas, sanctions, and rulemaking. Alphanume's Crypto Enforcement dataset structures SEC, CFTC, and DOJ public actions without converting every action into the same legal outcome.

The Crypto Enforcement API documentation defines published_date as structural and never inferred. action_date comes from the document text and can be null or imprecise. For a first-known event study, publication is the safer default because it identifies when the agency release entered the public record.

Choose the correct row and event keys

One agency action can name multiple respondents, so action_key identifies the parent action while record_id identifies a respondent row. Monetary relief repeats across respondent rows from the same action and must not be summed without de-duplication. respondent_key is normalized name text, not full entity resolution.

Field

Use

Guardrail

published_date

First-known public event date

Primary API date filter

action_date

Underlying action date when stated

Read with action_date_precision

action_type

Complaint, proceeding, order, indictment, plea, verdict, or other

Do not collapse distinct stages

allegation_categories

Theories stated in the public document

Allegation is not liability

settled_flag

Three-state settlement status

Null means the release did not say

listed_issuer_ticker

Ticker only when the document names one

Sparse by design

Follow-up linkage operates within the same agency and normalized respondent. An SEC complaint and DOJ indictment about related conduct remain separate chains. That design prevents a convenient but unsupported cross-agency entity merge.

Query and paginate a first-known table

Pull a completed date range and retain primary evidence. Results are ordered by publication date, action key, and respondent index. When more rows remain, pass all three values from next_cursor; a partial cursor is invalid. Save raw pages before grouping.

GET /v1/crypto/enforcement
date_gte=2025-01-01
date_lte=2025-12-31

Keep: record_id, action_key, source_agency, source_index,
published_date, action_date, action_date_precision, action_type,
respondent_index, respondent_name, respondent_key,
allegation_categories, settled_flag, listed_issuer_ticker,
document_url, prior_action_key, is_followup, last_updated

Use updated_since in incremental jobs because the daily follow-up sweep can relink previously served rows. If reproducibility requires the table exactly as retrieved, version raw extracts. Do not let a later linkage rewrite the historical feature set without recording the update.

Transform actions without changing legal meaning

Create separate binary features for action types, allegations, settlement state, agency, and follow-up status. Do not encode every complaint as a judgment or every settlement as an admission. For action dates with month, quarter, or year precision, either exclude them from day-level studies or use publication date. Never treat a normalized first day as exact.

events = rows.drop_duplicates(["action_key"])
events["first_known_date"] = events["published_date"]
events["is_complaint"] = events["action_type"].eq("civil_complaint")
events["is_settled_order"] = events["action_type"].eq("settled_order")
events["has_listed_issuer"] = events["listed_issuer_ticker"].notna()

assert events["first_known_date"].notna().all()
assert events["action_key"].is_unique
print(events.groupby(["source_agency", "action_type"]).size())

The parent-action table is useful for regime counts. A respondent-level table is useful for repeat-action chains. Keep them as separate outputs. If the study concerns listed securities, report how few actions actually state a listed issuer rather than resolving every respondent to a public ticker after the fact.

For an action-count signal, aggregate parent actions rather than respondent rows and state whether successive stages are counted separately. A complaint, settlement, and later judgment can represent the same underlying matter while remaining distinct public events. The follow-up fields help trace that sequence within one agency, but name normalization can join similarly named parties or miss renamed entities. Review chains that drive a result against document_url. If the research uses monetary relief, de-duplicate by action key and preserve the stated basis; a dollar figure can combine penalties, restitution, and disgorgement rather than one comparable economic measure.

State the signal's failure modes
  • Agency publication can follow the underlying action, so action_date and published_date answer different questions.
  • Allegations, settlements, judgments, sanctions, pleas, and rulemaking have different legal meanings.
  • Relief amounts repeat across respondent rows and inflate totals if summed directly.
  • Sparse listed-issuer links make a public-equity return study selective unless missing coverage is reported.
  • A regulatory action does not determine expected return, direction, liquidity, or execution.
Freeze one year's event keys

Pull one completed year, traverse every cursor, and export both the action-level and respondent-level tables with source URLs. Open a stratified sample across agencies and action types, then verify titles, dates, legal stage, and respondent counts. Record updates and exclusions. Only after those tables reproduce should a researcher attach market outcomes or define a regulatory-pressure index. The first deliverable is an auditable event panel, not a backtest chart.