Employer Scheme Onboarding: Setting Up Workplace-Banking Lending

How banks onboard employers and configure lending schemes — approved-employer lists, scheme parameters (interest, tenure, fees, insurance), and the allowance and deduction variables that drive affordability.

Every check-off loan a bank writes begins with a decision that happens long before any customer fills in an application: which employers it will lend against, and on what terms. In workplace banking, the employer is the anchor of the credit. Repayment is deducted at source from payroll, so the bank's exposure is shaped less by the individual borrower than by the scheme the borrower sits under — its interest rate, its tenure limits, its insurance arrangements, and the payslip structure used to test affordability. Get the configuration layer right and the rest of the origination process runs predictably. Get it wrong and every loan booked under that scheme inherits the error. This article looks at how an employer becomes an approved scheme in the Workplace Banking platform, the parameters that govern every loan written against it, and the maintainable allowance and deduction variable set that powers affordability checks.

The approved-employer list: lending only where there is a scheme

Workplace banking is not open-market lending. A customer can only proceed if they are an employee of an employer the bank has already approved and onboarded as a scheme. This is the first control in the entire process, and it sits in the configuration layer rather than in any individual credit decision. If the employer is not on the list, there is no scheme to lend against, the affordability calculator has nothing to draw on, and the application cannot start.

In practice, onboarding an employer means more than adding a name. It means recording the legal entity, the payroll-deduction arrangement (the check-off relationship that lets the bank recover instalments at source), and the full set of parameters and payslip variables that will govern lending under that scheme. Once that work is done, the employer appears in the list a Direct Sales Executive selects at the very start of an application. Selecting the scheme is the moment the configuration becomes visible: the platform surfaces that employer's parameters and its allowance and deduction set, and everything downstream — the calculators, the application, the credit assessment — operates within those boundaries.

This is also why employer onboarding is treated as a distinct discipline rather than an administrative afterthought. The approved list is effectively the bank's workplace-lending risk appetite expressed as data. For the wider context of where this sits in the end-to-end journey, see the complete guide to workplace banking, and for the foundations of the model itself, what workplace banking is and how check-off loans work in the Kenyan market.

Scheme parameters: the terms that govern every loan

Once a scheme is selected, the platform shows its parameters — the configured terms that constrain every loan booked under that employer. These are maintained per employer, which means two schemes can carry entirely different pricing and limits without any change to the underlying engine. The parameters are not suggestions; they are the rails. The calculators will not produce a figure outside them, and the application cannot capture a loan that breaches them.

The parameter set is deliberately compact. Each item controls a specific dimension of the loan, and together they define the envelope within which a borrower under that scheme can transact.

Because these are held against the employer record, a bank can price a low-risk public-sector scheme differently from a private employer, set tighter tenure limits where contract terms are short, or vary the insurance arrangement to match the cover negotiated for that workforce. The point is that the variation lives in configuration data, not in code — the same origination workflow serves every scheme, and the differences are expressed entirely through these parameters.

Allowances and deductions: the payslip variables behind affordability

Scheme parameters set the loan terms. The allowance and deduction variables set how much a given employee under that scheme can actually afford. When the affordability check runs, the user selects the employer and the calculator factors in all of that scheme's allowances and deductions to work out the borrower's capacity from their payslip. This is where the configuration layer connects to real take-home pay.

The platform recognises a defined set of allowances and a broader set of deductions. Allowances increase the income base; deductions reduce the disposable amount available to service a new instalment.

• Allowances considered: House, Commuter, Hardship, Other.
• Deductions considered: PAYE, NSSF, NITA, NHIF, Provident/Pension, Sacco Contributions, Sacco Loan 1 plus Sacco Loan Interest 1, Sacco Loan 2 plus Sacco Loan Interest 2, Bank Loan 1, Bank Loan 2, Other Loans, and Reimbursements.

Two things make this set useful in practice. First, it captures existing obligations — Sacco loans and their interest, other bank loans, and miscellaneous loans — so the affordability check reflects the borrower's true commitments rather than an optimistic gross figure. Where a customer is taking out a loan to buy off an existing facility, that facility being taken over is included in the affordability check so the calculation is honest about the position both before and after settlement. Second, the whole assessment is bounded by a configurable policy floor: a minimum take-home of KES 50,000 must remain after the new instalment, and that floor is enforced even where a buy-off is involved.

Crucially, this variable set is bank-maintained. The bank can add new allowance or deduction types and remove ones it no longer uses, so the affordability model can track changes in statutory deductions or in the payslip conventions of particular employers without a software release. The mechanics of how these variables feed the capacity calculation are covered in detail in the loan affordability check from a payslip article.

EmployerScheme: where the configuration lives

