CI-01 — Initial CU Infrastructure and Money-Movement Integration

Customer Integration · Working Draft · Revised Working Copy v2 · Updated August 21, 2026

1. Objective

Implement the first credit union’s concrete DragonPay integrations required to operate PP-01 P2P using the CU’s existing authentication context, member/account data, core-banking capabilities, CU-controlled funding mechanism, on-us posting, external ACH process, status evidence and operational procedures.

CI-01 is the CU-specific implementation boundary. It converts the first CU’s established technology and operating practices into the stable DragonPay contracts defined by PP-01 and the Payment Hub. CU-specific Symitar, PowerOn, MuleSoft, ACH, endpoint, credential, file and status details remain behind CI-01 adapters, Connections and Connectors rather than entering Product or shared Hub code.

The acquired RCUpay workflows are treated as production-proven behavioral input. They establish the Sender/Recipient operating model and identify several current integration surfaces, but they explicitly do not depict every dependent system or error path. CI-01 therefore includes a structured discovery and certification phase for mechanics not established by the supplied artifacts.

2. Initial CU integration shape

The initial CU integration should preserve the existing P2P behavior while replacing implementation coupling with DragonPay contracts. The first production path may use CU-authorized existing endpoints where appropriate, but DragonPay code must consume them only through CI-01 adapters/Connectors and PH-08 Connections.

Runtime architecture

CU Digital Banking / CX-01A authenticated launch
        ↓
CX-01 / PP-01
   ├─ Member/account/entitlement needs → CI-01 CU Service Adapters → CU middleware / Symitar
   └─ Payment Leg execution → PH-07 Route Decision → PH-08 Connection + Connector
                                           ↓
                                  CI-01 Payment Connector
                                           ↓
                              CU core / ACH process / processor

All CU-specific mapping, credentials, endpoints and external schemas remain below the shared DragonPay contracts.

Initial integration components

Component	Initial responsibility
CU Member/Account Adapter	Resolve trusted CU member references; retrieve eligible source-account facts, account status and masked display; obtain entitlement/limit inputs required by PP-01/PH-06.
CU Core Payment Connector	Execute CU-controlled Funding, same-CU Recipient Payout and Return-to-Sender movements through the approved Symitar/core interface; normalize results to PH-08.
CU Recipient Account Adapter	Resolve/validate an RCU recipient account when the claim selects same-CU delivery; return only the normalized eligibility/display facts required by PH-05/PP-01.
CU ACH Connector	Execute the external Recipient Payout through the CU’s existing ACH origination process; preserve file/API/processor evidence inside the concrete Connector and normalize execution state to PH-08.
CU Status/Return Adapter	Ingest or query authoritative CU/core/processor status, acknowledgements, Returns and corrections required by PH-08/PH-10.
Optional CU Risk Input Adapter	Retrieve CU-specific fraud/risk facts or scores when the first CU requires them; PH-06 remains authoritative for the DragonPay Decision and normalized score.
Optional PH-12 CU Communication Adapter	Use existing CU SMS/email services only if selected for first-CU delivery. PH-12 remains owner of communication requests, templates and delivery state.
Connections and secrets	PH-08 Connection records reference tenant-specific endpoints and secret/certificate references. Secrets remain in platform secret management, never in business records.

3. Production behavior inherited from RCUpay

The acquired Sender and Receiver workflows demonstrate the following behavior that CI-01 must enable for the first CU. PP-01/CX-01 own the customer behavior; CI-01 supplies the CU-specific facts and money-movement mechanics behind it.

