Request for

Proposal
US Chess Ratings System

July 2023

ISSUED BY
US Chess Federation

REPRESENTATIVE
Emanuel London
[email protected]
931.787.7497
Introduction & Background

The US Chess Federation (US Chess) invites qualified entities and individuals to submit a
Proposal to re-architect and rebuild its current Ratings System. Our goal with the Rating
System rebuild is to:

1. Create a comprehensive System Architecture

2. Rebuild the current Rating Engine
3. Rebuild the current Player/Game Database and Website (Member Services Area)
4. Migrate Player/Game Database to new system

The objective of this Request for Proposal is to locate a source that will provide the best
overall value to US Chess. While price is a significant factor, other criteria will form the
basis of our award decision, as more fully described in the Evaluation Factors section of
this Request for Proposal below.

Submission Guidelines & Requirements

The following submission guidelines & requirements apply to this Request for Proposal:

1. First and foremost, only qualified individuals or firms with prior experience on
projects such as this should submit proposals in response to this Request for
Proposal.

2. Bidders intent on submitting a proposal should so notify the representative

identified on the cover page no later than September 1, 2023

3. Bidders must list at least 3 projects that are substantially similar or as complex as
this project as part of their response, including references for each. Examples of

1
 work should be provided as well.

4. A technical proposal must be provided that is not more than 40 pages. This
technical proposal must provide an overview of the proposed solution as well as
resumes of all key personnel performing the work or leading the project. In
addition, the technical proposal should provide a proposed schedule and
milestones, as applicable.

5. A price proposal must be provided that is not more than 10 pages. This price
proposal should indicate the overall fixed price for the project as well as hourly
rates and an estimated total number of hours, should US Chess decide to award a
contract on an hourly rate basis.

6. Proposals must be signed by a representative that is authorized to commit to the

bidder's company.

7. If you have a standard set of terms and conditions, please submit them with your
proposal. All terms and conditions will be subject to negotiation.

8. Proposals must be received prior to October 2, 2023 to be considered.

9. Proposals must remain valid for a period of 90 days.

10. US Chess anticipates selecting at least two individuals or firms to have more in-
depth discussions with and will make an award to one of these “down-selected”
individuals or firms.
11. Updates to this proposal or other related announcements can be found and
http://new.uschess.org/rating-system-request-for-proposals

2
Company Background

US Chess is the official governing body and non-profit 501(c)(3) organization for
chess players and chess supporters in the United States. Our mission is to empower
people, enrich lives, and enhance communities through chess. Our vision is that chess is
recognized as an essential tool that is inclusive, benefits education and rehabilitation,
and promotes recreation and friendly competition.

US Chess represents the United States in the World Chess Federation (FIDE),
connecting our members to chess players around the world. Founded in 1939 with the
merger of the American Chess Federation and the National Chess Federation, US Chess
has grown to serve over 100,000 members and 1,200 affiliated chess clubs and
organisations today.

Every year, US Chess sanctions and rates over 10,000 tournaments and over
900,000 games. We host over 25 National Championships and award titles to both
amateurs and professionals, ranging from elementary school students to older adults.

Project Background

Our “Rating System” consists of different pieces of software that together rate
and store data about chess games and tournaments and present access to that data in
various formats. It comprises our Ratings Engine and Server, “Gambit” a custom PHP
application with a PostgreSQL database, and the Member Services Area (MSA), which is
where all the rating data is stored and presented to end users in various ways. These
systems also communicate with our Drupal/CiviCRM installation which stores current
and past US Chess members and their membership information.

3
 The Rating Server is based on an algorithm 1 that is a is a custom implementation
of the ELO2 rating system and dictates how we initiate, convert and calculate ratings for
all players playing in US Chess rated events. In addition to rating new games and events,
the Ratings Server is also capable of rerating past games and events if, for example,
events are input not in chronological order, or input errors were found, and handling all
the permutations of such actions.

In addition to rating games, the Ratings Server includes several scripts to generate
various reports on rated games as well as retrieve some external player data from other
rating organizations such as the World Chess Federation (FIDE). Jobs are triggered on a
schedule and a queue of events ready to be processed is maintained.

It includes a user-facing interface for tournament directors and an administrative

interface for US Chess staff.

From the user-facing interface, tournament directors can either manually enter
complete tournament information into a dynamically generated form or upload a
formatted file exported from a tournament management system such as WinTD or
SwissSys3 which can then be rated after payment is made for processing. Unrated events
are placed into a queue until they are rated. Online partners are also able to make
submissions electronically.

The administrative interface allows US Chess staff to view and search for and edit
various details of past events such as result, player information and organiser or other
tournament information.

The MSA4 is a separate custom built PHP application that contains up to date
records on all US Chess members and their complete tournament history and presents a
user interface for accessing this information.

1 https://new.uschess.org/sites/default/files/media/documents/the-us-chess-rating-system-revised-
september-2020.pdf
2
https://en.wikipedia.org/wiki/Elo_rating_system
3 https://swisssys.com/
4 http://www.uschess.org/msa

4
 The MSA database contains records of all US Chess rated games from 1991 to
present and stores close to 100 million records (that have not been normalized).

Both the Ratings System and MSA are severely outdated and face the challenges
of an outdated system such as speed, reliability and architecture not suitable for
interaction with modern web applications. This means it affects not only tournament
directors who currently submit events manually for ratings, but also online partners who
host digital events, players and website users who want to view information on
tournaments and other players and is an impediment to any innovation in the US Chess
rated chess space.

In addition to the Ratings Server and MSA, US Chess’s primary website is Drupal
9 and CiviCRM installation. CiviCRM serves as the primary source of US Chess
membership data and is the source of truth for US Chess members that the Ratings
System uses via a database copy.

The Rated Chess Lifecycle

Crucial to understanding our needs and our process is understanding the entire lifecycle
of a rated Chess event.

5
More details on the complete functioning of the System can be found in the supplemental
document, The Tournament Rating System.

Scope of Work
The objective of this project is to rebuild a Rating System collectively, as an online, API-
first software to calculate player ratings and a system to manage player ratings, game,
and tournament information. The new system should provide a user-friendly interface,
robust security measures, and clear data visualization.
It includes the following primary tasks:
1. System Architecture: The rebuild would involve designing a scalable and robust
system architecture to handle the large volume of data generated by the rating
engine and reporting website. This would ensure efficient processing and storage
of player data, game results, and rating calculations.
2. Rating Engine Rebuild: The rating engine is at the core of the US Chess system
and would require significant attention during the rebuild. The engine should
accurately calculate, and update player ratings based on their performance in
tournaments and matches and provide an estimator for players to see potential
ratings. It should precisely execute the specified ratings algorithm and testing of
hypothetical changes to algorithm.
3. Data Migration: The old system data should be migrated to the new system,
including player ratings, game information, and tournament details into an
appropriate database system. The migration process should be thoroughly tested
and validated to ensure data accuracy and integrity.
4. User Interface (UI) and User Experience (UX): The UI/UX of the MSA website
would be redesigned to provide an intuitive and user-friendly experience as well
as a UI/UX for the Ratings Engine. The interface should allow players, tournament
organizers, and other stakeholders to easily navigate the site, access relevant
reports and viewing tournament and rating history.

