15-mark question lab · start here

Check the login, then serve the four-action bank menu.

Build the solution in a sensible order: decode the three requirements, plan the two global arrays and the shared account ID, gate every action behind the login check, display the menu and dispatch each choice, and complete every action in a procedure that receives the account ID as its parameter. Learn the reasoning before revealing the complete program.

2D arraysLogin validationMenu loopProcedures with parametersError messages15 marks

Learning targets

By the end, you should be able to explain the algorithm before writing it.

Lesson overview

01 · Understand

Identify the two global arrays, the row index both share as the account ID, and the three requirements hidden in the bullet list.

02 · Construct

Build the program in order: a login check that confirms the account ID, name and password, a menu loop driven by CASE OF, and one PROCEDURE with an account ID parameter for each action.

03 · Complete

Guard every withdrawal with the overdraft limit and the withdrawal limit, display a suitable error message for every refusal, and exit cleanly on menu choice 4.

How Cambridge awards the marks: the mark scheme gives AO2 a maximum of 9 marks and AO3 a maximum of 6 marks. It lists requirements R1–R5, but does not assign a separate fixed mark total to each R requirement. The stage-to-mark links in this guide show alignment, not invented stage marks.

Source question

Read the whole question first

Do not begin coding after the first paragraph. The shared row index, the three columns of AccDetails[] and the phrase “with a parameter of the account ID” all fix the shape of your solution.

Question 12 · 15 marks

Cambridge IGCSE Computer Science · 0478/22 · Question 12

A two-dimensional (2D) array Account[] contains account holders’ names and passwords for a banking program.

A 2D array AccDetails[] has three columns containing the following details:

column one stores the balance – the amount of money in the account, for example 250.00
column two stores the overdraft limit – the maximum total amount an account holder can borrow from the bank after the account balance reaches 0.00, for example 100.00
column three stores the withdrawal limit – the amount of money that can be withdrawn at one time, for example 200.00

The amount of money in a bank account can be negative (overdrawn) but not by more than the overdraft limit.

For example, an account with an overdraft limit of 100.00 must have a balance that is greater than or equal to –100.00

Suitable error messages must be displayed if a withdrawal cannot take place, for example if the overdraft limit or the size of withdrawal is exceeded.

The bank account ID gives the index of each account holder’s data held in the two arrays.

For example, account ID 20’s details would be held in:

Account[20,1] and Account[20,2]
AccDetails[20,1] AccDetails[20,2] and AccDetails[20,3]

The variable Size contains the number of accounts.

The arrays and variable Size have already been set up and the data stored.

Write a program that meets the following requirements:

checks the account ID exists and the name and password entered by the account holder match the name and password stored in Account[] before any action can take place
displays a menu showing the four actions available for the account holder to choose from:
- 1. display balance
- 2. withdraw money
- 3. deposit money
- 4. exit
allows an action to be chosen and completed. Each action is completed by a procedure with a parameter of the account ID.

You must use pseudocode or program code and add comments to explain how your code works.

All inputs and outputs must contain suitable messages.

You only need to declare any local arrays and local variables that you use.

You do not need to declare and initialise the data in the global arrays Account[] and AccDetails[] and the variable Size

Before you move on

These are the five required techniques identified by the Cambridge mark scheme.

Mark-scheme map

Check the account ID exists and the entered name and password match Account[] — iteration, validation, selection, input and output.

Gate every action behind the login check, reading Account[ID,1] and Account[ID,2] through the shared row index.

Display the four-action menu and read the account holder’s selection, dispatching it with CASE OF — output, input and selection.

Repeat the menu until choice 4 is entered, refusing invalid choices with a suitable message.

Perform each selected action with the arrays inside a PROCEDURE that takes the account ID as its parameter.

Use the tabs along the top to work through the seven stages. The complete solution is kept in its own tab, and the interactive visualisation is the final tab.

Decode the requirements

Turn the question wording into a sequence of tasks.

R1 · R2 · R3

🧠 Step-by-step thinking

Identify the gate. “Before any action can take place” means the login check comes first: the account ID must exist and the name and password must match Account[] before the menu is even shown.
Spot the shared index. The account ID is the row number in both arrays — Account[ID,1] and Account[ID,2] hold the login pair, AccDetails[ID,1] to AccDetails[ID,3] hold the money. One number reaches every piece of data.
Read the menu as a loop. Four actions, chosen again and again until the account holder picks exit — a REPEAT … UNTIL menu loop wrapped around a CASE OF dispatch.
Translate the procedure rule. “Each action is completed by a procedure with a parameter of the account ID” fixes the shape of the whole answer: one PROCEDURE for the login check and one per action, each taking the ID.
Build the order. read the account ID → check the login details → menu loop (display, choose, dispatch) → each action in its own procedure → exit on choice 4.

Given: Account[] and AccDetails[]Gate: login before any actionLoop: menu until exitShape: one PROCEDURE per action

❓ Guiding questions – think before revealing

Why does the question mention account ID 20?
What does “before any action can take place” change?
What shape is the final program?

Reveal suggested reasoning

Why does the question mention account ID 20? It demonstrates the indexing rule: Account[20,1] and Account[20,2] hold that holder’s name and password, and AccDetails[20,1], AccDetails[20,2] and AccDetails[20,3] hold the balance, overdraft limit and withdrawal limit. The ID is the row index in both arrays.

