This section outlines the changes in the NSPA Scholarship Program Data Standard v1.0 release, the first formal release of the standard.

Despite the v1.0 designation, the data standard has been through five previous drafts (pre-release versions 1.0a through 1.0e) and has been in continuous production use since 2018. This document outlines the changes made since v1.0d, the most recent version used in production data exchanges.

The NSPA and Dell Foundation teams thank participants in the NSPA Data Standards Initiative, and all the NSPA Members, implementers, technologists, and subject matter experts who provided their time and brainpower to assist with the development of the standard.

Overview

The information that follows describes changes in the latest version of the NSPA Scholarship Program Data Standard.

The changes include:

Detail on each change follows.

Major Changes & Additions to the Data Model

The structure and contents of the NSPA Scholarship Program Data Standard are defined by its data model. This section describes the more notable changes to the data model.

Added a Metadata Entity (DATA-15)

Version 1.0 adds new Metadata information to the Scholarship Program entity.

A shared aspect of these elements is that their values are usually not directly entered by humans. The values are typically those that are automatically updated (such as a Last-Modified On value) or are values that are calculated (such as a general “Type of Program”) or looked up and provided for convenience (such as an entire hierarchy for coded hierarchical values). 

Change Detail

The change adds a new Metadata entity, with new elements to convey the following information: 

• Categorizations (e.g., shorthand program types such as "First-Generation" or "STEM" that are often tightly bound to one or more specific eligibility criteria). 

• The full path of hierarchical eligibility criteria codings (e.g., a program with an Activity of "Downhill Skiing" might have a "full path" entry of "Activity > Sports > Skiing > Downhill Skiing").

• Created By. An element named CreatedBy defined as a short string. The organization that initiated the record. By convention, the organization initiating this record within the NSPA Exchange ecosystem, but may contain agreed-upon values for any data exchange scenario.

• Created On. An element named CreatedOn defined as a datetime. The creation date for the record. If a CreatedBy value is present, should indicate the date the record was created in the originating system. Most date-related elements in the standard are just that: date-only data fields. This element and the following Last Modified On element are defined as date + time to support data update use cases where the precise time that an event happened on the record is important.

• Last Modified On. An element named LastModifiedOn defined as a datetime.

• Lists. An element named Lists defined as an array or short string values denoting lists on which the program appears (e.g., “Programs for Hispanic Americans” or “Weirdly Specific Programs” or “Programs for Families of Armed Servicemembers“). Common list names and definitions are maintained by the NSPA, but this field may be used for ad-hoc purposes to support information exchange. Typicaly, the sender of data defines the lists to be used.

• Eligibility Criteria Hierarchies. An element named EligibilityCriteriaHierarchies defined as an array of medium-length string values.

In addition, the following element has been refactored from the scholarship program record to the new Metadata entity:

• Program Categories. This element was bolted onto the main program detail in v1.0d, but conveys information that’s best thought of as metadata. With the addition of the Metadata entity, we’ve refactored the ProgramCategories array to the Metadata entity.

An example XML snippet follows, with the new Metadata entity starting on line 2:

Added Support for Multiple Eligibility Criteria Sets on a Single Record (DATA-63) (New 9/27)

A small but substantial number of programs have complex program criteria sets. For example, a program eligibility criteria might specify that students in one county are required to have a specific GPA and go into a specific field of study, while students in another county have no academic requirements and must simply attend a specific school.

Previous versions of the NSPA Data Standard did not have a way to encode complex sets of (Criteria A AND Criteria B) OR (Criteria C AND Criteria D) requirements. As an aside, the NSPA team has spoken with multiple maintainers of scholarship data systems; we lament the problem but haven't found a simple or obvious solution. In other words, the problem is common enough to be worth solving, even at the cost of some additional complexity.

This change provides support for expressing these combinations of criteria.

Change Detail

The change itself is relatively straightforward: the Eligibility Criteria entity cardinality was changed from 0..1 to 0..n. That is, instead of allowing a single set of criteria, a program may contain multiple sets on a single record — each of which can be considered separately.

The change is also straightforward technically. For example, in the XML schema, the declaration of the EligibilityCriteria went from:

<xs:element name="EligibilityCriteria" type="spi:EligibilityCriteria" minOccurs="0">

to:

<xs:element name="EligibilityCriteria" type="spi:EligibilityCriteria" minOccurs="0" maxOccurs="unbounded">

The JSON Schema change is analogously simple.

Note that the Eligibility Criteria data in previous versions will still validate, making migration to handle multiple criteria sets as straightforward as possible for current implementers.

Usage Notes

• Implementing systems should make each individual EligibilityCriteria a complete logical set. We strongly believe this will be the easiest to implement for data exchange and data use scenarios.

  • Implementers may elect to use some other scheme (e.g., having multiple sets only show “differences” between a baseline set). However, the meaning will be less clear, and will require custom logic to determine which set represents the “base” and which represents “differences from the base.”

  • So, again, we strongly encourage implementers to make each EligibilityCriteria a complete, logical set.