6
Functional Requirements
Ratings Engine
• The system must allow administrators and tournament directors to login.
• The system must allow full manual administration of all ratings activities.
• The system must use SingleSignOn.
• The system must allow manual tournament/event entry.
• The system must allow storage of payment information.
• The system must be capable of calculating ratings using the current as well as
prior algorithms.
• The system must allow near instantaneous rating calculation.
• The system must be able to validate tournament/event pairings that it matches
US Chess guidelines.
• The system must allow all actions via authenticated API.
• The system must facilitate integration with existing tournament management
software.
• The system must be highly available.
• The system must be capable of handling multiple simultaneous requests.
• The system must automatically identify and update Titles and Norms available to
players based on requirements.

Member Services Area

• The system must allow users to estimate their ratings in a tournament (ratings
estimator)
• The system must prevent data aggregation/crawling.
• The system must generate dynamic reports for players, tournament directors and
affiliates.
• The website design must be responsive.
• The system must have a user friendly interface.
• The system must return data in multiple formats (e.g. JSON, CSV)

7
 • The system must have secure data storage and backup.
• The website must be ADA compliant.

Technical Requirements

The following technical requirements are needed for the Rating System:
● Algorithm Implementation:
○ The new Rating System should implement US Chess’s rating algorithm for
calculating the relative skill levels of players.. This includes 7 different
rating systems: the Blitz system, Quick Chess (QC) system, the Regular
system, the online Blitz system, the online Quick system, the online
Regular system, and Correspondence Chess.
● API Design:
○ The application should follow an API-first approach and use RESTful
principles for endpoints and HTTP methods.
● API Integration:
○ The new Rating System should provide API endpoints for performing all
rating related activities.
● API Documentation:
○ The application should have detailed API documentation that explains how
to use the API and what endpoints are available.
● API Testing:
○ The application should have automated/end to end testing in place to
ensure that the API is working as expected.
● API Versioning:
○ The application should have API versioning in place to ensure that older
clients can continue to access the API while new features are added.
● Authentication:

8
 ○ The application should implement Single Sign-On (SSO) using a protocol
such as OAuth 2.0 or OpenID Connect.
● Authorization:
○ The application should use a role-based access control (RBAC) system to
control access to the API endpoints and specific actions available.
● Data Storage:
○ The new Rating System should be able to store player ratings in a database
or other persistent storage system that is best suited to meet US Chess’s
needs.
● Data Validation:
○ Input validation should be performed on all incoming requests to the API to
ensure that the data is in the correct format and meets certain
requirements.
● Error Handling:
○ The application should have a robust error handling mechanism in place to
handle any errors that occur during the execution of the API.
● Extensibility:
○ The application should be developed in a modular fashion to allow other
related functionality to be added later such as other rating systems (e.g.,
Fischer Random Chess), the possibility of incorporating color assignment,
or ratings conversions.
● Input Data:
○ The new Rating System should be able to process input data in the form of
game results, including whether there was a winner, loser or it was a draw
as well the several exceptions that may occur such as forfeit wins.
● Logging:
○ The application should have a logging system in place to track all requests
to the API and any errors that occur.
● Performance:

9
 ○ The new Rating System should be capable of producing near instantaneous
rating results for submitted games, rounds or tournaments.
● Platform:
○ The new Rating System should be built using a robust and scalable
platform and language. Providers should include in their proposals
appropriate recommendations for US Chess’ needs.
● Rating calculation:
○ The new Rating System should be capable of calculating ratings using the
current algorithm version as well as prior versions of the rating algorithm.
● Rating adjustment:
○ The new Rating System should be able to adjust and test adjustments to
ratings based on various factors.
● Reliability:
○ The new Rating System should produce identical or more precise ratings as
prior algorithm ratings.
● Scalability:
○ The new Rating System should be able to handle large amounts of data and
many concurrent users rating events.
● Security:
○ The new Rating System should implement proper security measures to
protect against unauthorised access to the data.
○ The application should use HTTPS for all API requests to ensure that data
is transmitted securely.
● Testing:
○ The new Rating System should use Functional and End-to-end tests to
ensure accurate and reliable functionality.
● User interface:
○ The new Rating System should provide administrative and non-
administrative user interfaces for the Rating Server and the MSA.

10
Deliverables Overview

Resources to be provided by US Chess:

1. Rating System White Paper

2. Existing Rating System Code (PHP)
3. Existing MSA Codebase (PHP)
4. Rating System Database (PostgreSQL)
5. MSA Database (MySQL)
6. Tournament and Ratings Lifecycle Documentation

Resources to be provided by Vendor:

1. New system architecture

2. End to End Testing Environment, to persist over the lifetime of the software
usage at US Chess
3. API Documentation that outlines how partners can interact with our systems
4. Software manuals and documentation that outline how to use and manage system
features

Technical Deliverables

All technical deliverables will be expected to conform to a standard format to be agreed

upon during final contract negotiations.
This standard format will outline:
● How the product is delivered
● How documentation will be provided
● How testing was conducted
● How User Acceptance testing can be conducted.
● Defect report process flow
● Defect resolution plan

11
The following technical deliverables are expected from the vendor:

● Design documents, including wireframes, mock-ups, and specifications for the

new system.
● A fully functional implementation of the new system, including the Rating Engine,
Results Database, and Member Services website.
● Ongoing support and maintenance for the new system, including bug fixes,
security updates, and feature enhancements.

RFP & Project Timelines

The Request for Proposal timeline is as follows:

Request for Proposal Issuance 07/28/2023

Selection of Top Bidders / 10/16/2023

Notification to Unsuccessful Bidders

Start of Negotiation 11/15/2023

Contract Award / 03/03/2024

Notification to Unsuccessful Bidders

The need-date for project completion is 12/15/2024. Bidders may propose a date earlier
or later, and will be evaluated accordingly.

12
Evaluation Factors

US Chess will rate proposals based on the following factors, with cost being the most
important factor:

1. Responsiveness to the requirements set forth in this Request for Proposal

2. Relevant past performance/experience
3. Samples of work
4. Cost, including an assessment of total cost of ownership.
5. Technical expertise/experience of bidder and bidder’s staff

US Chess reserves the right to award to the bidder that presents the best value to US
Chess as determined solely by US Chess in its absolute discretion.

13
Appendix
The Tournaments and Ratings Life Cycle

This document will describe the chess tournament life cycle and how it impacts US

Chess information systems, including website pages and internal programming. It is designed

to document how these systems currently function, the reasons behind their design, and how

they are used by US Chess staff, Tournament Directors (TDs), organizers, players, coaches and

others, not to serve as the final specs for the new tournament and ratings systems, though in

places it will point out limitations or weaknesses in the current data structures and

programming.

This document is divided into 8 sections:

o Pre-tournament activities

o Activities during the tournament

o Post-tournament reporting

o Ratings Computations

o Ratings List Generation

o The MSA System

o Other Reports for Members

o Staff Reports and Supplementary data interfaces

Pre Tournament Activities

Pre-tournament activities that impact US Chess operations have two primary purposes:

14
 1. to promote the event

2. to assist the tournament organizer/director in getting ready to run the event.

There are also a special category of events, National Events, run by the US Chess

office, for which there is also a National Events registration system that handles

registration, including verification of current membership and meeting age or other

limitations, and provides this information to the event TDs in a form that the tournament

pairing software can process to create the list of players in each section.

Promoting the event can be handled by Tournament Life Announcements (TLAs)

and email blasts ordered through those systems, which are part of the programming

developed by our Drupal/CiviCRM development partner. Although the

tournament/ratings system does not currently have access to TLA information, it might be

something that the new tournament/ratings system should have access to. (Special event

types such Grand Prix and Junior Grand Prix events have requirements that involve TLAs and

other forms of pre-event publicity from US Chess.)

The National Events registration system was developed in-house and is hosted on

the secure2.uschess.org system, with templates for upcoming events created on the

gambit.uschess.org system. For these events, the US Chess staff also creates

tournament information website pages to complement the tournament registration

templates, these information pages have links to show advance entries for upcoming

National Events, links to information pages for other upcoming National Events, links to

pairings and results for events in progress, and links to final standings (individual and

team) for completed National Events, including events from prior years.

15
 The primary pre-tournament activity for organizers and TDs is access to the

Member Services Area, to verify member IDs, membership status, and the look players’

current published ratings. (Some events are exempt from membership requirements, but

TDs still need to know those members’ IDs and ratings or create new IDs for them, including

FIDE IDs for FIDE rated players such as foreign-designated WIMS/IMs and GMs/WGMs, who

are exempt from membership requirements.)

US Chess currently maintains six ratings systems for tournament chess, three for

over-the-board events and three for online-only events. There is a seventh system for

correspondence (sometimes called postal) chess, but it is independent of the six

tournament rating systems. The member lookup is a key pre-tournament function, and

currently also exists as part of our customer-facing website, however, it can use speed

improvements.

Detailed information on MSA will be covered in a subsequent section. For tournament

pre-registration purposes, the MSA system provides the event organizer/TD with a player’s ID,

membership status and current published rating, and the TD can drill down to find a more

recent unofficial rating for a player, which the TD is permitted to use instead of the official

published rating covering that event, with some restrictions.

MSA also shows some FIDE information, like a player’s FIDE ID and country of

registry, which is important for events that are also FIDE rated.

TDs may collect US Chess dues as part of their advance registration fees, in which

case they will use the TD access to the CIVICRM membership system to process those

membership dues. For events or players that are membership-exempt (for example,

events involving players in grades K-3, in-house scholastic tournaments for K-12 schools

16
or FIDE titled players (IM/GM] who are not under the USA flag for FIDE), the TD may

have to create a new ID for a player not yet in our membership system, but without a

dues requirement. These are handled through the CIVICRM membership system.

If an event needs to be cancelled, moved or rescheduled at the last minute, a

system for rapidly posting and updating this information would be useful.

Tournament directors use pairing programs that have a database of current

members and handle the process of pairing players and creating pairing sheets and

standings for posting during the event. US Chess maintains three database formats of

members, referred to as the supplement files. These supplement files are currently

generated monthly after the 3rd Wednesday of the month and those ratings become

official on the first day of the next month, though some events can, if announced in pre-

event publicity, use an earlier ratings list. These ratings files can be downloaded from

the US Chess website and used to update the pairing programs used by that TD.

The three formats are:

• The monthly supplement files, a DBF file showing those players who

played in event or had a ratings change in the month since the last monthly

supplement was created. Since this format only supports two of the six

rating supplement files, there are two versions of this file, one which has

over-the-board regular ratings plus over-the-board quick ratings, and one

which has over-the-board regular ratings plus over-the-board blitz ratings.

• The Golden Master file, a DBF file showing all members and their current

published rating, even if there has been no change from the prior month or

17
 if they have no published ratings. The Golden Master files are also issued

in two sets for Regular/Quick or Regular/Blitz OTB ratings, matching the

monthly supplement files.

• The All-Ratings list, a tab-delimited text file showing all players and their

ratings in all six tournament ratings systems, both OTB and online.

The ratings file site, restricted to US Chess members, also has other files, including tab-

delimited text file versions of the rating supplement files and PDF files similar to the

published rating supplement files that US Chess used to print and mail out to TDs and

affiliates.

Activities During the Tournament

Once the tournament begins, the TD staff may still use US Chess information

systems. It is convenient, especially in large events (such as National Events), for the TD

staff to create, upload and validate a preliminary rating report to check on things like

correctly entered member IDs and current memberships for all players. This rating

report is entered and validated the same way as the post-tournament rating report, but it

not submitted for rating, so no fee is required.

At National Events, pairings and results are uploaded to the US Chess website

periodically during the tournament. This is done by having the pairing software generate

text files that can be uploaded to the US Chess website by the TD staff. These are

accessed by links that are part of the National Event registration page for that event.

Final standings files for past National Events are available online indefinitely.

18
During an event, it is not unusual for players and others to use MSA to look up the

tournament record of their next opponent once pairings are posted.

Post Tournament Reporting

Once an event is completed, the tournament rating report needs to be prepared,

validated and submitted to the national office, with payment of any ratings fee and

possibly other fees. Over 95% of events are submitted and paid for online, but some

TDs may still be mailing their reports to the national office for processing by US Chess

staff members, paying a higher per-game ratings fee.

The submitting TD can either upload the ratings report information or enter it

online. For small events the latter can be faster.

There are currently two DBF formats accepted for uploading ratings reports. The

original format dates back to the early 1990’s and does not include information such as

which player had which color pieces. The second format, one that is used for most

events these days, does include color information, but neither format has all of the

information needed to rate an event. A significant weakness of both DBF formats is that

when reporting double round-robin events, we only get the total score, so we do not

know if a 1-1 score represents a win and a loss (in either order) or two draws. This can

affect a player’s total win count, something that is part of the player statistics and

milestones pages on MSA.

19
 There are data fields used when computing ratings and others displayed on MSA

that are not part of either upload format, requiring the TD to enter that information

manually once the event has been uploaded.

The possibility of a new tournament submission format that includes all needed

fields has been discussed over the years, with formats such as XML and JSON suggested.

Until the new TLA system was written a few years ago, the tournament system also had

access to the TLA system. It no longer has that access, which means the US Chess

ratings staff must manually confirm whether an event notated as a Grand Prix or Junior

Grand Prix event met all the requirements for those events. Also, not having access to

the TLAs means the tournament system does not know if an event had a TLA for

National Chess Day, which is usually one of the prerequisites for waiving the ratings fee

for those events.

The ratings formulas do not currently utilize color information in computing updated

