Skip to main content
KreupAI Logo
RESOURCE GUIDEApplies to: IndiaCampusOS
KB-037

NEP 2020 and the Academic Bank of Credits: What Your ERP Must Now Store and Transmit

The ABC identifiers your SIS must reconcile, the credit fields it must carry, when each record is transmitted, and why a posted credit is not casually editable.

Author:Bosco Sabu John
12 min read

NEP 2020 and the Academic Bank of Credits: What Your ERP Must Now Store and Transmit

The Academic Bank of Credits holds credits transmitted by the awarding institution against a student's twelve-digit APAAR identifier. Your ERP must store that identifier, a credit record per course that reconciles to the Curriculum and Credit Framework, and an award event, because once credits are redeemed they cannot be reused.

This is for the registrar, the examination controller and the person who owns the student information system in an Indian higher education institution. Most published material on the Academic Bank of Credits explains the policy. This explains what the policy does to your database: which fields must exist, which identifiers must reconcile, what breaks when a name differs across three systems, and why a posted credit is not a row you can quietly update.

What the ABC is, and the regulation behind it

The Academic Bank of Credits is defined in the UGC (Establishment and Operation of Academic Bank of Credits in Higher Education) Regulations, 2021 as a digital entity established by the Commission to let students hold academic accounts through a formal system of credit recognition, credit accumulation, credit transfer and credit redemption. Those four words are not marketing. Each is a defined term with a different effect on your data.

  • Credit recognition is credits earned at a registered institution and transferred directly to the ABC by that institution.
  • Credit accumulation is the facility in the student's account that consolidates credits earned across institutions.
  • Credit transfer is the mechanism by which registered institutions receive or provide credits to individual academic bank accounts.
  • Credit redemption is commuting accrued credits to satisfy the credit requirement for an award.

One clause governs the whole integration design. The regulations provide that the ABC shall not accept any document pertaining to course credits directly from students, and shall treat such documents as valid only when transmitted by the registered institution awarding the credits. The student is the account holder, not the depositor, which is why the reconciliation burden sits with your ERP.

The Press Information Bureau factsheet on ABC and APAAR puts the mechanics plainly: award granting institutions in a capacity to issue certificates, degrees and marksheets upload credit data directly to the NAD-ABC portal against each student's APAAR ID, with the National Academic Depository as the storage layer. As of 2 July 2026 it records 2,899 registered higher education institutions, 4.79 crore APAAR IDs created and mapped, and 9.78 crore credit records mapped to learner identifiers.

[NEEDS SOURCE: the UGC ABC Regulations 2021 and the First Amendment as published in the Gazette of India or on ugc.gov.in. The regulation text quoted here is taken from a legal database reproduction, and the eligibility criteria for institutional registration in the original Regulation 7 (NAAC grade, NBA score, NIRF and world ranking thresholds) are reported to have been widened by amendment.]

ABC ID, APAAR and DigiLocker: one number, three systems

Treat these as three layers of one identity rather than three identifiers.

APAAR is the Automated Permanent Academic Account Registry identifier, a twelve-digit code issued under the Ministry of Education's One Nation One Student ID initiative, and the Ministry's material describes it as the identifier the ABC uses. In higher education practice the ABC ID and the APAAR ID are the same number. DigiLocker is the account layer and the delivery channel: the APAAR ID is pushed into the student's DigiLocker account, and awards published through the National Academic Depository appear there. NAD is the depository itself; the PIB release on the CSC rollout describes ABC as mirroring the NAD model, with institutions retaining authority over credit redemption and issuance of certificates.

The failure mode is generation, not usage. The APAAR FAQ states that where ID generation fails, the error indicates a demographic data mismatch between Aadhaar and academic records, which must be corrected and resubmitted. Your admissions record is load-bearing: a student whose SIS name carries an initial where Aadhaar carries an expansion will not get an ID, and no credit can be posted for a student without one.

The credit data model

Three rules shape the schema more than anything else.