Observed RCUpay behavior	DragonPay implementation responsibility
Member enters P2P from authenticated online/mobile banking.	CX-01A establishes trusted launch/member context; CI-01 resolves the CU member/account references required by backend integrations.
Sender accepts P2P disclosure, chooses recipient email/phone, source account, amount and security word, then confirms once.	PP-01/CX-01. CI-01 supplies eligible source-account, entitlement and limit facts; no CU-specific Product logic is placed in the UI.
Current flow performs CU core/GL activity before the Receiver claims.	CI-01 Core Payment Connector implements the first CU Funding Leg using the authoritative CU-controlled mechanism discovered/certified from the existing implementation.
Receiver has a limited claim period and must provide the Sender security word.	PP-01/CX-01/PH-12. CI-01 is involved only where CU-backed recipient/account validation is required.
Receiver can deposit to an RCU account or another FI.	CI-01 supports same-CU account validation and ON_US payout; external FI payout uses the CU ACH integration.
Same-CU receipt is described as immediate; external FI receipt occurs through ACH over subsequent business days.	PH-07 owns route/timing presentation; CI-01 supplies actual capability schedules/status evidence for the configured first-CU routes.
Failed/expired claim returns the funded amount to the Sender.	PH-04/PP-01 create the corrective Return-to-Sender movement; CI-01 executes the CU-specific return through PH-08.
Existing implementation sends SMS/email and tracks SMS opt status/reminders.	PH-12 owns communication behavior. A CU communication adapter may reuse approved first-CU services if that remains the launch decision.
Existing system uses MuleSoft, a P2P API and Symitar/PowerOn integrations.	CI-01 reverse-engineers the behavior and mappings. Shared PP/PH code depends only on DragonPay contracts, not MuleSoft or Symitar-specific APIs.

4. Discovery and legacy mapping

CI-01 begins with a behavioral and technical inventory of the acquired implementation. Every production-significant rule or dependency must be classified as Product behavior, shared Payment Hub behavior, CU integration behavior, or legacy implementation detail.

Required discovery outputs

• Inventory of the current P2P .NET service, MuleSoft flows/DataWeave, SymXchange operations/PowerOns, configuration, external files, queues and scheduled jobs used by Sender, Receiver, funding, payout, return, status and reconciliation paths.
• Trace from each existing API/flow to its authoritative downstream system and business purpose, including error/timeout behavior and retry semantics.
• Mapping of current RCUpay database entities/fields to PP-01, PH-03, PH-05 and integration-only state; legacy tables are not automatically reproduced.
• Identification of CU-specific limits, entitlements, risk/fraud inputs, manual overrides and account restrictions used by the current production flow.
• Identification of exact core/GL movements for Funding, same-CU Payout and Return-to-Sender, including authoritative success evidence and rollback/correction procedures.
• Identification of the external ACH creation/delivery/origination process, schedules/cutoffs, ODFI/processor relationship, acknowledgements, Returns, Notifications of Change where applicable, and production evidence sources.
• Identification of operational dependencies not visible in the supplied diagrams, including monitoring, batch jobs, reporting, support procedures and disaster-recovery assumptions. Discovery is complete for a capability only when DragonPay can reproduce its required behavior through a defined adapter/Connector contract and deterministic test scenario.

5. CU member, entitlement and account integration

CI-01 must provide server-side adapters that translate the trusted CU member context into the member/account facts required by PP-01, PH-05 and PH-06. The existing RCUpay documentation identifies an entitlement service used for RCUpay account limits; the exact full set of member/account interfaces must be confirmed during discovery.

Normalized member/account response

• tenant_id and trusted CU member/authorized-user references supplied from PH-01/CX-01A context.
• CU account external reference; account type/classification; masked display/name.
• account active/restricted status and Sender authority where supplied.
• P2P eligibility facts and CU entitlement identifiers required by PH-06 policy.
• CU transaction-limit facts or references when the CU remains authoritative for them.
• available-funds result when required for Funding; DragonPay does not persist the CU balance as authoritative truth.
• validation source, timestamp and freshness/expiration metadata. Adapters must use secure service authentication, bounded timeouts and STD-01 resilience controls. Read failures return normalized unavailable/indeterminate results; PP-01/PH-06 determine whether the payment may proceed.

6. CU-controlled Funding and Return integration

The first-CU P2P model requires authoritative Funding before the Recipient invitation is delivered. CI-01 must implement this as a PH-08-executable Payment Leg through the CU Core Payment Connector.

Funding contract

