Student Financial Aid: Use of Middleware for Systems Integration Holds Promise
Published: 2001-11-30T00:00:00

Fast Facts:

Highlights:
section_title: What GAO Found
paragraphs: Although the Department of Education spent millions of dollars to modernize and integrate its nonintegrated financial aid systems during the past 10 years, these efforts have met with limited success. Recently, Education's Office of Student Financial Assistance (SFA) began using a software approach known as middleware to provide users with a more complete and integrated view of information in its many databases. In selecting middleware, SFA has adopted a viable, industry-accepted means for integrating and utilizing its existing data on student loans and grants. To meet its human capital needs, SFA has solicited the help of a private sector "modernization partner" with experience in implementing and managing middleware solutions--particularly in the financial industry--and has also chosen to use a leading middleware software product.

section_title: Letter
paragraphs: Hand in hand with the rapid growth of the Internet is the need for both the  public and private sectors to provide citizens and customers with real-time  access to an increasing amount of data and services.  To accomplish this in  its areas of responsibility, the Department of Education spent millions of  dollars over the past 10 years to modernize and integrate its nonintegrated  financial aid systems in an effort to provide more information and greater  service to its customers—students, parents, schools, and lenders.   However, the department met with limited success.  For example,  Education’s first centralized grant and loan database on student financial  aid participants, the National Student Loan Data System (NSLDS), which  was developed to help schools screen applicants for student aid eligibility,  often does not contain the most recent information from other financial aid  systems.
Recently, Education’s Office of Student Financial Assistance (SFA) initiated  a new approach to database integration, utilizing a software approach  commonly referred to as middleware, to provide users with a more  complete and integrated view of information contained in its multiple  databases.  As such, you requested that we provide information on the use  of this technology, and the viability of SFA’s approach in using it to  integrate student financial aid information.  Appendix I describes our  objectives, scope, and methodology in more detail.
subsections: section_title: Background
paragraphs: SFA manages and administers student financial assistance programs  authorized under title IV of the Higher Education Act of 1965, as amended  (HEA).  These postsecondary programs include the William D. Ford  Federal Direct Loan Program (FDLP--often referred to as the "Direct  Loan"), the Federal Family Education Loan Program (FFELP--often  referred to as the "Guaranteed Loan"), the Federal Pell Grant Program, and  campus-based programs.  Annually, these programs together provide  about $50 billion in student aid to approximately 8 million students and  their families.  As a consequence, the student financial aid data exchange  environment is large and complex.  It includes about 5,300 schools  authorized to participate in the title IV program, 4,100 lenders, 36 guaranty  agencies, as well as other federal agencies.  Currently, SFA oversees or  directly manages approximately $220 billion in outstanding loans  representing about 100 million borrowers.  Figure 1 provides an overview  of this environment.
During the past three decades, the Department of Education has created  many nonintegrated information systems to support its growing number of  student financial aid programs.  In many cases, these systems—maintained  and operated by a host of different contractors, on multiple platforms— are unable to easily exchange timely, accurate, and useful information  needed to ensure the proper management and oversight of various student  aid programs.  Table 1 lists SFA’s current inventory of major systems.
Beginning in 1992, title IV student financial aid systems integration was the  subject of heightened congressional concern.  The 1992 HEA amendments  required the department to centralize data on student loan indebtedness by  integrating databases containing student financial aid program  information.  In response to this mandate, in January 1993 Education  awarded a 5-year, $39-million contract for development and maintenance of  NSLDS.  The system was to provide information on students across  programmatic boundaries, yet problems persisted.
Since 1995, because of concerns over Education’s vulnerabilities to losses  due to fraud, waste, abuse, and mismanagement, student financial aid has  been included on our high-risk list.  Studies had shown that Education had  used inadequate management information systems containing unreliable  data, and that inaccurate loan data were being loaded into NSLDS.
In 1997, 4 years after the initiation of the NSLDS contract, data  inconsistencies and errors across systems, such as a student’s enrollment  status or the amount of loan indebtedness, continued to have a negative  impact on the student’s ability to receive aid.  Education still lacked an  accurate, integrated system for student financial aid data; the  nonintegrated systems would sometimes provide conflicting information to  the department’s financial aid partners (schools, lenders, guaranty  agencies).  The department had opted to establish NSLDS as a data  repository rather than an integrated database; this meant that while the  system could receive and store information from other title IV systems, the  lack of uniformity in how the individual systems stored their information— no common student or institutional identifiers or data standards— complicated data-matching among systems.  Hence, NSLDS could not be  effectively updated (or update other systems) without expensive data  conversion programs.  As a result, data contained in other systems,  operated by a variety of contractors, were often in conflict with data stored  in NSLDS due to differences in the timing of updates among the multiple  data providers.
As also reported in 1997, large amounts of redundant student financial aid  data generated by schools, lenders, guaranty agencies, and several internal  department systems, were being stored in standalone databases, thereby  increasing the cost to administer the various title IV programs.  We  concluded that these data exchange and storage problems, as well as other  program operation and monitoring difficulties, were partly related to the  lack of a fully functional integrated database covering all title IV student  financial aid programs.
In 1998, in part to address these and other longstanding management  weaknesses, Congress amended HEA and established SFA as the federal  government’s first performance-based organization (PBO).  Under the PBO  concept, SFA is a discrete organizational unit within the Department of  Education, and focuses solely on programmatic—rather than policy— issues, which remain the responsibility of the Secretary of Education.   Thus, upon being designated a PBO, SFA was expected to shift from a focus  on adherence to required processes to a focus on customers and program  results.  Moreover, in establishing SFA as a PBO, Congress gave SFA  specific personnel hiring authority, including the ability to appoint up to 25  technical and professional employees without regard to provisions  governing appointments to the competitive service.  Also in conjunction  with its PBO status, SFA can seek waivers from governmentwide  regulations, policies, and procedures (e.g., acquisition, human capital, and  procurement).  This flexibility is intended to give SFA greater freedom in  achieving their performance goals while maintaining accountability for  operational aspects of federal student aid programs.
In September 1999, under this PBO procurement authority, SFA hired  Accenture (formerly Andersen Consulting) as its "modernization partner,"  to help it carry out its Modernization Blueprint.  Accenture’s role is to  provide leadership of critical planning activities essential to the success of  SFA’s modernization.  As a result of these and other events between 1992  and 1999, the management structure of SFA’s postsecondary education  activities was completely reorganized.  Under the partnership between the  PBO and Accenture, a new systems integration strategy emerged, focusing  on the use of middleware software technology to achieve database  integration and improve access to and use of SFA’s information.  Table 2  lists key events and milestones during the past decade affecting  Education’s student financial assistance programs and the systems that  support them.
section_title: Middleware Technology Used Successfully in Industry
paragraphs: Hundreds of organizations around the world have found successful  technology integration solutions through the use of middleware, sharing  data across different information systems and databases.  Middleware is a  type of software that enables programs and databases located on different  systems to work together as if they all resided in a single database.  Often  organizations use middleware together with Web-based applications to  present users with an integrated view of relevant data over the Internet,  without having to develop new systems or database software.  The  middleware acts as an intermediary that mines data from existing  databases and performs any necessary data transformation so that the  existing information can be quickly compiled and presented to the user.   For instance, middleware is used heavily in the banking industry,  particularly for those institutions involved in numerous mergers and  acquisitions, as it allows both banks to keep their existing systems,  programs, and databases essentially unchanged, while providing users such  as branch personnel with a composite view of both customer databases.
We contacted three major financial institutions that use the same  middleware product adopted by SFA:  IBM’s MQSeries.  According to these  companies, as with SFA, the driving force behind the acquisition of the  middleware technology was multiple, incompatible platforms. Overall,  banking industry information technology officials with whom we spoke  were pleased with the technical capabilities of middleware, but said that  the major issue in successfully implementing and maintaining a  middleware-based systems environment was retaining skilled employees— whether in-house or via an external contract.
According to SFA’s chief operating officer, by using the banking industry as  a benchmark for establishing the viability of the middleware approach, SFA  was better able to identify the strengths and weaknesses of that approach.   He saw the banking industry as analogous to SFA in that it had to  successfully address systems interoperability problems and provide users  with an integrated data view following mergers.  Similarly, we previously  noted a gap between the services available to bank customers, and those  available to students and their families—such as the ability to view  complete account data and make account changes worldwide, across  systems, through automated teller machines.
section_title: Middleware Implementation at SFA Is in Early Stages; Choice Appears Viable
paragraphs: SFA’s initiative is in its early stages, and as of July 1, 2001, SFA had made  the initial system modifications necessary to use the middleware  technology on five systems.  In addition, SFA’s contract programmers have  been developing software using extensible markup language (XML)13—now  becoming an industry standard—that will eventually standardize student  grant and loan origination and disbursement requests into a single common  record format for all aid programs.  Moreover, the enterprise application  integration architecture plans and documents are in place that are  conducive to the IBM MQSeries middleware product line being used to  facilitate data integration across SFA’s different computing platforms.
The first use of middleware and XML together for loan originations and  disbursements is expected in March 2002, when a single process for  delivering Direct Loan and Pell Grant aid to students, called Common  Origination and Disbursement (COD), is scheduled for implementation in  time for the 2002-2003 school year.  In March, SFA plans to provide at least  50 schools that participated in testing using COD with the option of  submitting data via its new common record format for Direct Loans and  Pell Grants.
The COD is designed to provide a consistent process—via the common  record—for requesting, reporting, and reconciling Pell Grants and Direct  Loans.  Now, schools must enter, submit, and reconcile data separately for  each program, data including name, address, and other pertinent  information for the same student in different formats—a redundant  process that can be quite time-consuming.
XML is a meta-markup language that provides a format for describing structured data.   XML is designed to enable the exchange of information (data) between different  applications and data sources on the World Wide Web and has been standardized by the  World Wide Web Consortium, an organization that develops common protocols to promote  the evolution and interoperability of the Web. common record format and outgoing records back to the schools in their  current record format.  Thus, if SFA’s middleware approach is operationally  successful, it will allow schools to use either method; those schools that do  not use the new common record format could migrate to the common  record on timetables that are more feasible for their individual  circumstances.  Figure 2 illustrates the first planned implementation of  COD for Direct Loan and Pell Grant originations and disbursements using  either the common record format or middleware.
According to the Modernization Blueprint, COD will ultimately provide the  5,300 schools that participate in the title IV student financial aid programs  with a single process for all aid origination and disbursement.  This is  expected to create a system that facilitates close to real-time sharing of  data across all of SFA’s partners, and establish a platform that supports  integrated technical and functional customer service for schools across all  programs.  SFA’s Modernization Blueprint also outlines key projects that  are scheduled for implementation over the course of several years.  Table 3  lists some of them.
In adopting this approach to better integration and utilization of its existing  data on student loans and grants, SFA may be able to address, at least in  part, long-standing database integration problems.  Such problems have  contributed to slow and inconvenient loan servicing and management, as  well as weak internal controls.
SFA fully expects that this solution will provide improved customer service  by permitting its eleven major systems to operate more cohesively in the  near future and help reduce the total number of needed systems over the  long term.  Some of the problems SFA hopes to eliminate include improving  the cumbersome process for gaining access to the various SFA system  databases.  This process sometimes requires users, such as an educational  institution’s financial aid or accounting staff, to continually log in and out  of different systems for related aid information on students for each  program.  These individuals must sometimes use a different school  identifier and password to gain access to student information for each SFA  program, and often do not have the ability to retrieve necessary  information when they do gain access.  As we noted in 1995, this internal  control problem of not having access to current, accurate information  sometimes led to loans and grants being improperly awarded.  SFA  expects that its middleware product will enable entities to gradually  upgrade or migrate to new systems and databases while maintaining a  consistent view for the user.  That is, middleware can enable SFA to realize  short-term, user-level integration, while enabling it to gradually improve its  older systems over time.
In short, by adopting a middleware-based strategy, SFA expects that it can  continue operating some of its existing systems, applications, and  databases, but in a more homogeneous fashion.  Moreover, according to  SFA’s chief operating officer, the alternative of developing a new, large,  central database or student financial aid system was less suitable because  of the cost and time involved in database redesign and data format  conversion.  Further, he expects middleware to be part of SFA’s long-term  solution for integrating databases under its Modernization Blueprint and,  through 2004,  allow the eventual retirement of several existing systems.   Finally, he expects this approach to allow SFA to be more responsive to  customer needs.  Figure 3 shows how the two alternative approaches differ  in providing data to users.
section_title: Successful Middleware Technology Implementation Requires Right People, Right Skills
paragraphs: The experiences of other organizations have demonstrated that critical  skill shortages must continually be addressed when using middleware as an  integration solution.  According to middleware users, the technology  requires experienced, highly skilled programmers, with a broad knowledge  of the entire environment in order to maintain seamless data exchanges.  Industry officials cite the lack of sufficient numbers of programmers with  the needed technical skills.  According to IBM representatives, extensive  technical training is needed before an experienced programmer can  become effective using its middleware product.
Banking officials confirm that finding people who are highly skilled in the  use of this technology is difficult.  For example, according to a senior  official at a major bank, an experienced, certified middleware systems  programmer can command over $100,000 annually, making retention of this  type of talent challenging even for this bank in today’s competitive  information technology marketplace.
SFA management recognizes that it will face the same inherent human  capital issues as these organizations and has tried to address them by  leveraging experiences from the banking industry and by acquiring  contracted expertise.  In addressing the human capital skills issue  associated with successful middleware implementation, SFA will count on  the help of its modernization partner, who has substantial experience in  implementing middleware solutions in the banking industry and the use of  the middleware product’s vendor (IBM) as programmers.
According to officials of another federal agency using MQSeries, when they  originally tried to develop similar capabilities in-house, they were later  forced to switch to the commercial product because of technical  difficulties in maintaining the system on their own.  A MQSeries users  group also exists; other federal agencies using the MQSeries include the  Customs Service, the Department of Veterans Affairs, and the Air Force,  from which SFA may be able to borrow knowledge and technical expertise.
section_title: Conclusion
paragraphs: As has been the case with several other organizations, a middleware  integration strategy is likely a viable technology alternative for SFA in  addressing its long-standing systems integration problems.  SFA recognizes  the human capital issues that middleware presents, and is preparing to  meet them.  While early, if implemented properly, middleware appears to be  a reasonable approach that could result in improved user-level systems  integration, while enabling SFA to gradually retire many of its remaining  systems over time.
section_title: Agency Comments and Our Evaluation
paragraphs: In commenting on our draft report, the Deputy Secretary sought  clarification on whether our analysis of SFA’s actions to use a middleware  integration strategy addressed the full range of issues that we and the  Education Inspector General had raised in past reports regarding SFA’s  systems integration problems and rationale for SFA’s programs being  included on our high-risk list.  Specifically, he suggested that we clarify  whether the middleware strategy adequately addressed our earlier  concerns about SFA’s lack of an architecture, the costs associated with  maintaining nine or more separate information systems, and the need for a  long-term integrated SFA database.  Additionally, the Deputy Secretary  wanted us to clarify whether the new strategy introduced any new  problems related to costs, increased risk of system breakdown, or  introduction of errors into the current systems environment.
While these are important issues, the focus of our review was to provide  information on the use of the middleware technology and its viability as a  means of integrating student financial aid information.  As we note in the  report, SFA’s middleware integration work is still in development and is  moving into very early stages of implementation.  Although preliminary  testing and pilot efforts involving the middleware data integration  capability have been positive, the actual versus expected benefits will not  be known or measured until planned projects and activities become  operational.  We have concluded that SFA’s middleware strategy itself  appears to be a reasonable technical approach for improving data  integration.
The Deputy Secretary also asked whether we took into account several  previous reports in which we stated that the department needed a sound  systems architecture before embarking on systems integration.  We note  that SFA has devised an enterprise-wide systems architecture in response  to our 1997 recommendation and that SFA provided us with requisite  technical documents that explained the guiding architecture on which it is  building its middleware strategy.  However, the scope of our review did not  include an assessment of the adequacy of departmentwide architecture  implementation and usage.
Finally, the Deputy Secretary raised several technical questions related to  the report’s graphics, terminology, and descriptions.  We have clarified or  modified these points where appropriate.  Education’s written comments,  along with our responses, are reproduced in appendix II.
As we agreed with your office, unless you publicly announce the contents  of this report earlier, we plan no further distribution of it until 30 days from  the date of this letter.  We are sending copies of this report to the Secretary  of Education, Education’s Office of Student Financial Assistance’s chief  operating officer, the Director of the Office of Management and Budget,  and appropriate congressional committees.  Copies will also be available to  other interested parties upon request.  This report will be available on our  Web site at www.gao.gov.  If you or your offices have questions regarding  this report, please call me at (202) 512-6257 or David B. Alston, Assistant  Director, at (202) 512-6369.  We can also be reached by e-mail at  mcclured@gao.gov and alstond@gao.gov, respectively.  Other individuals  making key contributions to this report included Nabajyoti Barkakati,  Michael P. Fruitman, and Glenn R. Nichols.
section_title: Objectives, Scope, and Methodology
paragraphs: Our objectives were to provide information on the use of middleware  technology, and to evaluate the viability of SFA’s approach to using it to  integrate student financial aid information.  To achieve these objectives, we  examined SFA documents, including the Modernization Blueprint and  updates and information technology target architectures.  We assessed how  critical information technology integration issues are being addressed at  SFA, including the merits and risks of the blueprint, and assessed agency  documentation to determine whether SFA’s systems environment lends  itself to a technically feasible middleware solution.  In addition, we  analyzed several technical documents on the general function and use of  middleware, and interviewed officials from SFA and Accenture, its  modernization partner.  We also interviewed officials from the Advisory  Committee on Student Financial Assistance to obtain their perspective on  SFA’s use of middleware.
Further, we spoke with officials from IBM, the developer of the middleware  product (MQSeries) being implemented by SFA.  We analyzed technical  documents describing the operation of the MQSeries in general, as well as  design documents addressing the implementation of this middleware  product at SFA.
To independently document the success of this middleware product in the  public and private sectors, we consulted with users from the U.S. Customs  Service, Bank of America, Chase Manhattan Bank, and First Union Bank.   We analyzed documents relating to the implementation of this middleware  product in two of these organizations.
We performed this work at SFA headquarters and Accenture offices in  Washington, D.C.; IBM’s office in McLean, Virginia, the U.S. Customs  Service office in Springfield, Virginia; and Bank of America offices in  Charlotte, North Carolina.  We also conducted telephone interviews with  officials from Chase Manhattan Bank and First Union Bank.  Our work was  performed from February through August 2001, in accordance with  generally accepted government auditing standards.
section_title: Comments From the Department of Education
subsections: section_title: GAO Comments
paragraphs: 1. We changed the report title to clarify that the scope of our review was  focused on determining if SFA’s middleware systems integration  strategy was a viable approach. 2. Given the scope of our review, we believe the report adequately  addresses this concern.  In drafting our report, we took into  consideration previous GAO, Education’s Inspector General reports,  and the department’s internal reports, particularly those relating to  Education’s lack of a guiding enterprise architecture and the  department’s pressing need to integrate its student financial aid  systems and databases.  For instance, we have already credited the  department with defining a departmentwide systems architecture in  response to our 1997 report on this topic.  Further, in reviewing SFA’s  middleware strategy, we confirmed that enterprise application  integration architecture plans and documentation existed and was  conducive to the IBM MQSeries middleware product line being used to  facilitate data integration across SFA’s current computing platforms.   However, the scope of our work did not permit us to assess the  adequacy of departmentwide architecture implementation and usage  issues.  3. The commitment indicated by the Secretary and SFA to resolve  longstanding problems mentioned in our previous reports can go a long  way towards providing the catalyst to solve many of Education’s data  integrity problems.  These problems have contributed to the inclusion  of SFA’s programs on GAO’s high-risk list.  However, neither the  department’s or SFA’s efforts to address critical data quality and  internal control issues related to its high-risk designation were included  in the scope of this review. We do note, however, that SFA expects to  reduce the number of total systems needed in the long-term in  conjunction with its middleware implementation. 4. Past problems as well as rationale for better integrated program and  financial data across SFA’s existing databases are explained in the  background section of our report rather than in this brief opening  paragraph.  As such, we made no changes to the report.  While  middleware provides a means for better user integration, sound  business practices and disciplined internal management controls will  be needed for any organization to achieve mission improvements and  financial benefits from its information systems investments.   5. Our discussion of integration in this context is based upon SFA’s most  recently released Modernization Blueprint, which states that SFA’s task  is to create: " . . . an integrated enterprise that meets our PBO goals of improved  customer and employee satisfaction, and reduced unit costs.  Part of  that task is to modernize key systems and processes to create an  enterprise that meets our customers needs.  We can view some of these  key processes and systems as major pieces of an overall integrated  solution.”
Given SFA’s description of the goals they wish to achieve through  integration, we did not modify our report.  6. We agree with the descriptions of the additional shortcomings of  NSLDS, but timeliness of updates remains a major issue.  The objective  of our review also was not to review and critique the problems of  NSLDS as we did previously, rather, to focus on looking forward and  assessing middleware as a suitable technology solution in the future for  integrating SFA’s systems.  Thus, we only provided one example of the  negative consequences stemming from the lack of integration but  provided numerous references to previous reports that describe these  and other problems in greater detail.  Accordingly, we did not modify  our report.   7. SFA’s Chief Operating Officer (COO) clearly considers the use of  middleware part of a long-term systems integration solution.   Therefore, we did not modify our report. 8. We concur that the scope of our review was to determine whether  middleware technology is viable and feasible in SFA’s system  environment and that other issues were not covered in our work.   Accordingly, we did not modify our report. 9. We updated our report to reflect that SFA now plans to have about 14  systems connected to middleware by December 2001. 10. We updated our report to clarify that some legacy systems, according to  SFA’s Modernization Blueprint, will not have to be modified for  middleware because some will be retired in the future.   11. We modified our report to reflect that the first planned use of  middleware for Direct Loan and Pell Grant originations and  disbursement would occur next year. 12. We updated our report to reflect the change in the implementation date.  13. We did not modify our report.  Education’s Central Automated  Processing System (EDCAPS) included in figure 1 and table 1 in our  report is not the same as the Central Data System (CDS), which has  been retired.  EDCAPS is the primary accounting system for the  department.  The department’s Management Improvement Team  Accomplishments document, dated October 30, 2001, describes  EDCAPS as Education’s “financial records and accounting system.”  CDS is not discussed in our report. 14. We modified our report to reflect that the PBO was established in 1998. 15. We modified our report to clarify responsibilities of SFA under the PBO  legislation.  16. We modified our report to indicate SFA’s participation. 17. We believe the appointment of SFA’s COO was a relevant milestone.
Several sections of the HEA Amendments of 1998 creating the PBO  address the functions of the COO, including the requirement to have a  PBO performance plan.  Likewise, the selection of the SFA  modernization partner also was a relevant milestone, especially in light  of the important role that the partner plays in SFA’s systems  modernization, which is described in the report.  Therefore, we did not  modify our report. 18. We modified our report to clarify that there are additional users of the  MQSeries product. 19. We did not modify our report.  The figure displays only the COD  process, which will initially include only Direct Loan and Pell Grant  origination and disbursements.  All Direct Loan and Pell Grant funds  are federal and ultimately come from the U.S. Treasury.  We purposely  omitted the Federal Reserve and other intermediary systems for  simplicity.  Schools will follow the COD process described in the figure  when originating loan and grant applications on behalf of students. 20. We modified our report to better reflect that middleware will also  convert disbursement records back to each school’s current record  format. 21. According to SFA’s most recently released Modernization Blueprint  (page 13), the COD is expected to be able to provide all schools that  participate in title IV financial aid programs with a single process for  aid origination and disbursement.  SFA staff confirmed the accuracy of  this statement.  Therefore, we did not modify our report. 22. According to SFA’s Modernization Blueprint, COD is expected to be  capable of handling all aid distribution. The first use will be for Direct  Loan and Pell Grant origination and distribution. Therefore, we did not  modify our report. 23. We did not modify our report.  The internal control problems identified  in the 1995 report focused on the need to have timely, accurate student  eligibility data.  Also, see comment 6. 24. As noted in the report, we are attributing the choice between two  options -- developing a large central database or maintaining several  integrated databases using middleware -- to SFA’s COO.  By 2004, SFA  does expect to retire several existing systems that should result in  fewer databases than currently exist. 25. We modified our report to note that SFA plans to retire systems through  2004.    26. We did not assess the capabilities of Accenture, as this was not  included in the scope of our work.  Therefore, we did not modify our  report. 27. As noted, we point out that SFA is attempting to address its human  capital challenges associated with the use of the new middleware  technology by leveraging the experiences from the banking industry as  well as acquiring recognized contractor expertise.  These are prudent  steps, but the adequacy of specific measures being taken both by SFA  management and its modernization partner in addressing workforce  management and planning needs go beyond the scope of this review;  therefore, we did not modify the report.   28. We modified the report to delete any reference to the availability of 24- hour customer support.
section_title: Related GAO Products
paragraphs: Financial Management:  Internal Control Weaknesses Leave Department  of Education Vulnerable to Improper Payments (GAO-01-585T, April 3,  2001).
High-Risk Series: An Update (GAO-01-263, January 2001).
High-Risk Series: An Update (GAO/HR-99-1, January 1999).
Student Financial Aid Information: Systems Architecture Needed to  Improve Programs’ Efficiency (GAO/AIMD-97-122, July 29, 1997).
High-Risk Program: Information on Selected High-Risk Areas (GAO/HR- 97-30, May 1997).
Department of Education:  Multiple, Nonintegrated Systems Hamper  Management of Student Financial Aid Programs (GAO/T-HEHS/AIMD-97- 132, May 15, 1997).
High Risk Series: Student Financial Aid (GAO/HR-97-11, February 1997).
Reporting of Student Loan Enrollment Status (GAO/HEHS-97-44R,  February 6, 1997).
Department of Education: Status of Actions to Improve the Management of  Student Financial Aid (GAO/HEHS-96-143, July 12, 1996).
Student Financial Aid: Data Not Fully Utilized to Identify Inappropriately  Awarded Loans and Grants (GAO/T-HEHS-95-199, July 12, 1995).
Student Financial Aid: Data Not Fully Utilized to Identify Inappropriately  Awarded Loans and Grants (GAO/HEHS-95-89, July 11, 1995).
Federal Family Education Loan Information System: Weak  ComputerControls Increase Risk of Unauthorized Access to Sensitive Data  (GAO/AIMD-95-117, June 12, 1995).
High-Risk Series: Student Financial Aid (GAO/HR-95-10, February 1995).
Financial Audit: Federal Family Education Loan Program’s Financial  Statements for Fiscal Years 1993 and 1992 (GAO/AIMD-94-131, June 30,  1994).
Financial Management: Education’s Student Loan Program Controls Over  Lenders Need Improvement (GAO/AIMD-93-33, September  9, 1993).
Financial Audit: Guaranteed Student Loan Program’s Internal Controls and  Structure Need Improvement (GAO/AFMD-93-20, March 16, 1993).
Department of Education: Management Commitment Needed to Improve  Information Resources Management (GAO/IMTEC-92-17, April 20, 1992).
subsections: section_title: GAO’s Mission
paragraphs: The General Accounting Office, the investigative arm of Congress, exists to  support Congress in meeting its constitutional responsibilities and to help improve  the performance and accountability of the federal government for the American  people. GAO examines the use of public funds; evaluates federal programs and  policies; and provides analyses, recommendations, and other assistance to help  Congress make informed oversight, policy, and funding decisions. GAO’s  commitment to good government is reflected in its core values of accountability,  integrity, and reliability.
section_title: Obtaining Copies of GAO Reports and Testimony
paragraphs: The fastest and easiest way to obtain copies of GAO documents is through the  Internet. GAO’s Web site (www.gao.gov) contains abstracts and full-text files of  current reports and testimony and an expanding archive of older products. The  Web site features a search engine to help you locate documents using key words  and phrases. You can print these documents in their entirety, including charts and  other graphics.
Each day, GAO issues a list of newly released reports, testimony, and  correspondence. GAO posts this list, known as “Today’s Reports,” on its Web site  daily. The list contains links to the full-text document files. To have GAO E-mail  this list to you every afternoon, go to our home page and complete the easy-to-use  electronic order form found under “To Order GAO Products.”
subsections: section_title: Order by Mail or Phone
section_title: Visit GAO’s Document Distribution Center
section_title: To Report Fraud, Waste, and Abuse in Federal Programs
paragraphs: Web site: www.gao.gov/fraudnet/fraudnet.htm, E-mail: fraudnet@gao.gov, or 1-800-424-5454 (automated answering system).
section_title: Public Affairs