Credit-card billing and debt repayment — illustrative business analysis
Portfolio exercise | IBTech / QNB Finansbank engagement context, 2018–2019
This document is a reconstructed teaching example, not a source document from QNB, IBTech, CBOT or Banksoft. All data, statuses, interfaces, IDs, acceptance criteria, rules and test results are fictional. The original internal system architecture and calculation logic are not disclosed or claimed.
1. Confirmed project scope and my role
I worked as a Business Analyst in an eight-person credit-card payments team at IBTech / QNB Finansbank (2018–2019). The domain covered:
- Credit-card billing statements (ekstre) and the billing cycle
- Statement balance / period debt (dönem borcu)
- Minimum payment amount (asgari ödeme tutarı)
- Payment due date (son ödeme tarihi)
- Credit-card debt repayment (kredi kartı borç ödeme)
- Data provided from our card-payment domain to Q, the bank's digital assistant
- Third-party software support from Banksoft
My historical BA work included requirements analysis, functional design and integration/acceptance test activities. The exact QNB schemas, vendor work allocations, payment endpoints and internal authorization model are not public.
Attribution boundary: I did not develop Q's natural-language engine. CBOT publicly identifies its platform as Q's conversational technology; my work was on the banking source-system side.
2. Business objects and concepts
A customer may ask several similar-sounding questions that must not be treated as equivalent.
| Business term | Meaning for analysis | Important distinction |
|---|---|---|
| Billing/statement date | Point when a statement cycle closes | Not the customer's payment deadline |
| Statement balance / period debt | Amount associated with the statement cycle | Not necessarily identical to the current outstanding card balance |
| Minimum payment | Amount defined as minimum for the billing cycle | Not synonymous with full statement debt |
| Payment due date | Deadline associated with the statement | Not the date a payment was posted |
| Outstanding debt | Liability remaining at a particular point in time | Can be affected by subsequent events; source semantics must be defined |
| Payment instruction | Customer-authorized request to pay | A request being sent does not prove final posting |
| Payment status | Confirmation or failure/uncertainty of payment | A network timeout does not prove payment failure |
QNB publishes the meanings of statement date, payment due date and minimum payment and describes different consequences for incomplete payment. See QNB card statement glossary. This example deliberately does not implement or restate QNB's interest calculation algorithm or minimum payment formula.
3. Illustrative integration responsibilities
The following diagram describes logical functions, not confirmed QNB/Banksoft components, transport protocols or deployment topology.
- Q / authenticated mobile channel: interprets a customer query or repayment request and presents permitted data.
- Banking integration boundary: authenticates/authorizes the request and translates the business intent into a controlled domain request.
- Card-payment source domain: supplies the requested statement and repayment information with explicitly defined cycle, currency, timestamp and status semantics.
- Repayment processing: if the request involves payment execution, independently validates authorization, amount and payment state; payment confirmation follows source-system confirmation.
- Third-party software support: Banksoft supported the card-payment system; its exact placement within QNB's original runtime is not established.
The author's confirmed place in this illustration is business analysis and functional testing on the card-payment source side. Do not read the diagram as a literal 2018–2019 API map.
Illustrative question → data dependency
| Example customer question | Required business concept | Analysis question |
|---|---|---|
| "What is my card statement debt?" | Statement balance, cycle identifier and currency | Which statement period is relevant? |
| "What is the minimum I need to pay?" | Minimum due, applicable cycle | Does the term refer to the original minimum or the remaining payable minimum after payments? |
| "When is the last day to pay?" | Due date, local business date/time convention | What happens around day-end or a non-working day? Follow the approved bank policy. |
| "Pay my credit card debt." | Permitted payment option, source account, payment amount and final status | How is the instruction authorized, and what is considered a confirmed result? |
The customer questions are examples; they do not prove that Q supported every example in the original project phase.
4. Sample read-only data contract (not a production API)
This fictitious logical response deliberately separates statement values from live/remaining values.
| Logical field | Synthetic example | Illustrative data rule |
|---|---|---|
| masked_card_reference | 1842 | Never display a full PAN or sensitive identifier |
| statement_cycle_id | DEMO-2026-09 | Represents the source billing cycle; fictional format |
| statement_date | 2026-09-12 | Distinct from due date |
| due_date | 2026-09-22 | Semantics and time zone must be agreed |
| currency | TRY | Consistent currency for amounts |
| statement_amount | 4,500.00 | Original statement amount for that cycle |
| minimum_due_original | 900.00 | Example only; no implied statutory percentage |
| remaining_statement_amount | 2,500.00 | Fictional example after an eligible payment |
| remaining_minimum_due | 0.00 | May differ from original minimum; actual bank rules determine value |
| balance_as_of | 2026-09-16T10:30:00+03:00 | Prevent treating historical data as current |
| source_status | AVAILABLE | Explicit distinction from unavailable/unknown |
Example scenario only: An illustrative customer owes TRY 4,500 on a fictional statement, has an original minimum amount of TRY 900 and makes a qualifying TRY 2,000 repayment. A hypothetical source may then show TRY 2,500 remaining statement amount and zero remaining minimum. The bank's actual allocation logic, posting sequence and interest rules could differ; this is not an authorized banking calculation.
5. Representative user stories
CARD-01 — Statement context
As an authenticated customer, I want to see my period statement debt and payment due date together so that I know what period the balance describes.
Illustrative acceptance criteria
- Given a valid current statement, when its data is retrieved, then the UI presents statement date, balance, due date and currency with consistent cycle context.
- If no statement exists for the requested cycle, the response indicates no statement available, not a confirmed zero balance.
- A stale or unavailable source cannot silently be represented as real-time information.
CARD-02 — Minimum vs full repayment
As an authenticated customer, I want to distinguish the minimum payable amount from the full statement debt before selecting a repayment option.
Illustrative acceptance criteria
- The minimum amount and full statement amount have different labels and meanings.
- Repayments made after statement generation do not automatically rewrite the original statement; any remaining balance must be returned according to approved source semantics.
- If a selected payment option is unavailable, it cannot be presented as an actionable choice.
CARD-03 — Safe payment outcome
As a customer initiating a credit-card debt repayment, I need an unambiguous outcome so I do not mistake a pending or timed-out operation for a completed payment.
Illustrative acceptance criteria
- A successful payment confirmation is shown only after the payment source confirms completion.
- Timeout, rejected payment, insufficient funds and pending outcome are distinguishable.
- Any retry design considers possible duplicate execution and uses source-side controls appropriate to that system.
- Logging and troubleshooting exclude full card numbers and other protected customer details.
CARD-04 — Consumer integration
As a downstream digital channel, I need an authorized, documented card-debt response so I can present the correct statement context.
Illustrative acceptance criteria
- Only fields approved for the requesting context are returned.
- Statement-cycle context, amounts, timestamp and currency are preserved.
- Missing data, missing authorization and technical unavailability produce distinguishable outcomes.
- The contract states whether balances are current, statement-as-of or pending confirmation.
6. Example SIT/UAT scenarios
| Test ID | Input / condition | Expected behavior |
|---|---|---|
| BILL-01 | Valid authenticated card with a statement | Correct cycle, statement amount, minimum and due date displayed |
| BILL-02 | Statement created, eligible partial payment posted | Original statement remains distinguishable from remaining payable amount |
| BILL-03 | Minimum amount already covered | Remaining-minimum display follows agreed source semantics; original minimum not erased |
| BILL-04 | Card has no current statement | No-statement state, not false zero-debt confirmation |
| BILL-05 | Multiple cards under the same customer | Information belongs to the selected, authorized card only |
| BILL-06 | Query just before/after due-date boundary | Dates evaluated according to approved bank calendar/time-zone rules |
| BILL-07 | Upstream source temporarily unavailable | Technical unavailability differs from no debt |
| BILL-08 | Payment is rejected | No successful repayment confirmation |
| BILL-09 | Payment submitted but downstream response times out | Ambiguous result handled without asserting success or safely assuming failure |
| BILL-10 | Repeated payment request during uncertain outcome | Duplicate execution risk controlled by the actual payment system |
| BILL-11 | Source returns mismatched cycle/currency | Validation error or documented rule for resolving mismatch |
| BILL-12 | Unauthorized access to another card | No financial data disclosed |
Traceability example: CARD-01 → BILL-01/04/06/11; CARD-02 → BILL-02/03; CARD-03 → BILL-08/09/10; CARD-04 → BILL-05/07/12.
No claim is made that these exact cases were authored or run against QNB's production or historical test environments.
7. Role boundaries and deliverables
Grounded in first-hand account
- Eight-person credit-card payments team at IBTech / QNB Finansbank
- Banksoft as third-party software support
- Credit-card statements, minimum due, due dates and debt repayment domain
- Q integration from banking-data / source-system side
- Business analysis, functional design and SIT/UAT participation
Demonstrated with this reconstructed artifact, not confirmed as a historic task list
- A sample logical data contract and field glossary
- Example business-rule questions about partial repayments and time boundaries
- Illustrative consumer/source responsibility mapping
- Sample functional user stories, acceptance criteria and test matrix
- Recommended confidentiality and ambiguous-payment-outcome safeguards
Out of scope / not established
- Exact Banksoft product/modules running at QNB in 2018–2019
- SOAP, REST, MQ, database technology, internal tables or middleware topology
- Auth mechanism, actual API route names, production monitoring and SLA
- Formulae for minimum payments or interest
- Specific incident resolutions, throughput, defect counts, delivery metrics
- Personal authorship of Q's CBOT/NLP interface or Banksoft vendor components
Public technical background
- QNB statement and payment terminology
- QNB Q assistant overview
- CBOT account of Q's conversational platform
- Banksoft Credit Card Management System product description
- Banksoft Internet Banking Management System product description
Sources above establish public product capabilities and business terminology; they do not reveal the original QNB internal architecture or confirm the author's exact task assignments.