Input	CI-01 responsibility
PaymentInstruction / Leg purpose = FUNDING	Map the canonical source account/amount/currency and bound Connection configuration to the CU-supported core operation.
External idempotency reference	Use the strongest CU-supported duplicate protection. If the CU interface lacks native idempotency, Connector safeguards and authoritative inquiry must prevent uncontrolled duplicate posting.
Execution deadline	Propagate/observe the applicable deadline; caller timeout does not imply payment failure.
Core result	Normalize NOT_SUBMITTED/SUBMITTED/ACKNOWLEDGED/FINAL/UNKNOWN handoff certainty, success/rejection/error and external posting/evidence references.
Authoritative funding success	Return FINAL success only when the CU-defined funding/posting evidence is satisfied; technical request acceptance alone is not enough.
Unknown result	Return UNKNOWN and support inquiry/correlation. A potentially submitted Funding movement must not be blindly repeated.

The exact Symitar operations, PowerOn names, GL/account identifiers and CU accounting treatment are Connection/Connector configuration or implementation details to be confirmed from the acquired system. PP-01 and PH-04 receive only the normalized funding outcome.

Return-to-Sender contract

When PP-01/PH-04 determines that a funded but unpaid P2P must terminate, PH-08 invokes a separate corrective Payment Leg. CI-01 maps that instruction to the CU-supported return movement and preserves its own idempotency, posting reference, handoff certainty and final evidence. A return failure or unknown result remains independently resolvable; it must not cause a second payout or second return.

7. Recipient account and ON_US payout integration

For a Recipient who chooses the same CU during claim, CI-01 must validate the intended receiving relationship and execute the Recipient Payout through the CU-approved on-us/core mechanism.

Recipient validation must provide only the normalized facts needed by PH-05/PP-01:

• whether the supplied CU recipient credentials/reference can be resolved through the approved flow;
• eligible destination account reference/type and masked display;
• account active/receive eligibility and any applicable CU restrictions;
• validation source/time and reusable external reference when permitted. The Recipient Payout Leg requires the ON_US Route Type. PH-07 selects the configured ON_US Route Capability/Connection; PH-08 invokes the CI-01 Core Payment Connector. CI-01 does not embed the Product decision that a same-CU destination is ON_US—that semantic requirement is owned by PP-01/PH-04.

Authoritative completion is the CU-defined successful recipient posting evidence. If the posting may have occurred but the response is uncertain, the Attempt becomes OUTCOME_UNKNOWN and CI-01 supports status inquiry rather than a new blind posting.

8. External Recipient ACH integration

For a Recipient who chooses another financial institution, PP-01 requires ACH for the initial Product. CI-01 must implement the first CU’s actual ACH origination path behind the PH-08 Connector Contract.

CI-01 ACH implementation must determine and implement:

• baseline destination account data collection is direct Recipient entry (routing number, account number, account type, account-holder name) per CX-01, validated against a routing-number lookup source; a provider-based tokenization/verification service is a possible future addition, not required for the initial Product;
• the first CU’s ACH execution method: Nacha file, CU/processor API, existing payment platform, or another approved CU process;
• Company Identification, SEC code and other CU-specific Nacha values when a file path is used;
• file/batch naming, grouping, balancing/control totals, delivery destination, pickup/release behavior and schedule when applicable;
• business-day calendar, Same Day/standard processing support, cutoffs and delivery evidence consumed by PH-07/PH-08;
• authoritative acceptance/completion evidence and the external identifiers/trace numbers required for operations/reconciliation;
• acknowledgement, rejection, Return and Notification of Change inputs where the selected process supplies them. If the initial CU uses a file-based process, file/batch mechanics stay inside the concrete ACH Connector unless repeated future integrations justify extracting shared file infrastructure. PH-08 records the normalized ConnectorOperation/evidence and PH-03 owns the Execution Attempt/Provider Transaction.

9. External status, returns and reconciliation evidence

CI-01 must make external CU evidence consumable by PH-08 and PH-10 without requiring those services to understand CU-specific schemas.

Normalized evidence should cover, where available:

• core posting/completion reference for Funding, ON_US Payout and Return-to-Sender;
• ACH file/batch/entry references retained by the concrete Connector;
• CU/processor acknowledgement or rejection;
• ACH trace/reference and current entry status;
• Return/correction reference, amount, reason and effective date;
• Notification of Change evidence when applicable;
• status-inquiry result and authoritative no-transaction evidence;
• mapping-set version, Connector version and external schema/message version. Asynchronous events/files are deduplicated before they change DragonPay state. Unknown or unmatched records are retained as secure evidence and routed through PH-10/PH-11 rather than silently creating or correcting payments.

