FTI / FA-DDX Data Boundaries
INTERNAL DRAFT — no counsel engaged. Highest-risk document in this packet. Federal Tax Information handling is strict and the governing standard changed recently. This is not a legal opinion. The single hard rule until an attorney reviews the
[LEGAL PLACEHOLDER]items below: do not let raw FTI into Eli. The intended technical posture (no raw-FTI custody) and a preliminary 800-171 Rev. 3 mapping can be shared as a design statement, not as a completed SSP, assessment, or control attestation. Re-verify implementation, deployment evidence, and current ED guidance at send time.
Last reviewed: 2026-06-26.
The standard, stated correctly
Data received from the IRS via the FUTURE Act Direct Data Exchange (FA-DDX) is Federal Tax Information (FTI). For Title IV aid partners, the governing safeguarding standard is NIST SP 800-171 Rev. 3, per ED's Dear Colleague Letter "Guidance on the Use of Federal Tax Information (FTI), FAFSA Data, and Non-FAFSA Data," dated September 30, 2025. FTI must be labeled and handled as Controlled Unclassified Information, CUI//SP-TAX, and that protection travels with the data wherever it is stored or accessed.
Correction to prior collateral. Earlier Eli materials (and the public
/securitypage) cited IRS Publication 1075 as the governing FTI standard. That is the IRS-side reference for agency/agency-contractor contexts; for ED aid partners the operative standard is NIST SP 800-171 Rev. 3. Lead with 800-171 Rev. 3; mention Pub 1075 only as the IRS-side reference. If a specific institution or state agency contractually imposes Pub 1075, honor that.
Eli's posture: do not take custody of raw FTI
The cleanest and lowest-risk architecture, and the one Eli is built around, is that Eli does not ingest or take custody of raw FTI.
- Eli does not call the FA-DDX API. The system assumes income/tax figures are already present on the case at intake (either pre-populated through the school's FA-DDX channel, or manually entered for exclusion cases). Eli never retrieves FTI from the IRS itself.
- The school's authorized staff see FTI inside the school's boundary. Eli's role is to support verification of non-FTI artifacts (uploaded documents, worksheets) and to reconcile reported figures, not to be the system of record for raw IRS transcript data.
- FA-DDX exclusions are handled deterministically, not by the AI. When FA-DDX cannot supply data (parents filed separately, a marital-status change after the tax year, or a foreign return), the case carries an exclusion flag that routes it to manual handling and surfaces it for professional judgment (
lib/pj/detect.ts,lib/funnel.ts). These are the residual cases a human works.
This posture means Eli's trust story is: "the school's authorized staff handle FTI inside their environment; Eli handles the verification workflow around it, and inherits FTI-grade controls for any tax-derived figures it does process."
If/when Eli does process tax-derived data
Even tax-derived figures (an AGI value reconciled against a document) warrant FTI-grade care. The repository/design elements below are a preliminary mapping, not proof that every applicable requirement is implemented or operating:
| 800-171 Rev. 3 family | Eli control |
|---|---|
| Access Control | Repository RLS migrations, server-side DB access, roles, and application tenancy scoping; deployed schema/policy and negative-access evidence remain required (../02-security/rbac-model.md) |
| Audit & Accountability | Partial: tamper-evident hash chain for review actions and agent runs; general record-read/access and security-event logging remains a gap (lib/audit-hash.ts) |
| Identification & Authentication | Signed sessions; MFA on roadmap |
| System & Communications Protection | HSTS/security-header configuration; deployed TLS plus provider encryption/key-management evidence required; app-layer field encryption is not implemented |
| Incident Response | Draft written plan; contact, notification commitment, exercise, and deployed escalation evidence remain open (../02-security/incident-response.md) |
| Media Protection / disposal | Draft retention/disposal design; production multi-store purge, backups, and deletion evidence are not implemented end to end (../02-security/data-retention-deletion.md) |
| Configuration Management | Typed code, automated tests, security headers, and CSP exist; a formally approved configuration/change-control program and evidence remain open (next.config.ts) |
Conditions on any contractor FTI access
If a pilot did require Eli to touch raw FTI, the conditions are heavy and explicit:
- access strictly on a least-privilege, legitimate-duties basis;
- the vendor assumes the safeguarding responsibilities and liability (HEA, IRC, Privacy Act);
- personnel complete applicable FTI training;
- the school/state agency ensures the external recipient meets NIST SP 800-171 Rev. 3;
- where Pub 1075 governs a particular channel, its contractor mechanics (IRS notification, contract clauses) apply.
The default recommendation is to keep raw FTI school-side and avoid these obligations until the controls above (MFA, app-layer encryption, an independent assessment) are in place and counsel has signed off.
[LEGAL PLACEHOLDER] — items to finalize when counsel is engaged
Until an attorney is engaged, these stay open and the hard rule holds (no raw FTI in Eli):
- Confirm the NIST SP 800-171 Rev. 3 framing and the "no custody of raw FTI" boundary as actually implemented.
[LEGAL PLACEHOLDER]— contract language on liability flow-down before any FTI touches Eli.- Re-verify the September 30, 2025 DCL is still the operative guidance at send time (internal task, no attorney needed).