The model lives in a spreadsheet
It works, and one person understands it. Nobody else can rerun it, version it or prove what changed between reporting cycles.
Data and quantitative risk analytics consultant
I turn regulatory complexity into automated, data-driven risk models.
Independent quantitative risk and regulatory analytics for banks, insurers and consumer finance companies. I read the requirement closely enough to model it correctly, then write the Python, R or SQL that lets it recalculate itself every reporting cycle.
For CROs · heads of credit risk · model risk teams · IFRS 9 programme owners
Professional proof
4 years in credit risk and regulatory modelling
5 countries with delivered engagements
7 named institutions in the source portfolio
Source-verified countable indicators as of July 2026.
01 — Problems addressed
Where regulatory programmes usually stall
Not in the methodology. In the gap between a defensible method and a calculation that runs, reconciles and can be explained a year later.
The methodology is not written down
Interpretation decisions were made verbally. A validator asks why a threshold was chosen and there is no reviewable note to point at.
Validation findings keep repeating
Calibration and stability tests fail in the same way each cycle because nothing upstream of the test has changed.
02 — Services
All services Eight areas of practice
Credit risk modelling
Develop, recalibrate and document transparent credit risk parameter models for decision-making, provisioning and capital assessment.
IFRS 9 and ECL analytics
Design, review and automate Expected Credit Loss analytics from risk parameters and forward-looking scenarios through controlled calculation outputs.
IFRS 17 analytics
Support quantitative assessment and structured vendor benchmarking for IFRS 17 analytical tools, within verified experience boundaries.
ICAAP and capital modelling
Build and document quantitative capital assessment methods across credit, market and operational risk, with scenario and stress testing support.
Model validation and backtesting
Provide structured challenge of model methodology, data, implementation, performance, stability and limitations.
Risk data automation
Replace fragile manual risk calculations with controlled, versioned and maintainable analytical pipelines.
Regulatory analytics and reporting
Build repeatable calculation and reporting processes with data lineage, reconciliation, controls and audit traceability.
Quantitative advisory
Focused technical advice for model design, methodology review, analytical prototyping, tool selection and team capability transfer.
03 — Model lifecycle
Full methodology How an engagement runs
Six stages, in this order, every time. The methodology note is agreed before code is written, preventing avoidable validation findings.
Requirement
Read the regulation and agree the interpretation in writing.
Output: Agreed scope and interpretation note
What the delivered pipeline looks like
01 Frame Clarify the question, users, outputs and governance requirements.
02 Assess Review data, methods, tools, controls and model risk.
03 Model Prepare data, test assumptions and build transparent analysis.
04 Validate Challenge performance, stability, implementation and limitations.
05 Automate Add repeatable code, controls, reconciliation and logging.
06 Transfer Document, train, hand over and define monitoring.
04 — Selected work
All work Selected case studies
Figures are withheld throughout, and each engagement states how it relates to Bedis Blaiej Analytics.
Automating PEL case calculations
Interest and premium entitlement calculations varied by contract case, subscription date and rate tier, making consistent manual treatment difficult.
Outcome: qualitative capability
Automating an IFRS 9 ECL calculator
The business team needed a consistent way to calculate Expected Credit Loss across retail segments without manually re-deriving the approved methodology.
Outcome: qualitative capability
From spreadsheet calculator to reproducible risk pipeline
Probability of Default and Loss Given Default logic needed to move beyond a single spreadsheet-based workflow into a more scalable and reproducible implementation.
Outcome: qualitative capability
Quantitative capital modelling under ICAAP
The institution required a defensible quantitative framework across credit, market and operational risk, supported by consistent data collection and internal rating logic.
Outcome: qualitative capability
05 — Analytical approach
Evidence, not assertion
Every model decision is backed by a chart, table or reconciliation a reviewer can reproduce.
Programming and data
Python, R and SQL for modelling and automation; VBA and SAS for legacy and regulatory platforms.
R Core
VBA Core
Python Core
SAS Strong
SQL Strong
Quantitative modelling
PD, LGD, EAD and CCF estimation; logistic regression, CreditMetrics and the ASRF framework.
PD / LGD / EAD / CCF Core
Logistic regression Core
CreditMetrics Strong
ASRF Strong
Review evidence
What survives independent challenge
| Control point | Reviewable evidence |
|---|---|
| Interpretation | Written methodology and decision record |
| Data | Lineage, exclusions and quality controls |
| Implementation | Versioned code and reconciliation output |
| Performance | Calibration, stability and backtesting evidence |
| Handover | Runbook, limitations and monitoring plan |
qualitative review framework — not client data
06 — Insights
Editorial approach Technical notes in review
Draft material remains private until Bedis completes technical and publication review.
Practical IFRS 9 model monitoring
Data, staging, parameters, scenarios, reconciliation and governance evidence.
Replacing spreadsheet risk tools
Specification, control assessment, reconciliation, testing and operational handover.
Model monitoring checklist
A future review aid for data, parameters, performance, controls and governance.
07 — Frequently asked
Practical questions
What type of engagement is a good fit?
A defined risk modelling, validation, regulatory analytics or automation question with an identified owner, available evidence and a clear decision or output.
Can projects be delivered outside Tunisia?
Yes. The source portfolio records engagement experience across France, Morocco, Tunisia, Egypt and the UAE. Delivery format and any travel requirements are agreed during scoping.
Should confidential model or customer data be sent through the website?
No. The public forms are only for initial scoping. A suitable secure document exchange and handling process can be agreed separately.
Can work fit an existing technology environment?
Usually. Python, R, SQL, SAS, VBA and Excel are all represented in the source experience. The target environment, access and change constraints are confirmed before implementation.
Can model validation be scoped independently from development?
Yes. Validation scope, evidence, independence expectations and governance reporting are agreed at the outset.
What does a practical handover include?
Depending on scope, handover can include versioned code, methodology, data definitions, controls, run instructions, limitations, monitoring requirements and a technical walkthrough.
Next step
Tell me what needs to run reliably.
A short brief is enough to establish whether this is a fit. Describe the situation in general terms only. Do not send client data or model files.