10. Connection configuration, resilience and observability

Each production integration path is represented by a PH-08 Connection using an approved deployed Connector. Production and non-production use separate deployments, endpoints, credentials, data and Connection configuration.

Connection concern	Initial requirement
Endpoint / destination	Reference the approved CU service, Symitar interface, file destination or processor endpoint for that deployment.
Credentials	Use secret/certificate references only; no raw secret in Product, Route, Attempt or audit data.
Identifiers/configuration	CU-specific core institution IDs, GL/account references, ACH values, processor identifiers and file settings are Connection configuration or securely referenced Connector config.
Health	Expose AVAILABLE/DEGRADED/UNAVAILABLE/MAINTENANCE/SUSPENDED/UNKNOWN plus last-success/freshness and applicable circuit/admission state.
Isolation	Per-Connection concurrency/rate limits/circuit breaker/backpressure prevent one CU dependency from exhausting the Payment Hub.
Timeout/retry	Use bounded dependency-specific timeouts and safe technical retry only before confirmed possible financial effect or when external idempotency guarantees safe replay.
Evidence	Retain mapping/external contract versions and secure request/response/file evidence needed for support and reconciliation.
Observability	Structured logs, metrics and traces include tenant, correlation, payment/Leg/Attempt, Connection and Connector version without exposing sensitive payloads.

CI-01 must pass the PH-08 Connector conformance suite for applicable operations and provide CU-specific deterministic simulators/stubs for development and fault testing.

11. First-CU communication and channel integration boundaries

The current RCUpay solution includes CU-specific SMS/email services, short-link behavior and SMS opt/reminder services. DragonPay must preserve required customer behavior without coupling PP-01 to those interfaces.

• CX-01A owns the first CU digital-banking launch, host placement, allowed origins, branding/content and channel-specific authentication assertion translation.
• CI-01 owns server-side member/account/core integration required after the trusted launch context is established.
• PH-12 owns invitation/status/receipt communication workflow. If the CU elects to reuse its existing SMS/email services, CI-01 may deliver the concrete PH-12 adapter/Connection and mapping as part of the first-CU package.
• Claim-link creation and security-word validation remain DragonPay PP/CX/PH responsibilities unless an approved first-CU constraint explicitly requires a CU service.
• Notification failure does not reverse or duplicate a completed financial movement; PP-01/PH-12 determine retry/customer status behavior.

12. Open discovery items before production build is complete

The supplied RCUpay workflows establish the high-level behavior and several integration APIs, but they do not support definitive implementation requirements for the following details. CI-01 discovery must resolve and document them before certification:

Area	Required answer
Member/account retrieval	Exact services and authoritative source used to list accounts, determine Sender authority/status and return masked display information.
Entitlements and limits	Exact entitlement codes, account/member-level limits, velocity interactions and manual override behavior used by RCUpay.
Fraud/risk	Exact source of any fraud score/risk indicators visible in the current flow; scale/meaning/freshness and any operational override inputs.
Funding	Exact Symitar PowerOn/core operations and CU-controlled GL/account movements used to secure funds before claim; success/reversal evidence.
Return-to-Sender	Exact reverse/corrective core movement and how duplicate/partial/unknown return conditions are resolved.
RCU recipient lookup	Exact username/member/account validation process and privacy/security controls for same-CU recipient selection.
ACH payout	Actual file/API/processor path, SEC code, Company ID, settlement/ODFI arrangement, release ownership, cutoffs and delivery timing.
Status/acknowledgement	Authoritative source and polling/event/file mechanisms for core and ACH acceptance, completion, rejection and delayed outcomes.
Returns/NoC	Current source, format, timing and operational handling for ACH Returns and Notifications of Change.
Idempotency	Native duplicate-protection behavior of each CU/core/processor interface and safe inquiry strategy after timeout.
Operations	Production monitoring, support escalation, manual controls, scheduled jobs, maintenance windows, recovery and DR expectations.
Legacy dependencies	Which MuleSoft/P2P API components are required temporarily versus replaced by DragonPay adapters/Connectors for the first production pilot.

