Financial Risk Governance Infrastructure: A Definition

In 2024, community associations collected $120.9 billion in assessments from homeowners. Of that, $30.2 billion went into reserves. About 2.5 million volunteers serve on association boards and committees.

Fraud examiners estimate that organizations lose about 5 percent of revenue to fraud. In the 2,402 cases in their 2026 study, the median loss was $104,000; among nonprofits, the closest category to an association, it was $69,000. The study did not measure community associations. No published, measured annual figure exists for fraud or misallocation in associations, and this article does not invent one.

Three Questions Software Answers

Accounting software answers what happened. Payment software answers how the money moves. Management software answers who does the work. Each is built around its own question.

A fourth question is different in kind: where can this go wrong, and what stops it? Software built around that question is what this article calls financial risk governance infrastructure for community associations: payments and accounting systems that govern how money moves, record every decision, evaluate counterparty risk, and enforce statutory compliance.

Why Loss Is the Organizing Question

A business earns. An association levies. Its income is the assessment, set by the board through the budget, and its purpose is to spend that money on what it was collected for. There is no revenue engine to make up for a loss.

Apply the fraud examiners' 5 percent to the $120.9 billion and it comes to about $6.0 billion a year. That is arithmetic, not a measurement: the 5 percent is an estimate for organizations of every kind. At the scale of one association it is easier to see. An association that collects $1 million in assessments and loses 5 percent loses $50,000, which is $250 a home across 200 homes.