ratings from an event, but MSA does include that information.

The usual practice for TD submitting an event online is to have their pairing

software create three DBF files for their event, one for overall tournament information,

one for information about each section of the event, and one with player information,

the player’s member ID and pairing number(s). For each round of the event, the pairing

number of the opponent, the result of that game, and the color of that game (under the

second format) is given. Players may have more than one pairing number in an event, for

a variety of reasons. The results of a player with more than one pairing number in a

section are combined when computing ratings but for tournament reporting purpose on

MSA each pairing number is shown separately.

20
Online Form

TDs may also create events manually using an online form, entering all the

information needed for their event, overall tournament information, information specific

to each section, and full player information for each section.

Each event is assigned a unique 12-character event ID, the first 8 characters are

the ending date of the event (i.e., the latest section ending date) in YYYYMMDD format,

the next 3 characters are a 3-digit serial that is incremented for each new event,

wrapping around from 999 to 000 about once a month, and the final digit indicates what

system generated that event. A ‘0’ means the event was generated under the previous

(dBase/Clipper) system, a ‘1’ means it was generated under the programming and

formulas in effect at the time of the transition to the current ratings programming, and a

‘2’ means it was generated after the programming was changed to require time control

fields that passed a parsing test, in late 2012. A few events have been created with a

final character greater than 2 to ensure that those event IDs were unique.

Because the 12-character event ID includes the event ending date, if there is a

change in the event ending date (generally due to an error made by the TD when

preparing the event to be submitted), the event must be resubmitted and a new event ID

generated using the correct event ending date.

There has been some discussion over the years of merging correspondence events and

ratings into the tournament ratings system. Making sure the event IDs remained unique was

one concern, tracking the type of correspondence event was another, one way of handling this

would be to make the 12 character be a non-numeric string that indicates the type of

21
correspondence event. The primary benefits of merging correspondence events into the

tournament system are that it would allow all affiliates to run and submit correspondence

events, and it would provide a unified database for all games played by member, regardless of

ratings system. There are some major differences between the OTB/Online ratings formulas

and the ones used for correspondence chess, including the order in which games are rated.

(All games in an OTB/Online section are rated at the same time, correspondence games are

rated one at a time, in the order the result is received by the US Chess correspondence chess

staff.)

A key component of the information for each section is the time control for that

section, which determines which ratings system it affects. For over-the-board events,

some events may be rated both under the OTB regular ratings system and the OTB quick

ratings system. Parsing the time control information to ensure it makes sense and

determine what ratings system applies is done during event validation. A separate flag

determines whether the event is an over-the-board event or an online-only event.

Combined with the time control information, this unambiguously determines which

ratings system(s) are to be updated from that event.

The form also lists which TDs were involved in the event and in what capacity,

which is used to track TD activity to help determine whether the TD is eligible to take

the test for promotion to a higher level of certification. (Some of the requirements for

promotion are not available through the tournament/ratings system.)

It supports two ways of structuring games:

1. Swiss System – most used, columns represent rounds played.

22
 2. Round Robin (RR) - columns represent the opponent number (i.e. a 10

player RR event is a 10 x 10 matrix). Only the result ode is entered, not the

opponent since that is determined by the column.

There has been some consideration for supporting double RR or even quad RR events.

In a double RR event, the players play all other opponents twice, once with each color. In a

quad RR event, they would play all the other opponents four times, twice with each color.

Double RR and Quad RR events are not that unusual in Blitz chess, where a game

might only last 10 minutes.

Results Codes

These are the result codes that are accepted, regardless of whether the structure

is a Swiss or a RR event:

• W – Win for this player (pairing number/row)

• L – Loss for this player

• D – Draw for this player

• U – Player was not paired in this round. Sometimes called a zero-point bye

• H – Player was not paired and received a half-point bye for this round

• B – Player was not paired and received a full-point bye for this round

• F – Player had a forfeit loss in this round

• X – Player had a forfeit win in this round

• Z – Player had a forfeit draw in this round (rarely used)

23
In general, the result codes need to agree with each other, if player A received a win,

then player B should be noted as having lost. One exception to this is the forfeit loss, a

double forfeit loss is possible. There can however be exceptions.

On occasions, generally the result of a TD ruling, players are awarded inconsistent

results for ratings purposes. For example, player A could be treated as a win for ratings

purposes while player B is treated as draw for ratings purpose. To ensure that

inconsistent results are intentional, special codes are used:

• N – Player received a win for ratings purposes

• R – Player received a draw for ratings purposes

• S – Player received a loss for ratings purposes

Result Code ‘I’ has been designated for ‘result pending’, which could be used in a

correspondence event.

It would be helpful if the new reporting system had a way to notate both the result for

ratings purposes and the result for pairing and prize purposes.

In addition to the information needed to rate an event, the TD submitting the event

also indicates the sponsoring affiliate, whether or not a section was part of the Grand

Prix system, and whether a section is to be FIDE rated, though a separate report

detailing information FIDE requires which US Chess does not require may be necessary,

and FIDE events have to be pre-registered with FIDE before they start to meet FIDE

requirements. This is not currently done using the tournament ratings system and should

be added to the new system.

Event Validation

24
 Validation of an event involves checking many fields, including cross-field

consistency.

Examples include:

• the sponsoring affiliate must be a current US Chess affiliate through the end of

the tournament date.

• Each TD listed as having worked at the event must be a current US Chess

member and a certified TD.

• The Chief TD for the event and the TD submitting the rating report must both be

authorized to direct events on behalf of the sponsoring affiliate.

• Each player result is compared to the result of the opponent in that round for

consistency. I.e. the report says that player A defeated player B in round 1, then

the report must also say that player B lost to player A in round 1, though cross-

round pairing can occur and is checked for.

• the ZIP code of the event is checked against the city and state.

• Colors are also compared for consistency when present.

As noted above, it is possible, though infrequent, that for ratings purposes the results

shown for each player in a game might be inconsistent with each other. For example,

player A could be shown as defeating player B while player B is shown as having a draw

against player A. Special result codes are used to indicate results inconsistencies. The

chief TD for the event is responsible for deciding when inconsistent results should be

reported.

25
 It would be better if the tournament/ratings system knew both what the result was for

prize purposes and what it was for ratings purposes, when different, but that is not currently

tracked. We also do not know what tie break methods were used for trophy allocation, either

knowing the tie break methods or knowing the tie break values that were used would be

helpful in ordering players on MSA in the same order in which prizes were awarded.

Having fields for reporting the prizes (monetary and non-monetary) would also be useful

information, and there is currently no way to upload the moves of individual games in a

tournament to the US Chess website, unlike the FIDE website. (A file format called PGN exists

for reporting the moves of a chess game.) The submitting TD is required to provide a list of

players who won cash prizes above the current money prize floor when the event is submitted,

but that information is not included on MSA.

The validation report separates issues detected during event validation into three

categories. (The full list of over 160 issues that can be reported when validating an event is

in Appendix A):

• Alerts – issues which may or may not be data problems. TDs are asked to check