What does “before any action can take place” change? The login check is not one of the menu actions — it runs first. Only when the ID exists and the name and password match does the menu loop begin; a failed login reaches no action at all.

What shape is the final program? A short main program that logs in and then loops the menu, plus a procedure for the login check and one procedure per action — the published answer defines CheckDetails, Balance, Withdrawal and Deposit, each with the ID as its parameter.

Reveal Cambridge pseudocode for Stage 1

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Gate: before any action — read the account ID, check it exists,
// then check the name and password against Account[]

// Menu: repeat until the account holder chooses exit
REPEAT
    // display the four actions, read the choice
    // CASE OF choice → call the procedure for that action,
    //   passing the account ID as the parameter
UNTIL Choice = 4

// Actions: one PROCEDURE each for balance, withdrawal and
// deposit — plus the login check

📖 Detailed explanation

“Checks the account ID exists” has two halves: the ID must be within range, and the entered name and password must equal the stored pair. Both must pass before any action.

“Displays a menu showing the four actions” names the exact four lines the program must print — display balance, withdraw money, deposit money, exit — and the holder must be able to choose repeatedly.

“Each action is completed by a procedure with a parameter of the account ID” is the structural heart of the question: the action logic lives in procedures, and the ID travels into each one as a parameter.

“Suitable error messages” covers every refusal: a failed login, a withdrawal above the withdrawal limit and a withdrawal that would breach the overdraft limit each need their own message.

⚠️ Common mistakes

Showing the menu before the login check has succeeded.
Checking the name but not the password, or comparing against the wrong column of Account[].
Writing the action code inline in the menu loop instead of in procedures with the ID parameter.
Forgetting that the balance may legitimately go negative, down to minus the overdraft limit.

💡 Exam hack / tip

Underline “before any action can take place” and “a procedure with a parameter of the account ID”. The first phrase puts the login gate first; the second dictates the whole program shape the examiners reward.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · algorithm designR1–R3 · full requirement coverageAO3 · logical orderAO3 · comments explain purpose

This planning stage supports AO2 by identifying the full range of techniques required. It supports AO3 by establishing a logical sequence. These are alignment notes, not separately allocated marks.

Plan the data and identifiers

Choose variables and arrays that store exactly what the algorithm needs.

Required data structures

🧠 Step-by-step thinking

Use the given structures exactly. Account[] is the 2D login array — column 1 name, column 2 password. AccDetails[] is the 2D money array — column 1 balance, column 2 overdraft limit, column 3 withdrawal limit. Size counts the accounts. The mark scheme requires these names as given.
One index reaches everything. Account ID 20 is row 20 in both arrays. Passing that single number to a procedure hands it the name, the password, the balance and both limits — no other identifier is needed to identify an account.
Add the main program variables. The published answer declares AccountNumber and Choice as INTEGERs and Valid and Exit as BOOLEANs — the account ID, the menu selection and the two flags.
Keep procedure variables local. Name and Password are declared inside the login procedure; Amount is declared inside the withdrawal and deposit procedures. Only the ID travels in, as a parameter.
Respect the declaration rule. You only need to declare local arrays and local variables — the globals exist already, and the published answer marks its global declarations as “for information”.

Given: Account[], AccDetails[], SizeGlobals: AccountNumber, Choice, ValidLocals: Name, Password, AmountParameter: the account ID

❓ Guiding questions – think before revealing

Which column holds which value?
Why does one parameter carry so much information?
What is Valid for?

Reveal suggested reasoning

Which column holds which value? Account[ID,1] is the name and Account[ID,2] the password. In AccDetails[], column 1 is the balance, column 2 the overdraft limit and column 3 the withdrawal limit. Mixing up columns 2 and 3 of AccDetails[] compares money against the wrong limit.

Why does one parameter carry so much information? Because the row index is shared. A procedure that receives AccID can read AccDetails[AccID,1] for the balance, AccDetails[AccID,2] for the overdraft limit and AccDetails[AccID,3] for the withdrawal limit — the ID is the key to the whole row.

What is Valid for? It is the BOOLEAN flag the login procedure sets. The main program tests it with IF Valid before entering the menu loop, so a failed login never reaches an action.

Reveal Cambridge pseudocode for Stage 2

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Given by the question — global, already set up:
//   Account[ID,1]     name                 (login array)
//   Account[ID,2]     password
//   AccDetails[ID,1]  balance         e.g. 250.00
//   AccDetails[ID,2]  overdraft limit e.g. 100.00
//   AccDetails[ID,3]  withdrawal limit e.g. 200.00
//   Size              number of accounts

// Main program globals (published answer, "for information"):
AccountNumber   // the account ID entered at login
Choice          // menu selection, 1 to 4
Valid           // TRUE when name and password match
Exit            // TRUE when choice 4 is made

// Local to each procedure:
Name, Password // inside the login check
Amount         // inside withdrawal and deposit

📖 Detailed explanation

The names are part of the marks. The mark scheme lists Account and AccDetails as the required arrays and Size and AccountNumber as required variables — inventing your own names loses the data-structure credit.

The ID is the only key you need. No second identifier is required to tie the arrays together: the row index is the account ID in both arrays, so one parameter identifies everything.

Locals keep procedures self-contained. Amount inside the withdrawal procedure and Amount inside the deposit procedure are separate locals with the same name — each exists only while its procedure runs.

The declaration rule cuts both ways. The globals must not be re-declared; the locals must be declared inside the procedure that uses them.

