feat: add InstrumentDocumentType with bank_statement

[armando-rodriguez-cko]

What

Adds InstrumentDocumentType with the single value bank_statement, the document type for the bank account behind a platforms payment instrument.

Reported internally: the value is documented in the API reference but missing from the SDK, and it is blocking a merchant. Verified against the spec, where that document type is a single-value enum whose only accepted value (and default) is bank_statement.

Why a separate type instead of adding the value to the existing document type

The existing document type lists identity documents (passport, national identity card, driving license) and is used for entity onboarding. The API models the bank account document type as its own enum. Adding bank_statement alongside the identity values would offer it in every place the API rejects it, and would equally suggest the identity values are accepted on an instrument document, where they are not.

Tests

One of the tests asserts bank_statement is not in the identity document type. That is deliberate: it is what stops the two being merged the next time someone reports the value as missing from the identity enum.

Not breaking

Purely additive. No existing constant, field or signature changes.

Refs INT-1691.

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:Purely additive new constant module mirroring an existing pattern (DocumentType), no new endpoints, persisted data, auth changes, or external integrations.

Operational gates

• ✅ jira_ticket (INT-1691)
• ✅ independent_review

Files analysed: 3

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
no_low_class_matched	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.
2.2.6_logical_extension — Purely additive new constant module mirroring an existing pattern (DocumentType), no new endpoints, persisted data, auth changes, or external integrations.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:The change is purely additive, introducing only a new constant module with a single string value and accompanying tests, reusing existing abstractions without touching auth, persistence, external integrations, or any existing signatures.

Operational gates

• ✅ jira_ticket (INT-1691)
• ✅ independent_review

Files analysed: 3

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
no_low_class_matched	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.
2.2.6_logical_extension — The change is purely additive, introducing only a new constant module with a single string value and accompanying tests, reusing existing abstractions without touching auth, persistence, external integrations, or any existing signatures.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[agent-wall-e]

✅ Auto-approved — this PR meets all Low-risk criteria.

All checks passed, no unresolved comments, and the change classification is:

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:Purely additive new constant module and spec mirroring an existing pattern (DocumentType), with no new endpoints, persisted data, auth changes, or external integrations.

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}