Home Registra Services About Nasaon Chinasa Joyce Onwe Blog Get Started
Registra — by Nasaon

The system that runs
an institution's records

Admissions, student information and computer-based examinations. Built for tertiary institutions anywhere — configured to your regulations, deployed on your own server, and running today at universities in Nigeria.

Registra — university operations portal covering admissions, student records, fee management, computer-based examinations, results, transcripts and clearance
What it is

Three systems
that talk to each other

Most institutions buy admissions from one vendor, records from another and examinations from a third, then spend every session moving data between them by hand. Registra is one chain.

Admissions

Candidates apply, pay and upload credentials. Officers assess against your cut-off and decide. Admitted candidates export straight into the student system.

Student information

Enrollment, matriculation, course registration, fees, results, transcripts and clearance — with a seat for every officer who touches a record.

Computer-based examinations

Invigilator-issued codes, hall-controlled sittings, and sessions that resume where a candidate stopped when power or network drops.

Admissions

An assessment desk,
not a form

The officer keeps the judgement. The system does the arithmetic, gathers the documents and makes sure the list that leaves your office is the list that arrives.

Aggregate computed as you go

JAMB score over eight plus O'level points, against a cut-off you configure. The number appears while the officer enters grades.

One consolidated document

Results, certificates and photographs merged into a single paginated file per candidate. No opening six attachments to assess one application.

Verified against the JAMB list

Upload the master list and candidates are checked against it. Declared grades stay flagged as declared until an officer confirms them against the certificate.

Return for correction

A candidate with a bad upload goes back for a fix instead of being rejected. Registries need the middle option, and most systems do not have one.

Edit-locked export lists

The admitted list and the register export as password-protected Excel, so a file cannot be quietly altered after it leaves the office.

Exports that go somewhere

A CSV that imports into the student system, a payments file for the bursary, and a Workspace export that creates student accounts in bulk.

Results

Every role
has its own seat

Lecturers, Exam Officers, HODs and Deans each get access scoped to what they are responsible for. A result moves between them inside the system — never as a spreadsheet emailed between offices, which is where institutions lose control of a result.

How a result reaches a student

Departmental board, faculty board and Senate approval happen exactly as they always have. Registra takes over the moment the approved result has to move — and makes sure the version students see is the version that was approved.

How a result reaches a student: board and Senate approval, then lecturer upload and signing, exam officer verification against the Senate-approved record, HOD and dean signatures, exam officer publication to the student portal and archive, and transcripts generated from that archive.
  1. Lecturer

    Uploads the approved result and signs it with their signature and a private signing PIN.

  2. Exam Officer

    Checks it against the Senate-approved record. Verifies it, or queries it back with reasons.

  3. HOD

    Signs, or rejects. A rejection returns to the Exam Officer, never straight to the lecturer.

  4. Dean

    Signs, or rejects the same way. Two signatures, two independent checks.

  5. Exam Officer

    Publishes. The result reaches the student portal and archives to Exams & Records.

  6. Transcripts

    Generated from that archive — from the same signed record, not a separate file.

A queried result returns to the lecturer with the reason attached, is corrected, and re-enters the chain. Nothing is deleted, nothing bypasses a step, and an audit log records who did what and when.

The rest of the system

Everything the registry
actually does

Your academic structure

Faculties, departments, programmes, courses, units and requirement areas modelled as they exist on paper, so registration and grading follow your own regulations.

Fees, scheduled and confirmed

The bursary schedules a fee and publishes it to students. Students pay through their portal, the payment lands on the bursary dashboard, and the receipt goes live in the student’s portal the moment the bursary confirms it. The institution sets its own installment policy — the percentage split, and who it applies to, from a single student to an entire level — and a ledger in the student portal shows what has been paid, what is outstanding, and what the institution owes back. Remita and Paystack in Nigeria, other gateways on request.

Enrollment and registration

Admitted candidates enroll, receive matric numbers and register for courses by session and semester, with student lookup for anyone who needs a record quickly.

Computer-based examinations

Candidates join with an exam code, candidate number and PIN issued by the invigilator. A dropped session resumes where it stopped, with answers already submitted preserved.

Transcripts and archive

Past sessions stay in the Exams & Records archive. Transcripts generate from that archive, and a document can be verified afterwards rather than taken on trust.

Audit log

Who changed a score, who signed it, who published it, and when. When a result is disputed, the question has an answer.

How it is deployed

Your server.
Your data.

Registra is not a platform you rent space on. Every institution gets its own build, on its own infrastructure, under its own domain — and we run it for you if you want us to.

On your infrastructure

The system runs on your server, under your subdomains. Student records, results and payment data never sit on a vendor's platform.

Built for your regulations

Cut-off marks, grading, approval chains and clearance steps configured to your academic regulations — not a generic template you have to bend your rules around.

Managed, if you want it

We can take on updates, backups, monitoring and support. Or hand the system to your ICT unit and step back. It stays yours either way.

Getting started

One module first,
not a platform plan

  1. We look at what you have

    Existing systems, where records live now, and which processes are still on paper.

  2. We scope one module

    Usually admissions, because it has a deadline and the pain is measurable. Not a three-year rollout.

  3. We build and deploy on your server

    Your subdomain, your branding, your database — configured to your regulations.

  4. We stay through the first cycle

    The first admissions run or exam diet is when problems surface. That is when we are most available.

See it running before you decide anything. Request a walkthrough with your own registry team.

Request a demo

Tell us what you are
trying to solve

An admissions cycle coming up, results still moving on paper, or transcripts taking weeks — say what it is and we will tell you honestly whether we can help.