⚠️ Common mistakes

Renaming Account[], AccDetails[] or Size, which the mark scheme treats as not using the supplied data structures.
Reading the overdraft limit from AccDetails[ID,3] — column 3 is the withdrawal limit.
Declaring Amount in the main program when it is local to the action procedures.
Copying the name and password into a new array instead of reading Account[] as given.

💡 Exam hack / tip

Sketch one row: ID 20 → Account[20,1] name, Account[20,2] password, AccDetails[20,1] balance, AccDetails[20,2] overdraft limit, AccDetails[20,3] withdrawal limit. Every requirement in this question is phrased against that one row.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · appropriate data structuresR1 · R3 · given names reusedAO3 · meaningful identifiers

The data plan supports AO2 because the chosen structures store exactly the required data, and AO3 because every identifier is meaningful. These are alignment notes, not separately allocated marks.

Check the account ID, name and password

The gate that every action must pass through.

🧠 Step-by-step thinking

Check the ID against the array bounds. The ID must point at a real row: the published answer refuses AccID < 0 OR AccID > Size with “Invalid Account Number” before either array is read.
Prompt for both credentials. Only when the ID exists: “Please Enter Name” and “Please Enter Password” read into the local Name and Password.
Compare against the stored pair. Name <> Account[AccID,1] OR Password <> Account[AccID,2] — either mismatch refuses the login with “Invalid name or password”.
Raise the flag on success. Only the ELSE branch sets Valid ← TRUE; the main program tests that flag before the menu is ever shown.
Expect iteration here. R1 itself names iteration and validation: a real login often loops until the details are correct — the visualisation’s sample session repeats the login after one wrong password.

Selection: ID within rangeComparison: two columnsFlag: Valid ← TRUEMessages: two refusals

❓ Guiding questions – think before revealing

Why check the ID before reading the arrays?
Why one OR test instead of two IFs?
Where does Valid get its value?

Reveal suggested reasoning

Why check the ID before reading the arrays? An out-of-range ID has no row to compare against — reading Account[99,1] when Size is 4 would access a cell that does not exist. The range check runs first and refuses safely.

Why one OR test instead of two IFs? Either mismatch — wrong name or wrong password — refuses the login, so OR combines them into a single refusal branch with a single message. Two separate IFs also work, but the published answer uses one condition.

Where does Valid get its value? Inside the login procedure. It starts FALSE, and only the branch where both the name and the password match sets it TRUE. Because the flag is global, the main program can test it after the procedure returns — the flag is how the procedure reports its result.

Reveal Cambridge pseudocode for Stage 3

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

PROCEDURE CheckDetails(AccID : INTEGER)
    DECLARE Name, Password : STRING // local variables
    Valid ← FALSE
    IF AccID < 0 OR AccID > Size
      THEN
        OUTPUT "Invalid Account Number"
      ELSE
        OUTPUT "Please Enter Name "
        INPUT Name
        OUTPUT "Please Enter Password "
        INPUT Password
        IF Name <> Account[AccID,1] OR Password <> Account[AccID,2]
          THEN
            OUTPUT "Invalid name or password"
          ELSE
            Valid ← TRUE
        ENDIF
    ENDIF
ENDPROCEDURE

📖 Detailed explanation

The procedure takes the ID as its parameter. The main program calls CheckDetails(AccountNumber) — the ID is passed in, and everything the procedure needs is reached through it.

Valid starts FALSE. Assume the login fails until it succeeds; only a matching pair flips the flag. That way a missed branch can never accidentally authorise a stranger.

The error messages are specific. “Invalid Account Number” for a bad ID and “Invalid name or password” for bad credentials — two different refusals with two different messages.

Local variables, global flag. Name and Password are local to the procedure; Valid is global so the caller can read the outcome.

⚠️ Common mistakes

Reading the name and password before confirming the ID exists.
Comparing Name against Account[AccID,2] — column 2 is the password.
Setting Valid ← TRUE at the start and only resetting it on failure, which risks authorising a stranger if a branch is missed.
Printing one vague “Login failed” message instead of saying which check failed.

💡 Exam hack / tip

Say the gate as a sentence: exists, then matches, then the menu. The published answer turns it into one procedure, CheckDetails(AccID), whose global flag Valid is tested before any action is allowed.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · validation, selection, input and outputR1 · login gate before any actionAO3 · accurate comparisons

The login gate is the R1 evidence for AO2 — validation, selection, input and output together — and the column-accurate comparisons are AO3 accuracy evidence. These are alignment notes, not separately allocated marks.

Display the menu and dispatch the choice

One REPEAT loop, one CASE OF, until the account holder exits.

🧠 Step-by-step thinking

Enter the loop only after a valid login. The published answer wraps the whole menu in IF Valid … THEN, with an ELSE that reports the invalid account number — the gate decides whether the menu ever appears.
Print the four actions every round. “Menu”, then 1 display balance, 2 withdraw money, 3 deposit money, 4 exit, then the prompt “please choose 1, 2, 3 or 4” — six output lines per round.
Dispatch with CASE OF. Each choice calls the matching procedure, passing the account ID: Balance(AccountNumber), Withdrawal(AccountNumber), Deposit(AccountNumber); choice 4 sets the exit flag.
Refuse anything else. The OTHERWISE arm prints “Invalid choice”, so a stray 5 can neither crash the program nor silently do nothing.
Repeat until exit. UNTIL Choice = 4 ends the loop; the account holder can perform any number of actions in one session.