that the information being reported is correct, but the event will not fail validation

due only to alerts.

• Warnings – issues which are most likely data problems that may require the TD to

correct the report or override the warning before revalidating the event. An

event cannot pass validation if there are any warnings that haven’t been

corrected or overridden.

26
 • Errors – Issues which are data issues that must be corrected before the event can

pass validation. Having a valid member ID for a current member is one such

example. There are some errors that require the US Chess staff to override the

error before the event can pass validation.

Membership Requirement Exceptions

In general, every player in an event must be a current US Chess member through the

end of the last day of the event. There are several exceptions to the membership

requirement. This may not be a complete list of all such exceptions:

1. The player is a FIDE titled player (GM, WGM, IM, WIM) whose FIDE country flag

is not USA.

2. The section is coded as a primary JTP (Junior Tournament Player) events. All of

the players are expected to be in grade 3 or lower. Since we don’t have grade

information for most players, we do this by age, all players must be under age 11. Any

affiliate may run a primary JTP event.

3. The event is coded as a K-12 in-house scholastic event. Only scholastic affiliates

(the affiliate ID starts with a ‘H’) may run in-house scholastic events, and the players

are expected to all be students at that school in grade 12 or lower, which is also

checked by age, all players must be under age 20. In practice, we have no way of

verifying that the players meet the student requirement.

4. The player is a house player, a former member or non-member who fills in to fill

out a round rather than give the odd player a full-point bye. Non-members who

serve as house players must have an ID, which can be generated via the CIVICRM

27
 membership system. However, house players in primary JTP or K-12 JTP events

must still meet the age limitations for the players in that section.

5. The event is one declared exempt from membership requirements by the national

office. This is an override that must be requested from the US Chess office.

An event is only allowed one house player per round in each section, since if there

are an odd number of players, only one additional player is needed to fill out the field for

that round. Events with more house players than that will not pass validation unless an

override is requested from and approved by the US Chess office. The house player in

one round of a section need not be the same house player as in other rounds of that

same section.

A common type of warning is when a player does not appear to be similar to the

other players in that section, which can happen if an incorrect ID was entered. For

example, if all of the players except one are young inexperienced players in California and the

other player is a high rated player from New Jersey, this will be flagged as a warning and the

TD has to verify that the ID is correct and override the warning.

Fees

Once an event has passed validation, any ratings fee and any additional fees need to

be paid. This may be done by the submitting TD or it may be done by an officer of the

sponsoring affiliate, in which case the submitting TD hands the event off to the affiliate

for payment after certifying that the events complied with all applicable US Chess rules.

National Events run by the national office do not pay ratings or other fees, so there

needs to be a mechanism to bypass the payment.

28
 An event in which one or more sections are listed as Grand Prix events may need to

pay a per-player fee that goes into a fund for assisting high rated players. Only events

that are coded as Enhanced Grand Prix events pay this fee, currently $1 per player in that

section.

Events that are FIDE rated may have fees that are passed on to the FIDE office

when the event is submitted for FIDE rating by the US Chess staff. These fees may be

changed by FIDE from time to time, and are adjusted for currency exchange rates, since

FIDE bills in Euros.

Non-US Chess Members

TDs have several options for dealing with players who are not current US Chess

members but are not exempt from that membership requirement.

1. Collect dues from that player and submit them through the CIVI-CRM

membership system before submitting the event for validation.

2. Pay a $20 fee to make that player a trial member for two months.

3. A third option, used when a TD finds out after an event is over that the

player was not a current member, is to pay a $10 correction fee for each

non-member in lieu of collecting dues.

The number of correction fees permitted in an event is limited and if an event has too

many of them, the US Chess staff will have to override an error. These correction fees are also

tracked over time to ensure that this option is not abused. The validation system computes a

total amount due, for the ratings fee as well as for any other fees.

Ratings Fees

29
 Certain events may be exempt from paying a ratings fee, for example events held

in conjunction with National Chess Day, the 2nd Saturday in October each year. A

unique waiver code is selected each year and sent to TDs who register events that will

be listed in TLA records as National Chess Day events. This waiver code is entered in

lieu of paying the ratings fee, though other fees may still be assessed. A system for pre-

entering waiver codes, possibly limited to certain dates or certain affiliates, would

simplify this process.

Events that are being submitted online are generally also paid for online by credit

card. However, there are occasions when the event is paid for by contacting the US

Chess office and supplying credit card information, or payment by check. There have also

been situations in which the organizer has arranged in advance to be invoiced for the ratings

fee after the event. Payments that are not made online need to be supported and properly

reported for accounting purposes.

When submitting an event, the TD is required to report whether any players in

the event earned cash prizes that were equal to or above the money prize threshold in

effect for that event. Changes to money prize floors are recorded in the ratings

correction table.

Once an event has passed validation and has been submitted for rating with any

payment due, the TD’s direct involvement in reporting the event is over and the ratings

system software takes over. (Errors detected in an event after it is rated, for example an

incorrectly reported result or member ID, are handled by having the TD notify the US

Chess staff of the correction, which is made by a staff member.)

30
US Chess staff have access to the information in an event that is in the process of being

submitted, it is used to handle staff overrides.

Ratings Computations and Ratings List Generation

Once an event has been submitted for rating, including payment of any required

fees, the event is handed over to the ratings system software.

The US Chess Ratings System is a complex mathematical process, the Executive

Board makes changes to it after consulting with the Ratings Committee. A copy of the

current white paper describing the mathematical process of computing ratings is available

at

https://new.uschess.org/sites/default/files/media/documents/the-us-chess-rating-

system-revised-september-2020.pdf

What follows is a summary of how the ratings programming prepares to go

through the steps detailed in this white paper to rate an event, and what happens

afterwards when recording the event in the database, not an explanation of the

mathematics behind ratings.

Prior to the 2005 rewrite of the ratings system, events were rated in the order in

which they were received. However, events are often submitted late, so events were

often rated out of chronological order. Also, when errors were made in reporting an

event (for example, an incorrect result, an incorrect member ID or the wrong ratings

system), those corrections had to be made manually.

31
 To get around these data issues, the current ratings software is capable of re-

rating events after a designated date, called the Re-rate Window. Events that are

submitted late or out of chronological order are put into the proper chronological order

for ratings purposes.

Each section of an event is rated as a single block of games, and the sections in

multi-section events may not be rated consecutively if other events fall in between them

in the sort order, given below.

The program to compute ratings for an event has several modes under which it runs and

ratings may be computed, and those events reported on MSA several times a day. The

modes currently supported are:

1. Finding events that have been submitted for rating and rating all sections of

them for the first time. This normally happens hourly from 6AM until 11PM

every day. We do not rate (or re-rate) any events overnight so that we can do

system backups and daily reporting with consistent data.

2. Re-rating all events necessary to consider changes to prior events, new events

that have been placed in chronological order or changes in that event. This is

done by month, re-rating all sections ending in any month in which there is a need

for re-rating, because a new event has been added, an event has been corrected or

