GrantDesk for agency IT

1. Overview and architecture

Applications arrive through a hosted applicant portal. Each submission is validated against your program's eligibility rules and required-document list, given an AI-drafted summary and risk flags for staff, then routed either into reviewer workflow or to a staff queue for a missing item or a question. Awards, disbursement schedules, and sub-recipient monitoring are tracked from decision through closeout, with an append-only audit log behind every step.

Integration with your own systems is deliberately file-based first: data is exchanged over SFTP using CSV files and a control manifest, with an API used only where one is genuinely available. It does not require a live API from your ERP, finance, or case-management system. Nothing in your stack is replaced. The new operational surface is the applicant portal, the staff workspace, and one SFTP endpoint for finance reconciliation.

  APPLICANTS                  AGENCY SYSTEMS
  online portal submissions   ERP / finance / identity / case data
        |  HTTPS + attachments       |  CSV + manifest (PGP) / SSO
        +-------------+--------------+
                      v
             INTAKE + VALIDATION     schema, required docs, eligibility rules
                      v
            SCREENING ENGINE         eligibility + completeness + AI summary
              /            \
   eligible  /              \ missing item / risk
            v                  v
   REVIEW WORKFLOW         STAFF QUEUE
   rubric scoring          reason + item -> staff
            \                    /
             v                  v
   AWARDS -> DISBURSEMENT -> SUB-RECIPIENT MONITORING -> REPORTING
                      v
         FINANCE EXPORT (/out) -> your ERP/AP        AUDIT LOG

From the finance system's point of view the flow is one-directional: award and disbursement records are published to an export file for your ERP/AP to consume. GrantDesk never reaches into your ERP to post entries itself.

2. Data exchange model

Applicant portal

The portal is served over HTTPS (TLS 1.2+). Applicants authenticate with an email-verified account; staff authenticate through your identity provider. Uploaded attachments are scanned and stored encrypted. No public endpoint accepts unauthenticated data writes.

SFTP and encryption for agency feeds

For agency-side data (finance reconciliation, case or eligibility reference data), each agency is provisioned a dedicated SFTP account, chrooted to its own home directory. Transport is SFTP over SSH only; FTP/FTPS and plain SCP are not accepted. Authentication is per-account SSH key pair, password auth disabled by default. On top of the transport layer, every file is PGP-encrypted (AES-256 content keys, RSA-4096 / Curve25519 key-encryption keys) so the payload stays protected at rest in the landing zone. Optional source-IP allow-listing per account.

/in/          files you push to GrantDesk
/in/archive/  processed files moved here after ingest
/out/         files GrantDesk publishes for you to pull
/out/archive/ retained copies of published files
/reject/      files that failed validation, with a paired .error.txt

Cadence

Reference-data ingest is batch-oriented, default nightly. Daily, weekly, or per-cycle cadences are set per source at onboarding. The /in directory is polled on a configurable interval (default 15 min) and a file is only ingested once its paired manifest is present, so a partially uploaded file is never processed.

File naming and CSV conventions

<source>_<agency>_<feed>_<YYYYMMDD>_<HHMMSS>_<seq>.csv.pgp
<source>_<agency>_<feed>_<YYYYMMDD>_<HHMMSS>_<seq>.manifest.json

example: erp_cityofx_award_20260824_020115_001.csv.pgp

• Encoding UTF-8 no BOM. Delimiter comma, RFC 4180 quoting. LF or CRLF.
• Header row required; columns mapped by name, so order is not significant and unknown columns are ignored and logged.
• Dates ISO 8601 YYYY-MM-DD; timestamps carry a UTC offset. Money is decimal, no separators or symbols. Identifiers are opaque strings, so leading zeros are preserved.

Control manifest

Every data file ships with a JSON manifest. A file whose manifest is missing, whose row count disagrees, or whose checksum fails is moved to /reject and never ingested.

{
  "schema_version": "1.0",
  "feed": "award",
  "source_id": "erp",
  "agency_code": "cityofx",
  "data_file": "erp_cityofx_award_20260824_020115_001.csv.pgp",
  "generated_at": "2026-08-24T02:01:15-05:00",
  "row_count": 312,
  "sha256_plaintext": "9f2c4b...e11a",
  "sha256_ciphertext": "3ab77d...90f4",
  "period_start": "2026-08-01",
  "period_end": "2026-08-31"
}

3. File specifications

Applications themselves are captured in the portal, not by file. The file feeds below cover the agency-side reference and finance data that the program joins on: program_id, application_id, award_id, and subrecipient_id.

3.1 Program configuration feed=program

One row per funding program, defining the intake form, eligibility rules, and rubric that drive screening and review. Usually configured in the workspace, importable by file for agencies that maintain program definitions elsewhere. Key fields: program_id, cfda_aln, funding_source, award_floor, award_ceiling, open_date, close_date.

3.2 Award file feed=award

One row per award, published by GrantDesk to /out for your finance system, or imported from it to reconcile obligations.

award_id,application_id,program_id,recipient_id,erp_vendor_no,award_amount,period_start,period_end,funding_source
AWD-3301,APP-20418,WFR-FY26,REC-114,V-88210,84000.00,2026-10-01,2027-09-30,federal:17.259
AWD-3302,APP-20455,HSG-FY26,REC-220,V-88247,72000.00,2026-10-01,2027-09-30,federal:14.231

3.3 Disbursement file feed=disbursement

One row per scheduled or executed drawdown against an award, so obligations, disbursements, and remaining balance stay reconciled between GrantDesk and your ledger. Carries disbursement_status (scheduled / approved / paid) and the milestone or reporting condition that gates it.