Iteration: REPEAT … UNTILSelection: CASE OFDispatch: procedure callsRefuse: OTHERWISE

❓ Guiding questions – think before revealing

Why is the menu inside IF Valid?
Why CASE OF rather than a chain of IFs?
What exactly is passed to the procedures?

Reveal suggested reasoning

Why is the menu inside IF Valid? The requirement says no action can take place before the check passes. Putting the whole menu loop in the TRUE branch of IF Valid makes the gate structural, not cosmetic — a failed login reaches only the ELSE output.

Why CASE OF rather than a chain of IFs? One integer choice against four constant alternatives is exactly what CASE OF expresses. It also gives a natural home for OTHERWISE — the invalid-choice message — without extra nested IFs.

What exactly is passed to the procedures? AccountNumber, the account ID. The procedures use it to index both arrays — the menu itself never touches the arrays, it only routes the ID.

Reveal Cambridge pseudocode for Stage 4

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

IF Valid
  THEN
    REPEAT
        OUTPUT "Menu"
        OUTPUT "1. display balance"
        OUTPUT "2. withdraw money"
        OUTPUT "3. deposit money"
        OUTPUT "4. exit"
        OUTPUT "please choose 1, 2, 3 or 4"
        INPUT Choice
        CASE OF Choice
          1 : Balance(AccountNumber)
          2 : Withdrawal(AccountNumber)
          3 : Deposit(AccountNumber)
          4 : Exit ← TRUE
          OTHERWISE OUTPUT "Invalid choice"
        ENDCASE
    UNTIL Choice = 4
  ELSE
    OUTPUT "Invalid account number "
ENDIF

📖 Detailed explanation

The menu repeats, it does not restart. After every completed action the loop prints the four actions again — one login, many actions, exactly what a bank menu does.

Exit is an action too. Choice 4 sets the flag and the UNTIL condition ends the loop; the published answer sets Exit ← TRUE there even though the UNTIL tests Choice = 4 — both express the leaving condition.

The dispatch keeps the loop thin. Each case is a single procedure call; all the money logic lives inside the procedures, which is what R3 rewards.

The ELSE branch is the failed gate. A login that never succeeded ends with “Invalid account number” and no menu — the program stops having done nothing.

⚠️ Common mistakes

Showing the menu before testing Valid.
Forgetting the OTHERWISE arm, so an invalid choice is ignored without a message.
Ending the loop with a condition that is TRUE immediately, such as testing the wrong way round.
Re-asking for the account number inside the menu loop instead of passing it to the procedures.

💡 Exam hack / tip

The menu is a router, not a worker: it reads one number and calls one procedure. If you find yourself writing balance arithmetic inside the CASE arms, that logic belongs in a procedure with the ID parameter.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · output, input and selectionR2 · menu display and choiceAO3 · clean dispatch structureAO3 · comments explain purpose

The menu loop is the R2 evidence for AO2 — output, input and selection — and the thin dispatch structure is AO3 logic evidence. These are alignment notes, not separately allocated marks.

Pass the account ID to each procedure

Why the ID travels in, and what stays local.

🧠 Step-by-step thinking

The requirement names the parameter. “Each action is completed by a procedure with a parameter of the account ID” — so every action procedure is declared as PROCEDURE Balance(AccID : INTEGER) and called as Balance(AccountNumber).
The parameter is a copy. AccID inside the procedure holds the value that was passed; the main program’s AccountNumber is unaffected. The procedure reaches the account’s row through its own name for the index.
Global arrays, local variables. Account[], AccDetails[] and Size are global, so the procedures read and write them directly; Name, Password and Amount are declared inside the procedures that use them.
Writing through the global array persists. AccDetails[AccID,1] ← AccDetails[AccID,1] - Amount changes the global balance, so a withdrawal is remembered by the next menu round after the procedure returns.
One flag crosses back. The login procedure reports through the global Valid because these procedures return no value; everything else the actions need is already reachable through the ID parameter.

Parameter: AccID : INTEGERLocal: Name, Password, AmountGlobal: Account[], AccDetails[]

❓ Guiding questions – think before revealing

Why pass the ID instead of reading it again inside each procedure?
What is the difference between AccID and AccountNumber?
Why is Amount local?

Reveal suggested reasoning

Why pass the ID instead of reading it again inside each procedure? The account was identified once at login. Passing the ID keeps every procedure working on the account that actually logged in — re-asking inside a procedure would let a different account’s row be edited mid-session.

What is the difference between AccID and AccountNumber? AccountNumber is the main program’s global copy; AccID is the parameter name inside each procedure. They hold the same value during a call, but the procedure only knows AccID.

Why is Amount local? Each action reads one amount and uses it immediately; nothing needs it afterwards. Declaring it inside the procedure keeps the two action procedures independent — the withdrawal’s Amount and the deposit’s Amount are separate locals with the same name.

Reveal Cambridge pseudocode for Stage 5

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

// Declaration — the parameter list names what travels in
PROCEDURE Balance(AccID : INTEGER)
    OUTPUT "Your balance is ", AccDetails[AccID,1]
ENDPROCEDURE

// Call — the value of AccountNumber is copied into AccID
Balance(AccountNumber)

// Inside a procedure:
//   AccID        local parameter — the account ID passed in
//   Amount       local variable  — declared inside
//   AccDetails[] global array    — read and written directly

