Source-derived document; review findings and open questions with the application owner.

Business rules

In this document

The following are bounded, source-level rules or intended behaviors. They are not confirmed production rules because the evidence does not establish successful build, deployment, execution, data correctness, or one integrated runtime system README.md; E0001 E0010.

The recorded online entry point is CICS sign-on CC00. COSGN00C validates credentials against USRSEC, redisplays sign-on errors, and exits on PF3 [COSGN00C.cbl; COSGN00.bms; COSGN00.CPY] E0028 E0030.
After authentication, users identified as ADMIN are routed to COADM01C; other authenticated users are routed to COMEN01C. The route uses XCTL and a commarea [COSGN00C.cbl; COSGN00.CPY] E0034.
The evidence does not establish the complete authorization matrix, lockout behavior, auditing, segregation of duties, identity propagation, or whether the recorded routing operates in a deployed environment E0016 E0032.

Account and customer maintenance

Account viewing reportedly uses cross-reference, account-master, and customer-master information E0025.
Account update reportedly validates screen input and commarea values before it may lock and rewrite account and customer records. The described failure cases include missing records, concurrent updates, and customer-update failure E0029.
The precise validation rules are not established because CSLKPCDY is absent. Lock scope, ordering, commit behavior, rollback, and the treatment of a partial customer update remain unknown E0029.
Recorded account journeys use BMS maps, terminal I/O, paging, and VSAM browse or update operations, but the complete screen fields, actions, state transitions, and responses are unavailable E0013 E0026.

Cards and transactions

Recorded card functions include listing and searching cards through named programs including COCRDLIC and COCRDSEC; the complete search criteria and result behavior are not available E0038.
Transaction processing reportedly validates account/card relationships, limits, expiry, and references. It may update balances or account data and may write rejects to DALYREJS [COTRN00C.cbl; COTRN01C.cbl; COTRN02C.cbl].
CBTRN02C visibly performs substantive validation and posting. Claims that CBTRN01C posts transactions are not supported by the visible absence of WRITE, REWRITE, or DELETE operations in that source [CBTRN01C.cbl; CBTRN02C.cbl].
Atomicity, duplicate handling, commit or rollback, reconciliation, restart, and recovery behavior are not established. The evidence therefore does not support treating every validation or posting path as an assured financial-control rule.

Bill payment

Bill payment reportedly requires an existing account, a positive balance, a non-duplicate transaction identifier, and confirmation before creating a transaction and updating the balance E0029.
The evidence does not establish how identifiers are generated or made unique, how concurrent payments are handled, whether confirmation can be withdrawn, or whether transaction creation and balance update are atomic E0029.
Programs and journeys associated with billing include COBIL00C and COACCT01; their complete inputs, outputs, and failure responses remain unavailable E0038.

Batch and file processing

Recorded batch intent covers initialization, loading or replacement, posting, interest and fee calculation, statements, reports, imports, exports, indexing, backups, cleanup, and scheduled workflows E0007 E0040.
REPROCT.ctl confirms a REPRO from FILEIN to FILEOUT, but does not establish filtering, validation, or transformation rules E0022.
CBEXPORT and CBIMPORT are described, but the export layout is unavailable and a sequential-versus-indexed file mismatch remains unresolved. Partial updates, end-of-file ordering, abends, restart, rerun, and compensation behavior are unknown E0045.
Dataset layouts and keys are inconsistent across the evidence, including differing account, card, transaction, and customer lengths. Copybook alignment, field semantics, encoding, lineage, retention, and protection of sensitive fields remain unresolved [ACCTFILE.jcl; CARDFILE.jcl; TRANFILE.jcl; XREFFILE.jcl; CVACT01Y.cpy; CVTRA05Y.cpy] E0002 E0036.

Authorization and security-sensitive processing

Optional authorization processing is described across MQ, IMS, DB2, and VSAM, but cross-system atomicity and the relationships among AUTHFRDS, DBPAUTP0, and related layouts are unproven. PAUTDTL1 declares 200 bytes while an unload specifies LRECL=206 [COPAUA0C.cbl; COPAUS2C.cbl; DBPAUTP0.dbd; UNLDPADB.JCL] E0009 E0011.
Security-related controls include USRSEC, RACF, and user-maintenance programs, but effective permissions and operational enforcement are not verified E0016.
Fixed-length plaintext passwords, example or literal FTP credentials, possible exposure of CVV or government identifiers, destructive replacement, JOURNAL(NO), RECOVERY(NONE), and ERROROPTION(IGNORE) are documented risk indicators. They are not, without runtime evidence, confirmed incidents or enforceable business rules [FTPJCL.JCL] E0032 E0033.

