UTA ↔ CNB EASI-Link Integration Specification — v5

Bank: City National Bank (CNB) — EASI-Link platform UTA System: Client Processing (replacing NetSuite AR) Document Status: Draft v5 — In ReviewLast Updated: 2026-05-05 Supersedes: UTA_Bank_Integration_CNB_EASI_Link_v4.md (retained for historical reference; do not edit) Authors: Cliff Song & Andrew (Product), with engineering review by Amir Hajizadeh and input from Jerome Calica (CNB)

---

How to Read This Document

This spec is organized by integration capability. Each service is documented in one place, with its confirmation status, channel choice, and rollout sequencing attached as metadata. If you want to see what's shipping first, see §9 Rollout Sequencing — but every service lives in its capability section regardless of when we build it.

Scope boundary — and who owns what. This document covers the UTA ↔ CNB integration boundary only at two layers:

1. The wire contract — what data crosses, in what format, on what schedule, via which channel, with which credentials. Documented per service in §5 / §6 / §7.
2. The business requirements UTA imposes on each call at the integration boundary — when to call each endpoint, what to do with the response payload, how to handle each exception class at the integration boundary. Examples already documented inline: §5's BAI2 prior-day-vs-current-day treatment and NACHA EDI consumption rules, §6's per-payment-type idempotency + RqUID assignment rules, §6's Positive Pay Phase-1 decisioning posture, §7's status-polling cadences and 50-tx batch ceiling, §8's cross-cutting cadences. Cliff (Product) owns this layer.

Three-document set required for full implementation:

Doc	Owner	Covers	Status
(A) This spec — UTA ↔ CNB integration spec	Cliff	The integration boundary: wire contract + integration-boundary requirements (above)	In flight (v5 — open items in §10)
(B) Client Processing behavior spec — what inside Client Processing triggers integration calls and processes the resulting payloads	Cliff (Product)	The upstream business-rules layer: AR-side matching rules, GL-posting cadence, deposit-creation logic, refund-authorization workflow, manual-review queue ownership, reconciliation rules	Not yet started — Cliff to scope and draft
(C) Engineering design doc — class decomposition, queue architecture, retry semantics, error-handling matrices, SFTP-listener + SOAP-poller structure	Amir's engineering team	The technical implementation of (A) + (B)	Drafted by Amir's team after (A) and (B) are both ready

This spec (A) alone is not sufficient input for engineering — (C) needs both the integration contract (A) AND the Client Processing behavior (B) to design against. Without (B), the engineering team can build the CNB-facing plumbing (SFTP listeners, SOAP envelope construction, status pollers) but won't know what inside Client Processing fires it or how the data is consumed once received.

Within this spec (A) only: if implementation surfaces a requirement gap at the integration boundary (an exception class with no documented handling rule, an unspecified poll cadence on a SOAP service, an SFTP file-arrival edge case), Amir's team flags it back to Cliff for a requirements decision, which gets landed in this spec — not in the engineering design. Requirement gaps inside Client Processing (matching rules, GL posting, refund authorization) land in (B), not (A).

If you are...	Read sections
Business stakeholder (skim, 5 min)	§1 Executive Summary, §2 What's Changed in v5, §9 Rollout Sequencing
CNB (Jerome / Joann / Maurice / Denise)	§1, §3 Architecture, §5 Inbound Data, §6 Outbound Payments, §7 Status, §10 Open Items
Dev team (Amir and engineers)	All sections; a separate engineering design doc will follow
Product team (Andrew + Cliff)	All sections; §9 Rollout, §10 Open Items, §11 Next Actions

Source citation policy: Every endpoint, field, schedule, and behavior is cited to the CNB source document + page, or to a dated conversation with Jerome / Joann / Maurice / Denise. Anything inferred or not yet confirmed is tagged [CONFIRM with CNB]. No Dev Test Cases or UAT Scenarios are written against a feature with open [CONFIRM] items — those features carry a Confirm-Blocked tag at the feature level.

Per-service metadata block: Each service in §5–§7 carries a small header block:

Status:    Cleared | Confirm-Blocked | Deferred | Not Yet Discussed
Channel:   SOAP | SFTP
Sequence:  (which rollout wave, see §9)

---

1. Executive Summary

UTA is replacing the AR functions of NetSuite with a custom system (Client Processing). This document specifies the integration between Client Processing and City National Bank via the EASI-Link platform.

The two-rail architecture:

1. SOAP / IFX — All outbound payment submissions, status inquiries, and on-demand inquiries. Single endpoint EASISubmit; the IFX XML payload inside determines the service. Authentication is X.509 mutual certificate + WS-Security.
2. SFTP — All inbound files (DDA reporting BAI2, NACHA EDI, check images, statements, exchange rates, ABA listing, positive pay exceptions). CNB pushes files to UTA's SFTP server. Authentication is User ID + RSA SSH key.

REST/JSON is not used. Per Jerome 2026-05-01, SOAP enables ACH batching that REST cannot match, and using a single rail eliminates the GUID-format incompatibility between REST and SOAP. The 2026-05-05 meeting confirmed dev-team approval of this approach; agentic tooling reduces the SOAP implementation lift.

Current state (2026-05-05):

• All inbound flows scope-locked. DDA Prior Day, DDA Current Day, NACHA EDI, Lockbox check images, Exchange Rate File, ABA Listing, Positive Pay Exception File, DDA Statement PDF.
• All outbound payment flows scope-locked on SOAP. ACH (both credit disbursements and authorized debit pulls), Domestic Wire, International Wire (with FX lock), Positive Pay (Issue/Void), Stop Payment, Book Transfer, and Check Issuance (outsourced + in-house).
• Status inquiry strategy locked: RqUID-based batches up to 50 transactions per call, parallel batches allowed, polling cadences set per payment type (§7).
• Phase 1 deferrals: Entitlements File, ARP, and Analysis Statements (EDI 822) — UTA still wants CNB to deliver these files where applicable, but does not intend to ingest/process them in Phase 1. Status History Chain (SOAP) is similarly available but reserved for audit/troubleshooting in Phase 2. Account count for Phase 1 (~24, pending business stakeholder verification — Cliff to confirm) makes a static internal table sufficient for the TPAS-ID-per-account map.
• PoC validated end-to-end on SOAP — <cnb:ExchangeRateRq> returned StatusCode 0 with live EUR/USD rate. The hardest path (mutual cert + WS-Security + IFX envelope) works.

Production target: October 2026 (~5 months out). Test readiness: 2–3 months for connectivity, file delivery, and API testing. [Source: Meeting 2026-05-05]

Open items from CNB:

• Jerome owes CNB's public SSH key (for UTA to install on UTA's SFTP) once UTA's SFTP is ready.
• Jerome owes TPAS IDs for each account once the SOAP environment is provisioned (§4.3).
• Jerome owes test-environment account-entitlement setup once Cliff provides the account list.
• Maurice owes the BAI lockbox memo enrichment timeline.
• Denise/Joanne owe the stop-payment-vs-positive-pay decision for voided checks.
• Stan owes the FCDA business justification.

Open items from UTA:

• Stand up UTA SFTP server and define the folder structure CNB will deliver into. CNB does not own the structure — UTA does.
• Cliff to provide accounts list (touring, endorsements, voiceovers) for test environment. Klutch is excluded — different bank.
• Department migration / double-counting strategy (zero-balance account structure) requires a follow-up call with business stakeholders + Jerome.
• Alan working on the SFTP-to-NetSuite bridge for NACHA files during the dual-delivery window. Architecture per Amir:
  • Primary path: NetSuite pulls from UTA's S3 bucket via S3 IAM credentials (using ns-aws-s3.js).
  • Fallback: AWS Lambda → SuiteTalk REST File API push into the NetSuite File Cabinet.
  • Direct SFTP → NetSuite is explicitly deferred. NetSuite publishes its outbound IPs only via DNS (outboundips.netsuite.com rotates); AWS security groups don't accept DNS-based allowlists, so locking the SFTP listener to a stable IP allowlist for NetSuite isn't viable until NetSuite changes that model.

---

2. What's Changed in v5 (vs. v4)