📖 Detailed explanation

Parameters make procedures reusable. The same Withdrawal procedure serves every account in the bank — the ID it receives decides whose row is updated.

Locals disappear when the procedure ends. Amount exists only during one action; the balance it changed lives on in the global AccDetails[].

Globals are visible everywhere. That is why the procedures may write AccDetails[AccID,1] without it being passed in — but the ID itself is passed, exactly as the question demands.

The published answer models this split precisely. Four procedures, each taking AccID : INTEGER, locals declared inside, arrays used globally — the structure R3 describes.

⚠️ Common mistakes

Declaring the action procedures with no parameter and relying on a global ID — the requirement explicitly demands the parameter.
Declaring AccID again inside the procedure body — the parameter list already declares it.
Assuming the parameter changes the caller’s variable: assigning to AccID inside does not change AccountNumber.
Passing the name or the balance instead of the account ID.

💡 Exam hack / tip

Read the requirement as a signature: a procedure with a parameter of the account ID becomes PROCEDURE …(AccID : INTEGER) written four times. If a procedure’s brackets are empty, R3 is not yet met.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · procedures with parametersR3 · arrays used inside proceduresAO3 · meaningful structure

Procedures with parameters and array access are the R3 evidence for AO2, and the clean local/global split is AO3 structure evidence. These are alignment notes, not separately allocated marks.

Complete each action in its procedure

Balance, withdrawal and deposit — the array work.

🧠 Step-by-step thinking

Displaying the balance is one line. Balance(AccID) outputs “Your balance is” followed by AccDetails[AccID,1] — the procedure exists to satisfy the parameter rule, not to compute.
Withdrawal reads, checks, then writes. Read Amount, test it against AccDetails[AccID,3] (the withdrawal limit) and against AccDetails[AccID,2] + AccDetails[AccID,1] (the overdraft limit plus the balance — the cash available), and only then subtract from the balance column.
Deposit validates the sign. The published answer loops UNTIL Amount > 0, then adds: AccDetails[AccID,1] ← AccDetails[AccID,1] + Amount.
Every refusal needs its message. “Amount greater than withdrawal limit” and “Amount greater than cash available” are the two withdrawal refusals the question’s own wording asks for.
The balance may go negative. An overdrawn balance is legal down to minus the overdraft limit — a withdrawal that lands the balance at −60.00 with a 150.00 overdraft limit is a success, not an error.

Read: AccDetails[ID,1]Write: the balance columnValidate: Amount > 0Output: suitable messages

❓ Guiding questions – think before revealing

Why is the cash available AccDetails[AccID,2] + AccDetails[AccID,1]?
Why does the withdrawal loop until the amount is acceptable?
Why does deposit not need the overdraft test?

Reveal suggested reasoning

Why is the cash available AccDetails[AccID,2] + AccDetails[AccID,1]? The overdraft limit is what may be borrowed after the balance reaches 0.00, so the most the account can lose in total is overdraft limit + balance. With balance 120.00 and overdraft limit 150.00, the account can spare 270.00 before it would breach −150.00.

Why does the withdrawal loop until the amount is acceptable? A refused withdrawal should re-ask rather than return to the menu half-done: the published answer’s REPEAT … UNTIL repeats the prompt until the amount passes both limits.

Why does deposit not need the overdraft test? A deposit only adds money — it can never push the balance below the overdraft floor. Only the sign matters, so the loop checks Amount > 0 alone.

Reveal Cambridge pseudocode for Stage 6

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

PROCEDURE Balance(AccID : INTEGER)
    OUTPUT "Your balance is ", AccDetails[AccID,1]
ENDPROCEDURE

PROCEDURE Deposit(AccID : INTEGER)
    DECLARE Amount : REAL // local variable
    REPEAT
        OUTPUT "Please enter a positive amount to deposit "
        INPUT Amount
    UNTIL Amount > 0
    AccDetails[AccID,1] ← AccDetails[AccID,1] + Amount
ENDPROCEDURE

// Withdrawal(AccID) follows the same shape with two limit
// checks — see the next stage

📖 Detailed explanation

Each procedure owns one action. Balance reads one cell; deposit validates one sign and adds; withdrawal checks two limits and subtracts. Nothing is shared except the arrays and the ID.

The balance column is the single source of truth. Every action reads and writes AccDetails[AccID,1], so a deposit made after a withdrawal is measured against the updated balance.

Suitable messages accompany every prompt and refusal. The question’s closing lines ask for messages on all inputs and outputs — each procedure names what it wants and what went wrong.

The parameter reaches every cell the action needs. One AccID indexes the balance, the overdraft limit and the withdrawal limit — nothing else is passed or re-entered.

⚠️ Common mistakes

Subtracting the amount before the limit checks pass, so a refused withdrawal still changes the balance.
Comparing the amount against the balance alone and forgetting the overdraft allowance.
Allowing a deposit of 0.00 or a negative amount because the sign test is missing.
Printing the balance from Account[] instead of AccDetails[].

💡 Exam hack / tip

Each action procedure is read one amount, check the limits that apply, then write the balance column. The checks differ: balance needs none, deposit needs the sign, withdrawal needs both limits.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · array reads and writesR3 · actions completed in proceduresAO3 · accurate arithmetic

The action procedures carry the R3 evidence for AO2 — arrays used inside procedures with parameters — and the correct arithmetic is AO3 accuracy evidence. These are alignment notes, not separately allocated marks.