13. Required integration interfaces

CI-01 implements concrete versions of the shared interfaces rather than creating a separate public integration API.

Interface	Initial implementation
Member/account facts	Resolve member; list eligible source accounts; validate source account; retrieve entitlement/limit facts; refresh time-sensitive account/funds result.
Recipient same-CU facts	Resolve/validate permitted RCU recipient and destination account; return masked display and eligibility evidence.
PH-08 Connector	validate the Connection; execute Funding/ON_US Payout/Return; execute ACH Payout; query external transaction status where supported; report Connection health; normalize asynchronous external evidence.
PH-07 configuration inputs	Connection capability, route type, timing/cutoff/calendar/operational state required to configure RouteCapabilityVersion.
PH-10 evidence	Strong external posting/transaction/file/trace/status references required by the applicable reconciliation handler.
PH-12 adapter (optional)	Send approved SMS/email communication through CU service and normalize delivery result/health if the first CU chooses that channel.
Operations	Connection validation/health, secure evidence retrieval, non-sensitive diagnostics and test/certification status surfaced through PH-08/PH-13/OX-01.

14. Implementation stories

CI01-01 — Inventory and map the acquired RCUpay implementation

Objective: Create the authoritative first-CU integration map before reproducing legacy behavior.

Build: Trace Sender, Receiver, funding, payout, return, status and notification flows across the P2P API, MuleSoft, Symitar/core, ACH and dependent services; classify each responsibility to PP/PH/CX/CI.

Acceptance: Every production-significant dependency has an owner, authoritative source, contract, failure behavior and migration/retention decision; unresolved mechanics are recorded as explicit discovery items rather than guessed requirements.

CI01-02 — Establish first-CU Connection and secret configuration

Objective: Create isolated test/certification/production-ready technical configuration for the first CU.

Build: Configure PH-08 Connections, endpoint/destination references, tenant/CU identifiers, secret/certificate references, health checks and allowed capabilities.

Acceptance: Connections validate without exposing credentials; non-production and production are isolated; Connector/version compatibility and health are observable.

CI01-03 — Integrate member entitlements and source accounts

Objective: Provide PP-01/PH-05/PH-06 the first CU member/account facts needed to enter and fund P2P.

Build: Implement member/account/entitlement adapter and normalized eligibility/display results using the approved CU interfaces.

Acceptance: Only the authenticated member’s eligible accounts are returned; account identifiers are masked; entitlement/limit source and freshness are retained; CU balances are not persisted as DragonPay truth.

CI01-04 — Implement final source-account and funds validation

Objective: Refresh time-sensitive Sender/account facts immediately before Funding.

Build: Call the authoritative CU interfaces for active status, authority, debit eligibility and required available-funds result; normalize failures/indeterminate results.

Acceptance: A failed required validation blocks Funding; timeout/unavailable responses do not fabricate eligibility; evidence/source timestamp is retained.

CI01-05 — Implement CU-controlled Funding Leg

Objective: Secure the Sender amount through the first CU’s existing core/GL mechanism after Sender Confirmation.

Build: Implement the PH-08 Core Payment Connector mapping for FUNDING using the certified Symitar/core operations and external idempotency/inquiry behavior.

Acceptance: One authorized Funding Leg creates at most one financial effect; authoritative success evidence is captured; timeout after possible effect becomes OUTCOME_UNKNOWN; PP/PH code contains no Symitar/PowerOn-specific logic.

CI01-06 — Implement Return-to-Sender movement

Objective: Return previously secured funds when PP-01 terminates before successful payout.

Build: Map the corrective Return Leg to the certified CU core/GL operation with independent idempotency, inquiry and posting evidence.

Acceptance: Return success is authoritative and independently traceable; duplicate return is prevented; unknown return outcome blocks another conflicting correction and is operationally visible.

CI01-07 — Validate same-CU recipient account

Objective: Allow a claiming recipient to select an eligible RCU destination without exposing core-specific identity logic.

Build: Implement approved recipient/member/account lookup and validation adapter; return normalized Party/PaymentInstrument reference, masked display and validation evidence.

Acceptance: Ambiguous/ineligible recipient results fail safely; sensitive account/member details are minimized; validation is tenant-scoped and auditable where required.