an event has been deleted. Once a month has been flagged as needing re-rating,

all subsequent months also need re-rating, because a player’s pre-event rating for

the next event may have changed. Re-rates are generally scheduled on a weekly

basis, with all re-ratable events being re-rated just ahead of the generation of the

next ratings list. (The re-rate window is events that were initially rated on or after

32
 January 1, 2004.) Most weekly re-rates only involve recent months for which

changes have been logged to sections that ended during that calendar month.

3. Re-rates of an individual event, updating the event.

4. Test re-rates of an individual event, without updating any information.

5. Test re-rates of all events affecting an individual since some starting point.

This is done to help assess whether a player’s rating floor needs to be adjusted

downward after a request for a floor review. This type of test re-rate can ignore

events coded as matches and ignore the current floor for that player. For this

mode, the player’s post-event rating is maintained in the ratings programming and

is used as the pre-event rating for that player’s next event, regardless of what the

player’s actual most recent event rating is, or whether there has been a manual

change to that player’s rating or floor.

When the re-rate window was first set, in 2005, it was set for all events that were

initially rated on or after January 1, 2004. The idea at the time was to slide the re-rate

window forward occasionally to limit the number of months that need re-rating. However,

this has not been done. One possibility that may be considered for the new ratings software is

to establish floating parameters for the re-rate window. For example, if the re-rate window

was reset to January 1, 2015, when the new programming becomes effective, we might move

it forward by one year on an annual basis.

This date is being suggested because it is after two major changes in the ratings

process, the changing of the effective games formula in May of 2013 and the conversion from

integer inter-event ratings storage to floating point inter-event ratings storage in September

33
of 2014. This might simplify the programming because it would not have to deal with re-

rating those older events using significantly different methodology.

Since January of 2021 only 2 corrections have been made to events inside the re-rate

window that ended prior to January 1, 2015, so this would not appear to create a lot of un-

re-ratable data corrections. It would also reduce the number of months of data that have to

be re-rated each month ahead of the generation of the next ratings list. (Currently this can

take up to about 30 hours over two days.)

Changes to the bonus threshold, made to ameliorate ratings inflation, are reviewed by

the Ratings Committee annually, but no change to the bonus threshold has been made for

several years, in large part because of reduced OTB activity during the pandemic. However, a

change to the bonus point threshold was proposed in 2023.

Ratings Tables

When a new event is to be rated, the information from the pending tournament

validation system is used to create records in the ratings system. There are currently

five tables involved:

1. The tournament table, containing information common to the entire event,

including where the event was held, the starting and ending dates, and

tournament director information.

2. The section table, containing information specific to that section of the event,

including section starting and ending dates, tournament director information, and

ratings system type (determined during validation).

34
 3. The player table, containing one record for each pairing number in a section. (As

noted earlier, a player may have more than one pairing number for an event, all

the games for that player in that section are aggregated for ratings purposes.)

4. The ratings table, containing the most recent set of post-event ratings from that

event plus previous ratings from that event. The ability to see a player’s ratings

history from an event can be consulted to show how changes made to an event

affected that player’s post-tournament rating.

5. The ratings summary table, containing the latest post-event ratings for each

player in each section of that event and each ratings system applicable to that

section. Some events may be rated as both regular over-the-board (OTB) and

quick OTB events, referred to as dual-rated events. The time control for the

section determines whether it is dual-rated, just as it determines which ratings

system(s) the section qualifies for. This table exists to speed up the process of

looking up a player’s pre-event rating for an event, since the ratings table can

have many records for each section, player and ratings system, based on how

many times the event has been re-rated.

Regardless of which mode is being used, the process for rating a section is essentially

identical except for the affected player in a mode 5 test re-rate for a specific member ID.

The first step is to see if there is a previous post-event rating for this player in this

ratings system. The order in which sections are rated unambiguously determines which

event is a player’s most recent event in that ratings system. This order is:

1. The ending date of that section

35
 2. The starting date of that section

3. The unique event ID for that section

4. The section number for that section

Once the player’s most recent section under the applicable ratings system is located,

the post-event rating and post-event floor from that section is saved. However, before

that information is used in the section currently being rated the ratings correction table

is checked for a manual change to a player’s rating, floor (including money prize floors) or

ceiling. An effective date is used in the ratings correction table to determine if the

manual rating record is applicable. The effective date of the manual change must be

after the ending date of the player’s previous section and on or before the ending date

of the section currently being rated. If there are overlapping events it may not be clear

which section is the first section for which a manually entered rating or floor change is

effective, this needs to be reassessed during programming and testing of the new system. In

practice floors seldom seem to occur in conjunction with overlapping events.

As noted above, for a player who is the subject of a mode 5 test re-rate, the information

from the previous section in the test re-rate overrides all other information in determining that

player’s pre-event rating for a section.

If a player does not have an existing rating in the rating system for this section, then

an estimated initial rating must be set using other information, including other US Chess

ratings systems, FIDE ratings and ratings from the Canadian Ratings System (CFC). Prior

to June of 2020 there was a table to specify what the estimated rating and game count was

36
based on a priority list of other ratings system. Since June of 2020 we have computed a

blended initial rating for that player using all known ratings information.

US Chess has monthly records of published FIDE ratings going back to January 2003,

so we are able to look up a player’s FIDE rating as of the start of that player’s first US

Chess rated event. However, we do not have historical date-specific information for CFC

ratings that can be tied to member IDs, so initial (blended) ratings that utilize CFC ratings

information have a record in the ratings correction table to supply this information to the

blending process. The US Chess staff checks the CFC website to determine the player’s

CFC rating.

If there are no prior events in any ratings system, the player’s initial rating is

computed (as described in the ratings White Paper) based on the players age as of the

starting date of the section (in fractional years) times 50, with a minimum of 100 and

capped at 1300 for players who are 26 or older. If there is no birthdate on file, the

player’s membership type is used.

Additional details on the blending process can be found in the Ratings System White

Paper cited above, along with the other mathematical details for ratings system

computation.

If a player’s updated established rating passes above designated 100 point

boundaries, the player’s floor may also be updated.

Since September of 2014, ratings have been kept in floating point, using internal FP

data types. The new programming has to be able to compute ratings using the ratings

formulas and system procedures (i.e., integer vs floating point inter-event ratings) that

were in effect at the time of the event so that those ratings do not change as a result of

37
the system rewrite except for very small floating point differences that may be

unavoidable due to changes in the math library used or the data storage format for

floating point numbers. Several of the factors used to compute effective games have

been changed over time, as has the bonus threshold.

Players may also earn a ‘money prize floor’ if their winnings from an event exceed a

certain amount. This threshold amount has changed over time. The ratings correction

table is used to convey this information to the ratings system program. A new floor that

is higher than the player’s post-event rating as computed becomes the player’s new

post-event rating. The ratings system does not know why a new ratings floor (which

could be higher or lower than the player’s current floor) was imposed, all manual floor

changes are treated the same. The ratings correction table also has the capability of