Guard the withdrawal with both limits

Two limits, two error messages, one guarded balance.

R1 · R2 · R3

🧠 Step-by-step thinking

Two limits, two tests. The withdrawal limit caps one withdrawal (AccDetails[AccID,3]); the overdraft limit caps how far the balance may fall (AccDetails[AccID,2] + AccDetails[AccID,1] is the cash available).
Refuse with a message for each. “Amount greater than withdrawal limit” for the first and “Amount greater than cash available” for the second — exactly the “suitable error messages” the question asks for when a withdrawal cannot take place.
Update only when both pass. IF Amount <= withdrawal limit AND Amount < cash available — the subtraction sits in the TRUE branch only, so a refused amount never changes the balance.
Watch the exact boundary. Acceptance uses a strictly-less-than test against the cash available, so an amount exactly equal to balance + overdraft limit is not accepted — keep your comparisons consistent so every refusal carries its message.
Finish on choice 4. The exit choice leaves the loop, the program ends, and the arrays keep every completed action — balance, overdraft floor and all.

Test 1: the withdrawal limitTest 2: balance + overdraftRefuse: two messagesBoundary: the −overdraft floor

❓ Guiding questions – think before revealing

Why can a successful withdrawal leave the balance negative?
What is the most this account can withdraw at once?
Why do the refusal and the acceptance use different comparisons?

Reveal suggested reasoning

Why can a successful withdrawal leave the balance negative? The overdraft limit is borrowing the bank allows: with an overdraft limit of 150.00, any balance down to −150.00 is legal. Withdrawing 180.00 from 120.00 leaves −60.00 — overdrawn but within the limit, so the withdrawal succeeds.

What is the most this account can withdraw at once? The smaller of the two ceilings: the withdrawal limit, and the cash available. With balance 120.00, overdraft limit 150.00 and withdrawal limit 200.00, the withdrawal limit binds at 200.00. Once the balance falls, the cash available becomes the binding ceiling instead.

Why do the refusal and the acceptance use different comparisons? The refusal messages fire on strictly greater than, while acceptance requires strictly less than the cash available, so an amount exactly equal to the cash available is neither refused with a message nor accepted — it is asked for again. In your own answer, keep the pair of comparisons consistent so every refusal has its message.

Reveal Cambridge pseudocode for Stage 7

CODE PLAN · STRUCTURE ONLYBuild this before filling in the details

PROCEDURE Withdrawal(AccID : INTEGER)
    DECLARE Amount : REAL // local variable
    REPEAT
        OUTPUT "Please enter amount to withdraw "
        INPUT Amount
        IF Amount > AccDetails[AccID,3]
          THEN
            OUTPUT "Amount greater than withdrawal limit"
        ENDIF
        IF Amount > AccDetails[AccID,2] + AccDetails[AccID,1]
          THEN
            OUTPUT "Amount greater than cash available"
        ENDIF
        IF Amount <= AccDetails[AccID,3] AND Amount < AccDetails[AccID,2] +
           AccDetails[AccID,1]
          THEN
            AccDetails[AccID,1] ← AccDetails[AccID,1] - Amount
        ENDIF
    UNTIL Amount <= AccDetails[AccID,3] AND Amount < AccDetails[AccID,2] +
          AccDetails[AccID,1] AND Amount > 0
ENDPROCEDURE

📖 Detailed explanation

The overdraft limit is measured from 0.00. Cash available is balance + overdraft limit, because the overdraft limit only counts after the balance reaches 0.00 — an account at 120.00 with a 150.00 limit can lose 270.00 in total.

Each refusal names its limit. Two separate IF statements give two separate messages, so the account holder learns which rule stopped the withdrawal.

The subtraction is inside its own IF. Only an amount that passes both limits reaches AccDetails[AccID,1] ← AccDetails[AccID,1] - Amount — a refused attempt leaves the balance untouched.

The exit choice ends the session cleanly. Choice 4 leaves the menu loop with every completed action already stored in the global arrays — no further output or tidy-up is required.

⚠️ Common mistakes

Comparing the amount against the overdraft limit alone, forgetting the balance that is still there to spend.
Testing the amount against the overdraft limit directly instead of against balance + overdraft limit.
Subtracting the amount on every pass, so a refused attempt still reduces the balance.
Accepting an amount exactly equal to the cash available, which would push the balance below the overdraft floor.

💡 Exam hack / tip

Compute the ceiling once in your head: cash available = balance + overdraft limit. A withdrawal passes only when it is at most the withdrawal limit and strictly less than that ceiling — everything else is refused with a message.

Reveal the Cambridge mark-scheme and rubric connection

AO2 · validation and selectionR1 · R3 · guarded array updatesAO3 · accurate boundary logicAO3 · suitable error messages

The guarded withdrawal completes the R1 and R3 evidence for AO2, and the two-limit boundary logic is AO3 accuracy evidence. These are alignment notes, not separately allocated marks.

Cambridge assessment criteria

What does a high-level response look like?

The mark scheme assesses the answer across AO2 and AO3. Use these descriptors to check the whole program, not just one isolated code section.

9 AO2 + 6 AO3 = 15

AO2 · Apply knowledge and understandingMaximum 9 marks · programming techniques and data structures