CI01-08 — Execute ON_US Recipient Payout

Objective: Post the funded P2P amount to an eligible same-CU recipient after claim.

Build: Implement ON_US payout through the Core Payment Connector using the RouteDecision-selected Connection.

Acceptance: Authoritative recipient posting completes the Leg; duplicate posting is prevented; uncertain posting uses inquiry/OUTCOME_UNKNOWN; external posting reference is available to PH-03/PH-10.

CI01-09 — Implement external ACH Recipient Payout

Objective: Originate the Recipient Payout through the first CU’s existing ACH process.

Build: Reverse-engineer and implement the actual CU ACH file/API/processor contract, including CU-specific mappings, timing, delivery and evidence inside the ACH Connector.

Acceptance: Valid external payout produces the required file/API artifact once, preserves trace/external references, distinguishes handoff from acceptance/completion and exposes current status to PH-08.

CI01-10 — Normalize acknowledgements and status inquiry

Objective: Make CU/core/processor execution state consumable by DragonPay without CU-specific schemas above CI-01.

Build: Implement status mapping, asynchronous event/file ingestion and queryStatus for the initial Core and ACH Connectors where supported.

Acceptance: Duplicate events/records are deduplicated; handoff/acknowledgement/final outcome remain distinct; unknown result can be investigated without blind resubmission.

CI01-11 — Process ACH Returns and corrections

Objective: Normalize post-payout external Returns/corrections required by PP-01 and PH-10.

Build: Parse or query the first CU’s Return/correction evidence and map original transaction, amount, reason, dates and external references to the shared contracts.

Acceptance: Original payment is correlated deterministically where possible; unmatched/ambiguous records do not silently modify payment state; corrective handling is delegated to PP/PH-04/PH-10/PH-11.

CI01-12 — Integrate CU risk and limit inputs

Objective: Preserve mature first-CU risk/limit behavior without copying its decision engine into CI-01.

Build: Identify and expose CU-provided entitlement, limit, fraud-score or risk facts required by PP-01/PH-06, including source, scale and freshness.

Acceptance: PH-06 receives normalized facts and remains authoritative for the DragonPay policy/risk Decision and its normalized outcome/reasons; CU overrides are represented only through approved authoritative inputs and audit paths.

CI01-13 — Provide integration resilience and operational health

Objective: Make each first-CU dependency production-safe and observable.

Build: Apply STD-01 circuit breakers, deadlines, isolation, rate/admission limits, bounded safe retry, health telemetry, mapping/version lineage and secure evidence handling per Connection.

Acceptance: A degraded CU dependency cannot exhaust the platform; Connection state is available to PH-07/PH-13; unsafe retry after possible financial effect is blocked.

CI01-14 — Build deterministic integration simulators and conformance tests

Objective: Allow Payment Hub and Product development to proceed independently of live CU environments.

Build: Create stubs/simulators for member/account, Funding, ON_US, ACH, status and Return behaviors plus Connector conformance tests for success/reject/timeout/unknown/duplicate/delayed scenarios.

Acceptance: Tests are deterministic; production code cannot enable simulator endpoints; Connectors pass applicable PH-08 contract/conformance cases before certification.

CI01-15 — Certify first-CU production integration

Objective: Prove the full acquired P2P behavior through DragonPay in the CU’s approved environments.

Build: Execute end-to-end certification with CU test members/accounts for Funding, invitation/claim, ON_US payout, ACH payout, failed/expired claim return, delayed/unknown outcomes, Returns, reconciliation and operations support.

Acceptance: CU and DragonPay sign off on mappings, credentials, evidence, monitoring, support/escalation, rollback and production runbook; no unresolved money-movement ambiguity remains for pilot scope.

15. Initial implementation sequence

1. Complete RCUpay code/MuleSoft/Symitar/ACH inventory and map every required behavior to DragonPay contracts.

2. Establish non-production Connections, secrets, deterministic simulators and CI-01 adapter/Connector project structure.

3. Implement member/account/entitlement and final source-account validation adapters.

4. Implement and certify CU-controlled Funding plus Return-to-Sender core movements.

5. Implement same-CU recipient validation and ON_US payout.