Credits have a shelf life. The Regulations set validity at not exceeding seven years, as specified by the awarding institution and subject to acceptance by the receiving institution. UGC's Guidelines for Multiple Entry and Exit repeat the seven-year maximum, and the SOP for operationalising the National Credit Framework adds that after seven years re-entry depends on validation or revalidation of prior learning outcomes. A credit record therefore needs an award date and an explicit expiry, and your ERP must answer which of a student's credits are still live on a given date, not just how many they hold.

Redemption consumes credits. The Ministry of Education's ABC guidance states that on collecting a certificate, diploma or degree, all credits earned until then stand debited and deleted from the account. The PIB factsheet says the same from the other end: once redeemed, credits cannot be reused for transfer or redemption. A credit is a balance with a lifecycle, so the data model needs a state on each credit record rather than a flag on the student.

Provenance decides eligibility. The Regulations require a student to earn at least fifty per cent of the credits from the institution awarding the degree, so every credit record must carry its awarding institution and the eligibility calculation must partition by source rather than sum.

Multiple entry and exit is what makes all three live at once. The UGC guidelines set award levels against credit bands, and the Curriculum and Credit Framework for Undergraduate Programmes sets the working numbers for a four-year programme: 40 credits plus 4 credits of work-based vocational courses for a UG certificate after one year, 80 credits plus 4 credits of skill-based vocational courses for a UG diploma after two years, 120 credits for a three-year degree, and 160 credits for a four-year honours degree, with re-entry permitted within three years and completion within a maximum of seven.

That extra 4 credits on exit is the detail that breaks naive implementations. A student exiting at the end of year one does not simply cash in the 40 credits already on the record. There is an additional vocational requirement attached to the exit itself, which means your ERP needs a concept of an exit award package, not just a running total.

Mapping a programme to the Curriculum and Credit Framework

The framework defines a credit as one hour of lecture or tutorial per week over a fifteen-week semester, two hours per week of practicum or lab work, or two hours per week for seminars, internships and studio activities. The NCrF SOP expresses the same relationship as roughly 15 hours of theory, 30 hours of lab work or 45 hours of experiential learning per semester.

Course categories are not decoration. The framework sets minimum credits by category, and an award is checked against the category minima as well as the total.

CategoryThree-year UGFour-year UG
Major (core)6080
Minor stream2432
Multidisciplinary99
Ability Enhancement Courses (AEC)88
Skill Enhancement Courses (SEC)99
Value Added Courses (VAC)6 to 86 to 8
Summer internship2 to 42 to 4
Research project or dissertationnot applicable12
Total120160

The ERP consequence is that a course master needs a framework category on every course, and the category has to be an enumerated value rather than free text, because eligibility is computed against it. Institutions that carried a legacy "elective / core" flag into the new structure find that they cannot answer whether a student has met the multidisciplinary minimum without a manual audit.

[NEEDS SOURCE: whether the framework category of a course must itself be transmitted to the ABC alongside the credit value, and the enumerated list the portal accepts.]

What must be transmitted, and when

The obligation is not a single annual upload. Different objects originate in different parts of the institution and move on different triggers.

Data objectWhere it originatesWhat it must carryTransmission trigger
APAAR / ABC IDStudent, via DigiLocker, using Aadhaar-verified demographicsTwelve-digit ID, verified against name and date of birthAt admission. UGC's July 2024 notification directs institutions to make the ABC ID a mandatory field in admission and examination forms
Institution registrationRegistrar, on the NAD-DigiLocker portalInstitution identity, account owner name, designation, mobile, official emailOnce, before any credit can be posted, with a nodal officer and NAD/ABC cell named on the institution website
Student enrolment recordAdmissions and SISName matching Aadhaar, date of birth, programme, roll or registration number, APAAR IDOn admission, and again on any correction to name or ID
Course credit recordExamination or academic sectionCourse code and title, credit value, framework category, session or semester, result status, awarding institutionOn declaration of results for the session
Marksheet or grade sheetExamination sectionStudent identifiers, session, subject results, linked to APAAR IDOn publication. UGC has directed upload of academic records for an examination year by a stated deadline, after which the window closes
Exit or final awardRegistrarAward level, date, total credits redeemedOn conferral, at which point the redeemed credits are debited from the account
Credit acceptance from another institutionAcademic council or equivalentSource institution, credit value, validity remaining, mapped course equivalenceOn admission by lateral entry or on approval of transfer credits

