Are you a charitable organization? Join our verified registry →
Every gift passes through a policy engine before any instruction is released. Recipient verification, OFAC screening, institution rules. If a check fails, the flow stops.
The standard approach to preventing bad transactions in financial services is to process them first and fix them later. A payment goes out, the compliance team reviews it the next morning, and if something is wrong, they initiate a reversal. The reversal creates its own paperwork, its own reconciliation burden, and its own client communication. The error is corrected, but not before it happened.
GivEZ takes the opposite approach. Every gift passes through a policy engine before any instruction is sent to the institution. If a check fails, the flow stops. No instruction is released. No money moves. The institution never receives a transfer request that has not been evaluated against every applicable rule.
The engine runs a sequence of evaluations on each gift. Every check must pass before an instruction is generated.
Recipient verification. The charity's EIN is validated against the IRS Exempt Organizations Business Master File, a public dataset the IRS publishes monthly. The engine confirms that the organization holds active 501(c)(3) status and has not had its exemption revoked. If the EIN is not in the file, or if the organization appears on the IRS auto-revocation list, the gift is halted.
OFAC screening. The recipient is checked against the Treasury Department's Specially Designated Nationals (SDN) list. OFAC compliance is not optional for organizations involved in financial transactions, and violations carry civil and criminal penalties. The engine screens every recipient on every gift, not on a sampling basis.
Institution-specific rules. Each institution can define its own safeguard policies. These might include per-transaction limits, daily or monthly caps, restrictions on eligible source accounts, or approval requirements for gifts above a threshold. The rules are configured per institution and evaluated on every gift. An institution that wants a $10,000 per-transaction cap gets it enforced automatically, on every transaction, before anything moves.
Balance and eligibility checks. The engine confirms that the source account has sufficient funds and that the account type is eligible for giving. An institution might allow giving from brokerage accounts but not from retirement accounts. These rules are part of the safeguard configuration.
In traditional payment systems, many compliance checks run in parallel with or after transaction processing. Suspicious activity reports are filed after the fact. AML monitoring reviews transactions in batches. Payment reversals are initiated after the problem is discovered.
For charitable giving, this model is worse than inadequate. A gift sent to a revoked charity cannot be easily reversed. A donation to an OFAC-sanctioned entity creates an immediate compliance incident. An unauthorized transfer from a restricted account type is a regulatory problem from the moment it executes.
Pre-transfer evaluation eliminates these scenarios by design. The safeguard engine is not a monitoring system. It is a gate. The instruction to transfer funds is not generated until every check has passed. If any check fails, the gift enters a review queue where the institution or the GivEZ operations team can examine it, correct the issue, or decline it.
GivEZ provides the baseline safeguards (recipient verification, OFAC screening, balance checks) as defaults that run on every gift. On top of those, each institution configures its own policy layer.
A community bank might set a $5,000 per-gift limit and require that all gifts originate from checking accounts only. A wealth manager might allow gifts up to $100,000 from brokerage accounts but require manual approval for anything above that threshold. A firm with international clients might add country-specific restrictions.
These rules are evaluated in the same pre-transfer pass as the baseline safeguards. They are not separate systems. A gift that passes OFAC screening but exceeds the institution's per-gift limit is still halted. The engine treats every rule with equal authority.
Each safeguard check produces a ledger entry. A successful OFAC screen is recorded. A passed balance check is recorded. A failed institution rule is recorded with the specific rule that triggered the halt. This means the ledger contains not just the outcome of each gift, but the compliance trail that led to that outcome.
When an auditor or compliance officer reviews a gift, they can see exactly which checks ran, in what order, and what each one returned. For a gift that was halted, they can see which rule stopped it and what happened next (reviewed, corrected, declined). The safeguard trail is part of the same append-only, hash-chained ledger as the gift itself.
If your compliance or risk team wants to see how the safeguard engine handles specific scenarios, book a session and we will run through your institution's rules together.
Research and perspectives on embedded giving, delivered when we publish.