Band	What the descriptor means
0	No creditable response.
1–3	At least one programming technique is used. Some data is stored, but not appropriately. Any use of iteration, selection, counting, totalling, input or output may be credited.
4–6	Some programming techniques are appropriate to the problem, with more than one technique applied. Some data structures are appropriate and store some of the required data.
7–9	The full range of techniques needed by the scenario is used appropriately. The chosen data structures are appropriate and store all the required data.

AO3 · Provide solutions to problemsMaximum 6 marks · comments, identifiers, logic and accuracy

Band	What the descriptor means
0	No creditable response.
1–2	Program seen without relevant comments. Some identifier names and some data-structure names are appropriate. The solution may be illogical or inaccurate in many places, but attempts at least one requirement.
3–4	Program seen with some relevant comments. The majority of identifiers and most data-structure names are meaningful. Parts may be illogical or inaccurate, but most requirements are met.
5–6	The program is fully commented. Suitable identifiers are meaningful throughout, and all data structures have meaningful names. The program is logical and accurate and meets all requirements; minor syntax errors are ignored.

How the seven stages contribute

These are links to the assessment criteria, not separate mark allocations.

R1–R5

Stage	Mark-scheme link	AO2 evidence	AO3 evidence
1 · Decode	R1–R3	Identifies the login gate, the shared row index and the procedure-per-action structure.	Establishes logical order and comments the plan.
2 · Data	Required data structures	Uses Account[], AccDetails[] and Size as given, with AccountNumber, Choice and Valid as globals.	Meaningful identifiers; locals stay inside procedures.
3 · Login	R1	Checks the ID exists and the name and password match Account[] before any action.	Accurate column comparisons and specific error messages.
4 · Menu	R2	Displays the four actions, reads the choice and dispatches with CASE OF until exit.	Clean dispatch; invalid choices refused with a message.
5 · Params	R3	Declares each action as a PROCEDURE with an account ID parameter.	Local and global data used correctly and consistently.
6 · Actions	R3	Completes balance, withdrawal and deposit through the arrays in their procedures.	Accurate arithmetic on the balance column.
7 · Guard	R1, R3	Guards withdrawals with the withdrawal limit and the overdraft limit, with error messages.	Boundary logic that never breaches the overdraft floor.

Consolidated Cambridge pseudocode

Complete solution

The full answer is presented in one place after the seven stages. Try to construct it yourself before opening this tab during revision.

15-mark exemplar style

Read this carefully: this mirrors the official published mark scheme answer for 0478/22 May/June 2023 Question 12. The global arrays Account[] and AccDetails[] and the variable Size are supplied by the question and are used exactly as given, and nothing is declared beyond the main program’s own variables, which the mark scheme lists as for information. The answer defines one procedure for the login check and one for each menu action — every procedure receives the account ID as its parameter, declares its working variables locally, and reaches the account’s data through the global arrays. The withdrawal procedure checks both the withdrawal limit and the cash available before it changes the balance, and each refusal has its own error message.

QUESTION 12 · PUBLISHED MARK SCHEME ANSWERCambridge 0478 style · 1-based indexing

// Procedures to be called
PROCEDURE CheckDetails(AccID : INTEGER)
    DECLARE Name, Password : STRING // local variables
    Valid ← FALSE
    IF AccID < 0 OR AccID > Size
      THEN
        OUTPUT "Invalid Account Number"
      ELSE
        OUTPUT "Please Enter Name "
        INPUT Name
        OUTPUT "Please Enter Password "
        INPUT Password
        IF Name <> Account[AccID,1] OR Password <> Account[AccID,2]
          THEN
            OUTPUT "Invalid name or password"
          ELSE
            Valid ← TRUE
        ENDIF
    ENDIF
ENDPROCEDURE

PROCEDURE Balance(AccID : INTEGER)
    OUTPUT "Your balance is ", AccDetails[AccID,1]
ENDPROCEDURE

PROCEDURE Withdrawal(AccID : INTEGER)
    DECLARE Amount : REAL // local variable
    REPEAT
        OUTPUT "Please enter amount to withdraw "
        INPUT Amount
        IF Amount > AccDetails[AccID,3]
          THEN
            OUTPUT "Amount greater than withdrawal limit"
        ENDIF
        IF Amount > AccDetails[AccID,2] + AccDetails[AccID,1]
          THEN
            OUTPUT "Amount greater than cash available"
        ENDIF
        IF Amount <= AccDetails[AccID,3] AND Amount < AccDetails[AccID,2] +
           AccDetails[AccID,1]
          THEN
            AccDetails[AccID,1] ← AccDetails[AccID,1] - Amount
        ENDIF
    UNTIL Amount <= AccDetails[AccID,3] AND Amount < AccDetails[AccID,2] +
          AccDetails[AccID,1] AND Amount > 0
ENDPROCEDURE

PROCEDURE Deposit(AccID : INTEGER)
    DECLARE Amount : REAL // local variable
    REPEAT
        OUTPUT "Please enter a positive amount to deposit "
        INPUT Amount
    UNTIL Amount > 0
    AccDetails[AccID,1] ← AccDetails[AccID,1] + Amount
ENDPROCEDURE

// Declarations of global variables for information – not required in candidate responses
DECLARE AccountNumber, Choice : INTEGER
DECLARE Valid, Exit : BOOLEAN

OUTPUT "Please enter your account number "
INPUT AccountNumber
CheckDetails(AccountNumber)