Two timing facts to hold on to. Credits obtained by undertaking courses in registered institutions during or after the academic year 2021-22 are the ones eligible to move through the system, so retrospective loading has a floor. And the upload window for an examination year is finite: UGC's directive on academic records for examination year 2025 set a June 30 cut-off, with corrections after that point permitted only in exceptional cases under NAD-ABC procedures.

[NEEDS SOURCE: the exact text, reference number and date of the UGC and Ministry of Education directives setting the upload deadlines for academic records and credit data, and the current deadline for the most recent examination year, from ugc.gov.in.]

Onboarding and first transmission, in order

  1. Fix the student master first. Name as per Aadhaar, date of birth, and one authoritative roll or registration number per student. Everything downstream fails on this and nothing downstream fixes it.
  2. Register the institution on the NAD-DigiLocker portal. The account owner is a named person with designation, mobile and official email, so choose someone who will still be in post in three years.
  3. Constitute the ABC/NAD cell and name a nodal officer, publishing the contact details on the institution website as UGC's notification directs.
  4. Add APAAR/ABC ID as a mandatory field in admission forms, examination forms and, where possible, the student identity card.
  5. Run a bulk identity reconciliation before generating a single ID. Compare SIS name against Aadhaar-form name for every enrolled student and resolve initials, expansions, surname order and transliteration variants. Expect the longest task in the project.
  6. Generate or collect APAAR IDs at admission, with assistance at the counter rather than by email instruction. An ID collected later is an ID collected for eighty per cent of the cohort.
  7. Tag every course with its framework category and credit value, and freeze the mapping for the session. A category changed mid-session invalidates the eligibility calculation for everyone on that course.
  8. Map result statuses to a credit-earned decision. Only a pass earns credits. Decide explicitly how backlogs, supplementary results, audit courses and withdrawals are represented, because each is a row that either does or does not get transmitted.
  9. Produce the first credit file for one completed session, not the full history, and validate it against the portal's format check before attempting volume.
  10. Reconcile the acknowledgement student by student. A file accepted at format level can still contain students whose ID did not resolve. Treat unmatched students as a work queue.
  11. Load retrospective sessions in reverse chronological order back to the 2021-22 floor, so recently graduated cohorts are complete first.
  12. Post the award event on conferral and record in your own database that the underlying credits are redeemed. Without this, your ERP and the ABC disagree the moment a student re-enters.
  13. Close the loop annually against the published deadline for the examination year, keeping acknowledgement references with the examination records.

Identity matching, retrospective credits, and correcting a posted credit

Identity matching is the whole project in one problem. Three systems hold a version of the student: the SIS holds what admissions typed, the ABC holds what APAAR generation resolved from Aadhaar, and DigiLocker holds what NAD published. If the SIS says "R. Sharma", Aadhaar says "Rahul Sharma" and the marksheet says "Rahul Kumar Sharma", generation may fail outright, or the credit posts to a student who cannot see it. The fix is not a fuzzy match at transmission time. It is a stored, verified APAAR ID on the student record, populated once at admission and treated as the key thereafter, with the name used only for display.

Retrospective credits face two constraints: eligibility begins with the academic year 2021-22, and the students concerned may have left, which means chasing IDs from alumni who have no reason to respond. Sequence the backlog by cohort recency and accept that the oldest eligible sessions will be incomplete.

Corrections and revocation are where the ERP assumption usually breaks. A credit posted to the ABC is not a row in your database that you own. UGC's direction on academic records states that corrections after the upload window are permitted only in exceptional cases under NAD-ABC procedures. And once credits have been redeemed against an award they are debited and cannot be reused. So a data entry error corrected six months later is not an update, it is a request. Build for that: hold a transmission log per credit record with the payload sent, the timestamp, the acknowledgement, and the current state (pending, posted, redeemed, correction requested). Without that log you cannot prove what you sent, which is what any correction request will turn on.

