Resale Certificates & Statutory Compliance

CommunityPay generates resale certificates as institutional packets — statute-compliant disclosure documents produced from live ledger data, bound to a cryptographic hash, and linked to the evidence chain that produced them.

This page describes how resale certificates are structured, how statutory compliance is enforced, and what happens when data is unavailable.

What Is a Resale Certificate?

A resale certificate is a legal disclosure document required when a unit in a condominium or common interest community is sold. State statutes define exactly what the certificate must contain — financial status, reserve fund health, insurance coverage, pending litigation, governing documents, and more.

The certificate is typically requested by the buyer, buyer's agent, or escrow company. The association (or its management) is required to produce it within a statutory deadline. In Washington State, that deadline is 10 days.

CommunityPay generates resale certificates from the same ledger data that governs day-to-day financial operations. The certificate is not a separate report compiled from spreadsheets — it is a structured extraction from the system of record.

Compliance Profile Architecture

Different states — and different statutes within the same state — define different disclosure requirements. CommunityPay handles this through a compliance profile registry.

What a Compliance Profile Contains

Each profile defines:

Active Profiles

The code defines 14 profiles across 10 states; six more are loaded from the legal data files. The code-defined profiles:

Washington is notable because it has two concurrent regimes. The Condominium Act (RCW 64.34) applies to communities formed before July 2018. The Washington Uniform Common Interest Ownership Act (RCW 64.90) applies to communities formed after that date, and all Washington communities transition to WUCIOA by January 1, 2028.

CommunityPay does not guess which regime applies. The compliance profile is selected explicitly at generation time. If an association is unsure which statute governs their community, that is a legal question outside the scope of this system.

Profile-Driven Generation

When a resale certificate is generated, the compliance profile determines:

1. Which data sections are assembled into the snapshot
2. Which statute subsection each section maps to
3. What the compliance check evaluates
4. Which mandatory disclosure text is included verbatim

This means the same underlying data can produce certificates under different statutory regimes, and each certificate accurately reflects the requirements of its governing statute.

Data Sections

Each required disclosure item in the compliance profile maps to a data section in the evidence snapshot. Data sections are assembled from production models — not from a separate reporting layer.

Live Ledger Sections

These sections are computed from the same double-entry ledger that enforces fund segregation, runs integrity scans, and produces enforcement decisions. There is no secondary data pipeline.

Record-Based Sections

Unknown Sections

Some statutory requirements reference data that the ledger does not hold — pending litigation, code and environmental matters, construction defects, declarant status, occupancy and use restrictions, leasehold terms. The board answers these on the certificate's disclosure form before the certificate is generated.

CommunityPay does not omit an item the board has not answered. It does not leave it blank. It emits a structured "unknown" payload:

{
  "data_status": "unknown",
  "statement": "CommunityPay does not currently hold litigation records for this association. The board or managing agent should provide this information separately."
}

This is a deliberate design choice. An omitted section is ambiguous — was the data unavailable, or was the system not asked? An "unknown" section is unambiguous. It tells the recipient exactly what the system knows and does not know, and who should provide the missing information.

Every required item in the compliance profile produces a section in the snapshot. The compliance check then scores coverage based on how many sections contain recorded data versus unknown payloads.

Compliance Check

After the snapshot is assembled, the system computes a compliance check. This is not a pass/fail judgment — it is a structured assessment of coverage against the statutory requirements.

What the Compliance Check Produces

What It Does Not Do

The compliance check does not determine whether the certificate is "legally sufficient." That is a legal conclusion that depends on the specific transaction, the parties involved, and potentially local custom. CommunityPay provides the data and the coverage assessment. Legal sufficiency is determined by the parties and their counsel.

Risk Flags

Each certificate includes risk flags — severity-ranked indicators of conditions that may affect the transaction or the certificate's completeness.

Risk flags are sorted deterministically: CRITICAL first, then HIGH, MEDIUM, LOW. Within the same severity, flags are sorted alphabetically by code. This ensures identical inputs always produce identical flag ordering — a requirement for content hash consistency.

Cryptographic Integrity

Every resale certificate is an institutional packet with the same integrity guarantees as all CommunityPay attestation artifacts.

Content Hash

The evidence snapshot is serialized to canonical JSON (sorted keys, minimal separators, UTF-8) and hashed with SHA-256. The hash is computed from the JSON snapshot, not from the rendered PDF.

Version Chain

If a new certificate is generated for the same HOA, unit, and compliance profile, the previous certificate's content hash is stored in the new certificate's previous_packet_hash field. This creates a tamper-evident chain. An escrow company receiving version 3 of a certificate can verify the chain back to version 1.

Immutability

Once generated, the evidence snapshot, content hash, public ID, reference number, and scope cannot be modified. Lifecycle fields (status, delivery date, sharing settings) remain mutable. This is enforced at the application layer — the save() method rejects updates to immutable fields.

Mandatory Disclosures

Each compliance profile includes mandatory disclosure text that must appear verbatim on the certificate. These are statutory requirements, not CommunityPay editorial.

For Washington Condominium Act certificates:

Pursuant to RCW 64.34.425, the purchase agreement is voidable by the purchaser until the certificate has been provided and for five days thereafter, or until conveyance, whichever occurs first.

The WUCIOA profile carries two mandatory disclosures: the buyer's cancellation right, which runs in business days under RCW 64.90.640(3)(b), and the conspicuous notice the statute requires.

These disclosures are embedded in the compliance profile definition, not composed at generation time. They cannot be edited, omitted, or paraphrased during certificate generation.

Multi-Jurisdiction Design

The compliance profile registry defines 14 profiles across 10 states in code, each following the same registry pattern described above: California, Oregon, Florida, Texas, Colorado, and the others in the table above.

Adding a new jurisdiction requires:

1. Mapping the statute's required disclosure items to data keys
2. Defining fee caps, delivery deadlines, and buyer review periods
3. Adding mandatory disclosure text from the statute
4. Activating the profile

The statutes behind the profiles are held in a legal corpus. For thirteen of the fourteen code-defined profiles, the statute is re-verified against official text on a 90-day cycle, and the release chain refuses to deploy when one has lapsed; Arizona and the data-file profiles are not in that check. The corpus holds 434 verified statutory thresholds.

No changes to the generation engine, snapshot assembly, compliance check, or cryptographic infrastructure are required. The engine is jurisdiction-agnostic — the compliance profile provides the jurisdiction-specific logic.

This describes production controls as of October 2026. Controls evolve; request a current posture packet for diligence.