Prepare encrypted complete FinCEN batch bytes with frozen alert sources for independent review

Send on every write that creates or changes money or state; a replay with the same key returns the original result with 200.

Attachment is the exact CSV named by imported SARX XML. Native requests retain bytes on SAR.Attachment instead; this field stays empty for them.

CTRRequest contains only reviewed form metadata. Monetary amounts, account numbers, ownership, dates and complete activity membership come from native source records; there are no caller-supplied financial totals. An empty Profile is the original own-account teller profile, which uses Person and the Bank location fields. CTRProfileV2 uses Persons, Entities, Locations and, for a corrected report, PriorPacketID; those fields are absent from v1 requests so retained v1 input digests never change. CTRProfileV3 uses the v2 fields plus directed-backfile instruction evidence and extended party identity.

SARRequest is confidential filing input supplied by verified filing staff. Personal and institution metadata are retained assertions for independent review, not identities inferred from an alert or a successful XSD check. Initial scope supports the actual large_transaction alert's exact event link. Other alert/window semantics and additional parties require another profile. SARProfileV2 uses AlertSources, Subjects, Products and the optional Branch, Attachment, SubjectUnknown, PriorPacketID and PriorActivitySequence fields; they are absent from v1 requests so retained v1 input digests never change. SARProfileV3 uses the v2 fields plus JointFilers, Directed, Branches, CyberEvents, IPAddresses and DisputeIDs; those are absent from v1/v2 requests.

Acknowledgment is one complete FinCEN XML 2.0 batch response. Parsing establishes its structure and exact activity membership, not the response's authenticity or that it belongs to a particular submitted file. The filing service must bind the original response bytes to an authenticated transmission receipt before use.

ContinuingReference names the exact accepted SAR activity a continuing report follows. It is plaintext packet content so admission guards can bind it.

PacketDisposal marks a packet whose encrypted documents were destroyed.

NativeProvenance distinguishes an actual source-generated, locally validated form from imported XML and independently authenticated bridge reports.

NativeValidation retains the complete deterministic engine reports without pretending the bank's local validator signed as an independent bridge. Maps marshal canonically across PostgreSQL JSONB key-order normalization.

SupportDocument is the one CSV attachment a SARX activity names, whether the batch was generated natively or imported with those exact bytes. The SAR XML User Guide 1.6 (section 4.5 and Attachment E) permits one MS Excel-compatible CSV of at most one megabyte per SAR, recorded by its full name in OriginalAttachmentFileName; batch filers place each CSV in the attachment zip file named <activity SeqNum>_<OriginalAttachmentFileName>. The exact bytes are a separate encrypted payload released only with the approved batch naming them.

ValidationReport is the bridge's complete schema + filing-rule result for an immutable configured ruleset. Findings are retained even on failure. The actual validator implementation must run the full schemas and business rules; manifest inspection is not sufficient to issue a successful report.