[NEEDS SOURCE: the published NAD-ABC procedure for correcting or revoking a credit record after transmission, including who may raise it, the approval path and the effect on a redeemed credit.]

Where teams get this wrong

Treating the ABC ID as a profile field. It is a foreign key. If it is nullable in your schema and nobody enforces it, you will discover at the end of a session that a fifth of the cohort cannot be transmitted.

Summing credits without partitioning by institution. The fifty per cent rule means an award check that only totals credits will pass students who are not eligible.

Modelling credits as a running total on the student. Redemption debits and deletes credits at award. A total cannot represent that. A ledger of credit records with states can.

Ignoring the exit award package. The additional vocational credits required at a one-year or two-year exit are part of the award condition, not a bonus. A student with 40 credits and no vocational component is not eligible for the certificate.

Leaving course categories as free text, when the framework minima per category are what gets checked, and assuming the upload window stays open. It closes for the examination year, and corrections afterwards are exceptional, so reconciliation has to happen inside the window rather than when someone notices.

What to automate, and what not to

Automate the identity reconciliation, the credit record construction, the transmission log and the state machine. Comparing SIS names against Aadhaar-form names across a cohort, blocking a credit record whose student has no verified APAAR ID, deriving the credit value and framework category from the course master rather than from a spreadsheet, and tracking each credit through pending, posted and redeemed are deterministic and belong in software. So does the eligibility calculation against category minima and the fifty per cent provenance rule, which is arithmetic no registrar should be doing by hand at award time.

Do not automate the academic judgement, and do not automate transmission of anything that has not been approved. Whether a credit earned elsewhere is equivalent to a course in your programme, whether a student's prior learning should be revalidated after seven years, and whether a correction request is justified are decisions for an academic body with a minute recording them. A system that pushes credits the moment results are entered will eventually push a result that was later revised. Post on approval of results, not on entry of results, and keep the approver named.

Where a system helps

The work that actually consumes a registrar's time is not the upload. It is holding one verified identity per student across admissions, examinations and the depository, and being able to say what state every credit is in. CampusOS holds the APAAR ID as a validated attribute of the student record rather than a text field, carries the framework category and credit value on the course master so credit records are derived rather than typed, and keeps a transmission log per credit with its acknowledgement and state so a correction request starts from evidence. Award eligibility is computed against category minima and the awarding-institution share rather than a total. See CampusOS for higher education.

FAQ

Is the ABC ID the same as the APAAR ID? In higher education they are the same twelve-digit identifier. The Ministry of Education describes APAAR as the identifier the ABC uses, and government material refers to the ABC ID and APAAR ID interchangeably for higher education students. The ID is generated against Aadhaar-verified demographics and delivered into the student's DigiLocker. [NEEDS SOURCE: a UGC or Ministry of Education statement confirming explicitly that the ABC ID and APAAR ID are one identifier for higher education students.]

Can a student deposit their own credits or upload a transcript? No. The Regulations provide that the ABC shall not accept any document pertaining to course credits directly from students, and treats such documents as valid only when transmitted by the registered institution that awarded the credits.

How long do credits last? Not exceeding seven years, as specified by the awarding institution and subject to acceptance by the receiving institution. After seven years, the NCrF SOP describes re-entry as depending on validation or revalidation of prior learning outcomes rather than on the original credits.

What happens to credits when a degree is awarded? They are debited and deleted from the account, and the PIB factsheet states that once redeemed credits cannot be reused for transfer or redemption. Your ERP should mark them redeemed against the award rather than leave them available.

Which academic years can we load retrospectively? Credits obtained by undertaking courses in registered institutions during or after the academic year 2021-22 are the ones eligible to move through the system. Earlier sessions sit outside it.

Related reading: What Is a Student Information System (SIS)? Scope and How It Differs From an LMS (KB-033), and Student Lifecycle Data in Saudi Institutions: Admission to Alumni, One Record (KB-036).

Sources