The bank account on a taxpayer's TaRMS record looks like administrative trivia. It is not. It is the destination of every refund withdrawal the taxpayer will ever make: the local SSP guide confirms that a withdrawal from the Single Account is paid "to the taxpayer's banking accounts" and — critically — that "the bank account must have been pre-loaded under Taxpayer Information." A taxpayer whose banking arrangements have changed and whose TaRMS record has not is, at best, a taxpayer whose refund stalls; at worst, a taxpayer whose money moves toward an account that no longer exists, or that belongs to someone it should not.

Bank details live in the Taxpayer Information module — the same four-page module (Taxpayer Profile, Applications, Requests, Drafts) walked in the Taxpayer Profile lesson. Changes are not free-form edits: the Taxpayer Profile page is "read-only / partly editable," and substantive changes travel as amendment applications that ZIMRA processes, tracked on the Applications page. The guide's security section closes the loop with a confirmed, load-bearing instruction: "Bank account changes: confirm the change visible on Taxpayer Information matches what you intended before requesting a refund withdrawal." That sentence exists because payment-diversion fraud exists.

The legal hooks are honest but indirect. No section of either Act says "notify ZIMRA when your bank account changes." What the statutes do impose is a general duty to keep registered particulars current — Section 25B(4) of the Income Tax Act [Chapter 23:06] (14 days, for address changes and cessation, "in such manner and form as may be prescribed") and Section 25 of the VAT Act [Chapter 23:12] (21 days, prescribed form, for changes in name, address, constitution or nature of the principal trade) — and the prescribed forms themselves demand bank details: Section 3 of the ITF 263 form requires Name of Bank, Branch Name & Code, Type of Account and Account Number, with the confirmed dual-currency rule that "where the taxpayer maintains accounts in both USD and ZiG, list both — refunds will be made in the currency of the over-payment." Keeping the bank record current is therefore part of the form-level compliance the Acts prescribe, even though the obligation is administrative rather than a named statutory duty — and this lesson says so plainly rather than inventing a section.