Added Parent Profession Eligibility Criteria (DATA-61) (New 9/27)

Previous versions of the NSPA Data Standard have an eligibility criterion to indicate a scholar’s own profession. However, field use suggests that the parent's profession is a common criterion used by many programs.

Change Detail

• Addition of a ParentProfession criterion, allowing for selection from a list of professions.

• The new Parent Profession criterion leverages the existing Profession definition, which is the same structure used to indicate a scholar’s profession. That being the case, new the Parent Profession allows for selection from the same NSPA Profession List used for scholars, the inclusion of a Standard Occupational Classification (SOC code), plus an indicator of whether the profession is a current profession.

Usage Notes

Added Unforeseen Event Eligibility Criteria (DATA-24)

In the not-too-distant past, the U.S. scholarship space has offered programs for students affected by major events, often natural disasters. (Perhaps there is a program for $1,000,000+ lottery winners. If so, we're not aware of it.) Examples include 9/11, Hurricanes Katrina and Harvey, Covid-19, and others. This addition supports a coded way to identify funding (or other programmatic support) for scholars who have been impacted by recent events.

Change Detail

Changes include:

• Addition of an UnforeseenEvent criteria, allowing for a selection from a list of events. Allows an “Other” value and Includes an UnforeseenEventOther element, to support the exchange of data related to a very recent event.

• The creation and publication of a new NSPA Unforeseen Event List. This is a “living” list, initially populated with relatively recent events and disasters for which the NSPA data teams have observed records for scholarships and financial aid.

The Unforeseen Event eligibility criteria are illustrated in the JSON data snippet shown below on lines 9 and 10, showing a program for the benefit of victims of the fictional Hurricane Steve.

Added Study Abroad Eligibility Criteria (DATA-30)

This change improves support for study-abroad programs, and programs explicitly for international students. (“Abroad,” generally speaking, is currently defined as “programs available to or explicitly serving residents of countries other than the program provider’s country.”)

In previous versions, the data model had a general "study abroad" indicator. But, it wasn’t otherwise apparent which programs were explicitly “for” students who wish to study abroad. This change more clearly indicates scholarships for the study-abroad crowd.

Change Detail

The core changes include:

• Created a new Eligibility Criteria named StudyAbroad.

• The Study Abroad contains one or more StudyAbroadDestination entities to indicate the host or destination country for the program, along with a state or province, county, and city, if applicable.

This change resulted in a light refactoring:

• The new Study Abroad Destination is identical in structure to the current Eligibility Location in that it will indicate a country along with a state or province, county, and city.

• Since this is identical to the current Eligibility Location structure, we refactored EligibilityLocation into a new general-purpose Location criterion and used that for both the previous Location Criteria and the new Study Abroad Destination criteria.

The code snippet below shows an example usage as JSON data. In this example, the destination country (the UK) is indicated in the StudyAbroadDestination. Note that the Location criterion in this example is also present, which indicates that the program is designed to serve students currently residing in the United States.

Usage Notes

• The destination or host country is indicated in the Study Abroad Destination. The specific country of origin requirements — if any — are indicated in the Location Eligibility Criteria.

• The Study Abroad indicator is reserved for truly international studies. It is not intended for use to, for example, indicate programs in another state within the same country.

• The Study Abroad Destination should always contain a country. Optionally, it may contain a state or province, county, and city, if the program has a specific location within a country.

• If the program is for a particular institution in the destination country, then the Study Abroad Destination can be assumed to share the specific county or city in which the institution resides, semantically speaking. However, data exchange implementers may opt to simply list the country and provide additional location details with the institution or institutions associated with the program.

Added Full-Time and Part-Time Enrollment Eligibility Criteria (DATA-49)(New 9/28)

Many programs specify whether a student must attend school full- or part-time. In particular, programs serving nontraditional, returning, or working students often explicitly allow part-time attendance to accommodate the needs of those students.

This change adds an eligibility criterion to indicate enrollment.

Change Detail

• Added a new EnrollmentStatus entity to the collection of eligibility criteria.

• Added a new EnrollmentStatusCriteriaList enumeration to indicate the program requirements. Values include:

  • Full-Time or Part-Time.

  • Full-Time Only.

  • Part-Time Only.

Usage Notes

• A reasonable person might wonder why a Full-Time or Part-Time value is included, which at first glance appears semantically equivalent to “no requirement” or “any enrollment status is eligible for an award.” However, the default assumption in many contexts is full-time attendance, so it’s useful to have an explicit statement that the program allows part-time attendance.

Added Award Use Location to Eligibility Criteria (DATA-56) (New 9/28)

Previous versions of the NSPA Data Standard Location eligibility coding had an ambiguity. In previous versions, Location generally indicates that a student must be "from" a particular area. However, some programs specifically don't consider where a student currently lives, rather the limitation is on where the student plans to attend school (or otherwise leverage the award).

This hasn't been a major issue since specific locations are frequently expressed by a specific school or school system, which is in the model. However, field use suggests this is often a relevant criterion, particularly for matching algorithms that connect scholars with opportunities.

This change adds an Award Use Location criteria to the Eligibility Criteria coding.

Change Detail

The change is simple:

• Added a new AwardUseLocations entity to the Eligibility Criteria. Award Use Locations are optional and can contain multiple entries.

• The new Award Use Locations entity uses the existing Location entity, so no additional changes were required.

The following simple example record illustrates the difference between the new Award Use Locations and the existing Locations Eligibility Criteria. In the following example, the program is “for” any student currently living in Austin, Texas — but the award may be used at any Texas institution.

Added Elements for "Scam" and “Listing Flags” (DATA-29, DATA-45) (Updated 9/28)

Some implementers, including NSPA, have a few types of programs that it wishes to have in a datastore, but that have properties making the program unsuitable for certain uses or specific purposes.

Examples include "Scams" (which can be used for a blacklist) and concerning factors that include "Application Fee" (i.e., programs that charge applicants to apply, which the NSPA community feels is not awesome), “Insecure Application” (i.e., for online applications that are not secure, or applications that require scholars to send Social Security Numbers over email, or similar).

Additionally, some valid programs have characteristics that exclude them from listing services. For example, applications that contain inconsistencies, applications that require a product purchase, or applications that require referrals or others' contact information are often excluded from listing services.

We’re taking care regarding the nomenclature. Not all “concerning” characteristics are necessarily scams or even unambiguously negative in all contexts.

This set of changes adds support for several new data points that indicate concerning or noteworthy aspects of a program and its program application.

Change Detail

Changes include:

• Added an optional NoteworthyApplicationCharacteristics entity to contain various issues that raise some level of concern.

• Added a RequiresApplicationFee Boolean and an ApplicationFeeAmount decimal.

• Added a new ApplicationAppearsInsecure Boolean. Indicates that an online application is not sent over an encrypted connection, or a downloadable form with personal information must be sent via email with no provisions for data protection, or similar security and privacy issues.

• Added a ListingFlags entity, containing an array of noteworthy listing characteristics. These flags do not necessarily indicate that a program is problematic, simply that it has characteristics that may exclude it from being listed on certain services. Contrast this with the Legitimacy Concern entity discussed next, which has characteristics that most providers would see as unambiguously negative.

• Added a LegitimacyConcern entity, containing a Boolean HasLegitimacyConcerns flag, a LegitimacyConcernType array of possible concerns (e.g., No Contact Information, No Evidence of Past Winners), and a LegitimacyConcernNotes text element to provide any details.

The NoteworthyApplicationCharacteristics eligibility criteria are illustrated in the JSON data snippet shown below on lines 12 through 32, showing a program with many, many questionable characteristics.

Usage Notes

• The NoteworthyApplicationCharacteristics entity is optional. Note that some implementers may choose never to emit or exchange records that have such “Noteworthy” characteristics. (For example, the NSPA Exchange intends to record questionable applications and programs for its own tracking and reporting — but would generally not share any programs with legitimacy concerns through its data services.)

• Some elements are not necessarily “bad” or problematic for all parties. For example, ApplicationAppearsInsecure indicates that an applicant’s data is not safe — but that doesn’t necessarily indicate nefarious intent. Similarly, an application fee could (hypothetically) be associated with a legitimate program, but some listing services have a firm rule to omit any program that requires a fee.

Added College Type and College Category Criteria (DATA-58, DATA-59, DATA-60) (New 9/27)

Many programs have criteria related to the type of institution (e.g., requiring attendance at a 2-year college or 4-year university), or a category of college (e.g., requiring attendance at an HBCU or a Hispanic-serving Institution).

Previous versions of the NSPA Data Standard required enumeration of every specific institution making up a type or category. In the case of HBCUs, for example, that would require the coding of 107 specific colleges (as of Q3-2021). This led to the coding of many, many colleges on a single record — and typically requires updates every few scholarship program cycles.

This change adds a College Type and College Category criteria to the data model and using the new fields in the eligibility criteria for a few college attendance-related elements.

Change Detail

• Added a new CollegeType element, and a new companion NSPA College Type List. College Type includes properties of the institution such as 4-Year College, 2-Year College, Trade School, Technical School, and so forth.

• Added a new CollegeCategory element, and a new companion NSPA College Category List. The College Category typically indicates a population served such as HBCU, Tribal College, Hispanic-Serving Institution, and similar. Many values take their definitions from the list of so-named Minority Serving Institutions (MSIs) defined by the U.S. Department of Education. (In fact, all 8 MSIs are represented in the NSPA College Category List.)

• Applied the College Type and College Category elements to the CollegePlan, CurrentSchool, and Graduation criteria.

• In all applications, the criteria are 0..n (that is, the data is optional, and can contain one or more values).

The following JSON record shows the added elements in the College Plan entity (lines 14–20):

Usage Notes

• As noted, a simple CollegeCategory of HBCU may represent 100+ specific colleges. Implementers may, optionally, include all specific schools meeting the College Type and/or College Category criteria in data exchange scenarios for convenience or clarity.

Improved Support for International Programs (DATA-27)

Many key partners have programs spanning the U.S. and Canada. This change (a) improves international support generally, and (b) adds specific support for the Canadian scholarship system.

Examples include adding citizenship statuses applicable in Canada, standardized test scores & grading systems, and more.

The changes in this version do not provide complete international support, but they do provide foundational elements and establish design patterns that we can build on over time.

Change Detail

A summary of changes, which are sprinkled throughout the model:

• A simple refinement to the definition of an existing data element. The Country value in the Location Eligibility Criteria will define the country context. Implementers (such as the NSPA Exchange) who maintain data systems that cross borders will include a country value (primarily, e.g., “US”, “CA”), on every record to ensure the context is clear, and that programs for the benefit of scholars in that country are easily found, segmented, and so forth.

• Added an EICode element to the existing School entity to contain the 4-digit code (e.g., AJAF, GPAB, LUAA) assigned to designated educational institutions. See the excellent documentation on Canada.ca here for a full definition and the current list of designated EIs.

• Refactored the CitizenshipStatuses eligibility criteria. Changed the data model from an enumeration based on USCitizenshipStatusValueList (which was, you may have guessed, U.S.-specific) into a text string. Defined the list of expected values by reference to a new Citizenship Status List. Removed the orphaned USCitizenshipStatusValueList enumeration from the schema.

• This change mirrors the Citizenship Status change noted above, technically. Refactored the AcademicEligibility criteria from a U.S.-centric enumeration into a text string. Defined the list of expected values by reference to a new Academic Criteria List. Removed the orphaned AcademicEligibilityCriteriaList.

Added a Descriptive Award Amount for Partial and Full Tuition (DATA-52) (New 9/28)

Previous versions of the NSPA Data Standard only support numeric award amounts. However, many programs have awards that cover full or partial tuition.

This change adds an indicator for awards that cover full and partial tuition.

Change Detail

• Added a new AwardAmountDescription element.

• Added a new AwardAmountDescriptionList enumeration. The list values contain:

  • Free Ride

  • Full Tuition

  • Partial Tuition

Line 8 of the following JSON snippet illustrates the use and placement of the new element:

Added a Selection Criteria text element (DATA-55) (New 9/27)

Many programs have award selection criteria, that is, the criteria by which program teams or award selection committees determine who receives an award from the pool of qualified applicants. As an unrealistically simple example: a merit-based program might have a minimum 3.2 GPA requirement to apply, but the selection process takes GPA into account and makes awards to those with the highest GPA.

This change adds a new text field to store a narrative version of the selection criteria.

Change Detail

The following XML snippet shows the new field in use:

Usage Notes

• The text field is a 4000-character LongString, similar to the existing Blurb and Eligibility Criteria Description elements.

• Similar to the Eligibility Criteria Description, the field may contain simple markdown characters, specifically characters for a bullet list, bold text, and italicized text. In the example above, each new line is preceded by a hyphen (“-”), which markdown libraries will translate to a bullet point.

Improved Future Enrollment Intentions, Current School Enrollment, and Alumni Support (DATA-2)

Previous versions of the data model had several related issues around college attendance, intentions, and graduation.

• In the eligibility criteria, the field named “College Attendance Criteria” would imply that a student is already attending a school. However, the previous definition actually meant “future college intentions” or “future plans.”

• Also in the eligibility criteria, the Graduation Status was a mix of requirement concepts like “graduating high school senior” (i.e., a future graduation) and “alumnus” (i.e., past graduation).

• There was no way to indicate that a student has a degree in a particular field of study.

• There was no way to indicate that a student has a degree from a particular institution.

• In the Graduation Status list itself, some statuses were in-progress statuses (primarily, e.g., "Graduating High School Senior"). However, this is semantically equivalent to having a current grade of "High School Senior." We want to avoid this kind of duplicate meaning where possible.

This change was a global update to clarify the purpose of existing elements, clean up or remove elements from the clunky “Graduation Status” list, and improve the support for Alumni requirements.

Change Detail

• Clarified the meaning of the current College Attendance Criteria by renaming it CollegePlans. Updated inline documentation.

• Refactored the current Graduation Status Criteria to focus on Alumni support thusly:

  • Clarified the meaning of the current Graduation Status Criteria entity by renaming it GraduationCriteria.

  • Renamed the general School entity in the Graduation Status Criteria to AlmaMater as a further way to make the “past graduation” meaning obvious.

  • Removed the clunky GraduationStatusList and replace it with the DegreeCriteriaList, which provides a straightforward way to note if applicants are required to have a particular degree.

  • Added a FieldOfStudy element to indicate that a degree in a particular field of study is required for applicant eligibility.

  • All elements are optional, all may contain multiple criteria, and all may be used singularly or in combination. For example, one can indicate solely that an applicant must have graduated from a school, or only that the student has a particular degree, or that a student must have graduated from a particular school, with a particular degree, in a particular field of study.

• Renamed the DegreeSeekingCriteriaList definition to DegreeCriteriaList to reflect its multipurpose use as a simple list of degrees.

• Removed the GraduationStatusList enumeration, which is unused after the above changes.

The newly reorganized Graduation eligibility criterion reflects the most significant change. The following JSON snippet shows example data for a Graduation eligibility criteria that leverages all available data elements:

In the example above, applicants are eligible if they:

1. Have a Bachelor’s Degree

2. …in English and Writing OR Film and Video Studies (i.e., the indicated CIP Codes)

3. …from U.C. Santa Cruz in sunny California

Added Element to Indicate a Program is Part of a List (DATA-38)

Previous versions of the data standard had multiple ways to categorize programs, including the Eligibility Criteria and the Program Category. However, there was no way to simply make a list of programs with a natural-language definition, or where human judgment is involved (e.g., “Unusual Scholarships” or "Scholarships for High School Students in California" or "Opportunities for Hispanic Americans" or "Essay Contests" or similar).

This change adds an element to indicate that a program is a member of a list. The NSPA publishes a defined set of lists and definitions. The list is flexible, allowing implementers to establish lists of their own. However, the recommended usage is that implementers use the NSPA-defined values where a conceptual match is present.

Change Detail

• This change was implemented in the new Metadata entity. See the Metadata discussion at DATA-15 above, which contains an example data snippet showing use.

• Added a new NSPA List of Lists, which defines the standard values.

Improvements to Logo File Treatment, Including Content Delivery Network Support (DATA-32)

Previous versions of the NSPA Scholarship Program Data Standard allowed for a small logo file to be included in the record (using Base 64 encoding).

The inclusion of the logo file is convenient for file-based transfer scenarios, and some API-based use cases. However, the increase in record size can cause performance issues for integration scenarios and high-traffic API usage. Implementers suggested that a URL reference would be useful — and would allow for API integrations to leverage a high-speed content delivery network suitable for image content.

In addition, the previous File Name element served as a proxy for the file type (e.g., the ".png" in "Organization-Logo-File.png" being the only hint that a logo is in PNG format). A more common pattern is to specify the file type using an enumeration or a MIME Type.

This change adds an element for a logo URL and another to hold the MIME type for the logo file.

Change Detail

Changes include:

• Added a LogoURL element. Content delivery network URLs can be long, so this is an sps:MediumString, which allows for a generous 512 characters.

• Added a MIMEType element. This allows for an explicit statement of file type such as “image/png”. By convention, file types (and thus the related MIME types) in the standard are limited to image/png, image/jpg, image/gif. But, the schema puts no technical limitation on the images conveyed, so data exchange implementers can use additional types by mutual agreement.

• Organized all logo-related elements into a new Object/Complex Type called Logo. Elsewhere in the design, we gather related elements into a single entity, and these additions indicate a similar pattern would keep the structure clean.

The following JSON data file snippets illustrate the previous version (lines 8 & 9) and the update (lines 21–26).

Additions to NSPA Lists (DATA-28)

The NSPA publishes several lists (a.k.a., value lists, vocabularies, descriptors, enumerations, etc.). Most are for types of things like activities where additions are frequent.

New List Overview

A few new lists were added for v1.0 release:

Academic Criteria

Previous versions of the standard had an enumeration baked into the Standard for Academic Criteria. In v1.0, the U.S.-centric list was ported to a flexible Academic Criteria list containing both U.S. and Canadian values, with metadata identifying the applicable context(s) for each entry. The current list is here.

Citizenship Status

Previous versions of the standard had an enumeration baked into the Standard for U.S. Citizenship Statuses. In v1.0, the U.S.-centric list was ported to a flexible Citizenship Status list containing both U.S. and Canadian values, with metadata identifying the applicable context(s) for each entry. The current list is here.

College Category

The new College Category List contains values that typically indicate the population served by an institution (e.g., HBCU, Hispanic-Serving Institution).

College Type

The new College Type List contains values about the academic and financial structure of an institution (e.g., 4-Year College, Technical School, Public, Private).

Legitimacy Concern

The v1.0 release data model adds an entity to track legitimacy concerns with a program. This new list indicates specific reasons for concern. The initial list is based on classic characteristics of concern (e.g., no contact information, no evidence of past winners, bogus program sponsor organizations). But, we expect to refine this list over time. The current list is here.

List

The new List of Lists (thusly named to prevent the unintentionally comical moniker “List List”) contains values for ad-hoc collections of programs. Some entries hint at properties that can be derived from data (e.g., New in 2021-2022, Programs for Hispanic-Americans). Others are curated lists (e.g., Major Programs in the U.S.).

Unforeseen Event

The v1.0 data model adds an eligibility criterion related to events, usually a natural disaster or another unfortunate happening. Semantically, the list of Events is driven by real-world occurrences, so this list is expected to change over time. The NSPA will populate the list with relatively recent events to set the hierarchy and general structure. The current list is here.

Change Summary for Existing Lists

• Activity List. Added several values.

• Affiliation Entity List. Added many, many values. Many were observed in NSPA Exchange data, with others introduced via imported data.

• College Readiness Program List. Added many new programs. Some light categorization and grouping. Improved synonyms.

• Condition List. Added many new conditions. Improved organization.

• Demographic Criteria List. Added many new items and categories.

• Interest List. Added many new interests, primarily from observed programs.

• Miscellaneous List. Added new one-off entities, moved some to other lists where applicable.

• Profession List. Added several.

• Situation List. Added several.

Added Automatic Application and Automatic Award Indicators (DATA-19 & DATA 20)

In field use with previous versions, adopters of the standard have run across a few programs with “automatic” criteria, which have some importance to data exchange use cases.

The first “automatic” criterion is a set of programs for which students are automatically enrolled (i.e., that do not require students to apply). An indicator for this type of program would be useful because these programs would typically not be presented to students in scholarship listing, searching, and matching systems. By definition, students need not apply. However, the programs are of interest to analysts, program designers, and those modeling financial aid scenarios.

The second “automatic” criterion is a set of programs for which all eligible applicants are automatically awarded a scholarship or benefit. An indicator for this type of program is useful because any eligible student should be encouraged to apply. This can be a useful piece of information for, say, search ranking algorithms that positively weighted programs where a scholar was most likely to win an award.

Change Detail

Changes include:

• Added an optional IsAutomaticApplication Boolean flag to indicate programs for which students need not apply to be considered.

• Added an optional IsAutomaticAward Boolean flag to indicate programs for which all qualifying students are awarded a scholarship.

Usage Notes

• Both elements are optional. For both elements, receiving systems can treat a missing value as the equivalent of false. These types of programs are currently rare enough in observed data that an explicit false is not necessary.

• The Is Automatic Award flag does not mean anyone who applies is awarded without verification, of course. This flag should be assumed to mean that any eligible applicant will receive an award only after the program staff verifies an applicant’s eligibility.

Minor Changes to the Data Model

This section describes relatively minor changes to the NSPA Scholarship Program data model.

Added Support for Multiple and External IDs (DATA-16) (New 9/28)

Many data exchange scenarios require the sending and receiving systems to be aware of each others' unique system ID. For example, a matching algorithm in one system may need to reply to a data matching request with a unique identifier valid in another system.

This change adds native support for multiple IDs in the data model.

Change Detail

• Added a new UniqueID entity. Multiple Unique ID entities are allowed on a single record.

• The Unique Identity includes:

  • A RecordId element. Typically a GUID/UUID, but can be any unique identifier in a given system.

  • A RecordIdSourceName element. The proper-noun name of an originating organization or system.

  • A RecordIdSourceUri element. An identifier in URI format, typically including a domain name (e.g., “uri://metalistingllc.com”, “uri://systemname.metalistingllc.com”), which enables the source identifier to be globally unique.

  • The Unique ID element is part of the Metadata element discussed above in DATA-15.

The following XML snippet shows the use:

Added Support for Multiple CIP Codes per Major in Field of Study Eligibility Criteria (DATA-40)

Previous versions of the data model had a "Fields of Study" eligibility criteria to indicate a scholar’s major or academic focus. In addition to a natural-language expression of the field of study (e.g., “Journalism”), the eligibility criteria allowed entry of a CIP code (e.g., “9.0401“).

This update was made because the previous data model allowed only one CIP Code per major — but our Field of Study value list allows for multiple CIP codes to align with a single Field of Study. This change makes it easier for students and the NSPA Data Team to use human-friendly names for fields of study, even when those friendly names encompass multiple CIP codes.

As an aside, this also allows indicating wide fields of study, for example, "STEM" and having all related CIP codes populate from metadata.

Change Detail

This change updates the cardinality of the CIPCode element from 0..1 to 0..n.

The following XML data snippet shows an example of a major with multiple CIP Codes:

Added Support for “Other” Values in Field of Study Eligibility Criteria (DATA-68) (New 9/30)

Previous versions of the Field of Study entity didn’t support entry of an explicit "Other" value. Since the data standard is moving to use a formal NSPA List (vs. the free-text + CIP approach of the previous version) this is clearly a missing element. This change adds the missing free-text field.

Change Detail

• This change adds a FieldNameOther element to the Fields of study.

The following XML data snippet shows an example:

Refactored Program Organization Name into Program Organization Entity (DATA-25)

Field implementation of previous versions revealed something that wasn't unexpected: having "typed" Associated Organizations made it odd to have a different (and looser) structure for the Program Organization. 

Notes from the field: 

Program Organization is pretty much the same as Associated Organizations in that it also has Type and Role. I liked that fact that we are giving a reference ID to the organization (in the same spirit as giving reference id to Program Name). I already have a database table where we add Program organization. Associated organizations will also be added in the same table.

This change refactored the Program Organization Name into a Program Organization entity containing the same properties as those already found in the Associated Organization.

Change Detail

Changes include:

• Renamed ProgramOrganizationName to ProgramOrganization. Instead of ProgramOrganizationName being a Short String, it now becomes an object of the “Organization” type. This will enforce that ProgramOrganization now has a Reference ID (whereas currently, only Associated Organizations have a Reference ID). This also adds an OrganizationType and OrganizationRole. 

• Added a “Program Sponsor” value to the OrganizationRole value list.

• On a wholly trivial note: the new Program Organization entity was moved below the ProgramReferenceId element to group it with the Additional Associated Organizations.

The JSON snippet below illustrates the Program Organization:

Add Organization ID to Organization (DATA-26)

The NSPA Exchange has always assigned a GUID to each unique organization, which is used internally to assist with data consistency and searching. Some prospective field implementers suggested that it would be useful for NSPA to expose its unique IDs as a number to support things like persistent mapping and a centralized store of identifiers. This change allows for the exchange of that GUID value. 

Change Detail

• See also DATA-25.

• The refactoring of ProgramOrganizationName from a string into an Organization entity (in DATA-25) added a GUID “for free,” since it was already part of the Organization definition.

• For this version, we’re simply going to let the Organization Reference ID GUID fill the Organization ID role. In the NSPA Exchange context, this will be a unique ID — but implementers may elect to use their own Organization ID in data exchange scenarios.

Added Country of Residence Support (DATA-36)

This change provides support for Country of Residence, which filled a semantic gap between the previous versions' Citizenship Status and Location elements, indicating country of origin for international students.

Change Detail

• There were no changes made to the data model.

• This was addressed with a nontechnical change. The data model already supports a Location criteria with a country element. As part of the general improvements for international support in v1.0, we’re clarifying that the existing Country element should be populated to indicate the context in which a program is valid.

• See also DATA-30, which elaborates on this change.

Clarified Support for Additional U.S. GPA Scales in Academic Eligibility (DATA-37)

Previous versions of the standard supported a minimum GPA (and maximum GPA) in the Academic Eligibility entity. By definition, the value is encoded on an unweighted 4.0 scale in the U.S. context. 

The real world, of course, contains a multitude of scales and indications. In the U.S., that minimally includes:

• A letter scale (e.g., A, A-, B+, B, B-, C, etc.)

• A 1–100, or percent-scale, grade

• A 5.0, or weighted, scale

• A 4.5, or honors, scale

...and more. 

Change Detail

The change for this version is technically simple: continue to normalize U.S. GPA input into an unweighted U.S. 4.0 scale, but establish a robust, standardized mapping to other scales.

• The NSPA has published a set of conversion tables (here). These closely align with the College Board’s recommendations.

• NSPA will use the conversions for its own uses (such as the NSPA Exchange). 

• Adopters will be encouraged to use the same conversions in data exchanges using the standard. (To be clear, adopters will continue to use whatever method best suits their use cases within their own systems. The recommendation will solely apply to exchanging data between systems using this standard.)

• As noted ad nauseam, this only applies to GPA in the U.S. context. We separately added support for Canadian grading scales (see DATA-27, above).

Add Support for U.S. Nationals in Citizenship (DATA-5)

The term "U.S. national" is used by UNCF and others. Many programs are open to people who are a "U.S. citizen, U.S. national or permanent resident." Generally, the term U.S. national also includes U.S. citizens, but in this context, it also refers to noncitizen U.S. nationals from American Samoa and Micronesia, a population served by UNCF. The categorization is generally useful, so it’s an addition to the list of U.S. Citizenship eligibility criteria.

This change adds support for U.S. Nationals in Citizenship.

Change Detail

The change is simple:

• Add the value “U.S. National” to the new NSPA Citizenship Status list as an option for programs in the U.S. context.

Added and Improved Values in Degree Seeking Criteria List (DATA-9, DATA-34)

In previous versions of the standard, the Degree Seeking enumeration indicated the degree or credential toward which applicants will be working. The previous list started with postsecondary experiences such as Professional Certification and has postsecondary degree values such as Bachelor's Degree.

Further, some scholarships are available for High School graduation, GED studies, and professional certificates, which were not included.

Change Detail

The following changes were made to the Degree Seeking Criteria List:

• Added a High School item.

• Added a GED item.

• Added a Professional Badge item.

• Added a Professional Certification item.

• Added a Professional Micro-credential item.

• Changed the former “Associate’s Degree” item to Associate Degree.

The following annotated listing shows the list in toto:

Added New Values to Relation List (DATA-46) (New 9/28)

The existing Relation List establishes a set of potential relationships between a scholar and an organization, entity, or another person. In field use, a few missing relationships were discovered: one to establish that a person is a retiree of an organization and another to establish that a person volunteers for an organization.

This change added the missing values.

Change Detail

The following changes were made to the RelationList enumeration:

• Added Retiree Of list item.

• Added Volunteer For list item.

The following annotated listing shows the list in toto:

Added New Values to Armed Services Lists (DATA-50, DATA-53, DATA-54) (New 9/28)

In field use, several missing values were unearthed in the various armed services list. For example:

• The Armed Services List enumeration was missing values from uniformed services such as NOAA and the USPHS. Additionally, there was no direct way to encode requirements related to “any service” (e.g., programs for retirees of any service).

• The Armed Services Relation List enumeration defines relationships between a scholar and an armed service including familial connections. In field use, missing values were discovered, including an indicator for a sibling of a service member and a general value for “any descendant” of a service member. In addition, some programs are offered for scholars with “any relation” to a service member.

• The Armed Services Status List enumeration was missing a value for “any status” (e.g., programs for a scholar with any connection to the Navy). In addition, the existing combination of values did not support encoding for retired reservists of a service.

This change adds the missing values.

Change Detail

The following changes were made to the ArmedServicesList enumeration:

• Added Any Service list item.

• Added Air Force National Guard list item.

• Added Army National Guard list item.

• Added Merchant Marine list item.

• Added NOAA list item.

• Added USPHS list item.

The following changes were made to the ArmedServicesRelationList enumeration:

• Added Any Relation list item.

• Added Descendant Of list item.

• Added Sibling Of list item.

The following changes were made to the ArmedServicesStatusList enumeration:

• Added Any Status list item.

• Added Retired Reservist list item.

Added Support for Maximum GPA and Maximum Class Rank Percentage (DATA-11)

Previous versions of the data model only allowed encoding for Minimum GPA and minimum amounts for other academic criteria. We originally left out the companion "Maximum" values because maximums were applied to few criteria, few programs, and made public for even fewer.

However, in practice, we are seeing examples in the field with published maximum GPA amounts. A few have been firm requirements, while others are an expressed preference.

This change adds selected maximum amounts to academic criteria.

Change Detail

The following were made to the AcademicEligibilityCriteriaList enumeration:

• Added a MaximumGPA item.

• Added a MaximumClassRankPercentage item.

Usage Notes

• Both values should only be added to the Eligibility Criteria if a maximum value is a requirement to apply. When the Maximum value is phrased as the upper boundary of a preferred range, it should be entered as a Preference Criteria.

Allowed Affiliation Entity Names Longer Than 100 Characters (DATA-33)

In real-world use, we've seen scholarship-related organization names that exceed 100 characters, e.g., "United Association of Journeymen and Apprentices of the Plumbing and Pipe Fitting Industry of the United States and Canada Local 344" and similar.

Change Detail

The Affiliation Entity string length was changed from a Short String (100 characters) to a Medium String (512 characters). The Affiliation Entity Other string length was also increased to a Medium String.

The change is illustrated on lines 10 and 16 in the following XSD listing:

Element & Entity Name Improvements (DATA-7, DATA-67)

A few minor element name changes were made for the final v1.0 release.

Change Detail

• Changed AgeRestrictionEligibility back to its intended name AgeEligibility. This change came from a minor coding error in the production system for v1.0d. (DATA-7)

• Renamed IsCurrentProfession to MustBeCurrentProfession for clarity. (DATA-67) (New 9/27)

Schema Improvements (DATA-65)

A few trivial schema improvements were made for the final v1.0 release.

• Removed unnecessary maxOccurs="1" from a few elements in the XML schema. (DATA-65) (New 9/28)

General Changes & Improvements

Developed a Flat-File Representation of the Standard (DATA-31)

The current technical representations of the NSPA Scholarship Program data model are in XML and JSON, which are suitable for machine-to-machine transfer and have robust tools available for developer use.

However, use-cases have emerged where humans are in the data exchange pipeline (e.g., program staff who keep data natively in Excel, exports from existing systems that are massaged by humans, and so forth).

We have developed a template for both a Simple and Extended transfer, which we’ll publish after initial field testing.