Bank Statement Design: Comparing Layout Variants With AI
Summary
Statement redesigns often stall because stakeholders choose between mock-ups that behave better than real statements. AI-drafted variants can be shown as real output on realistic records, which makes each review round more informative and makes unconventional ideas cheaper to try. The choice, the mandatory content and the sign-off stay with people. For heads of digital, operations and customer experience at banks and wealth managers.
Consider a head of digital at a retail bank, two weeks before a steering meeting. The plan is to show three layouts for the monthly current account statement and pick one. A designer builds each, so all three mock-ups use the same sample customer: twelve transactions, a short name, a positive balance, no notices. Everything fits. The meeting chooses layout B, mainly because its balance summary at the top looks calmer than the other two.
Six weeks later the first run on live accounts turns up a customer with 140 transactions spread over four pages, a 41-character account name that wraps into the balance box, and an overdraft notice that now sits on page four. Layout B was chosen on a statement that no customer receives.
Two costs produced that outcome. Choosing between static mock-ups on friendly data hides how a layout behaves on awkward records. And because each change request costs a design cycle, the team explored mainly the ideas it could afford to build. An AI design assistant changes both costs. The two changes are separate, and they call for different handling, so it helps to take them one at a time.
Two Different Benefits of Faster Variants
Faster iteration. In a normal redesign, a comment made in a review meeting ("put the charges below the transactions, not beside them") turns into a task, then a build, then a new set of screenshots for the next meeting. If the same change can be made in a short working session, the stakeholder sees it as real output on real-shaped records at the next meeting, and sometimes within the same week. The feedback loop shortens, so decisions are made on how a layout performs and not on how it was described.
Cheaper experimentation. Some ideas do not get built because they would take design days before anyone could judge them. Splitting the transaction list into money in and money out is one example. Showing the closing balance before the opening balance is another. When a draft is cheap, it can be built, looked at and thrown away without a budget conversation, and the team ends up testing options it would otherwise have ruled out on cost alone. The drafts still need a designer's review. A draft that is cheap to produce is not a draft that is correct.
Faster variants make the process quicker. They do not make the decision any easier, and they can make a review slower. Five layouts invite five opinions on each detail. A workable limit is three variants per round, each differing in one or two named variables, so the discussion is about those variables and not about everything at once. The first round narrows the field, and the second refines the survivor.
| Variable being tested | What differs between variants | What stakeholders usually argue about | What a test on real records shows |
|---|---|---|---|
| Summary position | Balances and amount due at the top, or after the transactions | Whether the customer sees the key figure first | Whether the summary box survives long names and an overdrawn balance |
| Transaction grouping | Chronological list, or grouped by type (card, transfer, fees) | Finding one payment versus understanding spending | How the layout behaves with 5 transactions and with 140 |
| Emphasis on key figures | Larger type for the closing balance or amount due, or standard body size | Readability against a busy page | Whether the larger figure still fits for the biggest balances and for a foreign-currency line |
What Has to Stay Fixed While the Layout Changes
A redesign is easier when everyone agrees on what is open to change. Readability decisions are mostly about three things: where the balance sits, how charges are grouped so that fees are visible as a block instead of being found by subtraction, and which notices need prominence so that a change to terms is not on the last page. Those are the free variables.
Some content is not free. A statement may have items that must appear, in a stated order or position, because of a regulatory requirement, a contract or a compliance reading of one. That list differs between jurisdictions and products, and the bank's compliance function owns it. It is an input to the redesign, handed over before the first variant is drawn. A variant that moves a required statement is not a bold layout choice. It is an error that happens to look good, and a stakeholder meeting is poorly placed to notice it.
The same boundary applies to the wording on the page. A redesign changes how existing text is arranged, and the assistant is not asked to improve it. Rewording a disclosure in plainer language may be a good idea, but it is a decision for the people who approve the text, made separately and recorded.
Testing Variants Before Anyone Chooses
The statement in the opening scenario passed review because the review data was friendly. The remedy is a fixed set of awkward records that each variant is run through before the stakeholder session, chosen from the cases the bank already knows exist:
- an account with no transactions in the period
- an account with 140 transactions, which runs over several pages
- an overdrawn balance, so a negative figure and a notice appear together
- a long account name and a long address
- joint holders, if the product allows them
- a foreign-currency line, if the product allows it
- a record with the notice flag set, and one with an optional field missing
The values should be invented or anonymised, but the shape should be real. Printed side by side, three variants on this set show differences that a single friendly sample hides, and the variants that break on a realistic record drop out before the committee has to discuss them. The meeting then compares layouts that all work.
Two things this does not replace. Testing with customers, to see which layout they find easier to read, is a separate piece of research. And the final choice remains a human judgement about the bank's brand, its customers and its obligations. The assistant produces options to look at, and the choosing, the mandatory content and its order, and the sign-off stay with named people.
How This Maps to CxReports
Here is how that workflow looks with the CxReports AI Assistant, using what the documentation states.
Starting from the current statement. The AI Assistant is a chat in the Report Editor, available to roles with the AI permission once a workspace administrator has configured an AI Integration with the organisation's own API key. A user can attach a screenshot or a PDF of the current statement (images up to 7 MB, PDFs up to 32 MB and 100 pages, three files per message, and no PDFs with the DeepSeek integration) and ask the assistant to rebuild it as a starting point. For how that works in practice, see AI-assisted report design. A PDF is uploaded to the AI provider, which keeps it for a period that depends on the provider, so attach an anonymised statement and not a real customer's.
Holding the variants in one report. The documentation describes a Page Visibility Expression, which shows or hides a page based on report parameters, and a Lookup parameter type that offers a list of values. A practical setup is a layout parameter with values A, B and C and one set of pages per variant, each page shown only when the parameter has its value. The assistant can create pages, elements and parameters, so describing that structure is a task it can attempt, and a designer reviews the result. A stakeholder then sets the parameter in the Set Parameters window to see the same customer record under each variant, and the Report tab can export each result as a PDF for circulation. When a variant is chosen, the other variants' pages are removed before the report goes into production.
Edge-case records. An invented JSON or CSV file of test accounts (up to 256 KB) can be attached and turned into a data source, and the data source holds the file's exact content, so the 140-transaction customer and the 41-character name arrive as written. Parameters select which test account a preview shows, and the Show Available Data popup displays the data keys the report is using. The assistant also receives an overview of the open report with each message and can inspect current data when asked, which is another reason to keep real customer data out of design sessions.
Telling the assistant what is fixed. A report-scoped AI Skill is text that the assistant receives as context for that report. It can carry the free and fixed items from the previous section:
Statement redesign: fixed and free content
- These items appear on each variant, in the position and order supplied by
Compliance: [list provided by the bank].
- Variants may change: summary placement, transaction grouping, type scale
for key figures, spacing.
- Do not rewrite statement wording. Use the existing text and dictionary keys.
- Build each variant as its own set of pages, shown by the layout parameter.
This guides the assistant and does not restrict it, so the review of each variant against the compliance list is still needed. Skills should hold instructions, not customer data.
Three limits are worth knowing in advance. First, headers, footers and page-number placement are defined in the template, in the Template Editor, and the assistant is documented for work on report pages and elements. A variant that moves the footer or the page number is a template change made by a person, and it applies to the reports that use that template. Second, themes are set per report by a person in Report Settings. The assistant is documented as able to inspect a theme, but its listed actions do not include editing one, so changes to brand colours or the theme's typography are made separately. Third, the documentation does not describe how hidden pages are counted. When variants are hidden by a visibility expression, check "Page x of y" and the table of contents in the preview before circulating anything. For layout decisions at the level of individual elements, see report template design and pixel-perfect reports.
The remaining responsibilities sit with the bank: the list of mandatory content, deciding which variant is chosen, accessibility and customer research, and sign-off. The actions the assistant takes appear as expandable rows in the chat so a designer can see what it changed. The documentation does not state how long conversation content is retained, so keep the decision record in the project's own files and not in the chat.
Getting Started
| Redesign need | CxReports mechanism | What stays with the bank |
|---|---|---|
| A first draft from the current statement | Assistant with an attached screenshot or PDF | Anonymising what is attached; reviewing the draft |
| Several layouts of the same statement | Pages per variant, shown by Page Visibility Expression and a layout parameter |
Choosing which variables to test |
| Awkward test records | Attached JSON or CSV turned into a data source; Show Available Data | Inventing realistic edge cases |
| Fixed and free content | Report-scoped AI Skill | The mandatory-content list; checking each variant against it |
| Shared circulation | Preview and Export PDF from the Report tab | Stakeholder process and sign-off |
| Footers, page numbers, brand theme | Template Editor and theme settings, configured by a person | Brand and template approval |
Documentation:
To compare statement variants on your own awkward records, request a demo.
This article covers statement design and review practice. It is not legal or regulatory advice. Which statement content is required, and where it must appear, depends on your jurisdiction, products and contracts, and is determined by your compliance function.