All of this configuration is owned by a single service. In the platform's microservice architecture, the EmployerScheme service is responsible for employer and scheme CRUD — creating, reading, updating and deleting employer records — along with the allowance and deduction types and the per-scheme parameters described above. Concentrating this in one service keeps the configuration layer coherent: there is one authoritative place where the approved-employer list, the scheme terms, and the payslip variable set are defined and maintained.

This separation matters for governance as much as for engineering. Because scheme configuration is a service of its own, changes to pricing or to the affordability variable set are discrete, auditable actions rather than ad hoc edits scattered across the origination flow. It also means the rest of the platform — the calculators, the application lifecycle, the workflow engine — consumes scheme data through a stable boundary rather than holding its own copies.

For government schemes there is an additional dimension: the employer code used by IPPD, the government payroll deduction system. For ministries and public-sector employers, the Scheme Loan Administrator generates the deduction data that is delivered to IPPD, which confirms capacity and books the deduction. The employer code is the key that ties a scheme to its IPPD arrangement, which is why it carries through from configuration all the way to booking. Where an employer code is missing at the disbursement stage, Credit Admin has to liaise with the Scheme Loan Administrator or the Scheme Relationship Manager before the loan can go out — a direct illustration of how a gap in the configuration layer stops the operational layer in its tracks.

How scheme configuration flows downstream

The value of getting configuration right shows up everywhere downstream, because scheme data is the input the rest of the platform runs on. The flow is straightforward but worth making explicit:

1. Scheme selection surfaces the employer's parameters and its allowance/deduction set.
2. The calculators apply those parameters. The forward and reverse calculators use the scheme interest rate, the amount and tenure limits, the processing fees and the insurance amount to produce repayment figures, while the affordability check pulls in the scheme's full payslip variable set. The mechanics of the forward and reverse loan calculators show how those parameters become EMI and maximum-loan figures.
3. The application captures a loan that already sits within the configured envelope, because the customer could not have been quoted anything outside it.
4. Credit and booking inherit the same terms — the rate, tenure, fees and insurance booked into core banking are the ones configured against the scheme.

In other words, configuration is not a one-off setup task that the bank forgets about; it is the live ruleset that constrains every quote, every application and every booking under the scheme. A change to a scheme parameter today changes the terms a customer can be offered tomorrow. That is exactly why the approved-employer list, the per-scheme parameters and the maintainable allowance/deduction set deserve to be treated as a first-class part of the lending platform rather than back-office plumbing. To see how the configured loan then moves through review, credit and approval, follow the workplace-banking loan workflow.

Frequently asked questions

Can different employers have different interest rates and tenures?

Yes. Scheme parameters are maintained per employer, so each approved scheme can carry its own interest rate, minimum and maximum loan amounts, processing fees, minimum and maximum tenure, and insurance amount payable. This lets a bank price and bound lending differently for, say, a public-sector ministry versus a private company, or apply tighter tenure limits where employment terms are short, all without changing the underlying origination process. When a Direct Sales Executive selects a scheme at the start of an application, the platform surfaces that employer's specific parameters, and the calculators and application then operate strictly within them. The variation lives in configuration data held against the employer record, not in separate code paths.

Who maintains the allowance and deduction variables?

The bank maintains them. The affordability model is built on a configurable set of allowance types (House, Commuter, Hardship, Other) and deduction types (including PAYE, NSSF, NITA, NHIF, Provident/Pension, Sacco contributions, Sacco loans and their interest, bank loans, other loans, and reimbursements). The bank can add new variables and remove ones it no longer uses, so the model can keep pace with changes in statutory deductions or in the payslip conventions of particular employers without waiting for a software release. These types are owned by the EmployerScheme service, which keeps the affordability variable set in one authoritative, auditable place rather than scattered across the origination flow.

What is an employer code and why does it matter for disbursement?

For government schemes, the employer code is the identifier that links a scheme to its arrangement in IPPD, the government payroll deduction system. For ministries and public-sector employers, the Scheme Loan Administrator generates the deduction data delivered to IPPD, which confirms capacity and books the deduction; the employer code is what ties the loan to that booking. It matters at disbursement because a missing code stops the process: where an employer code is absent, Credit Admin must liaise with the Scheme Loan Administrator or the Scheme Relationship Manager before the loan can be disbursed. It is a clear example of how a gap in scheme configuration directly blocks the operational stages downstream.

Employer scheme onboarding is the foundation the rest of workplace lending stands on — get the approved list, the parameters and the payslip variables right, and origination runs within rails you have set deliberately. To see how the configuration layer fits into the full platform, visit the Workplace Banking product page, or book a demo to walk through scheme setup and affordability with our team.