IF Valid
  THEN
    REPEAT
        OUTPUT "Menu"
        OUTPUT "1. display balance"
        OUTPUT "2. withdraw money"
        OUTPUT "3. deposit money"
        OUTPUT "4. exit"
        OUTPUT "please choose 1, 2, 3 or 4"
        INPUT Choice
        CASE OF Choice
          1 : Balance(AccountNumber)
          2 : Withdrawal(AccountNumber)
          3 : Deposit(AccountNumber)
          4 : Exit ← TRUE
          OTHERWISE OUTPUT "Invalid choice"
        ENDCASE
    UNTIL Choice = 4
  ELSE
    OUTPUT "Invalid account number "
ENDIF

Why this is a complete response

It covers the three mark-scheme requirements. R1: the account ID is checked against Size and the entered name and password are compared with Account[AccID,1] and Account[AccID,2] before any action can take place, with a specific error message for each refusal. R2: the four-action menu is displayed inside a REPEAT … UNTIL loop, the choice is read with a suitable prompt and dispatched with CASE OF, and the OTHERWISE arm refuses invalid choices. R3: every action is completed by a procedure — Balance, Withdrawal and Deposit each take the account ID as a parameter, declare their working variables locally, and read and write the global arrays, with both withdrawal limits guarded by their own error messages.

What to check before submitting

Check the ID range test before the arrays are read, the two-column comparison in the login procedure, the parameter lists on all four procedures, the CASE OF dispatch with its OTHERWISE arm, the two withdrawal-limit conditions and the subtraction inside its own IF, and the comments explaining the program.

Remember: the mark scheme awards AO2 a maximum of 9 marks and AO3 a maximum of 6 marks, giving 15 in total, judged by best fit across the whole response. R1, R2 and R3 are the technique requirements the examiners look for, not a fixed per-item mark split.

Interactive execution trace

Visualisation: watch the program work.

Step through one complete session on a four-account bank. Watch the login refuse one wrong password, the menu dispatch each choice to a procedure carrying the account ID, a withdrawal above the withdrawal limit refused, a withdrawal that takes the balance overdrawn inside the overdraft limit, a withdrawal that would breach the overdraft refused, a deposit, and the exit that ends the session.

Last tab · Trace player

Sample input → expected results

The sample uses 4 illustrative accounts — Ravi, Priya, Mateo and Amara — each with a balance, an overdraft limit and a withdrawal limit; Mateo’s account already starts overdrawn at −45.00, within its 200.00 overdraft limit, and Ravi’s 0.00 overdraft limit means his balance can never go negative. The traced session logs into Priya’s account (ID 2) and deliberately tests the boundaries: a wrong password is refused once before the correct login; a withdrawal of 250.00 is refused for exceeding the 200.00 withdrawal limit; a withdrawal of 180.00 takes the balance from 120.00 to −60.00 — overdrawn but within the 150.00 overdraft limit; a further withdrawal of 100.00 is refused because only 90.00 of cash remains available; and the follow-up withdrawal of 80.00 lands the balance at −140.00, just 10.00 above the −150.00 overdraft floor, before a deposit of 250.00 restores it to 110.00. The published example answer makes a single login attempt and stops after a failed login; the sample session repeats the login prompt so the whole menu story can be shown in one run. The walkthrough shows one complete run of the authentic 0478/22 May/June 2023 Question 12. These are illustrative values, not data supplied by the examination question.

Sample accounts Account[] names and passwords · AccDetails[] balances and limits

Account	Balance	Overdraft	Withdraw limit

The row number is the account ID — the index shared by Account[] and AccDetails[].

Reveal expected session results and summary

Expected session results After the traced session

Account	Final balance	Refused	Completed

Execution trace

Step 1 of 1

Initialisation

The program begins.

Program output so far

(No output yet)

Live variable values

Session counters

Ready

Tip: use Next step slowly and watch MenuChoice, Amount and Balance. MenuChoice changes once per menu round and finishes on 4, Amount holds each attempt — watch 250.00 and 100.00 get refused — and Balance only moves when a withdrawal or deposit passes its checks.

Trace colours: blue row = current account; amber cell = current detail being read, checked or updated; green cells = account details already processed.

Boundary example: after the balance falls to −60.00, the cash available is −60.00 + 150.00 = 90.00. The withdrawal of 100.00 is refused with “Amount greater than cash available” because 100 > 90; the follow-up 80.00 passes both limits and lands the balance at −140.00, still above the −150.00 overdraft floor. An attempt of exactly 90.00 would be neither refused with a message (90 > 90 is FALSE) nor accepted (90 < 90 is FALSE) — the procedure would silently re-ask.

Check the login, then serve the four-action bank menu.

Learning targets

01 · Understand

02 · Construct

03 · Complete

Read the whole question first

Before you move on

Decode the requirements

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Plan the data and identifiers

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Check the account ID, name and password

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Display the menu and dispatch the choice

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Pass the account ID to each procedure

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Complete each action in its procedure

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

Guard the withdrawal with both limits

🧠 Step-by-step thinking

❓ Guiding questions – think before revealing

📖 Detailed explanation

⚠️ Common mistakes

💡 Exam hack / tip

What does a high-level response look like?

How the seven stages contribute

Final self-check

Complete solution

Why this is a complete response

What to check before submitting

Visualisation: watch the program work.

Sample input → expected results

Sample accounts Account[] names and passwords · AccDetails[] balances and limits

Expected session results After the traced session

Execution trace

Initialisation

Live variable values

Session counters