Now consider what a business would need to recover a loss of that size. A business replaces a loss by selling more, and each extra dollar of sales leaves only its net margin. Across US firms that margin averages about 10 percent (9.74 percent in NYU's January 2026 data for 5,994 firms, and 8.56 percent excluding financials), and in grocery retail it is 1.3 percent. At 10 percent, a dollar lost takes $10 in sales to replace. To replace $6.0 billion it would need about $60 billion in sales, ten times the loss. The 10 percent is an illustration, and the arithmetic ignores any tax deduction for the loss itself. For an association none of this is available. It has no sales to earn back a loss. A lost dollar is repaid by the owners, through a higher assessment, or by maintenance that does not happen.

Who Pays, Who Chooses

Three parties touch the software an association uses.

The association pays for it. In many associations the manager chooses it. The vendor prices it, usually per unit and per payment.

Each is paid for something. The manager is paid to run the association's operations. The vendor is paid per unit and per payment processed. The association is the party whose members repay a loss.

None of this is a fault. It is how the work is organized. It does mean that a price per unit or per payment does not move when money is lost.

Seven Tests

A system belongs in this category if it passes seven tests. Each can be checked by a board, a CPA, a lender, or an insurer, and none depends on a vendor's description of itself.

1. Controls sit where money moves. A control kept in a policy manual depends on someone remembering it. A control kept in software depends on the code. A control kept in the database depends on neither. Ask: is the rule enforced at the posting, and again beneath the application, so that a bug in the software cannot post what the database refuses? Ask to see the rule refuse an entry.

2. Every decision is recorded, the refusals included, and the record is tamper-evident. Ask: can the system show what it blocked and why, and show that no record was removed?

3. Counterparties are evaluated before money leaves. Ask: before a payment, does the system check who is being paid, whether the destination changed, whether the person approving has authority, and how much can leave in a day?

4. The law in force is part of the record. Ask: are requirements mapped to statute, are thresholds checked against the primary text and dated, and does each decision store the authorities that applied?

5. Powers are separate. Ask: can the person who enters a bill also approve it and pay it, who can change an officer's authority, and can anyone at the software company move the association's money?

6. Funds do not mix. Ask: can operating cash cover a reserve expense, or reserve cash fill an operating gap, without a recorded board decision?

7. The books belong to the association, and others can examine them. Each association's books are its own, separate from every other association's. Ask: who can read them, can an accountant get read-only access, and can the whole book be exported with a manifest that proves its contents?

What the Research Points To

The fraud examiners' 2026 study asked what was missing where fraud occurred. One-third of cases, 33 percent, occurred because the organization lacked internal controls. Another 19 percent involved an override of the controls that did exist. A lack of management review was third, at 18 percent. Together the three accounted for 70 percent of cases.

It also compared losses. Median loss was $84,000 where management review was in place and $186,000 where it was not. Where proactive data monitoring was in place it was $70,000, against $150,000 where it was not. Across the eighteen controls the study measured, a control's presence was associated with a median loss lower by 37 percent on average. The study reports association, not cause, and it covers organizations of every kind.

The first two weaknesses are design questions. Is a control always on? Is an override scoped to one item, recorded, and closed to the people who handled the bill?

Nine Ways Money Goes Wrong

The Bill That Should Not Be Paid

A vendor that does not exist. An invoice padded by a few hundred dollars. The same invoice sent twice, a month apart. A volunteer treasurer has an evening, a stack of PDFs, and no second reader, and the invoice that looks right is paid.

The defense is to read every invoice twice, independently, and then test it. Is this a known vendor? Is the account right? Has this document, this number, or anything close to it been paid? Does the amount sit inside the limit? Does the bill-to name match? Is the vendor's insurance current? The outcome is one of three: submitted for approval, saved as a draft, or held, with one plain sentence saying why. Automation can read an invoice, enter it, and submit it. It cannot approve a bill or pay one.

The approval that follows belongs to the bill: its amount, its vendor, its fund, and the bank it will be paid to. A payment spends the approval once. If any of those four changes, the approval no longer covers the bill.

The Payment That Goes Somewhere Else

The usual form needs no break-in. A vendor's email is imitated, or a real contact is, and the association receives a courteous note: our bank has changed, please use the new account. The next invoice is paid in full, to the wrong place. The money is gone before the real vendor calls to ask where it is.

Two things defeat it, and an attacker cannot supply either: time and a second person. A change to where a vendor is paid is not a payment instruction. It is an event. It stops every bill already approved for that vendor, sends those bills back for approval, and tells the board. Before the new account can be paid, a second member of the board confirms it with the bank PIN and their own authenticator code. Where no one confirms, the account waits out a fixed period first. A vendor's first bank is different, because there is nothing to replace.

The Payment Nobody Authorized

A payout request that did not come from a bill. A destination typed into a form. A payment sent by someone with a login but no authority. Two payments launched in the same second to slip under a limit. A vendor who should never be paid.

A payout can exist for one reason: an approved, unpaid bill. Its amount is the approved amount. Its destination is the bank the approval covered, and the destination is never read from the request. Authority is checked again inside the posting, where no setting can override it. One cap limits any single payment and any 24 hours of them, and two requests sent together cannot both pass it. A vendor linked to a contractor record that shows a debarment, a lapsed license or insurance, or active strikes is refused unless the board writes a documented override, and that override covers one bill. Recurring bills never approve themselves; every generated bill waits for a person.

The Same Hands at Every Step

In a small association one person often enters the bill, approves it, and signs the check. That is efficient. It is also the arrangement most frauds need.

The remedy is the oldest one in government: separate the powers. Entering a bill, approving it, paying it, managing members, and changing the rules are different powers, held as separate switches, and an administrator grants each one on its own. A grant of a money power is recorded with the board decision it rests on, and every board member is told. A person approves a bill, and an association can require that the person recorded as its submitter cannot be that person. It can also require that a different person pays. Where it does, the payer can be neither an approver nor the submitter of record, which for a bill that arrived by email is the member who sent it in or who set the inbox to submit for the association. One person gives at most one approval. These rules are off by default, because associations run by one officer exist, and the setting in force is stored with every decision.

Authority comes from membership in the association, and only an association's administrator changes who holds it. A login at the software company holds none.

Money That Mixes

Operating cash covers a reserve project. Reserve cash fills a gap in operations. The books balance either way, and nothing records that the board allowed it. This is commingling, and the harm is invisible until the reserve is short.

Each entry is posted in a fund, and operating and reserve cash cannot mix inside one entry. A bill that belongs to the reserve is paid from the reserve, or after a board-approved transfer moves the money. Reserve money leaves the reserve only by a transfer the board approved. The money itself sits in an account in the association's name at a payment provider, not in the software company's own account.

An Entry Changed Afterward

Books are most often falsified after the fact: a figure adjusted before the audit, a period reopened, a line quietly edited.

A posted entry is never edited. It is corrected by a reversing entry, so the correction stands beside the error. A closed period cannot be posted into. The database refuses an entry that has no recorded decision, an unbalanced entry, and a change to a posted line. Decisions are sealed in a hash chain, so a change made around the application is detectable, and a nightly check confirms the database's rules are installed and firing.

The Rule Nobody Checked

Associations run on statute, and statute differs by state and changes by year. There is a limit on what a board may spend without a vote. There are restrictions on how reserve money may be used. There is a threshold above which a second signature is required. A volunteer board cannot be expected to hold them all, and the breach is rarely intent. It is a payment approved by the people allowed to approve it, that the law did not allow.

The defense is to treat the law as data. A requirement is mapped to the statute that imposes it. Each threshold that rests on a statute carries the date it was last checked against the primary text. A payment is tested against them before it posts: the association's approval limit, the reserve-fund rule, and the dual-signature threshold. Where a statute sets the limit, the decision records it.

The Association's Own Bank

The payout bank is where every dues payment lands. Whoever can change it can redirect the association's income, and in many systems it is a setting on a form.

Each association has one payout bank, and a vendor's bank can never be it. Adding or changing it takes the association's bank PIN, a fresh authenticator code, and the confirmation of a second board member. Automatic payouts then pause, and the first payout to the new bank waits until someone other than the person who asked releases it. The board is told at each step. If the payment provider ever shows a different default bank than the one pinned, payouts pause until a person reviews it.

A Stolen Login

A password is the weakest part of any system, and volunteers reuse them.

Paying a vendor, changing a vendor's bank, changing the transfer limit, changing who holds authority, and changing the payout bank each ask for a fresh code from an authenticator app. A text message is never accepted for these. A newly added authenticator confirms nothing until its owner approves it from an email sent to the address on file, and the owner is emailed whenever an authenticator is added, replaced, or turned off.

What This Is Not

It is not insurance, and it does not underwrite or bear a loss. Controls are configurable. An association can run with one officer, and then the separation rules do not apply to it. Nothing in the system stops fraud that happens outside it. The attestation a system produces is its own statement from its own records. It is not an audit and not an outside opinion. And there is no outcome data on losses prevented, because the study that would measure it has not been done.

The Record

Associations collected $120.9 billion in 2024. No published figure measures how much of it was lost. One reason is simple: a loss that leaves no record cannot be totaled. A system that records every decision, the refusals included, makes the total countable.

The current counts, checks, and verification results are published on the Trust Center page and updated as they change.

CommunityPay builds financial risk governance infrastructure for community associations — payments and accounting systems that govern how money moves, record every decision, evaluate counterparty risk, and enforce statutory compliance.

Sources:

• CAI Foundation for Community Association Research, Statistical Review 2024: https://foundation.caionline.org/wp-content/uploads/2025/03/FBStatsReview2024web.pdf
• ACFE, Occupational Fraud 2026: A Report to the Nations: https://www.acfe.com/-/media/files/acfe/pdfs/rttn/2026/2026-report-to-the-nations.pdf
• NYU Stern (Damodaran), Operating and Net Margins, US, January 2026: https://pages.stern.nyu.edu/~adamodar/New_Home_Page/datafile/margin.html