Area	v4 said	v5 says	Why it changed
SOAP-over-REST	Decided 2026-05-01	Confirmed by dev team 2026-05-05. Agentic tooling reduces SOAP implementation lift.	Meeting 2026-05-05.
Status inquiry batching	Not specified	50 transactions per <cnb:InquiryRq> call to stay within the 120-second Apigee timeout. Parallel batches allowed.	Meeting 2026-05-05.
Final status codes	Listed 0/5/10/30/31/40/60/96/116 generically	0 (processed) and 10 (processed with changes) are the FINAL statuses. Polling MUST stop once one is received. All other codes are intermediate.	Meeting 2026-05-05.
ACH polling cadence	Confirm-Blocked	Cleared. Aligned to ACH scoops at 9 AM, 11 AM, 2 PM, 4 PM, 5 PM, 6 PM. After each scoop, poll at 5-min intervals over a 30-min window.	Meeting 2026-05-05.
Wire polling cadence	"every 1–2 min"	Cleared. Every 5 minutes until final status.	Meeting 2026-05-05.
Outsource Check polling	Not specified	Cleared. One status request at submission, then a final request after 6:30 PM.	Meeting 2026-05-05.
Bulk submission response	Not specified	Documented (§7.5). Bulk submissions (>1 transaction in one document) return an ACK envelope only — no inline status. UTA then polls each RqUID individually. Single-transaction submissions return inline status.	Meeting 2026-05-05.
Change Status Inquiry (<cnb:InquiryChngRq>)	Cleared (Wave 2)	Removed from scope. Not applicable to UTA — bypass-release configuration + no BuildPay usage.	Meeting 2026-05-05.
Status History Chain (<cnb:InquiryStatusHistoryRq>)	Cleared (Wave 2)	Deferred to Phase 2. Reserved for audit / troubleshooting; not part of normal-flow polling.	Meeting 2026-05-05.
Status visibility scope	Not specified	Documented (§7.1). Status inquiry works ONLY for transactions UTA submitted via SOAP. Transactions initiated through EASI-Link directly, the Business Suite UI, or other channels cannot be queried by RqUID.	Meeting 2026-05-05.
Customer Login ID (TPAS ID)	Mentioned but not centralized	Centralized in §4.3 / §8.2. Required on every transaction at the granular payment level. 6–7 alphanumeric. Per-account assignment by Joann/Jerome ("JJ") when SOAP environment is provisioned. May change if accounts are removed/re-added. Letter-suffix variants (e.g., C, D) distinguish profile assignments.	Meeting 2026-05-05.
Entitlements File	Out of scope	Deferred to Phase 2. Static internal table sufficient for Phase 1's ~24 accounts. Will revisit when account count grows.	Meeting 2026-05-05.
ARP (Outstanding Checks Report)	Not in v4	Deferred — out of scope for now. Available on-demand from CNB; treasury hasn't requested.	Meeting 2026-05-05.
Analysis Statements (EDI 822)	Not in v4	Deferred to Phase 2. Account analysis file at the transactional level; finance can pull when needed.	Meeting 2026-05-05.
NACHA file format consistency	Not noted	Documented (§5.3). EDI 820 NACHA files vary by sender's format interpretation; usable as long as trace-ID matching is possible.	Meeting 2026-05-05.
ACH debit pulls (DirDebACH)	Not in v4 — only credit disbursements documented	In scope (§6.1). UTA can pull funds from third-party accounts with proper NACHA authorization. Authorization capture / storage / R-code handling are UTA's responsibility outside EASI Link.	Cliff direction post-05-05.
Production target	Not pinned	October 2026 (~5 months out from 2026-05-05).	Meeting 2026-05-05.
Test-env readiness	Not pinned	2–3 months for connectivity, file delivery, and API testing. Jerome's setup is minimal lead time once Cliff delivers the account list.	Meeting 2026-05-05.
Account-list scope (test env)	Not specified	Touring, endorsements, voiceovers departments. Clutch excluded — different bank.	Meeting 2026-05-05.
Department migration strategy	Not in v4	New open item (§10). Risk of double-counting deposits during incremental department migration when NetSuite + new system share operating accounts. Potential solution: zero-balance account structure with department-specific accounts feeding the main operating account. Requires follow-up call.	Meeting 2026-05-05.
NetSuite SFTP dual-delivery	Open item	Owner assigned (§10): Alan handling the SFTP-to-NetSuite connection for NACHA files during the dual-delivery window.	Meeting 2026-05-05.
7-series record file format	Not noted	Pending Jerome meeting (invite already sent). Trace-ID matching and format inconsistencies in the 7-series record.	Meeting 2026-05-05.

---

3. Integration Architecture at a Glance

CNB exposes the two channels v5 uses for non-overlapping purposes.

┌─────────────────────────────────────────────────────────────────────┐
│                          CNB EASI-Link                              │
└─────────────────────────────────────────────────────────────────────┘
                  │                              │
                  ▼                              ▼
        ┌──────────────────┐           ┌─────────────────┐
        │ SOAP / IFX XML   │           │ SFTP Push       │
        │ (outbound +      │           │ (inbound files) │
        │  status / inq)   │           │                 │
        ├──────────────────┤           ├─────────────────┤
        │ X.509 mutual     │           │ Public-key auth │
        │ WS-Security      │           │ CNB → UTA SFTP  │
        │ Basic256Rsa15    │           │ (RSA 2048/4096) │
        ├──────────────────┤           ├─────────────────┤
        │ ACH (batched)    │           │ DDA Current Day │
        │ Domestic Wire    │           │ DDA Prior Day   │
        │ International    │           │ EDI 820 NACHA   │
        │   Wire + FX Lock │           │ Image Deposit   │
        │ Stop Payment     │           │ Image Paid Chk  │
        │ Positive Pay     │           │ Exchange Rate   │
        │   (Issue/Void)   │           │ ABA Listing     │
        │ Book Transfer    │           │ Pos Pay Excpt   │
        │ Check Issuance   │           │ DDA Stmt PDF    │
        │ Status Inquiry   │           │ Status File     │
        │ FX Rate Inquiry  │           │                 │
        │ Image on-demand  │           │                 │
        └──────────────────┘           └─────────────────┘
                  │                              │
                  └──────────────┬───────────────┘
                                 ▼
                      ┌───────────────────────────┐
                      │  UTA Client Processing    │
                      │  (consumer system)        │
                      └───────────────────────────┘

Single SOAP operation: every SOAP call uses EASISubmit over https://www.qa.easilink.cnb.com/ws/easi.asmx (UAT). The IFX XML document inside the envelope determines the service — <PmtAddRq> for payments, <XferAddRq> for book transfers, <ChkIssueAddRq> for positive pay, etc.

---

4. Authentication & Connectivity

4.1 SOAP Authentication

Endpoint (UAT): https://www.qa.easilink.cnb.com/ws/easi.asmxOperation: Single EASISubmit — IFX XML payload inside determines the service.

Authentication: X.509 mutual certificate + WS-Security with Basic256Rsa15 algorithm suite, SignBeforeEncrypt message ordering, WSTrustFebruary2005 bindings.

Cert state (UAT):

Item	Value
Client cert thumbprint (UTA)	9a3117e63415c462eb9d0384a1f2ae9155b54dd1
Service cert thumbprint (CNB)	496C3E55... (rotated 2026-04-21; valid through 2027-02-23)
Service cert (prior, expired)	9c2704ad348dbb4bde26f1f8bf5d87386bc51388 (expired 2026-03-21)

Cert management scripts: Update-Thumbprints.ps1 and Refresh-GUIDs.ps1 in project root automate the cert + GUID rotation steps.

UAT credentials (confirmed working for the SOAP PoC; see §4.3 for per-account TPAS IDs):

• SPName: unitedtalent_soap_uat
• CustLoginId: 92936 (PoC-level; new per-account TPAS IDs to be issued by Jerome — see §4.3)
• Account: 101655075
• ABA: 122016066

Production credentials: To be issued by Jerome during onboarding.

Spec basis: Appendix B v14.1.0 §Overview, pp. 1–9.

4.2 SFTP Connectivity

Reference: CNB-Managed-File-Transfer-QRG.md (CNB MFT QRG v1.6, October 2022). v5 uses the "SFTP Preferred / Push to External" topology.

Protocol: SFTP. FTPS is also supported by CNB but not used. FTP / HTTP / HTTPS are explicitly unsupported. [QRG]

Topology: CNB pushes files to UTA's SFTP server. UTA does not poll CNB. CNB acts as the SFTP client; UTA hosts the SFTP server. [Source: Jerome Calica, CNB, 2026-04-21]

SFTP consolidation (per Meeting 2026-05-05): UTA is consolidating to a single new SFTP endpoint for NACHA files instead of the dual-system setup. Alan is working on the SFTP-to-NetSuite connection during the dual-delivery transition.

Authentication: User ID + public SSH key. No password. No PGP encryption is required. [QRG]

• UTA provides: SFTP URL and the folder structure specified below; UTA installs CNB's public SSH key.
• CNB provides: public SSH key (RSA 2048 or 4096) for UTA to install. [Owner: Jerome]

SSH key requirements:

Direction	Key type / size	Source
CNB → UTA (CNB's public key UTA installs)	RSA, 2048 or 4096 only	QRG
UTA → CNB (only if inverse direction is ever used; not in v5 scope)	RSA 2048/4096, Ed25519 255, or ECDSA 256/384/521	QRG

SSH key rotation (per Amir): No automatic key rotation today. CNB's current SFTP platform does not expire SSH keys. CNB plans to migrate to a new host in late 2026 / early 2027, after which key rotation will be self-service. Until that migration: UTA needs to document an internal manual rotation process (cadence, ownership, rollover procedure). See §10 Open Item #25.

Cipher / MAC / key-exchange compatibility: Modern OpenSSH defaults satisfy CNB's required algorithms; avoid disabling them in any hardening pass. Full lists in the QRG. See DSO-351 comment 95526 (Paul) for the SSH config decision context.

IP whitelisting (UTA firewall): UTA must whitelist CNB's source IPs for inbound SFTP. CNB-provided values (per Amir; re-verify with Jerome before provisioning):

Type	Values
Individual IPs	64.74.165.242, 12.9.150.242, 8.28.115.20, 63.199.123.20, 8.28.115.5, 63.199.123.5
CIDR ranges	199.250.12.0/24, 192.234.99.0/24, 199.250.8.0/24, 192.64.159.0/24, 159.55.220.0/24

These will need to be re-confirmed at the time UTA's SFTP listener is provisioned, since CNB's source ranges may change with the Seaburger migration.

Folder layout on UTA's SFTP — UTA owns and stands up this structure; CNB pushes files to the matching paths. Initial structure was sketched by Jerome 2026-04-24; v5 expands it to cover every inbound delivery in §5 and §7.4.

/<uta-sftp-root>/
├── /Production/
│   ├── /Prior_Day/                    ← DDA Prior Day BAI2 files (§5.2)
│   ├── /Current_Day/                  ← DDA Current Day BAI2 files (§5.1)
│   ├── /NACHA_EDI/                    ← EDI 820 NACHA files (§5.3)
│   ├── /LockBox_Images/               ← Deposit item images from lockbox (§5.4)
│   ├── /Paid_Check_Images/            ← Cleared outgoing check images (§5.5)
│   ├── /Exchange_Rates/               ← Nightly indicative FX rate file (§5.6)
│   ├── /ABA_Listing/                  ← Quarterly Fed ABA dictionary (§5.7)
│   ├── /Positive_Pay_Exceptions/      ← Daily PP exception XML, 1 PM decision deadline (§5.8)
│   ├── /DDA_Statements/               ← Monthly DDA statement PDFs (§5.9)
│   ├── /Status_Files/                 ← Final-status batch XML (§7.4)
│   ├── /Entitlements/                 ← Daily entitlements file — Phase 1 receive-and-archive only (§5.10)
│   ├── /Analysis_Statements/          ← EDI 822 account analysis — Phase 1 receive-and-archive only (§5.10)
│   └── /LockBox_Check_Report/         ← conditional — see note below
└── /UAT/
    ├── /Prior_Day/
    ├── /Current_Day/
    ├── /NACHA_EDI/
    ├── /LockBox_Images/
    ├── /Paid_Check_Images/
    ├── /Exchange_Rates/
    ├── /ABA_Listing/
    ├── /Positive_Pay_Exceptions/
    ├── /DDA_Statements/
    ├── /Status_Files/
    ├── /Entitlements/
    ├── /Analysis_Statements/
    └── /LockBox_Check_Report/         ← conditional

Folder-by-folder mapping to v5 services:

Folder	Service	Cadence	Format
/Prior_Day/	§5.2 DDA Prior Day	Daily ~5:30 AM PT Mon–Fri	BAI2
/Current_Day/	§5.1 DDA Current Day	Every 15 min, 4 AM – 7:45 PM PT Mon–Fri	BAI2
/NACHA_EDI/	§5.3 EDI 820 NACHA	3× daily (~3 AM, 4–4:30 AM, 1:50 PM PT)	EDI 820
/LockBox_Images/	§5.4 Image Deposit Item	Daily 4 AM PT Tue–Sat	XML w/ Base64 TIFF (or zip — pending §10 #7)
/Paid_Check_Images/	§5.5 Image Paid Check	Daily 4 AM PT Tue–Sat	XML w/ Base64 TIFF (or zip — pending §10 #7)
/Exchange_Rates/	§5.6 Exchange Rate File	Daily ~4 AM PT Mon–Fri	IFX XML
/ABA_Listing/	§5.7 ABA Bank Listing	Quarterly	Flat file
/Positive_Pay_Exceptions/	§5.8 Positive Pay Exception File	Daily ~6–7 AM PT Mon–Fri	XML
/DDA_Statements/	§5.9 DDA Statement PDF	Monthly per cycle	PDF
/Status_Files/	§7.4 Status File	Continuous, 3 AM – 11 PM PT Mon–Sat	XML (per service response schema)
/Entitlements/	§5.10 Entitlements File (Phase 2)	Daily 5:30 AM PT Tue–Sat (per spec)	XML
/Analysis_Statements/	§5.10 EDI 822 Account Analysis (Phase 2)	Per cycle	EDI 822
/LockBox_Check_Report/	Conditional — see below	TBD	TBD

/LockBox_Check_Report/ — conditional: Jerome included this folder 2026-04-24 pending verification with Maurice on the BAI lockbox memo line enrichment. If Maurice's BAI enrichment lands (§5.1), a separate lockbox check report becomes unnecessary. UTA provisions the folder so CNB can push if needed; whether files actually arrive depends on Maurice's outcome.

Notes for engineering:

• The Phase 2 folders (/Entitlements/, /Analysis_Statements/) are stood up in Wave 0 even though processing is deferred — Phase 1 disposition is "receive and archive."
• ARP (Outstanding Checks Report) is deferred and on-demand from CNB — no folder is provisioned in Phase 1. If treasury later requests ARP, add /ARP/ at that point.
• All filename patterns are documented per service in §5; UTA's parser routes by folder + filename pattern.
• [CONFIRM with CNB once UTA's SFTP is ready] — verify each folder is reachable for CNB's push and the filename patterns Jerome ultimately delivers match the spec patterns.

Operational notes from CNB MFT: 30-day online retention on CNB's side; older files archived. Files cannot be deleted/renamed by clients. To delete an uploaded file, contact CNB TM Servicing.

UTA-side S3 retention (separate from CNB MFT) — open question: UTA's S3 bucket backing the SFTP listener has its own lifecycle policy independent of CNB's 30-day window. DSO-351's original description called for 30 days in dev; Greg's 2026-05-05 distillation defaulted to 7 days for both environments and flagged retention as an open question. Amir's recommendation: 30 days in dev (easier troubleshooting during the test phase) / 7 days in prod. Decision needed before provisioning. See §10 Open Item #24.

Support contacts:

• Technical contact (primary): Jerome Calica.
• Operational support (escalation): CNB Treasury Management Client Services — (800) 599-0020 / TMServicing@cnb.com.

4.3 Customer Login ID (TPAS ID) — required on every SOAP transaction

Per Meeting 2026-05-05: every SOAP request submitted under the new architecture must carry a per-account TPAS ID in the <CustLoginId/> element under <CustId>. The PoC-level 92936 is not the production form — Jerome / Joann (collectively "JJ") will issue per-account TPAS IDs once the SOAP environment is provisioned for UTA's account list.

Format and behavior:

Attribute	Value
Length	6–7 alphanumeric characters
Scope	One TPAS ID per UTA account. UTA has ~24 accounts in scope (pending business stakeholder verification).
Mutability	IDs can change if accounts are removed and re-added by the implementation team — bake this into config, not constants.
Profile suffix	Optional letter suffix (e.g., C, D) distinguishes profile assignments under the same base ID.
Owner	Joann + Jerome ("JJ"). Provisioned when the SOAP environment is set up.

Phase 1 management: ~24 accounts (pending verification with business stakeholders — Cliff's action item) → maintain TPAS IDs in a static internal table keyed by account number. Sufficient until account count grows. The Entitlements File (§5.10 deferred) becomes useful at higher counts; revisit at that point.

Spec basis: Appendix B v14.1.0 p. 8 (<CustLoginId/> element); confirmed Meeting 2026-05-05.

---

5. Inbound Data Services

Every service in this section delivers data from CNB into UTA's environment via SFTP push.

5.1 DDA Current Day (intraday account activity, BAI2)

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 1

Purpose: Intraday delivery of every credit and debit posting to UTA's DDA — wires, ACH, lockbox — plus memo-posted (sent but not yet fully posted) items.

Attribute	Value
Mechanism	SFTP push
Format	BAI2
Cadence	Every 15 minutes during the window; may lag 1–5 min during 3pm wire volume spike
Window	4 AM – 7:45 PM PT Mon–Fri
Content	Deltas only — posted and memo-posted items
Memo posting applies to	Wires and ACH (wire sent, not yet fully settled; same-day posted ACH)
Includes	Incoming wires, balances, lockbox credits, same-day ACH
Filename pattern	CNB spec convention: EASI_TranCurrentDay.<SiteID>.<yyyymmddhhmi>.bai2 (or .bai2.pgp). Actual pattern delivered to UTA's SFTP TBD. [CONFIRM with CNB — actual filename pattern]

Spec basis: Appendix B v14.1.0 p. 110.

Format note: CNB's spec lists current-day in both IFX XML and BAI2. Per Jerome (2026-04-21), BAI is what is actually delivered and consumed; both formats carry the same field set (Appendix D pp. 9–10 vs. Appendix B pp. 106–109), so XML adds no information. IFX XML is not in scope.

Source-of-truth note: Sourced from CNB's IFS (core banking system). All DDA postings flow through IFS, so this feed captures the complete picture of account activity. ACH items are pushed into IFS by CNB's ACH processing engine — NACHA → IFS → DDA is sequential, so reading NACHA earlier than DDA does not give faster visibility. NACHA (§5.3) is delivered separately for richer remittance, not earlier arrival.

Lockbox memo line — pending: Maurice + Jerome adding transaction number, sequence number, and memo line to BAI so a separate lockbox feed is no longer needed. Timeline: Maurice to confirm. [Source: Jerome Calica, CNB, 2026-04-21] [CONFIRM with CNB — Maurice timeline]

Lockbox routing into BAI2 (per Jerome 2026-05-01):

• Checks mailed directly to lockbox feed into BAI2 automatically.
• Checks received at UTA office, courier'd to lockbox before cutoff, appear in BAI2.
• In-office scanned checks via Maurice's enhancement will route through the lockbox remittance system and appear in BAI2.
• Check number + amount enable cross-reference between BAI2 entries and image files.

CNB-specific BAI2 custom Type Codes (parser must handle these alongside standard BAI2 codes):

CNB extends BAI2 with custom Type Codes in the ranges 801, 900–919 (account status), 920–959 (credit), 960–999 (debit). Per Appendix D BAI v12.4.0 p. 8, the codes UTA may encounter on DDA-only accounts:

Type Code	Level	Description
935	CR DETAIL	RETURN WIRE — incoming wire that was returned. Must be handled by reconciliation logic.
936	CR DETAIL	DRAWDOWN WIRE

Other custom codes (801, 910, 940–945, 970, 973, 974) are CNS / sweep / dividend codes and should not appear on UTA's DDA-only accounts. If they do, treat as a config drift signal and investigate.

5.2 DDA Prior Day (end-of-day statement, BAI2)

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 1

Purpose: Authoritative prior-day closed dataset. Captures items CNB picked up after the ~6–7 PM cutoff that did not make the final intraday current-day file.

Attribute	Value
Mechanism	SFTP push
Format	BAI2
CNB generation	~2:00 AM PT daily (Mon–Fri, settled transactions)
UTA pull / availability	~5:30 AM PT
Filename pattern	EASI_TranPriorDay.<SiteID>.<yyyymmddhhmi>.bai2 (or .bai2.pgp). Actual pattern TBD. [CONFIRM with CNB]

Spec basis: Appendix B v14.1.0 p. 110.

When current-day and prior-day disagree: Prior day wins. Expected delta: ±5%. Deltas above 5% are an integration health signal worth investigating. [Source: Jerome Calica, CNB, 2026-04-21]

5.3 EDI 820 NACHA (ACH remittance feed from the Fed)

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 1

Purpose: Detailed ACH posting feed sourced directly from the Fed. Contains both pending and posted items with full remittance detail (no truncation) — including the complete ACH memo / addenda content.

Attribute	Value
Mechanism	SFTP push (single new SFTP endpoint per consolidation decision 2026-05-05)
Format	EDI 820 NACHA
Delivery cadence	Three deliveries per day: ~3 AM, ~4–4:30 AM, and 1:50 PM PT
Transaction codes	EDI 822 transaction codes carry the posted ACH items
Truncation	None — full remittance detail included
Sample files	6 recent NACHA files uploaded by Jerome to Box [Source: Jerome Calica, CNB, 2026-04-21]
Filename pattern	Not standardized in Appendix B or C. [CONFIRM with CNB — formal naming spec]

Format consistency caveat (per Meeting 2026-05-05): EDI 820 NACHA files vary slightly by sender's format interpretation (the Fed accepts a tolerant range of layouts). Confirmed usable as long as trace-ID matching is possible despite minor inconsistencies. UTA's parser must be tolerant of these variations.

7-series record format clarification: Jerome sent a meeting invite specifically to walk through the 7-series record file format, focusing on trace-ID matching and format inconsistencies. [Pending — Meeting 2026-05-05]

Alan ownership: During the dual-delivery transition window, Alan is responsible for the SFTP-to-NetSuite connection for NACHA files. [Action item from Meeting 2026-05-05]

5.4 Image Deposit Item File (lockbox + deposit checks)

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 1

Purpose: Receive deposit item images (front + back) for every check deposited to UTA's account, including lockbox-routed checks.

Attribute	Value
Mechanism	SFTP push only (no SOAP request alternative — per Appendix B v14.1.0 p. 125 / revision history v12.9.0: "The service is file push out only.")
Cadence	4 AM PT Tue–Sat
Filename pattern (per spec)	EASI_DepositItems.<SiteID>.<yyyymmddhhmi>.xml (or .xml.pgp); split-by-Company variant adds <CompanyName>
Image format (per spec)	Base64-encoded TIFF (CCITT Group 4) embedded in XML; one record per check (<TrnType> = Deposit or DepositItems)
Operational format note	Jerome described "TIF format in zip files" 2026-05-01. [CONFIRM with CNB — actual delivery format: XML-with-embedded-TIFF vs. zip-of-TIFFs]
Delivery folder	/LockBox_Images/

Spec basis: Appendix B v14.1.0 p. 125; revision history p. 6 (v12.9.0).

Cross-reference to BAI2: Check number + check amount on the BAI2 line correlate to the image record's <ChkNum/> + <CurAmt><Amt/>.

5.5 Image Paid Check File (outgoing checks cleared)

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 1 / Wave 2

Attribute	Value
Mechanism	SFTP push (SOAP <BankAcctTrnImgInqRq> is also available for on-demand single-check retrieval)
Cadence	4 AM PT Tue–Sat
Filename pattern	EASI_PaidChecks.<SiteID>.<yyyymmddhhmi>.xml (or .xml.pgp)
Image format	Base64-encoded TIFF (CCITT Group 4) embedded in XML; same caveat as §5.4 re: production format [CONFIRM]
Delivery folder	/Paid_Check_Images/ — separate from /LockBox_Images/ to keep deposit items and cleared outgoing checks in distinct folders

Spec basis: Appendix B v14.1.0 pp. 120, 124.

5.6 Exchange Rate File (nightly indicative rates)

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 2 (paired with International Wire build)

Purpose: CNB delivers a nightly indicative exchange rate file for UI pre-population before a user initiates an international wire. Not for GL posting — GL must use the locked rate from the two-step FX flow (§6.3).

Indicative-rate caveat: Per Jerome 2026-05-01, the file's rate spread is less advantageous than the live rate returned by <cnb:ExchangeRateRq> at submission time. Use the file for display only.

Attribute	Value
Mechanism	SFTP push
Cadence	~4 AM PT Mon–Fri
Filename pattern (per spec)	EASI_ExchangeRates.<SiteID>.<yyyymmddhhmi>.xml (PGP variant .xml.pgp)
Format	IFX XML; multiple <cnb:ExchangeRateRec> blocks

Spec basis: Appendix B v14.1.0 p. 142.

5.7 ABA Bank Listing File (Fed dictionary)

Status: Confirm-Blocked  |  Channel: SFTP  |  Sequence: Wave 2

Purpose: Reference dictionary of valid ABA routing numbers for account validation pre-flight.

Attribute	Value
Mechanism	SFTP push, flat file
Source	Federal Reserve
Cadence	Quarterly updates
Filename pattern	[CONFIRM with CNB — naming convention]
Sample file	Jerome to upload to Box for Cliff's review [Action item]

Decided: Adopted Meeting 2026-05-01.

5.8 Positive Pay Exception File

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 3

Purpose: Daily file listing every check that did not match a registered positive pay record. UTA must respond by 1 PM PT or CNB applies the configured default action.

Attribute	Value
Mechanism	SFTP push (XML file). SOAP <ChkIssueInqRq> also available for on-demand inquiry — see §6.7
Cadence	~6–7 AM PT Mon–Fri (file delivered)
Decision deadline	1 PM PT Mon–Fri
Default behavior	Configurable on CNB's side
Hold window	48 hours
Filename pattern	EASI_PosPayExceptions.<SiteID>.<yyyymmddhhmi>.xml (or .xml.pgp)
Content per exception	<cnb:ExceptionRqUID/> (correlates to Decision response), <ChkNum/>, <OrigDt/>, <AcctId/>, paid amount, paid date, payee name, exception reason, front + back check images (Base64 TIFF, CCITT Group 4)

Exception reasons (<StatusDesc/> per Appendix B v14.1.0 p. 134):

Reason	Meaning
Duplicate Pay	Same check number presented twice
Max Exception Limit Exceeded	Too many exceptions on this account
Max Amount Limit Exceeded	Item amount above configured threshold
Issue Missing Item Posted (PNI)	Item posted but no matching positive pay issue record
Issue Missing Item Not Posted	Item presented but not yet posted, no matching issue record
Voided Check	Item matches a record marked Void
Paid Amount Not Equal To Issue Amount	Amount mismatch
Paid Payee Mismatch	Payee name mismatch
Stale Date	Item too old
Below Min Amount	Item below configured threshold
Outside Serial Range	Check number outside the registered range

Spec basis: Appendix B v14.1.0 pp. 133–136.

5.9 DDA Statement PDF (monthly)

Status: Cleared (delivery) / Deferred (ingestion)  |  Channel: SFTP  |  Sequence: Wave 3

Purpose: Monthly DDA bank statement PDF. Stored in designated SFTP folder for retention; ingestion logic deferred.

Attribute	Value
Mechanism	SFTP push (PDF format elected)
Cadence	5 AM PT Mon–Sat
Filename pattern (PDF)	EASI_DDAStmts.<SiteID>.<AccountNumber>.<yyyymmdd>.pdf
Filename pattern (XML alternative — not consumed)	EASI_DDAStmts.<SiteID>.<yyyymmddhhmi>.xml (or .xml.pgp)
Size	~250 KB per 5-page statement, up to ~1 MB for 20-page statements

Spec basis: Appendix B v14.1.0 p. 119.

5.10 Phase 1 — Receive but Don't Process

UTA wants CNB to deliver these files in Phase 1 where applicable, but does not intend to ingest or process them yet. Phase 2 will pick up the processing logic.

File	Purpose	Phase 1 disposition	Source
Entitlements File	Daily XML with all account entitlements + TPAS IDs	Receive and archive; processing deferred. ~24-account scope makes a static internal table sufficient for now; the file becomes useful as account count grows.	Meeting 2026-05-05
ARP (Outstanding Checks Report)	Report of all printed / positive-pay-submitted checks still outstanding	Receive on-demand if requested by treasury; not currently requested.	Meeting 2026-05-05
Analysis Statements (EDI 822)	Account analysis at transactional level	Receive and archive; processing deferred. Finance can pull when needed.	Meeting 2026-05-05
FCDA integration	Foreign currency demand account — specs not yet available	Future phase; pending Stan's business justification.	Meeting 2026-05-05

5.11 Explicitly Out of Scope (Inbound)

Service	Why dropped
Dedicated 15-min incoming wire CSV	Redundant with DDA Current Day. Jerome 2026-04-21.
SOAP DepAcctStmtInqRq intraday polling	Entirely covered by SFTP current-day BAI2 feed.
SOAP IWN polling (DepAcctTrnInqRq)	DDA Current Day + EDI 820 NACHA cover incoming wire + ACH detection.
IWN SFTP file (Incoming Wire Notification File)	Same coverage as above — DDA Current Day BAI2 already includes incoming wires. Appendix B v14.1.0 p. 116.
Residual Remittance Image File	Not applicable to UTA's AR flow. Cliff 2026-04-24.
Lockbox remittance detail SOAP call	Once Maurice adds the memo line to BAI, separate lockbox feed is unnecessary.
Credit Card services (all — Entitlements, Relationships, Statement Image, Prior Cycle, Prior Day)	UTA does not consume CNB credit card products.
CNS Statement Image (SOAP) and Image CNS Statement File (SFTP)	UTA does not hold CNS / money market accounts at CNB. Appendix B v14.1.0 pp. 117, 119.
Bill Payment subordinate services and files (Payee Modification — eBills + Payee Info; Payee Registry File; Electronic Bill Presentment File; RithmPay Vendor Registry File)	All transitively out of scope since Bill Payment, Expedited CC Bill Payment, and RithmPay are out of scope (§6.8). Appendix B v14.1.0 pp. 24–36, 50.

---

6. Outbound Payment Services

Every service in this section submits to CNB via SOAP over EASISubmit. Each submission carries the per-account <CustLoginId/> (TPAS ID) per §4.3.

6.1 Domestic ACH (credit + debit, with batching)

Status: Cleared  |  Channel: SOAP  |  Sequence: Wave 2

Service path: <PaySvcRq> → <PmtAddRq>

Two directions in scope:

Direction	<SettlementMethod/>	Use case
ACH credit (UTA pushes funds out)	ACH	Standard ACH disbursement — paying clients, vendors, agents
ACH debit pull (UTA pulls funds in with authorization)	DirDebACH	Pulling from a third-party account UTA has authorization to debit (e.g., commission settlements, agency fee collections)

Service rules (apply to both directions):

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff	6 PM PT Mon–Fri
Future-dated	Up to 30 calendar days
Max amount	$99,999,999.99 per transaction
<PmtFormat/> (NACHA Standard Entry Class)	PPD (consumer), CCD (corporate), or CTX (corporate with addenda)
<AcctType/> (receiver, for credit; debited account, for debit)	DDA, SDA, or LOAN (LOAN only when settlement method is ACH)
<Category/> (Sender Entry Description)	Required, max 10 characters. Drives reconciliation tie-back.
<PayerInfo>	"Debit party information" — for credit, this is UTA; for debit pull, this is the third-party account being debited
<EmailAddr/> (under <CustPayeeInfo><FSPayee><ContactInfo>)	Optional. If populated, CNB sends a remittance email with ACH payment details to the recipient. Up to 2 email addresses, semicolon-separated, max 128 characters total. [Open item: confirm with UTA business stakeholders whether this should be used — see §10]

Spec basis: Appendix B v14.1.0 pp. 10–14, line 40 (<SettlementMethod/> ACH for credit or DirDebACH for debit).

Authorization for ACH debit pulls (NACHA-rules layer, NOT EASI Link):

EASI Link provides the technical rail (DirDebACH) but does not validate or store authorization for debits. The NACHA-required authorization layer is UTA's responsibility outside the integration:

• PPD (consumer accounts): signed written authorization from the account holder, retained per NACHA rules (currently 2 years post-revocation).
• CCD / CTX (business accounts): corporate trade agreement / authorization between UTA and the counterparty.
• UTA must store proof of authorization and be able to produce it on dispute. CNB will accept whatever UTA submits on DirDebACH — they do not police the authorization stack.
• Disputed and unauthorized debits get reversed (R-codes: R10 Customer Advises Not Authorized, R07 Authorization Revoked, etc.). UTA absorbs the operational + financial consequences.

Out of v5 scope (deferred): authorization-capture UI, signed-form storage, R-code handling, automated revocation processing. These belong in the Client Processing PoC spec, not the integration layer.

Batching capability — first-class feature:

CNB will batch ACH transactions when transactions in a single document share a common <PmtId/> AND match on each of: <SettlementMethod/>, <Name/> (debit party), <OrgIdNum/> (ACHID — or, if not specified, <DepAcctIdFrom> <AcctId/> must match), <PmtFormat/>, <Category/>, <PrcDt/>. [Source: Appendix B v14.1.0 p. 12]

Note: credits and debits batch on the same rules but cannot mix (different <SettlementMethod/> values).

What batching produces: A single offset transaction to the funding party (one debit on UTA's DDA for credit batches; one credit to UTA's DDA for debit-pull batches) regardless of how many items are in the batch — appears in BAI2 as a single summarized line with <Category/> (Sender Entry Description) tying back.

Worked example (per Jerome 2026-05-01): Nine payments to the same client + one to a different client, all sharing one PmtId, produce two ACH batches: nine same-client → one batch (single offset debit), tenth → its own batch.

Bulk submission response model (per Meeting 2026-05-05): When the document contains more than one transaction, CNB returns an acknowledgment-only response (see §7.5) — the per-transaction status is not inline. UTA must then poll each RqUID via §7.1 to get per-transaction status. Single-transaction submissions return inline status.

Status: See §7.1 for ACH polling cadence.

6.2 Domestic Wire

Status: Cleared  |  Channel: SOAP  |  Sequence: Wave 2

Service path: <PaySvcRq> → <PmtAddRq> with <SettlementMethod>FedNet</SettlementMethod>.

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff (Domestic Wire)	2:30 PM PT Mon–Fri
Cutoff (Book Wire — internal CNB-to-CNB)	4:00 PM PT Mon–Fri
Future-dated	Up to 30 calendar days
Max amount	$999,999,999.99
BBK ABA	9-digit ABA, optional if intermediary bank (IBK) is present
<Memo/> (OBI)	Optional, max 140 chars
Country	USA

Spec basis: Appendix B v14.1.0 pp. 63–68.

Book Wire note: CNB-to-CNB wires submitted with CNB ABA routing are automatically processed as Book Wires at the lower Book Wire rate.

Response identifiers: <PmtId/> returns 18-char IMAD for Fedwire; <RefInfo> blocks return IMAD/OMAD references.

Status: See §7.1 — Wire polling every 5 min until final.

6.3 International Wire + FX Lock

Status: Cleared  |  Channel: SOAP  |  Sequence: Wave 2

Two-step flow:

Step	SOAP element	Spec page
1. FX rate quote	<cnb:ExchangeRateRq>	Appendix B v14.1.0 p. 139
2. Wire submission with locked rate	<PmtAddRq> with <SettlementMethod>SWIFT</SettlementMethod> and the Step-1 RqUID echoed into <RefInfo><RefId/> (<RefType>QUOTERQUID</RefType>)	Appendix B v14.1.0 pp. 69–73

Service rules — International Wire:

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff — Business Int'l FX [Rate Sheet]	11:59 PM PT Mon–Fri
Cutoff — Business Int'l FX [Real Time]	2:30 PM PT Mon–Fri
Cutoff — Business Int'l USD	2:30 PM PT Mon–Fri
Cutoff — Consumer Int'l FX (any) and Int'l USD	1:55 PM PT Mon–Fri
Account type	Business accounts only for Int'l FX.
Future-dated	Int'l FX: no future dating. Int'l USD (Business): up to 30 days.
After-cutoff behavior	Int'l FX [Rate Sheet] cancelled next day at 2:30 PM. Int'l FX [Real Time] cancelled same day.

Service rules — Exchange Rate Inquiry:

Attribute	Value
Service availability	4 AM – 11:59 PM PT Mon–Fri
Major-currency cap	Inquiry not provided for amounts > $250K USD
Minor-currency cap	Inquiry not provided for amounts > $50K USD
<CurConvertRule/>	Direct (default) or Indirect

International Wire field differences from Domestic Wire:

• <SettlementMethod/> = SWIFT
• <BankIdType/> for BBK = SWIFT (8 or 11 char BIC)
• IBAN goes in <Memo/> as IBAN <IBAN#> — not a dedicated field
• Beneficiary <City/> and <Country/> required (<Country/> must NOT be USA)
• <RefInfo> carries FX lock reference: RefType = TRCTRL (rate-sheet, max 6 chars, required if amount > $50,000) OR QUOTERQUID (RqUID from preceding <cnb:ExchangeRateRq>)
• <CurAmt><Amt/> is in USD (debit amount); destination currency comes from FX response

FX lock mechanism: Reusing a morning rate for an afternoon payment requires exact match on amount + control ID; otherwise CNB will reprice at submission.

PoC status: <cnb:ExchangeRateRq> returned StatusCode 0 with live EUR/USD rate (1.2199) on 2026-04-21.

Status: See §7.1 — Wire polling every 5 min until final.

Spec basis: Appendix B v14.1.0 pp. 69–75 (International Wire), pp. 139–141 (Exchange Rate Inquiry).

6.4 Positive Pay Void

Status: Cleared  |  Channel: SOAP  |  Sequence: Wave 3

Purpose: Mark a check as Void via the Positive Pay rail. CNB will reject (NoPay) any presentation matching a Void record. Preferred path for voided checks in place of Stop Payment.

Service path: <BankSvcRq> → <ChkIssueAddRq> with <cnb:ChkAction>Void</cnb:ChkAction>. Same SOAP element as Positive Pay Issue Add (§6.7); only the <cnb:ChkAction> value differs.

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff	11 PM PT Mon–Sat
<cnb:ChkAction/>	Void (required; allowed values: Issue, Void)
<ChkNum/> (Serial Number)	Required, max 10 chars numeric
<cnb:Name> (Payee Name)	Optional, max 80 chars
<CurAmt><Amt/>	Required; max $1,000,000.00
<PaidDt/> (Issue Date)	Required, yyyy-mm-dd

Spec basis: Appendix B v14.1.0 p. 129 (line 40 confirms <cnb:ChkAction/> accepts Issue or Void).

Operational flow:

1. UTA registers the check as Void via <ChkIssueAddRq> with <cnb:ChkAction>Void</cnb:ChkAction>.
2. If presented, CNB matches it against the Void record and surfaces it as a Positive Pay exception with <StatusDesc>Voided Check</StatusDesc>.
3. Exception flows through the Positive Pay Exception File (§5.8) and SOAP exception inquiry.
4. UTA's automated decision rule for Voided Check exceptions = NoPay (or rely on CNB's configured default — [CONFIRM with Jerome]).

Stop Payment vs. Positive Pay Void: Denise / Joanne (via Jerome) to confirm whether stop payment is needed alongside positive pay for voided checks.

6.5 Stop Payment

Status: Cleared (capability) / Deprioritized vs. §6.4  |  Channel: SOAP  |  Sequence: Wave 3

Service paths:

Operation	SOAP element	Parent
Place stop	<StopChkAddRq>	<BankSvcRq>
Cancel stop	<StopChkCanRq>	<BankSvcRq>

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff	11 PM PT Mon–Sat
Future-dated	None
Stop term	Months (Count = 6 or 12) or Indefinite (Count = 0). Default = 6 months.
Single stop element	<StopChkInfo>
Range stop element	<ChkRange>
Stop cancel	<StopChkCanRq> with <StopChkId/> echoing the original <RqUID/>

Annual review of all stops required.

Cancel restriction: A Stop Payment Cancel will be rejected if the stop is no longer in Scheduled state. Status Inquiry (§7.1) returns the current PmtStatusCode to verify.

Spec basis: Appendix B v14.1.0 pp. 57–62.

6.6 Book Transfer (Account Transfer)

Status: Cleared  |  Channel: SOAP  |  Sequence: Wave 3

Service path: <BankSvcRq> → <XferAddRq>

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff	11 PM PT Mon–Sat
Future-dated	No
Account types	DDA → DDA only
<BankId/> allowed	122016066 or 026013958
Max amount	$999,999,999.99

Spec basis: Appendix B v14.1.0 pp. 88–90.

6.7 Check Issuance & Positive Pay (full lifecycle)

Status: Cleared  |  Channel: SOAP (with SFTP for exception file)  |  Sequence: Wave 3

Two parallel issuing paths (UTA uses both per Meeting 2026-05-01):

6.7.1 Outsourced Check Printing (CNB prints + mails)

CNB prints and delivers; auto-registers the check in CNB's positive pay system on issue.

Service path: <PaySvcRq> → <PmtAddRq> with <SettlementMethod>OutsourcedCheckPrinting</SettlementMethod>

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff	6:00 PM PT Mon–Fri
<DeliveryMethod/>	USPS, FedExOvernight, FedEx2ndDay, FedExGround
Country	USA or CAN
Max amount	$999,999,999.00

Spec basis: Appendix B v14.1.0 pp. 41–45.

6.7.2 In-House Check Printing (UTA prints; UTA registers via SOAP)

UTA prints. UTA must submit a Positive Pay Issue record via SOAP to register the check.

Service path: <BankSvcRq> → <ChkIssueAddRq> with <cnb:ChkAction>Issue</cnb:ChkAction>

Critical operational constraint: In-house checks must use a distinct check-number range from CNB's outsourced range. Otherwise check numbers will collide. [Owner: Jerome to confirm UTA's in-house range allocation]

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Cutoff	11 PM PT Mon–Sat
<ChkNum/>	Within UTA's allocated in-house range
<CurAmt><Amt/>	Max $1,000,000.00

Spec basis: Appendix B v14.1.0 pp. 129–132.

6.7.3 Positive Pay Exception Inquiry (SOAP, ad-hoc)

The SFTP exception file (§5.8) is the primary delivery mechanism; this SOAP inquiry is for ad-hoc lookup.

Service path: <BankSvcRq> → <ChkIssueInqRq>

Attribute	Value
Service availability	9 AM – 1 PM PT Mon–Fri
Cutoff	1 PM PT
Date range	Not supported — returns all current-day exceptions

Spec basis: Appendix B v14.1.0 pp. 133–135.

6.7.4 Positive Pay Decision (SOAP)

Service path: <BankSvcRq> → <ChkIssueStatusModRq>

Attribute	Value
Service availability	9 AM – 1 PM PT Mon–Fri
Cutoff	1 PM PT
<cnb:ExceptionRqUID/>	Required — correlates decision to exception
<ChkIssueStatusCode/>	Pay or NoPay
<cnb:StatusModReason/>	Altered, Forged, Fraudulent, or Refer to Maker

Spec basis: Appendix B v14.1.0 pp. 137–138.

6.8 Explicitly Out of Scope (Outbound)

Service	Why dropped
International ACH (IAT)	Not needed for UTA's current use case. Meeting 2026-05-01.
Wire Drawdown / 3rd Party Wire Drawdown	Not applicable with CNB-only banking. Meeting 2026-05-01.
CNS Transfer	UTA does not hold CNS / money market accounts at CNB. Meeting 2026-05-01.
RithmPay	Decided against — not in scope.
Bill Payment / Expedited CC Bill Payment	Consumer-style bill-pay not in UTA's flow.
Deposit Direct Send (RDC)	UTA delivers checks to lockbox; no remote-deposit X9.37 workflow.

---

7. Payment Status & Inquiry Services

UTA tracks every submitted payment to a final status via SOAP inquiry or the SFTP Status File. The strategy below was confirmed in Meeting 2026-05-05.

7.1 Status Inquiry by RqUID (primary method)

Status: Cleared  |  Channel: SOAP  |  Sequence: Wave 2

Service path: <cnb:InquiryRq> (sits directly under <cnb:CNBEASI> — not inside <IFX>).

Strategy: RqUID-batched polling (per Meeting 2026-05-05):

Attribute	Value
Service availability	3 AM – 11 PM PT Mon–Sat
Inquiry by RqUID	One <cnb:InquiryRq> per UID; multiple <cnb:InquiryRq> blocks per call, repeating
Batch size limit	50 transactions per call — to stay within the 120-second Apigee timeout
Parallel calls	Allowed for multiple batches when UTA has > 50 outstanding transactions
Returns	Latest status per UID

Final statuses (STOP polling once received):

Code	Meaning
0	Processed successfully — final
10	Processed with changes (e.g., effective date modified for late release) — final

All other codes are intermediate — keep polling on schedule. Polling MUST stop once a final code arrives, both to avoid unnecessary load and to satisfy CNB's expectation of well-behaved clients.

Status visibility constraint (per Meeting 2026-05-05): RqUID-based status inquiry works only for transactions UTA submitted via SOAP. Transactions initiated through any other channel — EASI-Link UI, CNB Business Suite, telephone instructions, paper, etc. — cannot be status-queried by UTA, since UTA does not hold their RqUIDs.

7.1.1 Per-payment-type polling cadence

ACH — aligned to scoops (per Meeting 2026-05-05):

Attribute	Value
First poll	Immediately after submission, to confirm validation
Scoop times (PT)	9 AM, 11 AM, 2 PM, 4 PM, 5 PM, 6 PM
Per-scoop poll pattern	5-minute intervals over a 30-minute window starting at the scoop time. Example for the 9 AM scoop: 9:05, 9:10, 9:15, 9:20, 9:25, 9:30.
Stop condition	Final status (0 or 10) received OR end of last scoop window without final status (escalate)

Polling outside the scoop windows is wasteful — CNB's processing happens at scoop times, not continuously.

Domestic Wire and International Wire (per Meeting 2026-05-05):

Attribute	Value
Cadence	Every 5 minutes until final status
Stop condition	Final status (0 or 10) received

Wire status transitions are fast; tight polling catches them promptly.

Outsource Check (per Meeting 2026-05-05):

Attribute	Value
First poll	At submission
Final poll	After 6:30 PM PT same day
Cadence between	None — only the two scheduled polls

Spec basis: Appendix B v14.1.0 p. 144; cadence per Meeting 2026-05-05.

7.2 Change Status Inquiry — REMOVED FROM SCOPE

Status: Out of Scope  |  Reason: Not applicable to UTA's configuration

<cnb:InquiryChngRq> (Appendix B v14.1.0 p. 146) returns only transactions whose status changed in a window. This is useful when the client's flow involves a release-approval step or BuildPay-style staging.

UTA does not use this service — UTA's submissions bypass the release queue (no human approval gate at the CNB layer; UTA's gating is upstream in Client Processing) and UTA does not use BuildPay. RqUID-batched polling (§7.1) is sufficient. [Source: Meeting 2026-05-05]

Implication for §8.1 status codes: because UTA's submissions bypass the release queue, codes 40 (awaiting authorized release), 41 (not enough releasers assigned), and 65 (denied by releaser) should not appear in normal-flow responses. If they do, treat it as a config drift signal — UTA's account configuration may have been changed back to require releaser approval. Investigate at the CNB-config level rather than handling as a normal pending state.

7.3 Status History Chain — Phase 2 Only

Status: Deferred to Phase 2  |  Channel: SOAP  |  Sequence: Phase 2

<cnb:InquiryStatusHistoryRq> (Appendix B v14.1.0 p. 148) returns the full ordered status chain for a UID. Reserved for audit / troubleshooting in later phases. Not part of normal-flow polling.

When to use (Phase 2): debugging a stuck transaction, audit investigation, dispute resolution. The chain shows every state transition — 5 (received), 40 (awaiting authorized release), 30 (ready for posting), 31 (scheduled for posting), 0 (processed) — with timestamps.

Spec basis: Appendix B v14.1.0 pp. 148–149.

7.4 Status File (SFTP) — final-status batch

Status: Cleared  |  Channel: SFTP  |  Sequence: Wave 2

Attribute	Value
Mechanism	SFTP push
Availability	3 AM – 11 PM PT Mon–Sat
Filename pattern	EASI_Status.<SiteID>.<yyyymmddhhmi>.xml (or .xml.pgp)
Schema	Same as the corresponding SOAP response per service
Content	Only transactions in final status

Use case: EOD reconciliation tie-out — confirm every submitted payment reached final status without polling each one individually. Complements §7.1 polling rather than replacing it.

Spec basis: Appendix B v14.1.0 p. 145.

7.5 ACK / Reject Response (bulk-submission pattern)

Status: Cleared  |  Channel: SOAP

When UTA submits a SOAP document containing more than one transaction, CNB returns an acknowledgment-only envelope instead of inline per-transaction status. UTA must then poll each individual RqUID using §7.1 to obtain status. Single-transaction submissions return inline status.

Behavior per channel (per Appendix B v14.1.0 p. 143 + Meeting 2026-05-05):

Submission type	Response
Single transaction over HTTPS	Most current transaction status returned inline (no separate ACK)
Bulk (>1 transaction in one document) over HTTPS	ACK envelope only — UTA polls per-RqUID via §7.1
SFTP file submission	ACK file (same name as request document) — UTA polls per-RqUID via §7.1

Schema validation failures: StatusCode 200 with <AdditionalStatus><StatusCode>202</StatusCode> describing the offending element. The request did not enter EASI-Link.

---

8. Cross-Cutting Concerns

8.1 Status / Reason Codes

The codes below are the ones UTA's implementation is most likely to encounter. Full table: EASI_Link_Appendix_C_v13.md.

Final statuses (STOP polling)

Code	Meaning
0	Processed successfully
10	Processed with changes (e.g., late-release effective-date modified, FX amount changed)

Intermediate statuses (keep polling)

Code	Meaning
5	Transaction received by EASI
30	Ready for posting
31	Scheduled for posting
32	Passed external validation (Wire)

Releaser codes — should NOT appear with UTA's bypass-release config

If any of these surface in a response, treat as a config drift signal — UTA's submissions are configured to bypass the release queue (§7.2). Investigate before treating as a normal pending state.

Code	Meaning
40	Awaiting authorized release
41	Awaiting release; not enough releasers assigned
65	Transaction denied by releaser

Common errors / rejections

Code	Meaning	Service	Typical action
20	Processed with warning — paid item(s) exist; paid item list provided	Stop Payment	Surface paid items to user; the stop arrived after presentation
50	Processing failed	Bill Pay, OCP	Investigate; non-recoverable for that submission
60	Account would overdraw	ACH, Account Transfer, BP	Return to submitter; do not auto-retry
70	Restrictive status on account (dormant, inactive)	Account Transfer, BP	Return to submitter; account state issue
72	Stop previously cancelled (101)	Stop Cancel	Verify state via Status Inquiry first
73	Stop previously cancelled — not on database	Stop Cancel	Same as 72
80 / 108	Duplicate transaction UID	All	Idempotency signal — the original submission landed; query its status
86	Transaction cancelled	All	Final
116	Account not found or closed	All	Return to submitter; do not auto-retry
118	Transaction rejected after OFAC Review	OCP, BP	Compliance hold; non-recoverable for that payee
204	Wire transaction rejected by the Wire Room	Domestic Wire, Int'l Wire	Investigate the rejection reason; manual repair may have failed
205	Transaction UID not recognized	Status Inquiry	UID was never received by EASI
206	Invalid Transaction for ACH ID — DirDebACH used with a Pre-Funding ACH ID	ACH (DirDebACH)	Provision a non-Pre-Funding ACH ID for debit pulls (open item — see §10).

Service availability

Code	Meaning	Action
90	Service temporarily unavailable; transaction will resume when service is restored	Wait (transaction is queued); do not resubmit
95	Service temporarily unavailable (interfacing system unexpected error)	Wait; do not resubmit — see Comments column in Appendix C for affected services
96	Service temporarily unavailable (Inquiry services — IDS/IPC/ISS/IRS/ICS)	Retry with backoff
99	Service temporarily unavailable; transaction failed — please resubmit	Resubmit with new RqUID

Setup / cert errors (Wave 0 / config validation)

Code	Meaning
100	Bad Site ID (CNB will investigate internally if fraud)
101	Invalid TPAS Client ID
102	Incorrect account number(s) or account is not setup in EASI or account is closed (incl. ACH ID)
103	Service not setup for account
105	Account number does not exist or is closed in Deposit (Stop Pay, Account Transfer)
106	ACH ID cannot be determined for the DDA
107	Certificate ID does not match SiteID (cert mismatch / rotation issue)

Validation errors

Code	Meaning
200	Format error from TPAS (paired with 202 in <AdditionalStatus>)
202	Value error — incorrect length, non-numeric, range exceeded, etc. (parse <StatusDesc> to debug)
203	Interfacing system returned 'Format Error'
901	Empty batch or empty Service Request
9003	XML Format Error — entire document rejected

For Positive Pay specifically, <ChkIssueStatus><StatusDesc/> carries one of the exception reasons listed in §5.8.

8.2 Identifier Discipline

Identifier	Purpose	Source
<cnb:BatchId/>	Document UID at the envelope level — 32-byte hex with edit dashes	Appendix B v14.1.0 p. 8
<RqUID/> (Service)	Service Request UID (one per <PaySvcRq> or <BankSvcRq> block)	Appendix B v14.1.0 p. 8
<RqUID/> (Transaction)	Primary transaction-level match key. 32-byte hex with edit dashes. Required to be echoed in BAI2 88,UTA-REF-<UID>/ continuation record. Used for Status Inquiry (§7.1), ACH batch correlation, Positive Pay exception correlation.	Appendix B v14.1.0 p. 8
<CustLoginId/> (TPAS ID)	Required on every transaction at the granular payment level. 6–7 alphanumeric, per-account assignment by JJ. Letter-suffix variants (C, D) for profile differentiation. May change if accounts re-added.	Meeting 2026-05-05; Appendix B v14.1.0 p. 8
<PmtId/> (request, optional)	ACH batching key — common value across transactions to be batched	Appendix B v14.1.0 p. 12
<PmtId/> (response)	CNB-assigned batch number / payment reference (e.g., 18-char IMAD on Domestic Wire)	Appendix B v14.1.0 pp. 13, 66
<XferId/>	CNB-assigned transfer reference for Book Transfer	Appendix B v14.1.0 p. 90
<cnb:ExceptionRqUID/>	Correlates a Positive Pay Exception to UTA's Decision	Appendix B v14.1.0 p. 134

GUID format note: SOAP uses 32-byte hex with edit dashes (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX). v5 standardizes on this form throughout.

8.3 Idempotency

Status: Confirm-Blocked

If UTA retries a SOAP submission with the same <RqUID/> after a network timeout where UTA does not know whether the first attempt landed: does CNB dedupe and return the original status, or create a duplicate? [CONFIRM with CNB — Jerome]

8.4 Pre-Flight Validation

Status: Phase 2

Purpose (Phase 2): Catch invalid submissions before sending them to CNB — e.g., validating the beneficiary's ABA locally against the §5.7 ABA Bank Listing file so UTA doesn't waste a round-trip on a wire / ACH that will be rejected with StatusCode 116. Phase 1 will rely on CNB's submission-time rejection. The §5.7 ABA file may still be received in Phase 1 (per §5.10) for archive use, with active validation logic deferred.

8.5 Monitoring & Alerting (integration boundary only)

• SFTP file delivery: If an expected push does not land within +15 min of its scheduled window, page on-call.
• SOAP submission failure: Log and surface promptly. Do not retry silently on non-200 responses unless idempotency is confirmed (§8.3).
• Status polling discipline: Alert if any RqUID reaches the end of its expected polling window without a final status (0 or 10).
• Cert expiry monitoring: Alert 30 days, 14 days, 7 days, and 1 day before either cert expires.
• Positive Pay decision-window monitoring: If §5.8 Exception File arrives but no decisions submitted by 12:30 PM PT (30-min buffer before 1 PM cutoff), alert.

8.6 No Cross-Bank Contamination

This document contains only CNB content. No other bank endpoints, field names, or patterns are referenced.

---

9. Rollout Sequencing

Production target: ~October–November 2026, subject to coordination with Jerome (CNB) and Amir Hajizadeh (UTA Engineering). Detailed wave-level timing TBD.

Wave	Services	Target
Wave 0 (Setup)	TBD	TBD
Wave 1 (Inbound)	TBD	TBD
Wave 2 (Outbound + Status)	TBD	TBD
Wave 3 (Check Ops + Statements)	TBD	TBD
Phase 2 / Deferred	TBD	TBD

---

10. Open Items (Consolidated)

#	Item	Section	Owner	Status
1	UTA SFTP server + folder structure stood up	§4.2	Cliff (UTA)	Open — CNB delivers into UTA-defined folders
1b	CNB's public SSH key for UTA to install	§4.2	Jerome	Open — once UTA's SFTP is ready
2	TPAS IDs per account	§4.3	Jerome (JJ)	Provisioned when SOAP env stood up
3	Phase 1 account list verified with business stakeholders (touring, endorsements, voiceovers — exclude Klutch)	§1, §4.3	Cliff (with business stakeholders) → Jerome	New from 2026-05-05
4	Lockbox memo line added to current-day BAI	§5.1	Maurice (via Jerome)	Timeline TBD
5	EDI 820 NACHA formal filename spec	§5.3	Jerome	Open
6	7-series record file format clarification (trace ID + format inconsistencies)	§5.3	Jerome	Meeting invite already sent
7	Image Deposit / Paid Check actual delivery format (XML w/ embedded TIFF vs. zip-of-TIFFs)	§5.4, §5.5	Jerome	Open
8	Separate SFTP folder confirmed for paid-check images vs. lockbox deposit-item images	§4.2, §5.5	Jerome	New
9	Status 96 root cause (UAT AcctInq intermittent)	§8.1	Jerome	Not a current blocker
10	ABA Bank Listing — filename convention + sample file	§5.7	Jerome	Sample file to Box
11	Idempotency semantics on SOAP retry	§8.3	Jerome	Open
12	Stop Payment alongside Positive Pay Void — needed or redundant?	§6.4, §6.5	Denise / Joanne (via Jerome)	Open
13	Positive Pay default action on no-decision-by-1PM	§5.8	Jerome	Open
14	Positive Pay exception sample files for testing	§5.8	Jerome	Action item
15	In-house check range allocation (which serial range is UTA's vs. CNB's)	§6.7.2	Jerome	Open
16	Outbound payment transaction limit per submission (vs. the 50-tx polling limit)	§6.1, §6.2	Jerome	New
17	ACK pattern threshold confirmation — is it strictly >1 transaction or a different threshold?	§7.5	Jerome	New
18	FCDA project business justification	n/a	Stan / Matt	Pending
19	Department migration / double-counting strategy (zero-balance account structure)	§10	Cliff + business stakeholders + Jerome	New from 2026-05-05; follow-up call needed
20	NetSuite SFTP dual-delivery during Seaburger migration	§4.2	Alan	New owner from 2026-05-05
21	Business Suite → API rail cutover plan for Positive Pay	§6.7	Jerome	Open
22	Pre-Funding vs. Standard ACH ID for UTA's account. DirDebACH is rejected (status 206) on a Pre-Funding ACH ID. If UTA's existing ACH ID is Pre-Funding-configured, Jerome must provision a separate Standard ACH ID for debit pulls — otherwise debit pulls fail at submission.	§6.1, §8.1	Jerome	New — needed before debit-pull build
23	ACH email remittance (<EmailAddr/>): confirm with UTA business stakeholders whether to populate this for ACH disbursements (CNB sends payment-detail email to recipient).	§6.1	Cliff (with business stakeholders)	New
24	UTA S3 bucket lifecycle (dev vs. prod retention) — DSO-351 original called for 30 days dev; Greg's distillation defaulted to 7 days for both. Amir recommends 30 days dev / 7 days prod. Decision needed before SFTP / S3 provisioning.	§4.2	Cliff + Amir + Greg	New (Amir)
25	Manual SSH key rotation process for UTA side — CNB's current platform doesn't expire keys; rotation becomes self-service after CNB's late-2026/early-2027 host migration. UTA needs an internal manual rotation playbook (cadence, ownership, rollover procedure) until then.	§4.2	Amir / UTA security	New (Amir)
26	Returning a misdirected incoming credit (wire or ACH received in error — e.g., funds intended for a different agency). Spec covers inbound reporting of returns (BAI 935 RETURN WIRE, <WireType>Return</WireType>) but defines no UTA-initiated service to send the credit back. Question to Jerome: is there an EASI Link service (wire return / RDFI ACH return via R-code) UTA can invoke, or is this strictly out-of-band Ops?	§5.1, §6	Jerome	New — question posed to Jerome 2026-05-13

---

11. Next Actions

Immediate (this week, per Meeting 2026-05-05):

1. Cliff: Complete this revised integration document (v5) by end of week.
2. Cliff: Share v5 with Jerome for review before wider team distribution (early next week).
3. Cliff: Verify Phase 1 account list with business stakeholders (touring, endorsements, voiceovers — Klutch excluded).
4. Cliff: Continue SFTP setup; notify Jerome when ready for file delivery.
5. Cliff: Schedule follow-up call with business stakeholders + Jerome to resolve department migration / account segregation strategy.
6. Cliff: Question Stan / Matt on FCDA project value proposition.

Waiting on CNB:

1. Jerome: CNB's public SSH key once UTA's SFTP is stood up.
2. Jerome: TPAS IDs for each account when SOAP environment provisioned.
3. Jerome: Set up test environment accounts once Cliff's account list arrives.
4. Jerome: 7-series record file format clarification meeting (invite already sent).
5. Jerome: Add exchange rate XML and ABA listing files to SFTP delivery schedule.
6. Jerome: Upload ABA listing sample file to Box.
7. Jerome: Confirm with Denise / Joanne whether stop payment is needed alongside Positive Pay Void.
8. Jerome: Provide Positive Pay exception sample files.
9. Jerome + Maurice: Add lockbox memo fields to current-day BAI.

Internal (UTA):

1. Alan: SFTP-to-NetSuite connection for NACHA files (during dual-delivery window).
2. Maintain static internal table of TPAS-IDs-per-account once Jerome provisions them. Revisit with Entitlements File when account count grows.

Approval path:

• This v5 spec is the artifact for both CNB and UTA to agree on for design, and serves as input to the engineering design document.
• Final design review call to invite the broader CNB team (Denise + others) to review the completed approach document and confirm mutual agreement.

Engineering design document — Amir's team owns drafting (separate from this spec; see the three-document set in How to Read This Document for context). Covers HOW the integration-boundary requirements in §5 / §6 / §7 / §8 plus the Client Processing behavior in document (B) are implemented: class decomposition, queue architecture, retry semantics, error-handling matrices for SOAP polling vs. SFTP file arrival, SFTP-listener structure, SOAP-poller structure for <cnb:InquiryRq> batches, OAuth/cert-refresh scheduling. Cliff's role here is requirements clarification when Amir's team flags an implementation question that exposes a gap at the integration boundary (when to call X, what to do with payload Y, how to handle exception Z) — those answers land in this spec. Gaps inside Client Processing (business rules, triggers, payload consumption) land in document (B). Engineering hand-off depends on BOTH (A) this spec AND (B) Client Processing behavior spec being ready — Amir's design needs both inputs. (A)-only hand-off would leave (C) without the business-rules layer it implements against.

Before Wave 1 build starts:

• Wave 0 complete: TPAS IDs issued, SFTP credentials exchanged, test-env entitlements set up.
• First set of sample files (current-day BAI + prior-day + NACHA + image file) successfully delivered and parsed in UAT.
• Engineering design document drafted and reviewed with Amir.

Before Wave 2 build starts:

• Wave 1 in production.
• Open items 5, 7, 10, 11 in §10 resolved (or consciously deferred with a deferral decision logged in CNB_Decisions_Log.md).

---

Appendix A — File Format Quick Reference

File	Format	Source doc
DDA Current Day	BAI2	Appendix B v14.1.0 p. 110; Appendix D BAI v12.4.0
DDA Prior Day	BAI2	Appendix B v14.1.0 p. 110; Appendix D
EDI 820 NACHA	NACHA (Fed standard)	[CONFIRM with CNB — formal spec]
Image Deposit Item	Per spec: XML w/ Base64 TIFF (CCITT Group 4)	Appendix B v14.1.0 p. 125
Image Paid Check	Per spec: XML w/ Base64 TIFF (CCITT Group 4)	Appendix B v14.1.0 pp. 120, 124
Exchange Rate File	IFX XML	Appendix B v14.1.0 p. 142
ABA Bank Listing	Flat file	[CONFIRM with CNB]
Positive Pay Exception	XML	Appendix B v14.1.0 p. 136
DDA Statement PDF	PDF	Appendix B v14.1.0 p. 119
Status File	XML (per service response schema)	Appendix B v14.1.0 p. 145
Analysis Statements (Phase 2)	EDI 822	Meeting 2026-05-05

Appendix B — SOAP Element Quick Reference

Service	Root element	Parent aggregate	Spec page
Domestic ACH	<PmtAddRq>	<PaySvcRq>	10
Domestic Wire	<PmtAddRq> (<SettlementMethod>FedNet</SettlementMethod>)	<PaySvcRq>	63
International Wire	<PmtAddRq> (<SettlementMethod>SWIFT</SettlementMethod>)	<PaySvcRq>	69
Outsourced Check Printing	<PmtAddRq> (<SettlementMethod>OutsourcedCheckPrinting</SettlementMethod>)	<PaySvcRq>	41
Stop Payment	<StopChkAddRq>	<BankSvcRq>	57
Stop Payment Cancel	<StopChkCanRq>	<BankSvcRq>	61
Account (Book) Transfer	<XferAddRq>	<BankSvcRq>	88
Positive Pay Issue / Void	<ChkIssueAddRq> (<cnb:ChkAction>Issue|Void</cnb:ChkAction>)	<BankSvcRq>	129
Positive Pay Exceptions Inquiry	<ChkIssueInqRq>	<BankSvcRq>	133
Positive Pay Decisions Add	<ChkIssueStatusModRq>	<BankSvcRq>	137
Exchange Rate Inquiry	<cnb:ExchangeRateRq>	<IFX> (no <BankSvcRq> wrapper)	139
Status Inquiry by RqUID (primary, batched up to 50)	<cnb:InquiryRq>	<cnb:CNBEASI> (no <IFX> wrapper)	144
Change Status (NOT IN SCOPE)	<cnb:InquiryChngRq>	<cnb:CNBEASI>	146
Status History Chain (Phase 2)	<cnb:InquiryStatusHistoryRq>	<cnb:CNBEASI>	148
Statement Image (DDA)	<BankAcctStmtImgInqRq>	<BankSvcRq>	117
Image Paid Check (on-demand)	<BankAcctTrnImgInqRq> (<TrnType>Check</TrnType>)	<BankSvcRq>	120

Appendix C — Source Document Index

Need	File	Primary pages
SOAP / IFX full reference	EASI_Link_Appendix_B_SOAP_v14.1.md	1–149
REST / JSON catalog (not in v5 scope; reference only)	EASI_Link_Appendix_B_REST_JSON_2025.md	all
SFTP file formats	EASI_Link_Appendix_C_v13.md	all
BAI2 format	EASI_Link_Appendix_D_BAI2_v12.4.md	all
Error / reason codes	EASI_Link_Appendix_C_v13.md	(Appendix C v13)
Remit Scan / lockbox	EASI_Link_RemitScan_UserGuide_Mar2026.md	all
Project-wide API summary	CNB-EASI-API-Comprehensive.md	all
Architectural decisions	Specifications/CNB_Decisions_Log.md	DEC-001 through DEC-015
CNB Managed File Transfer	Specifications/CNB-Managed-File-Transfer-QRG.md	all
Meeting notes — 2026-05-01 walkthrough	Meeting-Notes/CNB-Jerome-Meeting-2026-05-01.md	all
Meeting notes — 2026-05-05 final review	Meeting-Notes/CNB-Jerome-Meeting-2026-05-05.md	all

Appendix D — Glossary

Term	Meaning
ACH	Automated Clearing House — Fed-operated bulk payment network
Apigee	Google Cloud's API management platform sitting in front of EASI-Link; imposes the 120-second request timeout that drives the 50-tx batch limit
ARP	Account Reconciliation Plan — outstanding-checks report; available on-demand from CNB but deferred for UTA's Phase 1
BAI2	Bank Administration Institute v2 file format — bank statement
BIC	Bank Identifier Code — SWIFT bank routing code
Book Transfer	DDA-to-DDA fund movement within CNB (<XferAddRq>); same-day, no Fed network
Book Wire	A wire (<PmtAddRq> with FedNet) where both ABAs are CNB; auto-priced at the lower Book Wire rate
CCD	Cash Concentration or Disbursement — NACHA Standard Entry Class
CTX	Corporate Trade Exchange — NACHA Standard Entry Class with addenda
DDA	Demand Deposit Account — checking account
EASI-Link	CNB's treasury management platform
EDI 820	ACH payment order / remittance advice format (Fed-native for ACH)
EDI 822	Account Analysis Statement format — account analysis at transactional level
Entitlements File	Daily XML listing all account entitlements + TPAS IDs; valuable as account count grows
FCDA	Foreign Currency Demand Account — pending business justification
FedNet	The SettlementMethod value for domestic wires
IBAN	International Bank Account Number — used for Int'l Wire beneficiary in <Memo/>
IFS	CNB's core banking system — source of truth for DDA postings
IFX	Interactive Financial Exchange — XML standard CNB uses for SOAP payloads
IMAD	Input Message Accountability Data — Fedwire reference returned in <PmtId/> for domestic wires
JJ	Joann + Jerome (jointly responsible for TPAS-ID provisioning per Meeting 2026-05-05)
NACHA	National Automated Clearing House Association — governs ACH; file format name
PoC	Proof of Concept — end-to-end PoC completed 2026-04-21
PPD	Prearranged Payment and Deposit — NACHA Standard Entry Class for consumers
QUOTERQUID	RefType value used to bind a wire to a previously-quoted FX rate
RithmPay	CNB's third-party bill payment service via AgilLink — out of scope unless Stan confirms need
RqUID	32-byte hex Request UID with edit dashes — match key across every layer
Seaburger	CNB's new SFTP host, replacing Ipswich (migration in progress)
Scoop	An ACH processing window. CNB runs scoops at 9 AM, 11 AM, 2 PM, 4 PM, 5 PM, 6 PM PT — status changes happen at these windows, not continuously
SFTP	Secure File Transfer Protocol
SOAP	Simple Object Access Protocol
SWIFT	Society for Worldwide Interbank Financial Telecommunication — settlement method for international wires; also bank-routing format (BIC)
TPAS	Treasury Processing & Accounting System — CNB's term for the client side (i.e., UTA)
TPAS ID	Per-account customer login ID. 6–7 alphanumeric, assigned by JJ. Required on every SOAP transaction. See §4.3
TRCTRL	RefType value for a rate-sheet trader control number on Int'l Wire FX
WS-Security	Web Services Security — the envelope-signing standard SOAP uses
Zero-balance account	A potential structure for department migration: department-specific accounts feed a main operating account, sweeping daily

---

v5 Draft — 2026-05-05. Maintained by Cliff Song / UTA Product.Supersedes v4 (retained for reference; do not edit).