Downstream, the bank record feeds three machines: the Withdrawal page in Payments (refunds out of the Single Account — the previous lesson's "money out" exit), the ITF 263 application (Section 3 of the form, cross-checked against the Taxpayer Information profile — the guide confirms "ZIMRA cross-checks ITF 263 applications against this profile, so out-of-date information here delays clearance"), and the refund machinery of the Acts (ITA Section 48; VAT Section 44 — including the confirmed provisos that a VAT refund claim must be made within 6 years and that amounts of ZW$3,000 / US$60 or less are not refunded but carried forward). The lesson's discipline is simple: change the bank record when the banking change happens, not when the refund is needed; verify the change landed; keep accounts in both currencies on file; and treat every bank-detail amendment as a fraud-sensitive event under the Roles lesson's maker-checker controls.

Every lesson so far has treated the Single Account as the centre of the TaRMS universe: assessments in, payments in, allocations inside. This lesson is about the one piece of data that governs how money gets out — and how the taxpayer proves where it should go.

Consider what the bank record touches:

1. Refund withdrawals. The refund workflow (confirmed in the local guide, §19.4) ends with Payments → Withdrawal, and the guide is explicit: the destination account "must have been pre-loaded under Taxpayer Information." A credit balance with no current bank record is money you can see but not reach.
2. Tax clearance. Section 3 of the ITF 263 demands the bank details, and the SSP application flow includes a confirmed step: "Update the bank account details" before submission. An ITF 263 application against a stale profile invites delay — the guide confirms ZIMRA cross-checks applications against Taxpayer Information.
3. Currency routing. Refunds issue "in the currency of the over-payment" (confirmed). A taxpayer with only a ZiG account on file and a USD credit in the Single Account has built a currency wall between itself and its own money — the segregation doctrine from the Single Account lesson, now applied to the exit pipe.
4. Fraud surface. An attacker who can change the bank record can redirect every future refund. This is why the guide's security housekeeping section singles out bank changes for a verification ritual, and why the Roles lesson's separation of duties matters here more than almost anywhere else.

Where this sits in the course: the Taxpayer Profile lesson established the Taxpayer Information module and the amendment-application machinery in general; the Single Account lesson established the ledger the withdrawal drains and the currency segregation rule; the Withdrawals lesson (later in the queue) will walk the refund-out procedure end to end. This lesson owns the record itself: where it lives, how it changes, what the law actually requires, and the controls that keep it honest.

A TAXTAMI lesson does not invent statutory hooks. The straightforward truth: neither the Income Tax Act nor the VAT Act contains a provision expressly requiring notification of a change of bank account. The obligation is assembled from three layers.

B.1 The general change-notification duties

Income Tax Act Section 25B(4) (Part IIIA, the registration architecture walked in the First-Time Registration lesson) provides, confirmed verbatim from the source Act:

"Every person who has registered as a registrable taxpayer under this section shall, within 14 days after changing his or her address or ceasing to be a registrable taxpayer, notify the Commissioner in such manner and form as may be prescribed of his or her new address or of the fact of his or her having ceased to be a registrable taxpayer, as the case may be."

Note the precision: the named triggers are address change and cessation — not bank details. The phrase that does the work for our topic is "in such manner and form as may be prescribed": the prescribed registration and clearance forms are where bank details are demanded, and the practical expectation is that the whole prescribed record is kept current.

VAT Act Section 25 ("Registered operator to notify change of status"), confirmed verbatim:

"Subject to this Act, every registered operator shall within 21 days and in the prescribed form notify the Commissioner in writing of — (a) any change in the name, address, constitution or nature of the principal trade or trades of that registered operator; (b) any change of address at or from which, or the name in which, any trade is carried on by that registered operator; (c) any change whereby that registered operator ceases to satisfy the circumstances contemplated in the proviso to subsection (2) of section fourteen; (d) any change whereby paragraph (a) of subsection (5) of section twenty-seven becomes applicable in the case of that registered operator: Provided that this section shall not apply to the notification of any changes in the ownership of any company."

Again: name, address, constitution, nature of trade, accounting-basis and tax-period triggers — bank details are not in the list. The 21-day clock and the prescribed-form requirement are the statutory frame; the bank record rides inside the prescribed forms.

B.2 The prescribed forms demand the bank record

Section 3 of the ITF 263 form (confirmed from the ITF 263 guide) requires:

• Name of Bank — the bank where the account is held.
• Branch Name & Code — typically the four-digit branch code.
• Type of Account — current, savings, foreign currency account.
• Account Number — the full account number.
• And the dual-currency rule: "Where the taxpayer maintains accounts in both USD and ZiG, list both — refunds will be made in the currency of the over-payment."

The form-level demand converts the abstract "keep your particulars current" duty into a concrete one: every clearance application re-presents the bank record, and a wrong record on a signed form is a wrong declaration. The signing rules from the Manual Clearance lesson apply — the public officer (Section 61, for a company), trustee or representative (for a trust), or the taxpayer in person signs Section 3 along with the rest.

B.3 The refund machinery the record serves

The bank record exists because money flows out through it:

• ITA Section 48 — refunds of overpaid income tax, with the 60-day interest discipline under Section 48(3) (established verbatim in the Back-Filing lesson; summarised here, not re-walked).
• VAT Section 44 — refunds of VAT credits. Confirmed this run from the source Act, Section 44(1) refunds the Section 15(4) excess "to the extent that such amount has not been set off against unpaid tax in terms of subsection (6)," with two provisos worth quoting because they shape real behaviour:
• "the Commissioner shall not make a refund under this subsection unless the claim for the refund is made within 6 years after the end of the said tax period"; and
• where the refundable amount is "zw$3,000 or US$60 or the prescribed amount or less," it "shall not be refunded… but shall be carried forward to the next succeeding tax period."
• The Section 44(7) no-refund-while-any-return-unfiled rule and the Section 44(6) set-off were established in earlier lessons and continue to apply: a clean bank record does not unlock a refund that the filing record blocks.
• Finance Act Section 4B — the payments-side mirror (established verbatim in earlier lessons): banks as approved intermediaries must remit within 24 hours. The taxpayer's relationship with its bank matters in both directions; TaRMS knows the bank coming and going.

B.4 What this means doctrinally

The correct statement of the law is layered, and the lesson states it exactly: the Acts impose general, time-boxed duties to keep registered particulars current (14 days under ITA Section 25B(4) for the named triggers; 21 days under VAT Section 25 for its list); the prescribed forms — which those duties incorporate by reference — collect bank details; and the SSP operationalises the whole thing through Taxpayer Information amendment applications. There is no penalty provision aimed specifically at a stale bank account; the sanction is practical — stalled refunds, delayed clearance, and exposure to misdirection.

C.1 Where the record lives: Taxpayer Information, revisited

The Taxpayer Information module (Taxpayer Profile lesson) has four pages, all confirmed:

Page	Role in a bank-details change
Taxpayer Profile	The "read-only / partly editable view of the registration details, with the ability to submit applications for amendments and status changes." The bank record is viewed — and the amendment initiated — here.
Applications	"List of all amendments and status changes submitted on behalf of the taxpayer." The bank-change application is tracked here from submission to outcome.
Requests	Tax agent assignment requests — not part of this workflow.
Drafts	Incomplete applications not yet submitted — a half-finished bank change parks here.

Two structural points carry over from earlier lessons. First, the user vs taxpayer distinction: the SSP user must have shifted into the correct taxpayer before the profile shown is the right profile — an agent managing several clients changes the bank record of the taxpayer they are shifted into, not their own. Second, permissions: under Assignee Management (Roles lesson), only a user whose role allows profile amendments can lodge the change — and a well-governed taxpayer deliberately restricts that role.

C.2 The amendment lifecycle

Because the Taxpayer Profile page is only "partly editable," a bank-details change is an application, not an instant edit. The lifecycle, assembled from the confirmed module descriptions:

1. Initiate — open the profile, locate the banking section, submit the amendment with the new details.
2. Track — the application appears under Applications with a status.
3. Verify — once the change shows as effected, perform the guide's confirmed security check: "confirm the change visible on Taxpayer Information matches what you intended before requesting a refund withdrawal." This is not optional hygiene; it is the system's only confirmation step that the record now says what you think it says.
4. Propagate — the next ITF 263 application re-presents the bank record (Section 3); the next withdrawal pays into it. Neither machine asks again.

C.3 The dual-currency design

The Single Account lesson established that USD and ZiG ledgers never net. The bank record is where that doctrine meets the street:

• Refunds issue in the currency of the over-payment (confirmed, ITF 263 guide). A USD credit refunds in USD; a ZiG credit in ZiG.
• Therefore the record should hold both a USD-capable account (an FCA — foreign currency account, one of the confirmed "Type of Account" options) and a ZiG account. The ITF 263 guide says exactly this: "Where the taxpayer maintains accounts in both USD and ZiG, list both."
• A taxpayer with only one currency's account on file has a structural gap: the other currency's refunds have no landing strip. The cure costs nothing — load both accounts before either is needed.

C.4 The fraud lens: why this record gets its own security rule

Of all the editable particulars in TaRMS, the bank account is the only one whose alteration redirects money. The threat model is the same as supplier-payment fraud in any accounts-payable function: compromise a credential (or suborn an insider), change the destination account, wait for the next payment run — here, the next refund withdrawal. The defences, all from machinery already established:

• Credential hygiene (Login and Password lessons): unique logins, strong passwords, no sharing — the guide's confirmed housekeeping list.
• Role separation (Roles lesson): the permission to amend the profile should sit with few users, and ideally not the same users who initiate withdrawals — a maker-checker split across the two modules. The guide's confirmed quarterly review of Assignee Management ("remove ex-staff promptly") is the periodic audit.
• The verification ritual (confirmed): after any bank change, confirm on Taxpayer Information that the recorded account matches the intended account before a withdrawal is requested. An unexpected difference is the alarm bell.
• Notification vigilance (Notifications lesson): profile-amendment events generate notifications; an amendment notification nobody at the taxpayer initiated is treated as an incident — change passwords, review assignees, and contact ZIMRA via E-Messaging immediately.

C.5 Step-by-step: the procedural walkthrough

The consolidated procedure, with confirmed anchors and flagged specifics:

1. Log in at https://mytaxselfservice.zimra.co.zw; complete browser verification if requested (confirmed login flow).
2. Shift into the correct taxpayer (user → taxpayer mode; confirmed concept). An agent or group accountant confirms the TIN shown is the entity whose bank changed.
3. Open Taxpayer Information → Taxpayer Profile; locate the banking details among the registration particulars.
4. Initiate the amendment application; capture the new account exactly as the bank styles it — bank name, branch name & code, account type (current / savings / foreign currency account), account number (the ITF 263 field model). For dual-currency taxpayers, ensure both currencies' accounts are present after the change, not just the one that moved.
5. Attach any supporting documentation requested.
6. Submit; the application lists under Taxpayer Information → Applications. A half-completed application can be parked in Drafts and resumed.
7. Monitor Applications and Notifications for the outcome.
8. When the change shows as effected, perform the confirmed verification: open the profile and confirm the visible account matches what you intended.
9. Only then proceed to any pending Payments → Withdrawal request, and re-present the updated record on the next ITF 263 application (the SSP application flow's confirmed "Update the bank account details" step).
10. Minute the change in the taxpayer's own records (who requested it, who approved it internally, the bank's confirmation) — the Section 37B-grade record-keeping discipline applied to a fraud-sensitive event.

D.1 Individual: the consultant whose refund chased a closed account

Rudo (the Single Account lesson's two-currency consultant) finalises her ITF 12C and lands in a refund position: her QPDs exceeded final tax by USD 1,400. In March she had moved her FCA from one bank to another and closed the old account — but never touched TaRMS. Her refund application is approved; her withdrawal request points at the pre-loaded account, which no longer exists. The withdrawal fails and the credit sits in the Single Account while she lodges the bank-details amendment she should have lodged in March, waits for it to effect, performs the verification check, and re-requests the withdrawal. Total cost: weeks of delay on money that was already hers, plus the small indignity that the entire detour was avoidable with a ten-minute amendment at the time the account moved. The doctrinal point: the bank record is maintained on the banking event, not the refund event — by refund time it is too late to be timely.

D.2 SME: the dual-currency gap discovered at clearance time

Pamberi Hardware (the course's recurring SME) banks ZiG takings locally and holds a recently opened FCA for USD receipts. Its TaRMS record predates the FCA and lists only the ZiG account. Two consequences arrive in the same month. First, its ITF 263 renewal asks for Section 3 bank details; the accountant, following the SSP flow's confirmed "Update the bank account details" step, notices the missing FCA and adds it — clearance proceeds without delay because the profile was corrected in the application path. Second, a USD VAT credit (an input-tax-heavy month) becomes refundable; because the FCA is now on file, the refund can issue in the currency of the over-payment as the rule requires. Had the record stayed ZiG-only, the USD credit would have had no destination account — and remember the small-amount proviso: a credit of US$60 or less would not refund at all but carry forward under Section 44(1), so the refundable balance worth chasing is precisely the kind that needs the landing strip ready.

D.3 Large corporate: bank-record governance as a fraud control

Mukonde Holdings (five TINs, ten currency ledgers) treats bank-detail amendments as a controlled treasury event, not an admin task. Its standing controls: the profile-amendment permission sits with two named users in group tax, neither of whom holds the withdrawal-initiation permission (maker-checker across modules, per the Roles lesson); every amendment requires an internal treasury instruction with dual sign-off before anything is touched in the SSP; after every amendment, a second person performs the confirmed verification step and files a dated screenshot; Assignee Management is reviewed quarterly and leavers removed same-day; and any profile-amendment notification that does not match an internal instruction triggers the incident routine — password resets, assignee review, immediate E-Messaging contact with ZIMRA, and a hold on all pending withdrawals. The group's posture takes the guide's one-sentence security rule and builds the corporate control it implies. The cost is minutes per quarter; the risk retired is the redirection of six-figure refunds.

Stated honestly: no reported case in the source materials deals with TaRMS bank-detail amendments, misdirected refunds, or the SSP profile machinery — the construct is administrative and recent. The adjacent authority is the refund line already established in this course (the Section 48 refund-and-interest discipline and the VAT Section 44 architecture, walked in the Back-Filing and Old-Period lessons), which governs entitlement to the money; nothing in the cases speaks to the plumbing this lesson covers. Where a misdirection dispute ever litigates, the battleground would likely be ordinary principles of payment, mandate and negligence rather than tax law — outside this course's lane, and flagged as such rather than padded.

1. Updating at refund time instead of banking time. The withdrawal machinery reads the pre-loaded record; an amendment lodged after the refund is approved adds its full processing time to the wait. Correct approach: amend within days of the banking change — and treat the ITA Section 25B(4)/VAT Section 25 clocks (14/21 days for the named particulars) as the cultural norm for the whole record.
2. One-currency records in a two-currency world. Refunds issue in the currency of the over-payment; a missing FCA (or missing ZiG account) strands that currency's credits. Correct approach: both accounts on file, always — the ITF 263 guide says "list both."
3. Skipping the verification step. The guide's security rule exists verbatim because typos and tampering both happen. Correct approach: after every change, open the profile and confirm the visible account against the bank's own confirmation letter before any withdrawal request.
4. Loose amendment permissions. If every assignee can edit the profile, every assignee can redirect refunds. Correct approach: restrict the amendment role; separate it from withdrawal initiation; review assignees quarterly (confirmed housekeeping).
5. Assuming the change is instant. The profile is "partly editable" and substantive changes travel as applications ZIMRA processes. Correct approach: track under Applications; do not promise the bank change to anyone (or schedule a withdrawal) until it shows as effected.
6. Forgetting the ITF 263 ripple. A stale or mid-amendment bank record at clearance-renewal time invites delay, since ZIMRA cross-checks the application against Taxpayer Information (confirmed). Correct approach: sequence amendments away from the October–November renewal window, or complete them well before applying.
7. Treating an unexpected amendment notification as noise. It is the single highest-signal fraud indicator this module produces. Correct approach: the incident routine in C.4 — immediately.

Work through the questions one at a time. Choose an answer and it is graded immediately, with an explanation and the provision it comes from. Your progress is saved, so you can stop and resume.

• The bank record under Taxpayer Information is the destination of every refund withdrawal — and "must have been pre-loaded" there before Payments → Withdrawal can pay (confirmed). Maintain it on the banking event, not the refund event.
• No statute names bank details. The duties are general (ITA Section 25B(4): 14 days, address/cessation, prescribed manner and form; VAT Section 25: 21 days, prescribed form, its own list with the ownership-change proviso) and the prescribed forms — ITF 263 Section 3 above all — carry the bank record inside them. State the law in layers; never invent a section.
• Both currencies, always. Refunds issue in the currency of the over-payment; a one-currency record strands the other currency's credits behind the segregation wall.
• Changes are applications, not edits: profile (partly editable) → amendment application → tracked under Applications → verified on completion. The confirmed security rule — confirm the visible change matches your intent before any withdrawal — is the system's one verification step; never skip it.
• The bank record is a fraud surface. Restrict the amendment permission, separate it from withdrawal initiation, review assignees quarterly, and treat any unexplained amendment notification as an incident.
• The refund machinery has its own gates regardless of a clean bank record: VAT claims within 6 years; amounts of ZW$3,000/US$60 or less carried forward, not refunded (Section 44(1) provisos, confirmed); no VAT refund while any return is unfiled (Section 44(7), established); Section 48's interest discipline on the income tax side.
• A stale record also drags on tax clearance: ZIMRA cross-checks ITF 263 applications against Taxpayer Information (confirmed) — sequence bank changes away from the renewal window.

Where the bank record bites

Machine	What it reads	Failure mode if record is stale
Payments → Withdrawal	The pre-loaded account under Taxpayer Information	Withdrawal stalls or pays toward a dead/wrong account; refund delayed
ITF 263 application (Section 3)	Bank name, branch name & code, account type, account number; both currencies	Clearance delayed — ZIMRA cross-checks against the profile
Currency routing of refunds	Account in the currency of the over-payment	That currency's credits have no landing strip
Fraud controls	Amendment notifications + the post-change verification step	Unnoticed redirection of future refunds

Statutory anchor comparison

Provision	Clock	Named triggers	Bank details named?
ITA Section 25B(4)	14 days	Change of address; cessation as registrable taxpayer	No — enters via "manner and form as may be prescribed"
VAT Section 25	21 days	Name, address, constitution, nature of principal trade; trading address/name; Section 14(2)-proviso and Section 27(5)(a) triggers	No — prescribed-form requirement; ownership changes excluded by proviso
ITF 263 Section 3 (prescribed form)	Per application	Bank, branch & code, account type, account number; both currencies	Yes — the form-level demand

The change-and-verify flow

flowchart TD
 A[Banking change happens at the bank] --> B[Shift to correct taxpayer in SSP]
 B --> C[Taxpayer Information - Taxpayer Profile]
 C --> D[Submit amendment application with new bank details]
 D --> E[Track under Applications - drafts sit in Drafts]
 E --> F{Change effected?}
 F -->|No| E
 F -->|Yes| G
 G --> H{Match?}
 H -->|No| I[Incident routine: hold withdrawals, reset credentials, review assignees, E-Message ZIMRA]
 H -->|Yes| J[Safe to request Payments - Withdrawal and to file ITF 263]

Statutes & sections

• Income Tax Act [Chapter 23:06] — Section 25B(4) (14-day notification of address change/cessation, in prescribed manner and form — confirmed verbatim); Section 48 (refunds; Section 48(3) interest discipline — established in earlier lessons); Section 61 (public officer, signing context); Section 80/80A (ITF 263 engine — established).
• VAT Act [Chapter 23:12] — Section 25 (21-day prescribed-form notification of changes in name/address/constitution/nature of trade, with ownership-change proviso — confirmed verbatim); Section 44(1) and provisos (refund of Section 15(4) excess; 6-year claim limit; ZW$3,000/US$60 carry-forward floor — confirmed verbatim); Section 44(6)–(7) (set-off; no refund while returns unfiled — established).
• Finance Act [Chapter 23:04] — Section 4B (approved intermediary 24-hour remittance — established in earlier lessons; payments-side context only).

Case law

• None on point: no reported authority in the sources addresses bank-detail amendments, misdirected refunds or the SSP profile machinery. The refund-entitlement line (Section 48; VAT Section 44) is walked in the Back-Filing and Old-Period lessons.

ZIMRA guidance

• Comprehensive Guide to the ZIMRA Self-Service Portal (local source): Taxpayer Information module four pages and amendment-application machinery (§5); withdrawal destination "pre-loaded under Taxpayer Information" (§19.4); security rule on bank account changes (§20); user-vs-taxpayer concept (§2.3).
• Comprehensive Guide to the ITF 263 (local source): Section 3 bank-details fields; dual-currency "list both" rule; refunds in the currency of the over-payment; the SSP application flow's "Update the bank account details" step.
• Official SSP online help (https://mytaxselfservice.zimra.co.zw/help/ssp/en/default.htm) — unreachable this run; screen-level specifics flagged throughout.