imposing a ratings ceiling on a player, but in practice this has only been used a handful of

times in the last 50 years. However, if a ceiling is imposed it would take effect AFTER

the computation of all ratings but before they are stored in the database, so that the

ceiling does not negatively impact other players.

There is a hard-coded limit of 32 rounds in an event. In practice very few events have

had more than 20 rounds, but quadruple-RRs for 10 player events would exceed the 32 round

limit. The player table is not normalized, the rounds data (opponent pairing number, result and

color) are in text fields that are unpacked during the aggregation of the games to be rated in a

section.

Once the updated ratings for an event are computed, they are reviewed for whether

or not a player’s floor needs to be raised. (A player with a rating of 1800-1899 has a

floor of 1700, unless the player already has a higher floor). This is referred to as the

38
player’s peak-rating based floor, to separate it from manually raised or lower floors that

would be in the ratings correction table. Floors range from 1200 to 2100 with a special

floor at 2200 that is only for players who have played 300 games with a ratings of 2200

or greater, these players are referred to as Original Life Master and the 2200 floor is

inserted via the ratings correction table. (The ‘Original’ part stems from some historical

issues in which the term ‘life master’ was used in several contexts.)

Floors are only applicable to established ratings, not provisional ratings. (See below.)

All players have a hard floor of 100, no ratings are allowed to drop below 100. A soft

floor of 101-150 is used for younger players who are just beginning to play tournament

chess, the soft floor is raised for each section the player competes in and each win or

draw in the games in those sections. This was done for promotional purposes; it was felt

that having a large number of newer players all at 100 points might discourage those players

from continuing to play in rated tournaments. If there was no 100-point hard floor or 101-

150 soft floor, quite a few of these players would have negative ratings, which would almost

certainly be discouraging.

If the player’s pre-event floor is higher than the player’s post-event rating as

computed, then the player’s floor is substituted for the computed post-event rating.

This ensures that a player does not drop below that player’s current floor. A facility for

setting a ratings ceiling also exists, though it has not been used much.

The player’s rating status may also be updated. A player is considered

provisionally rated if the player has less than 26 rated games in that ratings system. A

player who has all losses or all wins (the latter is very rare) is also considered

provisionally rated. Once a player has 26 games (and they are not all wins or all losses)

39
the player’s rating is considered established. This is an administrative status, often used by

organizers to decide whether a player is eligible to play in certain events, it has no impact on

the ratings computed and is not part of the determination of the standard vs special ratings

formula usage in the ratings formulae.

Players who compete in FIDE events outside the USA, ones that are not US Chess

rated, may have an adjustment to their US Chess rating based upon their results in that

FIDE event. However, this is generally limited to players with a FIDE rating of 2200 or

higher, and to players who are either current US Chess members or not playing under a

FIDE country other than USA, though others may opt into these FIDE adjustments by

contacting the US Chess office.

The FIDE adjustment is computed by taking the converted FIDE rating of their

FIDE-rated opponents and using those as the pre-event ratings for those players then

computing a new rating using the standard ratings formula approach, but only for that

one player. This process ignores any games against opponents who do not have a published

FIDE rating yet and is a weakness of the current FIDE adjustment process, but it isn’t clear

how that could be improved upon.

There is a FIDE-to-US Chess conversion formula (see section 2.1 of the White

Paper) that is applied before computing FIDE adjustments, both for FIDE adjustments

and in the blending, formula cited above, and some events, those involving all youth

players, use a different conversion formula when computing FIDE adjustments. These

conversion formulas are periodically reviewed by the Ratings Committee and have

changed a few times over the years.

40
 For sections that are coded as matches (either by the submitting TD or because

the event looked a match during validation--some TDs try to bypass the match rules),

there are limits on the number of ratings points that can be gained or lost in a match, as

well as cumulative limits on gains or losses in match play over six months and three

years. Bonuses cannot be earned in a match. For certain event eligibility purposes,

matches may be excluded during a test ratings computation for a player (mode 5).

A common point of confusion is the game count associated with a provisional rating.

This does not represent the number of rated games this player has played in this ratings

system. That’s because the process of initializing a rating using other ratings information

produces an ‘effective game count’ value, anywhere from 0 to 10 games, which is utilized in

the ratings formula. For example, a player who has a FIDE rating but no US Chess rating

might have a game count of 5 or 10, based on that player’s FIDE rating.

Ratings List Generation

Official ratings are currently updated once a month. The current schedule is to

cut off processing of new events at the end of the day on the 3 rd Wednesday of the

month, with the new ratings list generated and checked for problems before rating of

new events or re-rating of existing events resumes, generally by 1PM on the Thursday

following the 3rd Wednesday.

US Chess staff are asked to not enter any corrections to events that ended more

than a year ago on the Tuesday or Wednesday ahead of a ratings list cutoff. That’s

because a full re-rate going back to the start of the re-rate window is run before

generating a new ratings list, so that we have all events reflecting the most recent

41
ratings. The changes to ratings during the early stage of a full re-rate are minimal, and

usually reflect updates to member information, specifically the member’s birthdate, since

that is what is used to initialize a player’s rating when there is no other ratings

information available.

However, it is also possible that a previously unrated player has been identified as

having a FIDE ID and rating or a CFC rating that had not yet been recorded at the time the

event was rated. Updating a player’s birthdate, adding a FIDE ID or logging a CFC rating in

the ratings correction table are not activities that automatically trigger a re-rate of the events

for that player, which is why we do a full re-rate ahead of generating a new ratings list.

The first step in generating a new ratings list is to make sure the full re-rate is

complete, since new events could be submitted on Wednesday evening ahead of the

cutoff for the ratings list. This may involve starting another, usually small, re-rate after

the cutoff time for the ratings list.

Once a full re-rate is complete, a new ratings list is generated. If a player’s rating

in any of the 6 OTB/Online ratings system has changed since the previous ratings list, or

if the player had any rated games in any of those ratings systems since the previous

ratings list, even if they didn’t result in a change in the player’s rating expressed as an

integer, then a record for that player is included in the new ratings list. It is worth noting

that because of re-rating, a player’s rating could change without the player having played in

any games since the previous rating list generation. Ratings changes due to re-rates are

usually very small, perhaps 1 or 2 points.

The ratings list table entry shows the player’s current rating in each ratings

system. It also includes the effective date of the ratings list (the 1 st day of the month

42
following its generation), and for convenience it includes the player’s current expiration

date, membership type and state. For each rating the player’s current rating, its status

(provisional or established), the game count for a provisional rating and the player’s

current floor are all included for each rating system. The convention for reporting a

provisional rating is nnnn/nn, ie 1250/17 represents a provisional rating based on 17

games. For an established rating, an asterisk is used (but not displayed on MSA.)

Once the new ratings list is generated and checked, rating supplement files are

created and posted on the US Chess website in an area where current players and TDs

can access those files, but these files are not accessible without logging in to the US

Chess website.

At present we generate the following files for each new ratings list:

• A monthly update file format (DBF) showing OTB Regular and OTB Quick ratings