6. Implement the actual external ACH payout path and timing/cutoff configuration.

7. Implement status inquiry, asynchronous acknowledgements, Returns/corrections and reconciliation evidence.

8. Add first-CU risk/limit inputs and optional CU communication adapter if selected.

9. Run resilience/conformance/fault tests, then end-to-end UAT and production certification.

10. Pilot with bounded volume and operational monitoring before broader CU rollout.

16. Scope boundaries

CI-01 owns

• First-CU technical discovery and legacy behavior mapping.
• CU member/account/entitlement and same-CU recipient integration adapters.
• Concrete first-CU Core and ACH Connector implementations.
• CU-specific mapping/configuration for core/GL, ACH, processor, status, acknowledgement, Return and correction behavior.
• Connection validation, certification fixtures, CU-specific simulators and production integration runbooks.
• Optional concrete CU communication adapter when the first-CU launch chooses its existing messaging services.

Owned elsewhere

• PP-01 owns P2P business behavior, Funding/claim/payout/return workflow semantics and customer rules.
• CX-01/CX-01A owns reusable experience plus first-CU digital-banking launch/branding/host integration.
• PH-05 owns shared Party/PaymentInstrument records; CI-01 supplies CU facts and references.
• PH-06 owns DragonPay policy/risk Decisions and their normalized outcome/reasons.
• PH-07 owns Route Capability/Route Decision; CI-01 supplies configured capability facts, not transaction routing policy.
• PH-08 owns ExecutionAttempt lifecycle, Connection/Connector contract, handoff certainty and normalized execution processing.
• PH-10 owns reconciliation result; CI-01 supplies external evidence.
• PH-11 owns durable human Cases/corrective requests.
• PH-12 owns communications/documents; CI-01 may implement a selected first-CU adapter.
• PH-13/OX-01 own operational/reporting presentation. Initial CI-01 does not require direct DragonPay FedNow/RTP participation, a reusable integration marketplace, support for every core/processor, a generic MuleSoft replacement platform, shared multi-CU settlement infrastructure, or migration of unrelated acquired-company middleware. New CUs receive separate integration epics or reusable Connector implementations as justified.

17. Completion criteria

• The acquired RCUpay production behaviors required by the initial PP-01 release are mapped to explicit DragonPay Product/Hub/Channel/Integration ownership.
• Authenticated first-CU members can be resolved and eligible source accounts/entitlement/limit facts are supplied through normalized adapters.
• The Sender’s source account can be authoritatively revalidated immediately before Funding.
• Funding executes through the certified CU-controlled core/GL path and produces authoritative posting evidence without exposing Symitar-specific logic above CI-01.
• A funded payment can be returned to the Sender through a separately idempotent certified corrective movement.
• A claiming same-CU recipient can be resolved/validated and paid through an ON_US Connection.
• An external recipient can be paid through the first CU’s certified ACH process with trace/evidence and applicable schedule/cutoff behavior.
• Core and ACH outcomes distinguish not-submitted, submitted/acknowledged, final and unknown handoff certainty; possible financial effects are never blindly retried.
• Authoritative acknowledgements/status/Returns/corrections can be queried or ingested and normalized for PH-08/PH-10.
• Required first-CU risk/limit facts are available to PH-06 without moving decision ownership into CI-01.
• Connections use isolated endpoints/credentials/secrets and expose normalized health/resilience telemetry to PH-07/PH-13.
• Deterministic simulators and PH-08 Connector conformance tests cover success, rejection, duplicate, timeout-before-handoff, timeout-after-possible-handoff, delayed status, Return and recovery scenarios.
• End-to-end UAT demonstrates Funding → Claim → ON_US or ACH Payout and the failed/declined/expired Claim → Return-to-Sender path.
• Operations can correlate each Payment Leg/Attempt to CU posting/file/trace/evidence and resolve an unknown outcome without direct database changes.
• Production mappings, credentials, monitoring, support/escalation, operational schedules, rollback and recovery procedures are approved for the pilot.
• PP-01, PH-03 through PH-13 and CX-01 contain no first-CU Symitar, MuleSoft, PowerOn, GL-account, ACH-file or endpoint-specific implementation logic.