Automated evidence review

Business rules — advisory review

Overall assessment

The draft is appropriately cautious and generally distinguishes source-level intent from verified production behavior. However, it mixes business rules with system capabilities, implementation observations, security risks, and evidence-quality findings. Several statements remain stronger than the cited evidence appears to support, while key rule definitions and transaction semantics are still missing.

Unsupported or insufficiently supported claims

“Validates credentials against USRSEC” and role routing: These may be visible in COSGN00C, but the draft should distinguish source behavior from effective authentication and authorization. It should state whether password comparison, status checks, expiry, and role derivation are actually shown.
Account viewing: “Uses cross-reference, account-master, and customer-master information” does not establish which records are mandatory, how joins are performed, or what happens when one is missing. The citation label is also inconsistent: <span class="prsd-reference" title="Evidence E0025 retained privately">E0025</span>.
Account update: “May lock and rewrite account and customer records” does not establish that both updates occur, in what order, under what predicates, or whether the operation is atomic. The absent CSLKPCDY prevents confirmation of the validation rules.
Transaction processing: The assertions about limits, expiry, references, balance updates, and DALYREJS need direct citations to the relevant source branches and conditions. “May update” and “may write” are too vague to serve as business rules.
Bill payment: The four stated prerequisites are presented as reported behavior, but the evidence does not establish their exact predicates—for example, whether “positive balance” means pre-payment available balance, ledger balance, or a permitted overdraft condition.
Batch intent: Initialization, interest, fees, statements, backups, and scheduling are catalogued capabilities or intended operations, not confirmed business rules. They should be separated from rules actually implemented in source.
Security statements: Plaintext passwords, FTP credentials, CVV or identifier exposure, and weak recovery settings are evidence-based risk indicators only. The draft correctly qualifies them, but they should not appear under business rules unless a governing policy or active runtime configuration confirms them.

Contradictions and evidence-quality issues

The document calls these “business rules” while repeatedly stating that they are not confirmed production rules. Consider renaming the section to “Source-indicated rules and unresolved behavior.”
CBTRN01C and COTRN01C, and similarly CBTRN02C/COTRN02C, appear to be different naming forms. The draft should establish whether these are aliases, renamed files, or conflicting artifacts before using one to contradict the other.
The draft correctly notes that claims that CBTRN01C posts transactions conflict with the visible absence of data-update verbs. This should be stated as a source interpretation conflict, not necessarily a functional contradiction; posting could be delegated to another program or performed through an indirect mechanism.
Several evidence references appear mismatched, including E0025 linked to evidence-E0029.md, E0007 to evidence-E0008.md, and E0040 to evidence-E0041.md. Citation integrity should be corrected.
Conflicting layouts, file types, job orders, PF-key behavior, FTP direction, and dataset names are important implementation discrepancies, but they do not by themselves establish conflicting business rules.
“Optional authorization processing” is ambiguous. It is unclear whether optional means disabled in some deployments, conditionally invoked by a transaction, or merely incompletely evidenced.

Important gaps

The draft does not define:

The complete actor, role, and authorization matrix, including whether non-ADMIN users have differentiated privileges.
Authentication failure limits, lockout, password lifecycle, session timeout, and audit requirements.
Exact account, customer, card, and transaction validation predicates.
Currency, amount, date, status, expiry, overdraft, limit, reversal, refund, and fee rules.
Duplicate transaction identity scope and idempotency behavior.
Bill-payment states, cancellation or withdrawal rules, and treatment of declined or partially completed payments.
Record ownership, effective dating, referential integrity, and handling of stale or missing cross-reference data.
Commit boundaries, locking strategy, retry behavior, rollback, reconciliation, and recovery for financial updates.
Batch control totals, balancing, restart checkpoints, rerun/idempotency rules, and handling of rejected records.
Whether source branches are reachable in the recorded deployment and whether called programs, copybooks, datasets, and queues actually align.