Vendor Compliance Monitoring

CommunityPay holds contractor records read from public state license registers, and checks the stored record before an association's bill payment posts. This page describes what the registry holds, what the payment-time check evaluates, how the VECR attestation is built, and what none of it covers.

Compliance Monitoring Architecture

Data Sources

BuildRated aggregates vendor data from two categories:

Public data. Three state license registers: Washington Labor & Industries, the Oregon Construction Contractors Board, and the Oregon Building Codes Division. Ingest jobs read them. None is on the schedule today, so each record is as current as the last read, and the vendor intelligence page shows when that was. What a record contains is what the board publishes — where a board does not publish a bond or insurance record, the field is empty.

Proprietary data. None today. A payment sync from the CommunityPay ledger exists in code, has no schedule entry and no caller, and has never run. No association payment has reached a contractor record. On-time rate, dispute rate, and relationship quality are fields on the model, not figures the platform has computed.

The Payment-Time Check and the Sweep

Two mechanisms read the credentials of a vendor an association has linked to a contractor profile.

The payment-time check is the vendor_risk guard. It runs on bill payments and on vendor payouts, and it reads the stored contractor record. It refuses the payment for any of these: a debarment, a license that is suspended or revoked, a license past its expiration date, insurance past its expiration date, or active contractor strikes. The refusal is recorded in the enforcement decision with the reason. A board member can authorize one payment of one bill despite it with a VENDOR_RISK override, which names the bill and the amount, lasts at most 24 hours, and is used up by that payment.

The compliance sweep evaluates four credentials for every linked vendor and raises alerts. It runs when it is invoked. No schedule runs it today.

Alert Generation

When the sweep runs, it generates compliance alerts as a credential approaches or reaches expiration:

These are the alert types the sweep raises. A multiple-issues type is defined and is not raised. A suspended license is recorded as LICENSE_EXPIRED; there is no separate suspension alert. There is no debarment alert and no tax-lien alert — those are flags on the contractor record, and the payment-time check reads the debarment flag.

An alert's severity follows the days left before expiry: an expired or missing credential is CRITICAL, one to six days left is HIGH, seven to 29 is MEDIUM, and 30 or more is LOW. They are recorded and surfaced. An alert does not itself block a payment; the payment-time check above does.

The VECR Artifact

The Vendor Eligibility & Compliance Record (VECR) is an attestation of a vendor's compliance posture. It is designed for consumption by escrow officers, CPAs, and underwriters.

VECR Sections

Each VECR contains five evidence sections:

1. Credential Status

Current status of all four tracked credentials, with dates and verification details:

Each credential reports one of CURRENT, EXPIRING_SOON (within 30 days of expiry), EXPIRED, MISSING, or NOT_REQUIRED. The W-9 status is CURRENT when a taxpayer identification number is recorded and MISSING when it is not.

2. Compliance History

Compliance data over the trailing 12 months, built from the daily compliance signals on record (a day with no signal counts as no observation):

• Continuity: The current run of compliant signals
• Gap count: The number of times a compliant run was broken
• Compliance rate: The share of signals on record that were compliant or warnings
• Most recent gap: The date of the most recent break, and the longest gap

3. Performance Metrics

Figures read from the payment and review records kept in BuildRated: verified payment volume and count, associations served, average project value, dispute rate, and the would-hire-again rate. The sync that would carry CommunityPay payments into those records has not run, so these fields hold no data today.

4. Violation Summary

Risk-relevant violation and enforcement data:

• Debarment status
• Contractor strikes
• Tax debt flags
• Safety violations
• Lawsuit history
• Number and severity of risk flags

5. Eligibility Determination

The VECR concludes with an eligibility determination:

Content Hash

The VECR evidence snapshot is hashed with SHA-256 using canonical JSON serialization. The hash covers all five sections. Any modification to any section would produce a different hash, making the VECR tamper-evident.

Integration with Enforcement

Vendor compliance data feeds into the enforcement system at three points:

1. Guard-Level Integration

