Case Study · Finance
TBB: an end-to-end data scientist programme for bankers
Within the Banks Association of Türkiye's training programme, a 62-hour, 21-day 'Data Analytics Journey' for bank employees who use data in their work: introduction to data science, SQL, Python, statistics and EDA, visualisation, machine learning, industry cases. Evening sessions, homework for every module, hands-on work in Colab; every module was scored out of 10 in TBB's participant survey — averaging above 9.
- 62 hours
- Duration
- 9+ / 10
- Evaluation
- 10 / 10
- Highest
- 2
- Industry cases
21 days, 7 modules
TBB participant survey per module
Introduction and machine learning modules
Retail sales forecasting · bank transaction classification
Problem
In banks data is everywhere; yet most people who work with it do so without writing SQL, opening Python or seeing the model behind the report. The goal for the Banks Association of Türkiye’s training programme was to take a bank employee who uses data in their work from zero to the point of building a machine learning model themselves — not in theory, but at the keyboard every evening.
Seven modules, one journey
We designed the programme as a “Data Analytics Journey”: each module builds on the one before, and by the end the participant has been through every step of a data science project.
| # | Module | Hours | What was learned |
|---|---|---|---|
| 1 | Introduction to data analysis, data science and AI | 2 | Data literacy; what analysts and data scientists do; the tools the journey will need |
| 2 | Databases and SQL querying | 12 | Relational structures, data types; select, where, group by, join, subquery, DML; rank, case, while |
| 3 | Python programming | 15 | Data structures, conditions, loops, functions, files; pandas, numpy, matplotlib |
| 4 | Basic statistics and EDA in Python | 3 | Missing and outlying values, distributions, correlation; exploratory analysis |
| 5 | Data visualisation and tools | 6 | Visualisation principles; dashboards in Power BI |
| 6 | Basic machine learning in Python | 18 | Data preparation, regression and classification, validation, model selection |
| 7 | Data science industry cases | 6 | Two end-to-end cases: retail store sales forecasting, bank customer transaction classification |
Four instructors shared the modules: Ahmet Can taught SQL, Burak Python and machine learning, Hasan visualisation, Sabri the introduction and the industry cases. Sessions ran on weekday evenings 17:00–20:00 over Teams; each module’s homework was solved in the next session, code was shared in Google Colab, files kept on a shared Drive.
Industry cases
The last module was the journey’s exam: two real datasets, start to finish. In the retail case a store chain’s daily sales were forecast — with calendar, promotion and competitor-distance variables, from EDA to model comparison. In the bank case a model classifying customer transactions from hundreds of anonymised variables was built; the focus was on class imbalance, feature selection and gradient boosting. The participants had learned to write SQL in the first module; in the last they were debating XGBoost parameters.
Measurement
At the end of every module TBB ran a standard participant survey: did the training add to knowledge and skills, did the exercises support learning, were the presentation and materials adequate. All seven modules scored above 8.5 out of 10; the introduction and machine learning modules scored full marks, visualisation and EDA 9.6–9.9. The lowest score was the SQL module — the densest content, the most homework; that score became the input for rethinking SQL hours and homework load in later programmes.
Why this way
- Evenings, but at the keyboard every evening. Three hours after work is tiring; had the content been lecture rather than practice, attendance would have dropped by the third week.
- The industry case comes last, but is known from the start. In the first session the participant sees what they will be able to do at the end of the journey; they know why they are learning SQL.
- The survey supplies the data. Module scores became the input for correcting the programme; which module’s hours and homework load needed to change was discussed with scores, not guesses.