3.4 Sub-recipient master feed=subrecipient

Reference feed for pass-through monitoring. Maps subrecipient_id to uei (Unique Entity ID), risk-assessment tier, reporting cadence, and single-audit status, so monitoring obligations and due dates are tracked against each pass-through entity.

4. Screening and scoring

Order of operations

• Completeness check. Every required field and attachment on the program's intake form is present. Missing items produce a missing-item hold and a request back to the applicant.
• Eligibility rules. The program's eligibility conditions (entity type, geography, prior-award status, program-specific gates) are evaluated. A failed hard rule short-circuits to ineligible for staff confirmation.
• Compliance flags. Heuristic and AI checks surface likely issues, unallowable cost items, budget math that does not tie, duplicate-benefit signals, for a human to confirm.
• AI summary. A short, consistent brief of narrative and budget is drafted for reviewers. It is labeled as AI-drafted and is never a determination.
• Rubric scoring. Eligible, complete applications go to assigned reviewers, who score against the program rubric; scores roll up and rank.

Flag taxonomy

Classification is deterministic and logged: each flag records the exact rule and values that produced it (submitted vs required, threshold, rule version), so staff see why an application is in the queue, not just that it is. Approved awards are written to the finance export keyed by erp_vendor_no; GrantDesk does not post to the ERP directly.

5. Security and data integrity

The controls below describe the system's design. Where language says "designed to," it reflects control intent and implementation, not a completed third-party audit or a specific certification, which is not claimed here.

Data minimization

GrantDesk collects only the applicant and program data a program's own form requires. Where a program does not need a given category of personal data, it is not collected. Unmapped columns on any agency feed are ignored and not persisted into the application store.

Encryption and access

• In transit: HTTPS (TLS 1.2+) for the portal and workspace; SFTP over SSH plus PGP payload encryption (AES-256 / RSA-4096 / Curve25519) for agency feeds.
• At rest: data stores, attachments, and backups designed to be AES-256 encrypted; keys held in a managed secrets store.
• RBAC: least-privilege roles (Applicant, Reviewer, Program staff, Award manager, Finance approver, Agency admin, Auditor). Designed to support SSO via SAML 2.0 / OIDC with MFA at your IdP. Access is scoped to a single agency; no cross-agency visibility.
• Conflict of interest: reviewers are blocked from applications where a declared or detected conflict exists, and the block is recorded.
• Immutable audit log: every submission, screening decision (with the rule and values behind it), score, award action, disbursement, and report is written to an append-only, hash-chained log. The Auditor role can read it; no role can edit or delete it through the application.

Uniform Guidance and applicant privacy

GrantDesk is designed around the federal grants framework in 2 CFR 200 (Uniform Guidance) and common program rules such as ARPA and SLFRF: eligibility documentation, sub-recipient risk assessment and monitoring, allowable-cost checks, and audit-ready records. It is designed to operate as a service provider handling applicant data only for the grants purpose, under the agency's direction, never for any secondary purpose, advertising, or model training. This is design and contractual intent, not a claim of a completed audit or certification, and it supports rather than replaces the agency's own compliance responsibility.

6. Implementation and onboarding

A typical agency goes from kickoff to a live program in roughly 4 to 8 weeks, gated mainly by how quickly the program's rules, rubric, and required-document list are confirmed.

• Program configuration (wk 1-2). Build the intake form, eligibility rules, required-document list, and scoring rubric for the first program; confirm the data-privacy scope.
• Identity and SFTP provisioning (wk 2). SSO connection, staff roles, and, where finance reconciliation is in scope, SFTP accounts and key exchange with an end-to-end zero-row test.
• Sample-cycle validation (wk 2-4). Run real or representative applications through screening and review to tune eligibility rules, flag thresholds, and the rubric before opening.
• Parallel or soft open (wk 4-6). Open the portal to a limited cohort or run alongside your current process for one cycle; the finance export is advisory.
• Go-live (wk 6+). The portal is the intake channel; the review workflow and the finance export become the systems of record for the program.
• Compliance handoff (go-live + 2 wk). Train staff on flag reason codes, sub-recipient monitoring, and progress and closeout reporting.

7. IT FAQ

Do you need write access to our ERP/finance system?

No. GrantDesk never writes to your ERP and needs no credentials to it. It publishes an award and disbursement file to your SFTP /out directory, and your existing import process consumes it under your controls.

Where is our data hosted?

A managed cloud environment with encryption at rest and logically isolated per-agency data. Single-tenant or agency-specified region deployment is available; the hosting model, region, and subprocessors are documented in the data-processing agreement.

How is applicant PII protected?

By collecting only what a program's form requires, then applying least-privilege RBAC, SSO/MFA support, TLS in transit, PGP-encrypted agency feeds, encryption at rest, and an immutable audit log. Attachments are access-controlled and logged.

How does the AI use our data?

AI features (screening summaries, risk flags, report drafts) run on your program's own data solely to produce advisory output for staff. Your data is not used to train shared models, and AI output is always labeled and staff-reviewed before it counts.

Can applicants use it without training?

Yes. The portal presents one clear form per program, with required-item prompts and save-and-return. It is designed to be simpler than the PDF-and-email intake most offices run today.

Can we run single-tenant?

Single-tenant hosting is a standard option where policy requires it. The file-based finance interface keeps the external surface small, which makes an isolated deployment practical.

What happens to our data at contract end?

You receive a full export of your data (applications, awards, monitoring records, audit log) in a documented format. After the export is confirmed, GrantDesk securely disposes of your data on a defined schedule, using cryptographic erasure where a full wipe is impractical, and records a disposal confirmation in the audit log.