• A tab-delimited text file version of the above data

• A monthly update file format (DBF) showing OTB Regular and OTB Blitz ratings

• A tab-delimited text file version of the above data

• A golden master file format (DBF) showing OTB Regular and OTB Quick ratings

• A tab-delimited text file version of the above data

• A golden master file format (DBF) showing OTB Regular and OTB Quick ratings

• A tab-delimited text file version of the above data

• A tab-delimited text file format (ALLRATINGS) showing all six OTB and online

ratings systems

43
 • Two PDF files showing the three OTB ratings in a format similar to that used for

the printed ratings supplements we used to print and mail to TDs and affiliates.

One of these files has the ‘Bell’ font encoded in the PDF, the other does not.

The monthly update file only includes those members for whom a ratings supplement

record was generated for that month, typically around 25,000 records. The golden

master file includes all member records (currently about 1.1 million current and former

members.)

Both the monthly supplement format and the golden master format only have fields for

two ratings system, which is why there are two versions of each of those files. These file

formats were defined many years ago and have not been updated as new ratings systems

have been created and needs to be updated. A unified format should be part of the new

system.

The golden master DBF file format does not include detailed information on provisional

ratings, ie, the provisional game count. This information is included in the tab-delimited text

file versions of this format.

The reason neither DBF file format has been changed to include additional information is

that updating the DBF file format will break at least one of the pairing programs currently in

widespread use.

The tab delimited (ALLRATINGS) text file format was developed in 2020 so that there was

a single file containing all six of our OTB/Online ratings. The ALLRATINGS file also has

information that is missing from the other file formats, namely the member’s status (active,

deceased, duplicate ID, inactive), country, and the member’s FIDE ID and FIDE country code

44
as of the date of the list generation. It also shows the number of games the player had in each

ratings system in the past month. It is our hope that the developers of pairing programs will

begin to utilize the ALLRATINGS file format, perhaps allowing us at a future date to

discontinue issuing one or both of the DBF file formats.

TDs and Affiliates can also request custom ratings lists in either a tab-delimited or

ratings list PDF format, these custom ratings lists are generated automatically and

emailed to the person who requested them.

The MSA System

Historically, US Chess published member ratings either in Chess Life or in periodic

ratings supplements. In 2003, this information was placed online in the Member Services

area, or MSA.

MSA provides information about players, affiliates, and tournament directors.

For players, their current published ratings and other items are shown on their member

page. Another page shows their tournament history, in summary or detailed form. It is also

possible to show just a player’s opponents and results from an event.

Other tabs provide the player’s ratings supplement history (i.e., their official published

rating over time), their milestones and norms-based title history (and their norms earned.)

There are links on the player’s member page to show their ratings history in

graphical form and to provide a statistical summary of their tournament results (wins,

losses and draws) over time, in several different formats.

45
 For tournament directors, the history of the events at which they have worked,

and in what capacity, is shown.

For affiliates, the history of the events under their affiliate ID is shown. An active

players list for players who have participated in events sponsored by that affiliate can

also be shown.

MSA can also be used to search for a rated tournament by name, date, state or

other criteria. Rated tournament data goes back to December 1991.

The Milestones system is a way of encouraging players by acknowledging their

progress. For example, we award milestones in each ratings system when a player

reaches 25, 50, 100, 250, 500, 750 and 1000 wins, and for every 500 wins beyond

1000.

The Milestones page (the ‘More’ tab on the member’s page) also shows when a

player first achieved a National Master rating, the Original Life Master title (300 OTB

regular games played with a rating of 2200 or higher), and the norms based titles.

The Norms Based titles were developed by the Ratings Committee in 2008 as a way of

recognizing sustained performance at various skill levels. Norms are earned and when 5

norms for a norms based title are earned the title is awarded. (Some titles also have a ratings

requirement.) Details of the norms based title system are found at

http://www.glicko.net/ratings/titles.pdf.

Norms are not computed on an event until after that event has been re-rated for

the first time, since the pre-event ratings may not yet be correct because the event has

not yet been placed in chronological order.

46
 MSA includes a ratings estimator that player can use to estimate their rating from

an event. Each time the ratings system formula is changed, usually just the bonus

threshold, a new version of the ratings estimator program is generated.

MSA can show a list of tournaments rated by state and tournament rating reports

received.

Other Reports for Members

In addition to the MSA pages, there are numerous other reports available at

http://www.uschess.org/index.php/Of-Continuing-Interest/Links-to-Available-Reports-

Standings.html.

US Chess maintains leader boards showing the most active players nationally and in each

state by week, month or year in each of our ratings systems. These are updated daily.

Members can request reports showing the top players by state under several

different selection criteria.

For players who participate in the annual Grand Prix competition (events open to

master), reports showing Grand Prix events received and current standings for the

current and previous calendar year are available.

For players who are eligible for the Junior Grand Prix competition, reports

showing JGP events and standings are available.

For players in FIDE events, a list of events notated as having been FIDE rated is

available, along with a list of all US Chess members who have been identified as having a

FIDE ID.

47
 It is possible to generate a list of certified TDs in a state, with optional contact

information. There is an annual Member Appreciation Program recognition system for

affiliates and states, showing the number of memberships processed.

US Chess issues numerous Top 100 player lists each month, by ratings system, by

gender and by age. Eligibility for gender or age-based Top 100 lists must be confirmed

with the US Chess office.

Staff Reports and Supplementary Data Interfaces

Several reports are generated for staff use on a regular basis:

• A monthly list of memberships by state. One use for this report is to allocate

Delegates for the next year.

• A monthly list of memberships by age.

• A monthly list of memberships by gender.

• A monthly list of female members by age.

• A monthly list of events with large number or a high percentage of female

participants.

• A quarterly list of members and tournaments by metropolitan area (CBSA), using

Census Bureau data correlated by the member’s county as determined by the

member’s ZIP code.

• A weekly list of tournament activity.

• A monthly set of graphs showing the number of games played by ratings system

by month, overall and for various age categories.

48
• A monthly set of graphs showing the number of members participating in rated

events by month by ratings system and age group.

• A monthly report showing JTP and scholastic activity in terms of games rated,

total player counts and member counts.

• There are also numerous staff interfaces to review or update data:

• Tournament header table

• Section header table

• Player table and Player Results (the latter is more like a tournament cross-table

and is easier to use.)

• Ratings history for a player (including re-rate history)

• Rated Event Status. (Can be used to delete a duplicated event, update what

ratings system it should be rated under, etc.)

• Status history for a rating report (when it was uploaded, revised, validated,

submitted, rated)

• Rating supplement records table

• FIDE Ratings tables (current and historical ratings)

• Grand Prix events lists and standings.

• Junior Grand Prix events lists and standings (including validation of JGP eligibility)

• Top 100 list validation and generation

• Ratings Corrections Table (including floors)

• FIDE adjustments

• Milestones Table (including entry/updating milestones information for OLM titles)

49
• State Top Player Lists

• Ratings Table

50