The vendor_risk guard reads the stored contractor record at payment time, as described above. A vendor with no link to a contractor record passes the guard, and the decision records that it could not evaluate the vendor.

2. Signals

Vendor compliance signals are registered in the VENDOR_COMPLIANCE namespace of the signal registry and are read by eligibility rules and exclusion triggers.

3. FADR Integration

When a FADR (Funds Authorization & Disbursement Record) is generated for a payment, it includes the vendor's compliance status at payment time. This creates a permanent record of the vendor's credential posture when the payment was authorized — not the current status, but the historical status at decision time.

Vendor Banks and Payments

The vendor's bank is a control surface of its own.

• A vendor's bank is attached at the vendor's first payment, paid by its stored identifier, and removed from the processor after the payout settles plus seven days. It is removed at once when the vendor is deactivated or its bank changes, and the payment rail refuses an inactive vendor.
• A changed vendor bank waits three business days before the rail pays it. A different board member can end the wait early, after calling the vendor at a number the association already had, with a fresh authenticator code and the association's bank PIN.
• Reactivating a vendor takes a fresh authenticator code.
• Every vendor payment sent by transfer and every top-up from the association's bank is emailed to the whole board.

BuildRated Score

The BuildRated score is a composite quality metric (0-100) computed from five components:

The score is evidence-based: it reflects verified data, not self-reported claims or consumer reviews. The BuildRated platform explicitly does not use purchased testimonials, fake reviews, or consumer opinion data.

What This Monitoring Does Not Cover

The limits are part of the specification. An association deciding whether to rely on this should read them first.

• Two states. Oregon and Washington only. A contractor licensed elsewhere has no record here, and the check has nothing to read.
• A vendor is checked only once it is matched to a contractor record. Until an association matches its vendor to a contractor, the guard passes and records that it could not evaluate. The decision says so plainly. It does not read as a clean result.
• Records are not refreshed on a schedule. Ingest is not on the schedule today, and neither is the sweep. Each record is as current as the last read from the state board, and a license that lapsed or was suspended since then is not reflected until the next read.
• One threshold, not a schedule of them. Each credential produces one alert at 30 days and one when it lapses. A longer list of lead times is declared in the code and is not referenced by any check.
• Bond is recorded, not enforced. The payment-time check reads debarment, license status, license expiry, insurance expiry, and active contractor strikes. It does not block on a bond.
• Debarment and strike flags are fields on the contractor record, set by a process separate from the license feed. The payment-time check reads them.
• No payment history flows. The sync that would carry on-time and dispute rates from the ledger has never run, so the score's payment signals have no data behind them.
• This is a copy of a public register. It is as current as the board's last publication and as accurate as the board's own data. It is not a substitute for a certificate of insurance from the contractor.

What This System Proves

The vendor compliance system provides auditable evidence that:

1. The stored record is read at payment time — a linked vendor's debarment, license, insurance, and strikes are read before every bill payment posts, not checked once at onboarding and forgotten
2. Expiration is flagged before it happens — when the sweep runs, an alert is raised at 30 days, not after the lapse
3. The payment-time check is recorded either way — an evaluation and a could-not-evaluate are both written to the decision, so an unchecked vendor is visible as unchecked
4. Compliance history is preserved — the VECR captures longitudinal data, not just point-in-time status
5. Eligibility determinations are reproducible — the same inputs always produce the same eligibility status

Each of these describes the mechanism as built. What the mechanism has evaluated to date is covered above.

CARI Integration

Vendor compliance signals measured here — COI status, license verification, bond coverage, and W-9 completion — feed directly into the CARI Vendor Risk sub-score, which carries a 15% weight in the composite CARI score. The aggregate compliance rate across an HOA's entire vendor portfolio is a key signal: associations that maintain current credentials across all active vendors score higher than those with compliance gaps. VECR eligibility determinations are computed from the same underlying data used for CARI Vendor Risk evaluation.

For published methodology and component weights, see CARI Methodology and Scoring Framework.